Are you data-oriented or process-oriented?
Yet another entry on a topic that’s been kicked around in my head for several years, but which seems to come up every week or two. It’s the recognition that there are two different types of people: data-oriented people and process-oriented people. Okay, that’s a gross oversimplification. There are loads of people who are neither. And, there are people who can manage to approach a problem from both perspectives, but those people tend to have a bias one way or the other.
This isn’t an idea I came up with. A business analyst at National Instruments named Drake Botello actually first explained the concept to me. Drake started his career at National Instruments working on various internal applications. When I got to know him well, he had long since switched over to supporting the company’s data warehouse. On the app side, he had to be more process-focused. On the data warehouse side, he had to be more data-oriented, and what he found was that he often ran into challenges when working with business analysts that supported transactional apps that generated data that wound up in the DW. Drake formed the “data vs. process” theory from those experiences.
So, what does it actually mean?
Well, a process-oriented person expects any system, first and foremost, to support the process it was designed to support in the most efficient manner possible. He views data as a natural, incidental byproduct of the process — it doesn’t need to be thought of beyond what specific reporting capabilities are needed to support the process: all of the data comes from the process, so if the process is good, then the data will be good.
A data-oriented person, on the other hand, sees data design, data capture, data integrity, and data analysis as a critical part of any process. He feels it is perfectly acceptable to incorporate additional steps in a process as required to ensure the integrity of the data that gets generated.
Both of these are perfectly valid perspectives. While I don’t have any way to prove it, my sense is the process-oriented perspective outnumbers the data-oriented perspective by 5-to-1 or so.
This perspective can and does cause problems. My earlier post about operational reporting (not the title, but that’s the meat of the content) comes at this issue from a different angle by pointing out that marketing automation and sales force automation tools, which are geared towards driving very efficient, repeatable processes have a bias towards operational reporting. A data warehouse is just the opposite — it’s geared toward metrics reporting and analysis.
These different perspectives are spawned from different legitimate needs. Still, you don’t want a data-oriented person designing a transactional system any more than you want a process-oriented person designing a data warehouse — they’re both liable to see their assignments as relatively straightforward…and then thoroughly muck them up!
I’ll give one simple example of how two people might approach a contact management system. Contacts’ job titles change over time, right? So, when that happens, how should the system handle it? A process-oriented person may say the job title in the system should be overwritten with the newest job title. He may even pat himself on the back by recording a timestamp as to when the title was last updated (“for analysis purposes.”) But, he will likely say there is no need to retain the previous job title. What use is that? A contact management system is for managing contacts and communication with someone. Since you only really care about the current job title — that’s what you would want to use in any correspondence — the old data is old and not of any use.
A data-oriented person, on the other hand, would demand that a historical record of the person’s job title over time must be maintained and accessible. What if you want to analyze which job titles you are most effective selling to? if you sold to the contact before his promotion, but you don’t know what his title was at that point, your analysis will be severely hampered!
I’ve got a definite data bias, as you can probably tell from my tone. But, I do realize that data requirements can add some very real complexities and difficulties to transactional processes. The best situation is to have both perspectives at the table and collaborating.
Of course, there are also lots of people who don’t really think “data” or “process” at all. This is probably the overwhelming majority of the human population. But if you’re still reading this entry, you’re not one of them!
