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.
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.
SUMMARY BPM QUICK WIN SCENARIO
Ad-hoc service dispatch with escalation
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.
Low-code situational app -- or BPM w/decision tables (better).
* Detect event
* Dispatch/Escalate ticket to responsible parties
* Close ticket
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.
Pick something that you can win.. and that takes you in the right direction.
A small measureable success is better than a large intangible one. Don't get greedy. Small steps. It is a marathon, not a sprint.
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.
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 quickest win is stop executing processes that deliver results nobody needs or sees value in.
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.
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.
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”.
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.
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... :-)
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.