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

What is the key best practice for designing efficient processes?

Vote 0 Votes
Connie Moore has an interesting excerpt on her Forrester blog where she calls for the need for a scientific approach to designing processes.  In your opinion, What is the key best practice for designing efficient processes?

12 Replies

| Add a Reply
  • Peter - it should be interesting to see what responses you get. But before you get started, I would argue that it is not so much efficient processes that will get people excited - it's effective processes. How do you carve up a business domain in order to get the processes you need (rather than the usual proxy for the org chart which is the processes you probably have today).

  • Asking lots of questions and listening very carefully!

    More often than not users don't know every activity and associated business rules to a process. They know bits and pieces. So it is crucial to talk to many users, and better yet many users in the same room, to understand the overal process landscape and then how to make it better. As the team agrees on flow a developer should become involved to ensure the flow is technically possible and best suited to business rules and integration realities.

    Just last week I joined a group of 12 business users from 8 different countries to design and standardize a regional HR process. We mapped the process directly in a BPM product using BPMN. The act of mapping the flow itself helped business users to discuss different nuances among countries and agree to standard business practices. My colleague helped the team understand how the tool could support the overal solution as it would evolve for map to web-based app. The best part about the meeting was to watch users take ownership of the process. They now feel that the resulting application will be theirs, no IT's.

  • I agree with Derek. Efficiency must not be your main goal. The most efficiently used road is the one with a traffic jam all day.

    But it is not about the road, it's about the car with it's destination.

    So when desiging a process, start with it's destination; it's result. Then wonder what goals do apply to this result. And that is depending on your organisation strategy. It might be quality, it might be speed, it might be cost. Everything in the process must support this goal. And ofcourse you can do this as efficient as possible, but don't let efficiency be your main driver.

    Because then you might end up doing the wrong things very efficient.

  • Perfect article and the epitome of what's wrong in the BPM and Process industry today. Since when does the "science of systems" dictate how a business process should be designed. Why do we need to complicate the methods around business transformation and improvement with science ? Only reason I see is to keep the status quo and old ideals alive from the 80's and 90's. The article actually reads more like a sales pitch than insight which is unfortunate.

    It's not so much one key practice, but an amalgamation or hybrid of ideals. Start with that old firm favourite, the Customer and what they need from the process, then work back to how best to fulfil that desire.

    Unfortunately a 5 step process will become a 25 step process due to regulatory constraints or other factors but it's the flow and the experience perceived that's important.

    Ask yourself, "When was the last time I actually felt good being involved in a process ?" - you might find it has little to do with straight through processing and more about the experience and engagement.

    Connie makes a statement in the blog:

    "Fine-tuning or continuously improving your way to a level of operational excellence that makes a dramatic difference in this economy is a huge effort and may not yield major results. But trying to transform a process — or better yet, transform the business — is an even bigger undertaking, with significantly more risk involved."

    Partially true. Fine tuning won't achieve operational excellence or a dramatic change because of it's very nature in that it's just tweaking something ad infinitum. Unfortunately, also trying to transform a process or business using archaic methods like scientific "systems thinking" or Six Sigma which no longer fit in today's fluid economy and social context will guarantee organisational disaster, where the only major result is another bankruptcy....

    Derek said he was interested in opinion. There's mine. Think different. Not backward.

  • Not sure that current best practice is an endorsement for BPM, so here are a couple of thoughts off the beaten track:

    a) Tape two signs to your monitor: - Who's the customer of the process I'm designing? - Why me?

    b) Don't focus on the control flow - unless you're planning to also seperately design communication and short-cut processes. Rather design from a personal perspective: What would I need to do, with whom would I need to communicate?

    c) Don't pretend that your process will be there for all eternity. There have been numerous variations in the past and anyway, the next change request is just around the corner

    d) Keep in mind that designing for greenfield is the exception. You've got to work with what's already there, systems as well as work habits and attitudes. It may be good but if the process is not taken up and acepted by employees it's actually ... not good.

    e) Keep in mind that the designer is no more than a facilitator. The real subject matter experts are usually to be found outside a design project because they are indispensible.

    f) (Do I need to apologize for the following?) Ask yourself if you are designing how a part of the business should work or if you're just delivering content to justify buying BPMS licences. Either way, focus on what's intended and stick to it.

    g) Test, test and test again. Will this work at all, will the process work the way we want it to work, are all the assumptions behind the design realistic, what are the limitations of the process, how does it impact other processes?

    Btw, I could help with the last one :-)

  • Subject matter expertise. A variant on Garth's response. Find that individual who's been with the company twenty-five years, who's had every job, done every function in the company, knows all the "in's" and "out's," and plumb the depth of that person's knowledge. At that point I don't care what methodology, technology or platform you use - assuming, of course, you know the best practices of your own preferred platform of choice - I'm after the information in that person's head. That person is worth their weight in gold and upper management should say "Functionally, this person knows what we need and speaks for us in that regard." Throw them in a war room with one good PM, one good solutions architect, a small team of crack developers and you're off to the races.

    Cheers, Pat

  • Oh, I forget to mention...

    h) Stating that your process design conforms to BPMN, epc, BPEL, XML standards doesn't make the content of your design any better (or worse). It just proves that you've read the book and done the training. Now focus on the business!

  • A truly scientific approach to process design would likely result in both more effective and more efficient processes. But the key here is that the BPM professional must approach the process as a scientist would; by asking questions, and lots of them, challenging assumptions, eliminating noise, preconceived standards and even process boundaries before evaluation of any change or process intervention. A client once told me that customer "delight" for the firm would be achieved or enhanced if service agreements could be drafted, reviewed and delivered without error or omission within 24 hours of securing a customer engagement. Rather than proceeding to study the existing contract process, draw the workflows, solicit input from stakeholders, etc. and design a process to get accurate agreements out more swiftly, I asked why customers indicated this. Did they really want a fast, accurate agreement? If so, why? Turns out that what customers wanted was not a paper or electronic document, but responsive service. Other vendors had taken days to come out and make the initial assessment that served as the basis for swift issue resolution when systems failed. What the customer really wanted was the assurance that the client would be ready to provide system support rapidly. The process needing study and redesign was very different from that which had been originally identified.
    As Connie notes in her blog, "we didn't understand the situation well enough the first time" to design the system perfectly. Starting with why and pursuing a series of corollary investigative questions serves the BPM pro well in understanding the system and then designing efficient and effective processes to produce results.

  • The single most important best practice is to "Know your Process Design Lens".

    As a designer, you would need to wear multiple lenses to fully understand what effectiveness and efficiency mean for a particular process. At its highest level, there are three types of lenses - Customer Lens, Employee Lens or the Shareholder Lens. You need to prioritize these lenses before you embark on process design, and then use the lenses in that priority to ensure that the resulting design is effective and efficient.

    The priority of the Lenses is determined by your objectives - be it improving customer experience (Customer Lens), or enhancing employee productivity (Employee Lens), or boosting profitability (Shareholder Lens).

    Knowing your process design lens is the critical first step. Once you know it, you could apply any structured or scientific approach to process design. But if you get it wrong, no amount of rigor in your scientific approach would help achieve results.

  • One of the most important factors is to make sure you involve all your stakeholders. Ensure you involve those who are most affected by the process (Users). Visualize/draw out the process to ensure people can see each step. I have found that people can much more clearly identify and relate to a process when then can see it drawn out on a whiteboard or the like. When you are designing the process with the stakeholders, ask A LOT of questions, often people don’t know what they don’t know or they don’t think about the little things because they have never had to really think it through in this level of detail and explain it to someone that does not know the process. When building out the first version of the process don’t try to be perfect. I have seen people get too bogged down in trying to create the perfect process they end up making it too complicated and cause too much work for those using it. Thus eliminating the efficiency they are trying to gain. Once you build out the process use the tools as they are meant to be used by gaining insight into the processes and striving to continually improve over time. There is no such thing as the perfect process.

  • The key best practice for designing efficient processes begins with analysis and modeling. The idea is to provide an understanding and create a view of processes, to raise process improvement ideas.

    “Visibility is critical: "If you can't see it, you can't fix it. You probably don't even know you have it." Gartner Fellow and Managing Vice President, Daryl C. Plummer

    I noted additional best practices in my blog http://wp.me/pO8n7-4p .

  • Firstly, great quote on your post Stephanie.

    I would agree with others that the objective should be effective, not efficient, processes.

    The key best practice is to fully understand the business. Understand it at a high level, then keep drilling down, breaking into more manageable clusters, the divisions and detail of the business. Take the ideal and the current operation, determine the realistic and from there foundation processes can be built. This needs to be refactored periodically so that you have current visibility. The key (ideal) components for this are communication at all levels and a dedicated buy in from stakeholders.

Add a Reply

Recently Commented On

Monthly Archives