Goals should come before either ;-)
There's always a problem to be solved, and the nature of the problem will tell you whether data or process should be the primary concern.
Yes, sure. First, business objectives, then the processes to achieve the objectives, and then, required data to be treated along the processes. This approach based on a process architecture before going to the operational processes, allows us minimize overlaps between processes activities and related data, which means more efficiency in development time of enterprise applications, and also in business operation time.
Scott makes a good point. By better understanding process and the people (role and responsibilities) associated with it you will better recognize and grasp the data needed to both complete the process and then improve the process/operations through reporting and analytics. Even experts often don't realize the potential of BPM-based solutions for reporting and CPI. They have never had access to real process data (touch time, turn around time) coupled with form data to fully improve costs, quality, and speed.
Process and data go in tandem. First, you have to define information requirements which drives both.
I hope that architecture comes first before process and data. Then all depends, as usual.
What do you need in order to cut a tree? Probably muscle power and an axe (pre-industrial phase for example sake...). But probably also some knowledge so you know how to start cutting... And knowledge about which tree and which wood... The question is therefore a bit more challenging than you would expect.
The how implies process. Doesn't matter if you're a complete beginner or seasoned lumberjack. The beginner lumberjack needs more information on the how than the seasoned one (hence why managing process knowledge is a tough gig :-)). Both need however information on tree thickness, amount of trees to cut etc.
Data could be 50. But that doesn't do anything for me unless I have context. Context is: thickness in cm of the tree or the amount of trees...
So... I think process is a good starting point. However you cannot do without data. And as the axe becomes blunt over time, I probably need KPI's here... In the right context.
This is a chicken and egg question. It starts with management setting goals. Hopefully they look at data, but they might use a scenario comparison process to do that. Processes and people need to be created to attain the goals, but data is leveraged and checked to see if goals are on track. Events and busines patterns are found in data, analyzed and in turn turned into rule and process adjustments that are either emerging or humming along. What comes first? They work together and are codependent. I've played the role as a process bigot, a rule bigot, an algorythm and a data bigot. Alone they are beneficial. The true multiplier effect takes place when they are used together :)
(this is a 1:1 copy of my answer to Scott's original post)
Shocked by how many people start with goals.
Think about how a company starts.
First thing is something sells.
Then we work out how to make more of these sales, cost-effectively.
A company is born - a system for repeating something we have seen work.
Systems are always paramount.
Somewhere along the line, managers - people hired to manage existing processes - decided they knew better.
So they created goals - their bet on where the company should go and what it should do.
If you redesign the company's processes to suit these goals, you are buying into that manager's bets on the future.
The key difference is that systems adapt, goals usually don't.
This, of course is where data comes in.
A system is as good as the data that drives it.
Every step produces data. In wasteful systems that data is discarded.
But in a good system, there is a virtuous loop - the data produced by the system is used to make a better system.
That system has some assumptions at its core - that its end result is to produce more sales, more profit or more customers (often conflicting).
But a goal is a whole set of assumptions put together into a single view of tnhe result. It has multiple points of failure - each assumption could be at least partially mistaken. Often a minot error at one point causes a catastroiphic result. And often the frigging of the system to keep it on track takes most of the company's effort.
Think systems - not goals. For goals, read assumptions. And data is the rock they ar all built on.
In the Lean BPM philosophy the answer is 'neither'. In the lean BPM philosophy, business users will run 'processes' without thinking in formal terms like processes and data. By the time they start noticing recurring patterns, their existing 'processes' will have both process-elements as well as data-elements. If they go back and look at their proto-processes in retrospect, some would have started out with data and some would have started with 'processes'.
If they do want to do some up-front design, then in that case, the answer would vary depending on circumstance. Some processes are more naturally modeled with a data-first mindset and some with a process-first mindset.
As discussed over Twitter as well, yeah, imho process and data are inseparable --> just like so many other applied business constructs.
Sure, if you look at the implementation methodology anything that floats your boat is your right answer. I've seen it succeed both ways so I don't really have a preference.
Process discovery unveils the underlying data model but in so many cases it is the data model instances that lead your to-be process to branch out into unforeseen directions.I just do both at the same time.
Perhaps it's not a coincidence that the "data first" posting which was the (negative) inspiration for Mr. Francis' excellent original question, came from IBM, IBM of course being the alma mater of relational database guru E. F. Codd.
I concur with multiple comments that suggest data and process must go together, although from a technical perspective, data is logically prior. And if it isn't, bad things happen. The importance of data versus process (versus code) is even a sociology-of-IT question when, bizarrely today, relational database technology is not a given, but a question.
From the sales perspective I will highlight the question of business case. Data and process models are infrastructure. There's no business case for operational infrastructure. No one really wants to pay for data modeling. Both data and process are about modeling reality; but before reality can be modeled it needs to be learned. Who will pay for learning reality? Lots of times it just doesn't happen.
So given such challenges, how do we assure ourselves that our applications and our bridges don't fall down? As has been suggested, the devil is in the details. The win is sellling a project which enables incremental data and process learning. On this basis, it's possible to deliver new capability continuously, and then the funding will also be assured.
Data begets Process begets Data. But, the process may not produce any data, of course not considering meta data about the process itself.
Process begets Data begets Process. A process may not necessarily produce data, that is, a process may not beget data.
This would suggest that we are not in the typical chicken and egg scenario. Too many ifs and buts.
I think processes and data influence each others.
If your approach start with a process you will be able to:
If you focus first on data, then you will be able to identify processes:
So I would definitively suggest an iterative approach to build a solution in which processes and data are aligned.