In a former life as a chemical process engineer, the two would typically be developed together, as metrics and controls are absolutes for manufacturing efficiency, and particularly for safety. In business there's not so much discipline in terms of formally defined processes, but you will rarely come into a situation where business processes don't exist, regardless of how dysfunctional they may be. For me, some sort of metrics should be put in place before improvement, if for no other reason that to set the performance criteria for improvement projects, understand the potential benefits, and know what success should look like. This is an integral part of most improvement techniques such as lean sigma. Otherwise, you don't have a compelling reason for improvement other than anecdotes.
Having a baseline is essential. As my first boss was fond of saying, "if you can't measure it, you can't manage it." Transforming an organization through the use of autmation is difficult. Change is hard for humans. If you can celebrate the victories, if you can show quantitative benefits it really helps in winning the hearts and minds.
We recommend identifying the key performance indicators (KPIs) of your business (3 to 5 per team) and making sure that your automation delivers those numbers by having them designed in from the outset. As you do that you must gather the current state, the baseline, so everyone can see the improvement as it happens.
As Walter suggests... It's often necessary to start with Process Discovery... and that gets us into "Chicken and Egg" territory.
Asking people "what's the process?" is generally a good place to start, but then we have to verify that the process is "what they think it is"... and that generally involves metrics in one way or another. What a tangled web we weave :-)
For example, Insurers measure turnaround time (TaT) for key transactions such as Claims. They want to understand the average cyle time to complete an end-to-end claims transaction (first notice of loss to payment). TaT is calculated by dividing the sum of time elapsed to process a claim by the sum of claim transactions completed. BPM-based systems track this data at the process level and form level. Through the process engine solutions capture who does what at any point of time and how long it takes. Through the form, solutions capture what data was entered (claimant, product, channel, incident, location, etc.).With this information Insurers identify issues and bottlenecks. Then they determine ways to improve operations through changes in process, systems, and personnel.Before starting any project, make sure you first identify key metrics and define standards of measurements. Capture the KPIs in your workflows and forms. Create canned reports and domains where data can be sliced and diced based on line of business, geography, demographic, and product line.
So think about metrics from the beginning. What do you want to meaure? Is it defined? Do you have the means to capture it? How do you want it displayed? Who needs to see it? How will it help you to make changes? Can those changes be made easily?
In theory, one should know key process measures (and metrics, and indicators too) at the process analysis phase, i.e. before process design, not mentioning implementation.
In practice the whole understanding of what the process is and how wide it spans is often fundamentally broken at the beginning of the project so it'll change on the way. (Or better to say - it must change for the project to be successfull.)
So there may be a temptation to start the project without defining what the good process is. This is very dangerous indeed for a process professional - people become accustomed to improvements very fast so there is a huge chance they won't appreciate what you did. They already forgot what it was like at the beginning!
So you must ask the project sponsor the simple question at the start of the project: "How would you know that the process has been improved"?
The answer isn't that simple in most cases and it'll probably require significant efforts. People sometimes go mad at this point - "are you kidding me?! Am I that stupid to not being able to see what's wrong and what's right?" Be patient and insist and they will give the answer.
And by the way, it isn't necessary for the measure to be qualitive. Once in my practice the project sponsor said: "I'll know the process is good if project managers won't chase me like they do now." And we were pretty fine with this "measure". So I personally don't buy this "can't measure - can't manage" mantra. Not literally at least.
Neither - Information Requirements always come first. The problem is nobody knows how to define them anymore.
Both Metrics and Process are very important factors for any business implementation.
But, I presume Process comes First. The reasons as follow:
"Process helps in realizing / visualizing a Business Functionality, but Metrics helps is enriching it and making it better"
A process need not be just a workflow defined and designed in a flow chart or modeller - it can be the set of steps an activities performed to achieve a business functionality. Yes these related steps -> can be a candidate of a structured/streamlined process when we put on put BPM Glasses and visualize it as a Process Flow
Process helps in Designing/Building a Business Functionality and Metrics helps it Adopting it!!
(I can build a process which has a screen rendering time of 10 minutes, which is right as per the PROCESS and functionality - but to be adopted by users with a response time less than 5 seconds(METRICS) - it has to be Modified/Enriched)
When you are serious with your customers, you can't see process and metrics as something separate. A process is 'the thing' to deliver what you promise.
So, somehow you have to know if the process performs or not. That doesn't have to be fancy BI tooling. It can also be a call to the customer to ask if everything is fine (aren't that the metrics in a restaurant?)
Besides that you have to be aware that, in process management, there are metrics on different levels:
1. On case level (how is this case doing?)
2. On execution level (How many cases are in process currently and what is the status?)
3. On process level (How did this process perform the last half year)
In BPM, I see a lot of focus on number 3. As this is just used for traditional PDCA, I call this 'lockerroom talk' . After you played the game, you'll take a look how it went. 'Oh damn, we lost'
So, I am a bigger fan of 2 and 1, which, I think, is what process management about, Knowing what is going on with all the cases that are in the process at this moment.
But, what is a speedometer without a throttle or a brake? Useless. So if something is not going well, you must be able to act upon it, otherwise those metrics are only frustrating.
And to be able to act, you need to incorporate the right level of flexibility in your processes. So, there we have chicken-egg again.
Wait, not completely. Because processes are already happening at this moment. Cases are already processed. So, to answer the question, I would say metrics to show how well it is going. Because metrics (on all above levels) are just part of a good process,
To get real time feed back on activity as people and machines do the job requires such processes to be "digitised". To achieve this needs articulation and direct build of the process that will deliver required metric data which will both encourage empowerment and continuous improvement. So logic suggests process first followed by metrics that support better processes; they are or should be intrinsically linked and both important.
I'd like to present an analogy that I find interesting: when the metric goal forces to automate the process.
It is the political promise a good example: We will reduce the elapsed time for XYZ process to 48 hours.Usually that promise has a little or nothing to do with the capacity, business requirements, or any desired competitive advantage. It is set as a goal, to highlight an improvement in how a process is run.
The magic happens when answering the "how". How do we complete that XYZ process in less than 48 hours?. And then, the process come. But not just the standard process, it probably need to be re thinked and redisgned to meet that politically promised goal.
In sum, in this example, the metric comes first, and the whole process should be designed to meet the goals.
Process or metric first? Sort of like chicken or egg first.
We know they really they evolve together.
For both known commodities and for new products and services that need new processes.
Except however we need to consider economics and competition.
In a competitive market (and other external measures can apply to non-market activities such as government services) the KPIs are the gating factor to whether you get to play or not.
So by all means be creative in how you build a process. And maybe even move the needle on industry metrics.
But you work inside your ultimate "metric", which may be your stock price, or at least your profit margin. And you also work inside accepted industry standards and inside the envelope of tacit knowledge that is not codified.
In an efficient market there should have been enough competitive pressure to ensure that all surviving processes are minimally efficient for the job. (Although as Bogdan Nafornita has stated in another BPM.com comment, there are lots of niches where markets aren't competitive.) Aberdeen Group publishes analyses which categorize industry sectors by how well good work processes have been adopted. ranging from "best-in-class" to "laggard". It seems that it takes quite a while for efficient markets to winnow out the laggards.
The interesting thing is not which comes first. The interesting thing is what happens when you have your metrics and your process and then apply BPM technology. BOOM! A whole new class of metrics, and an entire new way to think about process. This is why surprisingly few of the traditional process improvement folks have successfully made the leap to BPM: their methods simply don't translate well to a BPM-enabled environment. Which is a shame, because we can always use more people who have spent real time and effort understanding how their business really works.
Lean was the inspairation for Lean Startup. And the core of this is the Minimal Viable Product. A product designed to harvest data to direct improvements, rather than creating a "perfect" product first, then discovering half the feautres you'd expensively designed in lie there unused, while there is a clamour for features you hadn't even considered.
Minimal Viable Process should come first - designed to harvest metrics, collerate oceans of rich data and rapidly re-iterate into something more powerful than one person could ever have envisaged. The key is that the metrics must come from the process customer - effectively involving them in the design process - rather than internal prototype testing.
So you create a process to get the metrics, which you then use to create the process. All clear?!