Resolved
3 votes

As with this last discussion, it seems more than a few people believe that the best way to achieve BPM success is with quick wins. So your experience, what are the quickest wins you can get with BPM?

Tuesday, March 01 2016, 09:50 AM
Share this post:
Responses (12)
  • Accepted Answer

    Tuesday, March 01 2016, 09:55 AM - #Permalink
    Resolved
    3 votes

    I may use this term incorrectly but isn't this an oxymoron? BPM requires thought, planning and constant nurturing to develop into long term success. If you want quick wins use some of the tecniques associated with BPM to identify and fix them.

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, March 01 2016, 10:13 AM - #Permalink
    Resolved
    3 votes

    With the right BPM supporting software you can achieve quick wins with users showing their ideas actually working within days. The "win" is that business users now recognise it's their input direct into the transparent build that is the future and so a new journey begins of employee empowermenr, knowledge of what is really happening and constant change to support efficiency.

    As ever do research and choose wisely the BPM supporting software platform.

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, March 01 2016, 10:20 AM - #Permalink
    Resolved
    5 votes

    1. Strong, senior team of analysts/developers, highly familiar with 1/ the platform the development is done on, 2/ the industry of the client and 3/ the BPMN method and style of the development organization.

    2. Strong repository of (mainly) technically-relevant process patterns (like EIP 2.0) - this leads to faster development and simpler integration testing.

    3. Solution is broken down into modular processes based on business object scope and business ownership.

    4. Hybrid development methodology - classic BPM + SCRUM.

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, March 01 2016, 11:18 AM - #Permalink
    Resolved
    4 votes
    After define the global framework, start on the critical business processes according to the strategy, designing and implementing of processes E2E, one by one, putting in evidence the business benefits.
    We just can do it clarifying first the "as-is" situation involving the stakeholders, in order to have term of comparison with the "to-be" situation, and show them the delta improvements after implementation.
    Note that the global vision and control of E2E processes is critical for sustainable success, in my opinion, and it's completely different of implement just separate parts of E2E process, which can even deceive the short term in terms of use and user satisfaction, but may undermine the real improvement of business efficiency, due the major difficult to control the overlaps of business activities, increasing the risk of dissatisfaction in medium term.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, March 01 2016, 11:21 AM - #Permalink
    Resolved
    5 votes

    SUMMARY BPM QUICK WIN SCENARIO

    Ad-hoc service dispatch with escalation

    BUSINESS PAIN

    As a business finds itself in a state of constant reconfiguration, sometimes it's hard for big systems to keep up. Bench utilization rates, first time fix rates, and production uptime (e.g. OEE) are critical manufacturing, asset and service metrics. And tough enough to manage in a stable work environment.

    But what happens when you have to scale up and down all the time? And your workforce is increasingly fragmented and not full-time?

    The essential heavy weight solution is a service management system -- which are increasingly oriented to contingent labour. However, sometimes, a manager just needs to be able to manage some new responsibility for an asset, which for some reason isn't onboarded for a regular system.

    SOLUTION ALTERNATIVES

    Low-code situational app -- or BPM w/decision tables (better).

    SIMPLE REQUIREMENTS

    * Detect event

    * Dispatch/Escalate ticket to responsible parties

    * Close ticket

    BPM WIN

    This scenario can be a quick and simple win for BPM! Especially for BPM-in-place. And much better than a spreadsheet and clipboards.

    Except for the escalation part. Process diagrams for escalation patterns quickly becomes spaghetti, unless you use a decision table or DMN along with the BPM. But by pairing BPM process automation with DMN or a decision table the delivery is very fast, transparent to management, and importantly can be very easily modified.

    DO IT AGAIN

    With this solution in place, it's a snap that there will be a steady stream of BPM projects and wins.

    The reply is currently minimized Show
  • Accepted Answer

    Ian Gotts
    Ian Gotts
    Offline
    Tuesday, March 01 2016, 11:54 AM - #Permalink
    Resolved
    4 votes

    Pick something that you can win.. and that takes you in the right direction.

    Some pointers

    1. Get committed users/sponsors who have a vested interest in the success. If you can find any go back to 1. and start again
    2. Keep scope small and tight
    3. Get a decidcated team, no matter how small.
    4. Keep it out of the limelight - supporting processes not core processes
    5. Measure before and after so you can demonstrate tangible success
    6. Don't tell anyone until you have a success

    A small measureable success is better than a large intangible one. Don't get greedy. Small steps. It is a marathon, not a sprint.

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, March 01 2016, 12:08 PM - #Permalink
    Resolved
    5 votes

    Instead of “quick win”, I use “quick BPM and business win”, “pain point” or “challenge point” expressions. Ideally, find a pain point which others (e.g. classic development practices) refused to solve. For example, a small document-centric application was quickly implemented with BPM while the vendor of this document management system refused to implement this application.

    In addition to many good recommendations already given, it is important that your BPM-centric implementation is quick – not only at development phase but for the whole life cycle of your BPM-centric solution (development, testing, deployment, maintenance, support). For example, a couple of the first BPM-centric implementations were carried out with SCRUM but their product owners were concentrated only on functional aspects (as we know, there is no solution architect role in SCRUM). As the result, the deployment took much longer than expected.

    Thanks,
    AS

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, March 01 2016, 12:52 PM - #Permalink
    Resolved
    3 votes

    Alright, relatively simple: you need a tune-up game.

    As fallen NFL star Paul Crewe goes on to explain in that vastly inferior (but still fun) 2005 remake of 1974's The Longest Yard, the tune-up game is a match you arrange prior to a big game—an easy win that builds your team's confidence before they go on to tackle (sorry) a more powerful foe.

    Ian's point is on the mark: Pick a fight you can win. If it's a high-visibility effort, great, but it's the win itself that matters most. Generally speaking, these types of projects are in-house (as opposed to customer- or supplier-facing).A nice back-office system, like IT or capital expenditure request submission, can be relatively straightforward to implement and yet receive solid support and adoption across the organization.

    Finally, don't be shy about getting assistance from the vendor. A win is a win. Eventually, your team will be ready to take on projects of any complexity; in the meantime, a little help can go a long way. Early success will create a space in which your team can build confidence, experience, and broad organizational support.

     

     

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, March 01 2016, 01:16 PM - #Permalink
    Resolved
    5 votes

    The quickest win is stop executing processes that deliver results nobody needs or sees value in.

    • E Scott Menter
      more than a month ago
      Hard to argue that "stop doing useless work" isn't good advice.
    • Emiel Kelly
      more than a month ago
      Indeed, it isn't, Scott. But in my experience the most overlooked step when doing some BPM initiatives (whether it be automating, improving etc)

      I see companies dive into the details fast without wondering if they apply on the right processes.

      So, that's a quick win on 2 sides; you stop doing useless things and you don't spend your BPM budget (for this question, I once assume BPM is something you can buy or implement) on things that don't matter.
    • karl walter keirstead
      more than a month ago
      In healthcare, there is a constant battle at the user level/agency level between data collection needed for 1:1 patient care versus government mandated data collection for long term outcomes studies across patient population groups.

      The users resist every step they see as unnecessary, they resist data entry at fields on forms, they absolutely hate having to navigate menus/pick icons to the point where, in our software suite, we went to one screen for "taking" tasks (some navigation is still required for performing tasks).

      We don't spend a lot of time on the vendor side trying to simplify workflows.
    • Emiel Kelly
      more than a month ago
      Karl Walter,

      You address an also important point; a process can (and will) have more than 1 stakeholder.

      As a traditional process guy, I always start with the customer. If they don't want the process result anymore, why bother about the other stakeholders.

      Another point is that in healthcare the process result is most of the time not a well upfront defined product or service. Processes in healthcare have the goal to solve problems (I have headache, my leg is broken etc). And depending on the individual case, the process is designed live.

      So then it's indeed hard to 'stop doing useless things' because you don't know yet what that thing is.
    • E Scott Menter
      more than a month ago
      And on that point, what may actually be a useless task from the point of view of the business looks more like "the reason I have a job" to the person doing it. It's great we're all so committed to making organizations as efficient as possible, but if we don't appreciate and value the human element, we're neither good business people nor good people.
    • Emiel Kelly
      more than a month ago
      Scott, In 'process projects' I spend most of my time with people who execute the work, so I absolutely agree.

      But I never commit so much to efficiency when it's applied to ineffectivity.

      But your point raises another one I always do early in projects; what is the desired management style for the process we're talking about?

      Is it good old taylorism where small tasks are executed by probably machines or robots, is it more goal driven where people have to decide on the best path, depending on the case etc.

      That for examples happens in healthcare. I'm a big fan of Jos de Blok here in Holland who created small teams responsible for care. And he hates process management ;-)

      The teams do manage processes (or actually cases), but I won't tell him ;-)


      So the way of steering is very depending on, there we go again, the desired process result.

      Brings me to an old saying ; a good process starts at the end.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, March 01 2016, 04:25 PM - #Permalink
    Resolved
    3 votes

    Quick Wins definitely are the preferred business development approach compared to wasting time responding to RFPs.

    Here is the pitch we have perfected over the past two decades..

    How to Quick Start BPM in your organization

    Let’s face it.

    BPM and its direct antecedents (flowgraphs) have been around for a long time.

    • The methodology is not well known because we encounter business people daily who have never heard of BPM.
    • Another subset has heard of BPM but feel what they are doing presently (or not doing) is sufficient.
    • A third group has tried to implement BPM only to end up as members of a not-so-elite group that, according to some, experience failure rates of 70%.

    We need to break out of this mould.

    Technology alone is not going to help, so this leaves leadership and user onboarding to master.

    If an organization wants BPM and users cooperate, it should be able to achieve liftoff and here is how to fast track your BPM initiative.

    Pilot Phase

    1. Go for low-hanging fruit – pick an initiative with not too long a timeframe, not too high a risk, with the potential to demonstrate quantifiable benefits.

    2. Pick a pilot project process that is confined to one or two silos.

    3. Go to the trouble of preparing an ROI (you will want to document before/after to get support for other initiatives).

    Make sure you document the “before” (i.e. how long it takes to do work, how consistent the outcomes are).

    Desired State of Affairs: e.g. The new process reduces the time to analyze a claim by 30%, the level of customer satisfaction increased from 2.5 to 4.5.

    4. Bring in a facilitator to graphically map out the process in real-time.

    Forget notations and UMLs – most processes only need nodes, directional arcs, branching decision boxes, imposed delays, loopbacks, exit points.

    Facilitators lose much of their “magic” when they force a group of ordinary users to watch them build processes with notations, languages.

    5. Park images of data collection forms needed at process steps onto your mapping canvas so you can drag and drop form images at steps as you build your process.

    Make sure the images post to forms that include a memo field – you will want at run time to be able to take quick note of complaints from stakeholders that the process logic is wrong, the forms in use are wrong, the performing roles are wrong, etc..

    6. Do not slow down the project by programming rule sets during the first cycle.

    Instead, describe rules in narrative terms only and make the branching decision boxes manual.

    You can build rule sets and convert decision boxes to auto off-line.

    7. Assign actual imposed delays to process steps that need these, but use a run-time environment that allows a temporary override down to 1-2 minutes for testing purposes.

    8. Encode process steps with their correct Routings but allow a temporary override of the parent Routing of all Routings so that one person can run through the entire process without having to log out/in under different user accounts.

    9. Compile your mapped process, roll it out, get a small group of stakeholders to piano-play the process, incorporate their suggestions/comments/corrections, re-map, roll out again etc.

    If you cannot get through all of the listed steps in 1 ½ hours, your SOW for today is larger/more complex than it should be.

    Only map in one session what you can roll out and test, update, roll out and test again. You can advance the process next session. Your users want/expect “instant gratification”.

    Production Phase

    1. Replace the imaged forms with real forms, build rule sets, put branching at decision boxes to auto, reset imposed delays to their plan-side values.

    2. Collect run-time data (should be automatic in the environment you are using) for statistical analysis/machine analysis to improve your process.

    3. Blend in FOMM (Figure of Merit Matrix) constructs at Cases so you can more easily track progress toward meeting Case objectives.

    The overall objective for your “Quick Results” BPM project is on-time/on-budget completion, before/after documentation, user testimonials that it is easier to do their work with the system than without it.

    Overall, you should be able to see increased productivity, increased throughput (be it in the area of processing patients, settling insurance claims, or completing MRO on a Blackhawk helicopter), reduction in processing errors, increased compliance with internal and external rules/regulations, all of which contribute to better outcomes and increased competitive advantage.

    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, March 02 2016, 01:07 PM - #Permalink
    Resolved
    3 votes

    Actually by not mentioning you're "doing BPM"... Start with whatever business improvement initative (e.g., a Lean exercise) and keep it small. Create sneaky BPM strongholds (seeding) that produce pragmatic (as in: "Hey, I can actually use this in my daily practise!") results. Obviously you have a plan or roadmap that is fully BPM related, but you just don't tell anybody. After a while and some marvelous results (harvesting), you could reveal that it was actually BPM all the way. But then again, you don't have to... :-)

    • Emiel Kelly
      more than a month ago
      BPM is daily business, so you don't have to tell anyone. They are already doing it.
    • Walter Bril
      more than a month ago
      That's what I'm saying. It is not important to label and broadcast it. It is however important to be aware and act.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, March 03 2016, 09:27 AM - #Permalink
    Resolved
    2 votes

    Sure,. no need to mention BPM

    Organizations have had written policy/procedue for decades that address workflow.

    What is the difference between this and a graphic flowgraph where at each step you get to see 1) optional instructions 2) the forms needed to attest to completion/data collection and 3) the skill performance requirements?

    What is the difference between a manila file folder with content in reverse chronological order and a Case file comprising date/timestamped interventions in reverse chronological order?

    Even if you don't mention BPM, a consultant who says "let's document your workflow, but, we need to use a special language and notation and given the complexity, you will need a permanent BA given that "ordinary" users will not be able/want to master the language/notation".

    Compare this to handing over the mouse to any user in a GoToMeeting session and saying ". . .here, you build the worklow"

    Remember Critical Path (early 1950s)? - it had steps/arcs, attributes at steps and you did not need a degree in electrical engineering to build a project plan.

    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
276 Replies
26/09/2016
David Chassels
269 Replies
23/09/2016
Emiel Kelly
221 Replies
26/09/2016
Bogdan Nafornita
209 Replies
26/09/2016
E Scott Menter
182 Replies
26/09/2016