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

What Best Practices Do Companies Need to Take When They're Just Getting Started With BPM?

Vote 0 Votes

5 Replies

| Add a Reply
  • Companies have many processes - some formal and some informal. Maybe only 20% of them are high value processes [the old 80/20 rule]. Start with one of those high value processes. Really understand [analyze] the process - look to remove non-value added activities; look for ways to make the process more efficient [design]. Document the new process and/or implement in software [construction]. Roll out the new process [implement]. Measure the original process and measure the new improved process. This is the only way that you will know if you have actually improved the process.

  • The stakeholders in the company understood and identified why they should undertake a BPM strategy and the potential of BPM. This is an important best practice. A good understanding of BPM improvement capabilities, BPM automation, change through BPM, and who benefits from BPM is critical. Second best practice is to identify the process efficiencies - and optimization potentials. Caution! Sometimes companies spend enormous amount of time and energy modeling and analyzing – without showing value to the stakeholders. I have seen too many cases of this (pure modeling and analysis) – all for reasons that sound reasonable; but almost always showing little or no value. So the third best practice is showing results quickly – with some tangible ROI. If the company is just starting with BPM – there will most probably be skeptics. Like most other new solutions you need to show results – through BPM automation.

    One technique that has worked well for many companies is to start with a Risk/Business value matrix and develop potential improvement BPM projects as an ordered and prioritized list. Then form those you can pick the ones that will quickly show the greatest value to the stakeholders. Ideally you should be able to show the before and after BPM efficiencies – once the solution is operationalized (hopefully within a 30 to 90 day window).

  • I agree with Scott on focusing on the high-value business processes to start with. In addition to that here are some additional practices:

    - evangelize process management and BPM techniques (modeling, runtime execution, state management, reporting, etc.) with both business and technology stakeholders.
    - Business partners need to understand how BPM can introduce change (automate processes, reduce manual efforts/errors, enable organizational agility, make IT systems more transparent, extract business rules and manage them outside legacy systems etc.)
    - Technology infrastructure needs to be thought through to support enterprise SLA requirements (connectivity components, availability etc.)
    - Developers and technical leads need training on BPM tools - how to think in terms of process flows, how to design flows using a modeling tool, etc.). It is also important that they understand when to use BPM tools and techniques. BPM isn't appropriate for everything so guidelines/principles in usage should be communicated as well.

  • There are so many best practices to consider. But I think if you are truly "just starting" with BPM, it is important to coalesce a core, multi-disciplined team to spearhead your early efforts. It will be important to invest in this team your vision:
    * for the business,
    * for the business process management that will support that business.
    * for the role of this new BPM team in enabling that vision....

    And that investment needs formal and informal time, group time and individual one-on-one time. This is the time to practice some of that L thing - Leadership. Take your team to lunch. Get to know them, make sure that they share your values at least regarding this endeavor. Hold whiteboard sessions to explain your approach, rather than just emailing out powerpoints (yuck).

    Now. Who should be on that team?
    1. Business SME (subject matter expert)
    2. BPMS expert (expert in the tool)
    3. (if #1 or #2 don't have it, get someone with some Process Improvement expertise)
    4. Integration expert
    5. project manager
    6. sponsor (um, likely that's you)
    7. executive sponsor (someone who can go to bat for you, if you're not an executive)
    8. Add people to the team as it becomes clear what capabilities you'll need. Add carefully. The first few people you pick are crucial.

    You can have more than 1 of these, but you really can't accept part-time contributions for the core team unless THIS is their first priority (outside of the exec sponsor). If they can drop everything else to help you, then you can accept their help. But if they have something else that is first priority, odds are that they will leave you hanging when you need them most. That doesn't work for BPM.

    Why our own integration expert? because integration teams are notoriously the long pole in the tent for most BPM projects. The integrations BPM projects require aren't hard, but the integration teams are likely working on the "5 year plan" and your BPM pilot project is definitely not on that plan.

    If you have the right people, and direction, you're probably halfway there. Now get to work :)

  • Everyone has offered some very good points. Here are a few that I have found to be useful:

    Focus on execution – as Dr. Khoshafian points out the goal is to end up with a BPM application that people use every day. Modeling has huge value – but when we are talking about process modeling the maximum value is through execution.

    Start with a well-defined scope -- pick a process, define it, and deliver results.

    Don’t sacrifice the good for the perfect. One huge value point of BPM is the incredibly rapid time to deployment. It is easy to adapt and change later, but showing early results and demonstrating the quick time-to-value of BPM is critical to long-term success and eventual enterprise proliferation.

    Executive or senior management support for the project -- both to help champion change and to ensure visibility into the results BPM delivers.

    Establish a "center of excellence" -- which may be a small steering committee or oversight team when you are first getting BPM off the ground. Having a central group that champions process thinking and can govern consistency across process improvements will ensure that a reliable, consistent methodology for BPM is applied across various processes and departments.

    Plan on using BPM to improve not one process but dozens or even hundreds of processes across the enterprise. This will cement process thinking at all levels.

Add a Reply

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT