As with this [url="http://bpm.com/bpm-today/in-the-forum/is-it-better-to-start-by-defining-all-the-processes-or-to-get-control-of-a-few-important-processes-first"]last discussion[/url], 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?
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.
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.
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.
[b]SUMMARY BPM QUICK WIN SCENARIO[/b]
Ad-hoc service dispatch with escalation
As a business finds itself in a
[u]state of constant reconfiguration[/u], sometimes it's
[u]hard for big systems to keep up[/u].
[b]Bench utilization [/b]rates,
[b]first time fix[/b]rates, and production uptime (e.g.
[b]OEE[/b]) 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?
[u]And your workforce is increasingly fragmented and not full-time[/u]?
The essential heavy weight solution is a service management system -- which are increasingly oriented to
[b]contingent labour[/b]. 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.
[b]Except for the escalation par[/b]t. 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.
[b]DO IT AGAIN[/b]
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.
Get committed users/sponsors who have a vested interest in the success. If you can find any go back to 1. and start again
Keep scope small and tight
Get a decidcated team, no matter how small.
Keep it out of the limelight - supporting processes not core processes
Measure before and after so you can demonstrate tangible success
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.
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.
- Bogdan Nafornita
- 9 months ago
I think, that "solution architect" is a must-have role in any agile or any methodology project. This role has the responsibly over all technical aspects of the solution.
- Dr Alexander Samarin
- 9 months ago
Alright, relatively simple: [url="http://www.tzr.io/yarn-clip/9d11e7c1-c60a-4487-9c41-67903d48fbd3"]you need a tune-up game[/url].
As fallen NFL star Paul Crewe goes on to explain in that vastly inferior (but still fun) 2005 [url="https://en.wikipedia.org/wiki/The_Longest_Yard_(2005_film)"]remake [/url]of 1974's [url="https://en.wikipedia.org/wiki/The_Longest_Yard_(1974_film)"]
[i]The Longest Yard[/i][/url], 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.
[url="http://bpm.com/bpm-today/in-the-forum/what-are-the-best-ways-to-get-quick-wins-with-bpm#reply-3442"]Ian's point[/url] 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.
- E Scott Menter
- 9 months ago
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.
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.
- karl walter keirstead
- 9 months ago
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.
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.
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.
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.
[u]not[/u]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.
- Page :
However, you are not allowed to reply to this post.