We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion
BPM
user-pic

How important is continuous process improvement and what's the best way to achieve it?

Vote 0 Votes
How important is continuous process improvement and what's the best way to achieve it?

15 Replies

| Add a Reply
  • Process Improvement is integral, without it, there is minimal value in BPM itself. Business Activity Monitoring (BAM) is a key ingredient-- the ability to collect metrics, analyze process trends and patterns, and make key decisions on historical process metrics will allow businesses (note, businesses) to make decisions on how to improve their processes over time.

  • What Jordan said . . . Well, seriously how can you improve anything without a baseline and metrics to guide you?

  • Business Process Management is about making and keeping your customers happy by process. It's about using the process, not about having them.

    That's why the real value of BPM, to me, is what I call the agility cycle. And that is indeed about monitoring and see real live how you deliver all your promises to your customers.

    But what is a speedometer without a throttle or a break....useless.

    So it's about being able to change. This might mean giving people more authority, changing work distribution, changing priorities, changing business rules or skipping or adding steps because it will help you to deliver your promises.

    If you are doing this you are really managing by processes.

    Most see process improvement as PDCA. That is what I like to call the improvement cycle. Because this cost time it will probably be a project instead of daily routine. Based on information on process performance you decide to analyze and improve your process.

    But no customer will pay you to improve, so I always try to make processes as flexible as needed.

    So BPM means to me:

    Continuous level: Execute - Monitor- Adjust (in a cycle)

    And you can imagine if you have to change to often it might mean the process itself needs attention, so then we come in to the improvement cycle:

    Measure- Analyze - (Re) design - Execute

    But that's just common Process Improvement. It's about execution, seeing and acting.

    So improvement belongs to BPM as tulips to Holland.


  • Throw away the rule book!

    Yes, in order to improve processes (improve productivity) you must have tools that let you monitor and then improve *OR* improve and then monitor. This is how you create a continuous loop. Here are some terms I like, from being in this space for many years;

    "Why monitor what you can't improve"
    "We don't want to guide people through inefficient processes"
    "Minimum Improvement Opportunity (MIO) is the efficiency gap between your best workers and your average workers"
    "WIthout Desktop Analytics (User monitoring), I hadn't realized how little we knew about what our users (biggest expense) actually did"

    So, while I am in the business of improving processes undertaken by workers (users/agents/customer service/tellers/back office), I am also in the business of monitoring how they work, down to the most granular level. This is achieved by the next generation of "Desktop Analytics" and "Desktop Monitoring" and is how we sell the, "Continuous User Process Improvement" story, every day.

  • BAM, Scorecards, remnants of a long gone era.....Continous improvement isn't important anymore, it's too incremental.

    Something which struck me several times last week (apart from the usual project headache) was the obsession with continuous improvement and incrementally forcing change on the business ad-nauseum till it becomes almost like a corporate Groundhog Day. We have Deming, Rummler Brache, Six Sigma’s DMAIC, LEAN, they all offer a method and practice of improving the efficiency and quality of processes then loop back in on themselves with the typically generic ‘more of the same’ cycle. The trouble I have with this is that the feedback mechanism is broken and what really happens is that another round of incremental improvements is sought as part of the next project, and the next, and the next. As soon as we implement a rigid cycle as a methodology we lose the ability to continually adapt and change. Sure, the measurement and management information stream of data allows us to monitor and react to the change, but we interpret that information according to the restrictions imposed as part of the methodology.

    At no point in these cycles is there a step that says, “stop hacking the process to death and just start over from scratch”. BPM becomes harder to sell and explain the ROI when you reduce the cost efficiencies with each project to the point they become insignificant and the project more costly than the return. But more often than not the business are inclined to walk away and admit defeat (or success, depending on your view of the pint glass) that the process cannot be improved anymore, so it must be optimum.

    We need to teach organisations that it’s not bad practice to throw something away entirely in order to achieve the greatest gains. We need to educate the leadership that the retention of a process out of some nostalgic desire and misty eyed belief it works in today’s context is wrong and that it’s ok to say goodbye to a beloved one and make way for a newborn.

    What’s more, we as a discipline need to adopt the same approach, that it’s ok to start over and create methods and tools that are context rich for today’s adaptive and social enterprise, not keep hold of the old ways because they remind us of fuzzy and warm times of old.

    The process of process improvement is defunct. Roll a 6 and start again.

  • And how to do it, comes to a lot of education.

    My first step is always making everyone aware what BPM is about. It's about delivering results with goals attached to that. And we, as process people, use the process the deliver those results.

    Yes, USE the process. So don't start improving a process out of the blue, but teach employees what the (customer) results are that need to be delivered. Teach them what are the aspects that make up a good (what is actually good?) process.

    Not a process room with analysts. No, a company with process aware employees. And than you will probably experience that process manager is a role, not something on a business card.

  • Here's the thing: Once BPM means using technology (whether it's a BPMS or not), continuous improvement and agility means releasing new code or new configuration.

    Most organizations should to start here. Find a way to speed up their release cycles, to work on smaller iterations and to compress their entire process development life cycle.

    If you can do that, then usually you will see a virtuous cycle develop. People will see their ideas implemented. They will have confidence to suggest experiments that might not work because the cost of 'being wrong' is minimal. The culture will start to fall into place. Changes won't get held up in the search for perfection since people will have faith that another release is coming.

    It might sound easy but for many organizations it runs contrary to many of their current IT, compliance and financial procedures. They simply aren't set up or empowered change the system on a monthly - let alone a weekly or daily basis - so people fall into the trap of trying to squeeze 1 more feature in ...

  • Theo really nailed this. It's not about process improvement, it's about process change. The time and motion studies of the early 20th century seem quaint now, and for a reason: in most applications, saving 8 seconds, or 8 cents, doesn't justify the continual analysis and readjustment that would be required to identify the opportunity in the first place.

    Changes in regulations, customer expectations, and competitive products: these are what drive process change, and they are neither incremental nor predictable. If your BPM solution can't support a rapid cycle of destruction and re-invention, you'll find yourself a receding speck in your competition's rear-view mirror.

    • Wasn't your grand grand grand father called Darwin?;-)

      'It's not the fittest who survive, but the ones most adaptive to.....'


      So inject some agility DNA in your processes!

    • Actually, I know a company that saved 11 seconds on every process that resulted in a $25m+ per annum saving. Admittedly, it was a large contact center but it only took 12 weeks to build the improvement (Desktop Automation)! I have another customer that built an automation in just over 10 weeks that saved over $1.5m a month - 50 people effectively doing the work of 300 (thanks to rapid improvement and automation and of existing processes).

      But on another note, to me, "Failing Quickly = SUCCESS". It seems a lot of tried and tested REAL strategies that worked in the past have been lost in a myriad of 3 letter acronyms!

      What happened to Rapid Prototyping? Build something quickly, try it, (with real people) and if it works move on. Rapid Prototyping is often the best way to get buy-in, since you "see" something OR you see what you didn't expect! This leads to the best Continuous Process Improvement I have ever known.

      • But probably you have it also seen the other way round: Investing in new systems (even with RP) and coming to the conclusion that process performance (and as we all know that's not only about costs) didn't improve.

        That's why it is so important to know the characteristics of a process and it's result.

        Automation will most of the times saves most in straight through, production like, processes where a lot of process instances take place (multiplied by those 11 seconds is indeed a large benefit)

        In more knowledge processes (some call it case management) straight through automation might not have that large impact. Maybe a good improvement might then be education of employees or better information supply.

        So be aware to see improving a process not as clicking setup.exe and not to threat every process the same.

        What works for a certain type of process might be a stupid decision for another.

  • Continuous improvement in organizations by nature is disruptive; and this is how it should be. This avoids the "one more feature here, tweak it there" approach that burdens processes through increment instead of innovation. Continuous improvement is important because it ensures the organization is adapting and in the best case, is itself the catalyst for market change. This creates competitive advantages that produce differentiated profitability.
    One of the best ways to encourage and achieve innovative improvement is by seeding the organization with a broader skilled team; silo-breakers with high EQ (emotional intelligence) who are used to working in fluid environments and, as Emiel noted above, are not functioning to a title on a business card, but to defined end goal focused on customer retention, satisfaction, expansion and through this, profitability.

  • If you are dealing with a large scale, where every little bit helps, traditional continuous improvement can still be a good ting. Don't forget improvements can be more than labor; there can be material cost improvements.

    But indeed I have seen cases where constant improvements become such a pain that the change management aspects cost more than the savings from the improvement.

  • What I also try to make clear at the start of any process project is that the characteristics of a process are very important to know. Why? Because then you can understand what the impact of change will be.

    For example if you have a very standardized process with people doing their task and more directive process steering, a change from the outside will lead to a traditional process improvement project.

    I use a train metaphor for this. A train is a very reliable way of transport (good if you want the same process result for years). But the route is completely standardized. If something happens (broken rails, snow), a train cannot adapt easily (it's not agile), causing delays. Asapting to this Change in the process will be a hard job (building new rails, faster trains)and cannot be done on the fly. So that must be a large project.

    A car is more flexible and is my metaphor for processes with more employee empowerment and ability to adapt during execution (the trip). When there is a traffic jam, you can take another route because there are more roads to take. When you are late, you can speed up (of course there are always law restrictions) But it is more flexible. So during the process you are able to adapt to changes from the outside. More agility to reach your destination (process result)

    The most agile process is the one with an unknown route upfront. Only a destination and the time you have to be there (the process result with it's goal). So depending on this goals the employees (some with the role of process manager) decide what will be the best thing to do (what road, what type of transport). This is very flexible and can adapt to change easily. Probably hard (or scary?) to manage, but not all processes need this.

    That is why I like to start with a 'process characteristics map'; .

    Depending on the needed flexibility we decide on the needed characteristics (workflow, people, systems, information supply, steering information etc) for execution of the process. Because that's what it is all about : execute the process to deliver the desired results.

    If the result must be the same for years, you can take the train.

    If the result and it's goals for can change often you have to be more flexible and need a car, bike and airplane.

    So change might not have the same impact on every process.

    It is about preparing your processes for the change they will have to cope with. Then you are really using your process to make your customers happy.

    Have a nice trip!

  • Process improvement must be high up the agenda for business in these tough times. As far as business is concerned this is about efficiency at the front line and recognising that people are any organisation’s greatest asset. This puts the BPM mindset to the fore. We have a customer that embarked on this over 10 years ago and the model that has evolved is interesting showing what can be achieved working closely with users.
    The first build took place using "agile software" with iterative build working direct with users. Once up and running we found ourselves becoming mentors to users to help with the required minor changes, some undertaken themselves with close guidance. Over the years larger changes were required for example inflation proofing payments had been undertaken via a spreadsheet but it had become time consuming and prone to errors so we were asked could it be "automated" into a process which was duly delivered saving several man days a month with no errors.
    Looking back the statistics tell the story. Over 10 years there have been some 3000 changes in one form or other to the system and all driven by users requesting improvements. In a recent benchmarking exercise with similar organisations its cost to money distributed ratio was less than half that of any other body.

Add a Reply

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT