There must be 50 ways to support the transparency, management and improvement of processes…..
I have tweeted it before: getting tired of the many people I meet that still associate process management first and most of all with documenting processes. Almost like a reflex "Ah, we will work with processes, so… we need to model and document this/all processes".
Sure it can help, but first of all it's not the only action a business can take. And second it may definitely not be the right action – other actions might add much more value.
Therefore, here are fifty (ok, some more) other possible interventions that can support the transparency, management and improvement of processes. Did I miss something? Let me know!
(Note, I concentrate on interventions focused on a specific process, and have left out the many interventions one can do to support implementation of process management and BPM within a company on a larger scale…)
The key activity
1. Understand all possible interventions, understand the context, and select, based on best practices, budget and requirements, a good set of interventions for the process, in close cooperation with key stakeholders and in line with your process management strategy (do you have one?)
High level understanding
2. Identify the process (and more important: the service/product that it delivers) and place it in a Product Catalogue
3. Identify the process (name it) and place it in a process architecture/decomposition
4. Identify all stakeholders in the process and understand their goals and high level role in the process
5. Identify all external stakeholders to a process (suppliers, partners, customers) and identify the primary interactions with the process (flows of information, physical goods)
6. Establish SIPOC – Supplier, Input, Process, Output, Customer, but only one a very high level
7. Understand how this process is related to other processes (input/output/supporting/managing) and the fit
8. Classify the process using certain classification criteria: high/low volume, routine – ad hoc, high/low cost, high/low strategic relevance
9. Understand how this process relates to your core competencies. Discuss and decide on sourcing strategies
10. Define the products and services that are output and that are input to the process, and establish quality criteria
11. Understand what IT-systems are supporting the process, with what functionality
12. Understand the relation between the process and core business objects (data) : Create, Read, Update, Delete.
Measurement & Governance
13. Establish goals, associated key performance indicators & targets for a process and start measuring
14. Define a Service Level Agreement with the key customers (internal/external)
15. Discuss and understand the control model: what can we do if all KPI's are in red?
16. Plan the process execution. Create a simple plan, that estimates demand, defines required capabilities and needed resources (per month, quarter, …)
17. Assign someone / people to be accountable for certain aspects of a process (execution, quality, performance measurement, improvement, improving maturity). Make sure there are clear lines of responsible for process vs. line management
18. Implement reporting lines and procedures for these accountable people
19. Set up a "quality circle" of process experts, that discuss and propose improvements
20. Establish a evaluation cycle that follows a Plan-Do-Check-Act cycle for the process
21. Implement a cross-function process governance board (strategic and tactical level) in which functional departments govern process performance and improvement activities
22. Implement procedures and supporting roles/resources for participant support (helpdesk), process incidents, problems and change requests/change management
23. Implement a regular customer satisfaction measurement/evaluation – outside in
24. Make sure all your process KPI measurements are stored safely, so that in time, you can do trend analysis and inline simulation
25. Audit compliance and report on findings
Analysis & Improvement
26. Determine the voice of the business: how this process needs to operate to execute the strategy
27. Adopt a best practice process framework (such as APQC, SCOR, eTOM, …) and assess the process
28. Understand all applicable regulations and policies and understand compliance requirements
29. Perform an outside in analysis of the customer: who is the customer and what is important for them (voice of the customer)
30. Determine the "voice of the employee": what do the process participants find important in terms of roles, development, employee happiness and fulfillment?
31. Assess the performance of the process (specific measurements, such as cycle time, throughput, cost, quality, compliance)
32. Perform a value added/waste analysis, and remove waste & non-value added activities
33. Perform a bottleneck analysis (ToC)
34. Understand process breakdowns, using a Rootcause analysis
35. Assess the capability of the process, based on the current resources: what are the limits & regular operating levels?
36. Identify the risks in the process and come up with/implement controls
37. Identity quality aspects and implement first time right / error proof interventions and checks where required + audits to proof adherence
38. Measure a certain aspect and it’s variance, and attempt to understand natural and special causes for the variation
39. Define a process improvement plan, including key indicators, and make someone / people responsible for executing it in a certain time frame
Maturity
40. Assess the maturity of a process and define the required maturity
41. Define a maturity improvement plan (based on a maturity model), including key indicators, and make someone / people responsible for executing it in a certain time frame
42. Implement PDCA cycle, roles and responsibilities focused on Maturity
Culture, awareness and HR
43. Train the process participants and managers in the process. Create a RACI matrix.
44. Understand the roles and come up with clear functions, with clear business rules around mandate and separation of duties
45. Understand the roles in a process (and the activities they execute and/or manage) and define required competencies
46. Organize awareness sessions to make people understand their role in a process and the impact of their behavior on customer, other people and process performance
47. Train relevant stakeholders in process thinking
48. Organize a BPM-game, where participants learn about the concepts of process, process improvement and process management through an engaging game
49. Organize a BPM day for various departments involved in a process, and use it to build (social) cohesion and alignment
50. Build awareness and capability at the management level in process thinking, process improvement and process stewardship
51. Implement incentives for process improvements (as opposed to rewarding repeated fire fighting behavior)
Technology
52. Go and buy a BPM Suite and automate the process and the BAM
53. Go and buy a BRM suite and support business rules and knowledge support
And finally: document your process(es) (are you really sure??)
54. Understand the stakeholders, goals, life expectation and required detail for documentation
55. Create a process model with supporting documentation, containing a detailed analysis of activities, events, business rules, roles, data flow, physical flow
56. Publish the process model & documentation to relevant stakeholders
57. Place the process model & documentation under configuration management and implement processes to signal updates/deviations and keeping documentation updated
Process driven transformation - exploring succesful change interventions(by Roeland Loggen)
Tuesday, June 14, 2011
Tuesday, June 07, 2011
BPM Research - 2011 live! Correlation BPM and Performance.
General
We recently concluded a research into BPM, together with the University Utrecht.
Key facts: Focus on The Netherlands, web based Survey, 168 participants, statistically healthy, and from all major companies and organizations in The Netherlands (Private and Public sector).
One of the interesting findings
We asked various questions on the adoption of BPM practices (such as identifying processes, documenting them, assigning ownership, implementing plan-do-check-act, etc.). In addition we asked them about the satisfaction on process performance (cycle time, cost, quality, etc).
We calculated averages and found the following (in diagram):
We found a positive correlation (and yes, we did check all the statistics). I would say: a first statistical finding that shows that BPM actually can help.
Interestingly, when you look at the point-cloud, you see a small top-performing group (high process performance) with average high BPM maturity. And a group with low performance satisfaction, that varies in BPM maturity.
We performed research to find out if there were significant BPM maturity factors in the top-performers, in comparison to the lowest performers. We found significant factors - the key one being "management has an active role in the improvement of processes".
Interested in more findings? Such as the 7 key trends in BPM adoption? The 10 critical barriers? The most used BPM technology in The Netherlands? The Dutch survey results can be found on http://bit.ly/jttlwv.
An english summary is available (mail Roeland dot Loggen at Capgemini dot com or twitter me - Roeland).
Thursday, May 19, 2011
Sense-Research-Respond patterns
In recent discussions and a number of projects we have done, we see an emerging pattern: Sense-Research-Respond.
Typical situation: the need to respond to an ever increasing number of alerts/signals/data, but to do this as cost effective as possible.
A number of business situations:
- An organisation knows it can and should detect signals of fraud by clients and internal workers and respond to it, but is trying to find an efficient way
- Inspection agencies that need to cut cost, and are moving to more risk-based inspections instead of trying to do 100%. But: how to pick the right risk-situations and tune the selection process, based on insights?
- Organizations that see the enormous growth in social media, and are finding references to their products and organization (positive and negative) and want an innovative but economic way to deal with these developments
In the last years we have seen the following pattern for these type of business situations:
The key ingredients:
- The capability to sense: to filter and detect data/events (and when needed correlated ones), that need attention. Usually driven by business rules ("risk profiles"), and easily tuned. The typical technology: Complex Event Processing, based on technology from for instance Tibco, IBM.
- The capability to research: advanced tooling, such as Palantir, SAS, to further research a certain situation, link it to other earlier events and to support decision making: will we need to react to this,and give it priority over other signals (as resources and time is constrained)
- The capability to effectively handle the situation, efficiently coordinating people in own and possibly other organizations. Sometimes this can follow pre-defined structured processes, but often, as situations can differ greatly, might require more flexible case management solutions. Technology such as Pega, Cordys, BeInformed, IBM.
And we have learned that technology is mature enough to handle these situations.
We have even developed a number of offerings around it, such as our "Grapevine" offering for social media. See here for a short video. Another is our Alert offering for Fraud detection.
Fascinating times. My lesson: don't ignore the growing available data-volumes (and become obsolete). Don't drown (and go under). But conquer in a smart way to use effectively. The ability to respond is a critical capability in modern organizations.
Wednesday, May 18, 2011
The Future Process-App: think Navigator
Do you remember the time that we did not have navigators installed in our cars?
Two typical situations I remember:
1. Driving with my wife, on vacation, where she was frantically trying to understand the map, while I was stressed out, since our next exit might be the one, and the next one was 30 km ahead.
2. Coming well prepared with a Google Map's driving instruction, only to find out that at step 23 there was a roadblock, making the rest of the procedure unusable. (And the frustration that we saw beautiful other route possibilities, but were afraid to divert from our Google route).
Both situations show a remarkable similarity to the current support of IT-solutions for knowledge workers:
1. No process support at all, just data. IT solutions that are great at storing and providing information (system of record), but not helping to plan and coordinate activities. For the knowledge worker, this means that he or she needs to plan and coordinate actions with other means, such as e-mail, spreadsheets, notes, etc. And for managers it make it quite difficult to get an oversight of the work in progress (who does what, what is still ahead?)
2. Solutions that provide support for activities (systems of engagement), but only using a very rigid procedural template, that locks the knowledge worker in : current workflow solutions. For the knowledge worker, this often means: tweaking the workflow (filling in false data to get access to the right functionality later in the process) or turning to shadow systems for activity management, just to be able to serve the customer request correctly. Both choices lead to incorrect or incomplete management information for the manager.
Based on the projects we are doing for various customers, a new paradigm is dawning:
The navigator as metaphor for the modern process-driven knowledge worker IT-solutions!
Key features:
- It provides real-time situational awareness (where are you? Where do you want to go? What are possible routes? Where are the traffic jams, possible roadblocks? What traffic (business) rules limit your choices?
- It provides goal-driven suggestions, but the knowledge worker can still decide to change route, and the system will re-establish other suggestions. It gives the right balance between standardization and freedom, driven by business policies
- It's easy to use
That's exactly what our Advanced Case Management solutions are providing: a navigator for goal-driven case handling.
Wednesday, April 27, 2011
BPM and ERP - caution
I see a number of blogitems on BPM and ERP appear.
A quick mindshare, based on some painful experiences (and a bit of bluntness, I admit)
So you have this big ERP system (or maybe even multiple). And you experience repeatedly how difficult it is to move from a datacentric to a agile process centric application view.... Adapting processes is a pain? UI is outdated? Connecting to eCommerce frontend a nightmare?
Then a BPMS supplier comes in, and sells you this great new layer of technology.
Beware....
Some simple questions:
- You invested heavily in the ERP system and now it is full of user screens.
Are you really going to rebuild (duplicating) all of them in a BPMS?
- Your ERP system is full of business rules
Are you really duplicating many business rules in your BPMS/BRMS?
- Your ERP system has workflow capabilities (that might even be growing in maturity)
Will you really move all workflow capability to the BPMS?
You might end up with an even bigger monster....
And another lesson: if you will deliver the project, and need to work together with the ERP vendor or other service partner, responsible (making money) of the ERP system - beware of politics...
Saturday, April 23, 2011
Article published: 4+2 processmodel
Just published a (dutch) article in BPM Magazine of April 2011:
The 4+2 Process model, a framework for better understanding of process area's you will need to cover in analysis and design.
Monday, March 07, 2011
BPM: Regressing and forgetting 60 years of management thinking
Around 2005 I first got involved in a project with some new innovative technology: Business Process Management (as we called it back then).
As business analyst, I was part of a team that also consisted of a number of developers.
And till today, I remember the look in their eyes when they started to understand the possibilities and implications of this technology. And the same look I saw in the business manager's eyes. And I did not like it.
The developers look: "Wow, before I could only drive the behavior of computers, but with this, this.... I can program people" (I won't go into the finer aspects of the developer psychology, including the way nerds are treated - hum ignored - by the cool business people - BPM as revenge!).
The manager's look: "Wow, so I get a process-driven application, which pushes my people's behavior, and gives me near real-time insight". (As most managers have had unsecure childhoods, BPM was the perfect way to regain control).
And the uneasy feeling I got, was also because at that stage as was reading lot's of management material, studying the history of management. The look in the eyes of these people felt "industrial revolution" or "Taylorian".
Interesting - a new innovative technology, that takes us back to the thinking of 80 years ago - ignoring all the developments in management thinking - empowerment, self-steering teams, work as social dimension, etc.
And it let back to the notion of "first process, than people".
Oh, by the way - the project failed. Insufficient user acceptance.
My lesson: Don't confuse the ends with the means. Process is not the goal - the goal is to support people collaborating and adding value to company and stakeholders. And process can be an element in helping these people structure and support their work. Process is (Capital) A means (and unfortunately often a barrier in many organizations...)
(This post also posted on http://www.noprocess.org/)
As business analyst, I was part of a team that also consisted of a number of developers.
And till today, I remember the look in their eyes when they started to understand the possibilities and implications of this technology. And the same look I saw in the business manager's eyes. And I did not like it.
The developers look: "Wow, before I could only drive the behavior of computers, but with this, this.... I can program people" (I won't go into the finer aspects of the developer psychology, including the way nerds are treated - hum ignored - by the cool business people - BPM as revenge!).
The manager's look: "Wow, so I get a process-driven application, which pushes my people's behavior, and gives me near real-time insight". (As most managers have had unsecure childhoods, BPM was the perfect way to regain control).
And the uneasy feeling I got, was also because at that stage as was reading lot's of management material, studying the history of management. The look in the eyes of these people felt "industrial revolution" or "Taylorian".
Interesting - a new innovative technology, that takes us back to the thinking of 80 years ago - ignoring all the developments in management thinking - empowerment, self-steering teams, work as social dimension, etc.
And it let back to the notion of "first process, than people".
Oh, by the way - the project failed. Insufficient user acceptance.
My lesson: Don't confuse the ends with the means. Process is not the goal - the goal is to support people collaborating and adding value to company and stakeholders. And process can be an element in helping these people structure and support their work. Process is (Capital) A means (and unfortunately often a barrier in many organizations...)
(This post also posted on http://www.noprocess.org/)
Saturday, March 05, 2011
Friday, March 04, 2011
Understanding management's hesitance towards BPM
Sometimes I get the feeling that BPM is a solution, still trying to find a problem to solve.
And I often hear BPM-specialists complain that "management does not support BPM".
Our research in the Dutch Market (this is a sneekpeek, watch this space, and Capgemini for more publications in a number of weeks!) suggests that BPM-specialists need to dare to apply a key BPM-principle on themselves: "Outside in thinking".
If management is the customer, why aren't they convinced of BPM?
In our research, we found a number of things, clarifying why management is not eagerly and happily jumping the BPM-train:
1. BPM is fairly complex and abstract
2. BPM takes time and requires a lot of energy from managers to fight the often dominant functional culture, existing in most organizations (and we all know: pick your fights carefully)
3. BPM has not delivered some of it's key promises (according to our findings):
- It has resulted at this stage in only limited increases in transparancy (process intelligence is mostly still a promise)
- Through BPM (as a discipline, with focus on maturity) organizations have not reached agility - changing processes is still hard and timeconsuming
4. Due to its history, BPM is often still viewed/confused as an IT-subject ("the new workflow")
5. The IT-promise of faster time to market of changes has not been delivered (and although our research does not give a cause, we suspect that many BPM-technology implementations are less flexible than expected and that many supporting IT-organisations still need to learn to increase speed, as they are likely caught in old-world "9 month" releasecycles, treating changes in processes and business rules as full fletched change requests)
Tricky situation. Even more if we see that research participants state that:
- The management of only a few organizations see and leverage processes as bridge between strategy and operations, using process interventions for change and improvements
- Management commitment is one of the key CSF's for BPM projects
My thoughts: for BPM to earn it's status as integral element in management and technology, we need to further develop BPM!
But.... We have some really interesting findings that suggest why BPM is already becoming an essential capability in best-in-class organizations - more on this later...
And I often hear BPM-specialists complain that "management does not support BPM".
Our research in the Dutch Market (this is a sneekpeek, watch this space, and Capgemini for more publications in a number of weeks!) suggests that BPM-specialists need to dare to apply a key BPM-principle on themselves: "Outside in thinking".
If management is the customer, why aren't they convinced of BPM?
In our research, we found a number of things, clarifying why management is not eagerly and happily jumping the BPM-train:
1. BPM is fairly complex and abstract
2. BPM takes time and requires a lot of energy from managers to fight the often dominant functional culture, existing in most organizations (and we all know: pick your fights carefully)
3. BPM has not delivered some of it's key promises (according to our findings):
- It has resulted at this stage in only limited increases in transparancy (process intelligence is mostly still a promise)
- Through BPM (as a discipline, with focus on maturity) organizations have not reached agility - changing processes is still hard and timeconsuming
4. Due to its history, BPM is often still viewed/confused as an IT-subject ("the new workflow")
5. The IT-promise of faster time to market of changes has not been delivered (and although our research does not give a cause, we suspect that many BPM-technology implementations are less flexible than expected and that many supporting IT-organisations still need to learn to increase speed, as they are likely caught in old-world "9 month" releasecycles, treating changes in processes and business rules as full fletched change requests)
Tricky situation. Even more if we see that research participants state that:
- The management of only a few organizations see and leverage processes as bridge between strategy and operations, using process interventions for change and improvements
- Management commitment is one of the key CSF's for BPM projects
My thoughts: for BPM to earn it's status as integral element in management and technology, we need to further develop BPM!
But.... We have some really interesting findings that suggest why BPM is already becoming an essential capability in best-in-class organizations - more on this later...
Sunday, February 27, 2011
Short bookreview - ACM: Mastering the unpredictable
Being very involved in the area of Adaptive Case Management at Capgemini, I am reading everything I find on the subject.
I recently finished "Mastering the unpredictable" - How Adaptive Case Management will revolutionize the way knowledge workers get things done. http://mtubook.wordpress.com/
A short review:
Pro's:
- Gives various, sometime overlapping, views on the subject of ACM
- Has some very clear viewpoints on the functionality and end-user perspective
Cons:
- No details on hard business cases - how can ACM actually be of real value to a business, besides the "improve productivity and increase transparency" promise?
- No information on approach. A lot of complaints about the traditional process-design methods, not suitable for knowledge work analysis, but no answers or a method on how to actually design a case management solution for a domain: how to deal with the complex set of rules, activities, data, functionality, input/output, events, etc.
- No case descriptions, with actual lessons learned by companies implementing ACM.
My conclusions: I was expecting more - am disappointed. Due to the overlap between the articles, no article really seem to go in depth towards practical implementation issues, business cases and tested approaches. Basically a lot of articles, each defining ACM and exploring some of the functional aspects. Good as an, somewhat lengthy, basic introduction to the subject (but much of that info can be found on the net as well...)
I won't enter the discussion of ACM being part of BPM or not. Well, a little bit: ACM is about activity, collaboration, transparency... If we restrict the "P" in BPM to Taylorian strict procedural processes, ACM would not be a part. But for me the P stands for productive people delivering results trough coordinated activities, making ACM part of BPM.
Maybe we should relabel BPM to BCM "Business Collaboration Management" or Business Value Delivery Management: the discipline of helping people to work together and deliver value....
By the way: Tips for better books are welcome....
Tuesday, February 22, 2011
Introduction to case management (presentation)
I recently gave a presentation about Case management. It introduces case management as a business work pattern. I explore the characteristics of this workpattern, the current IT support, present the Capgemini BPM grid (a services classification method) and describe Capgemini's Case management framework. Various animations..
Dutch article: Link between BPM and groupdynamics
Did you ever realize the strong relation between processes, BPM and groupdynamics?
Groupdynamics: http://en.wikipedia.org/wiki/Group_dynamics
The attached article explores the relationship, leading to valuable advice to business analysts and BPM consultants (note: written in Dutch).
Recently published in the Dutch BPM Magazine.
The article:
Groupdynamics: http://en.wikipedia.org/wiki/Group_dynamics
The attached article explores the relationship, leading to valuable advice to business analysts and BPM consultants (note: written in Dutch).
Recently published in the Dutch BPM Magazine.
The article:
Subscribe to:
Posts (Atom)