Resolved
4 votes

From Ian Gotts: What comes first: metrics or process? Do you measure something and then improve the process...or you define the process which helps you understand the measures?

Tuesday, September 15 2015, 09:52 AM
Share this post:
Responses (17)
  • Accepted Answer

    Ron Evans
    Ron Evans
    Offline
    Tuesday, September 15 2015, 10:17 AM - #Permalink
    Resolved
    4 votes

    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.

    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, September 15 2015, 10:17 AM - #Permalink
    Resolved
    3 votes
    In principle: How do you know what to measure when you don't know what (and how) you do stuff? More practical: Bring both worlds closer together and eliminate metric waste...
    Like
    2
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, September 15 2015, 10:36 AM - #Permalink
    Resolved
    3 votes

    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.

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, September 15 2015, 10:39 AM - #Permalink
    Resolved
    4 votes

    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 :-)

    • E Scott Menter
      more than a month ago
      You scrambled my plans by beating me to the egg metaphor. I feel like such a... turkey.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, September 15 2015, 10:51 AM - #Permalink
    Resolved
    5 votes
    As success is built on measuring past performance any solution supporting business transformation must capture key metrics and enable rich analytics. This means that people doing the work have to be thinking about what to measure right from the beginning.
     
    Metrics cover the following:
    • Financial – Spend, Savings, Volumes
    • Efficiency – Revenue, Cost, Labor Intensity, Migrations, Cycle Time, Unit Cost, Transaction Volumes, Self-Service Volumes, Automation, Outsourced, Offshored, Shared Service Utilizations
    • Risk – Audit Issues, Compliance Issues, Not in Good Order (NIGO), Leakage
    • Satisfaction – Net Promoter Score (NPS), Complaints, SLAs Achieved, First Call Resolution (FCR), Quality, Call Abandonment, Customer/Stakeholder Satisfaction

    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?

    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, September 15 2015, 10:56 AM - #Permalink
    Resolved
    4 votes

    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.

    The reply is currently minimized Show
  • Accepted Answer

    Tim Bryce
    Tim Bryce
    Offline
    Tuesday, September 15 2015, 11:08 AM - #Permalink
    Resolved
    2 votes

    Neither - Information Requirements always come first. The problem is nobody knows how to define them anymore.

     

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, September 15 2015, 11:11 AM - #Permalink
    Resolved
    10 votes

    Interesting PoVs.

    Both Metrics and Process are very important factors for any business implementation.

    But, I presume Process comes First. The reasons as follow:

    • Every system that is built and which is a candidate for improvement or refinement - was formerly built based on some process
    • Without any Process - it is tough to visualize any business or real time (day-to-day life) functionalities
    • The system built on Java, .NET, Mainframe or a ny obsolete technology --> can be a candidate for better development leveraging a tool (when we use our BPM glasses and think from a process flow standpoint)
      • But, not to forget, when the same process was built earlier - it must have been through a Process Cycle, Requirement Capture, Visualizing functionality, Implementation etc
    • If we are not happy with the Data Statistics,Metrics, Performance, KPIs emitted by the current process or system - we try improvising the process to tame it and serve better (based on feedback mechanism)

    An Analogy:

    • Unless we start the ignition of the Car and set the Gear Box right - the car wont move forward
    • My Metrics for measurement can be to check the Speed/Milage, Fuel Efficiency of the Car
    • But, in order to get the desired data, I need to undergo through a defined process for - Driving School training, Get a Driving License, Well versed with the steps to be performed - to start the vehicle or change the Gear, when to apply brakes etc...

    "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)

     

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, September 15 2015, 11:17 AM - #Permalink
    Resolved
    4 votes
    Despite being an issue that can lead to both answers, first the metrics then processes and vice versa, I suggest first the corporate objectives and the related measures, then the processes designed to better respond to the range of metrics, otherwise we can fall into the extreme of drawing deviant processes of business strategy.
    Anyway, this question made me back to the times of the early Greek philosophers who discussed the genesis of knowledge, first we organized mentally and then we do (Plato), or we need to do first something to get this mental picture, and learn how to make better afterwards (Aristoteles).
    As the virtue is in the middle, I think the best is first prepare the objectives and define the guidelines of how to do, to avoid the chaos, and then do the processes, get the results to compare with what was planned, learn, and then do better, as continuous improvement cycle.
    Is like to define the sheet music of a song and give freedom to the players for variations without leave the song structure, which will lead to perfection with practise.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, September 16 2015, 02:06 AM - #Permalink
    Resolved
    3 votes

    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,

    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, September 16 2015, 07:59 AM - #Permalink
    Resolved
    2 votes

    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.

    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, September 16 2015, 01:38 PM - #Permalink
    Resolved
    3 votes

    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.

    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, September 16 2015, 02:47 PM - #Permalink
    Resolved
    3 votes

    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 reply is currently minimized Show
  • Accepted Answer

    Wednesday, September 16 2015, 11:39 PM - #Permalink
    Resolved
    2 votes

    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.

    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, September 17 2015, 01:57 PM - #Permalink
    Resolved
    2 votes

    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?!

    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, September 23 2015, 02:38 PM - #Permalink
    Resolved
    2 votes
    Neither. Because both are necessary to manage the work to achieve a particular goal. Without process, metrics are non-systematic. Without metrics, process has no goal (an observable and measurable end-result within a more or less fixed timeframe). Thanks, AS
    The reply is currently minimized Show
  • Accepted Answer

    Monday, September 28 2015, 03:58 AM - #Permalink
    Resolved
    2 votes
    Process - reasons is Every system that is built and which is a candidate for improvement or refinement was formerly built based on some process. Without any Process it is tough to visualize any business or real time functionalities.
    The reply is currently minimized Show
Your Reply

Join the Discussion

Want to join the discussion?

Login, or create an account to participate in the forum.

Top Participants

Dr Alexander Samarin
278 Replies
29/09/2016
David Chassels
270 Replies
29/09/2016
Emiel Kelly
223 Replies
29/09/2016
Bogdan Nafornita
210 Replies
29/09/2016
E Scott Menter
182 Replies
28/09/2016