tag:blogger.com,1999:blog-369152542024-03-13T06:11:09.895+01:00Process transformation - interventions for meaningful changeProcess driven transformation - exploring succesful change interventions(by Roeland Loggen)Roeland Loggenhttp://www.blogger.com/profile/02744153944427657174noreply@blogger.comBlogger156125tag:blogger.com,1999:blog-36915254.post-84809613490446307072022-10-21T17:39:00.003+02:002022-10-21T17:41:04.782+02:00The 9 building blocks of process management<p> </p><p>It's not easy: managing through processes. Viewpoints and concepts of involved managers and employees differ. When can we say we are managing processes (instead of departments)? What do we mean by a (Lean) process management system? </p><p>In our organization, but probably many more, we have had many discussions about these questions. </p><p>Over the years our discussions and discovery have led to a framework of mutual understanding of what we mean by managing processes, consisting of 9 building blocks. Hope this helps on your journey in managing and improving processes!</p><p>Our process management framework / 9 building blocks: </p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh8SW_dqBZ2ABxQGPG4dXMTnf3P0_NnVgOUH5Jf0BFB_GpaGPhluK-S2VjZTmyr5MjT-rCpmuQ7jqOMxUi9IxoanijEXY7iN3dZ5vgw_2PayuDgqQSsbjN5Ll3b0XloJyTVOF95MBdLpXrlFbi6bqzTwezUuF9OhN_iJIs6ML6gn8AiFLhRG08/s529/Building%20blocks.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="495" data-original-width="529" height="411" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh8SW_dqBZ2ABxQGPG4dXMTnf3P0_NnVgOUH5Jf0BFB_GpaGPhluK-S2VjZTmyr5MjT-rCpmuQ7jqOMxUi9IxoanijEXY7iN3dZ5vgw_2PayuDgqQSsbjN5Ll3b0XloJyTVOF95MBdLpXrlFbi6bqzTwezUuF9OhN_iJIs6ML6gn8AiFLhRG08/w440-h411/Building%20blocks.png" width="440" /></a></div><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: left;"><br /></div><b>1. Clear overview of processes, clear roles & governances and... committed ownership</b><br /><p>If you don't know what you have, how can you manage it. It starts with identifying your processes. This is a social construction effort. When you have a supported list (or visual process hierarchy/landscape map), you can start talking about roles and governance. </p><p>Who is the process owner? Who is process manager? Who maintains process standards? And how do these people with these roles relate to line management and work floor? What are their tasks, meeting structures, reporting structure? These are important questions to answer. </p><p>Then roles need to be assigned, people need to be trained and coached. Key requirement: really committed people that want, can and do. </p><p><b>2. Standards</b></p><p>How do we want to work together, delivering value to the customer? What behavior is needed, who does what when how. This needs to be clear and people need to be trained in it. </p><p><b>3. Execute process</b></p><p>Of course, this is the main most important element in process management: the actual delivery of value to customers. Employees, coached by the team lead/process managers, perform the tasks and deliver services and products. </p><p><b>4. Manage the execution</b></p><p>Here is the operational PDCA: the day/week standup, the checks on how people are doing and how the process is performing, the standard leader work to monitor performance, employee wellbeing and customer satisfaction. It requires daily management, being able to respond to issues - illness, supplier delays, quality issues, sudden changes in demand, etc. It also requires involving employees in identifying these issues or improvement suggestions. </p><p><b>5. Manage improvements</b></p><p>There will always be issues that need improvement or improvement suggestions. In addition, from the strategy (process) plan, certain improvement targets might have been defined. This manage improvement is aimed at deciding which improvements are done when / in what sequence and then plan for this improvements to be realized + manage this to results. The second PDCA. A toyota kata method works fine, for instance in combination with teams using the A3 process, C5 process or breaktrough projects. </p><p><b>6. Deliver improvement </b> </p><p>This is the actual work of improvement teams, working structured on process improvements: what is the issue? what is the goal? what are facts (go to the gemba)? What do the facts say? What is the root cause? What are possible countermeasures? What are testresults of experiments? Will we deploy the improvement wider / in standards? Here the third PDCA can be seen. </p><p><b>7. Plan and manage alignment</b></p><p>So many stakeholders and voices, so many requirements. These need to be aligned and decided upon: what can we realistically do? What does management want? What means can they offer (budget, people)? What do our customers want? Are their needs evolving? What do our value chain partners need? What do our employees need? And what legal and societal requirements are there that impact the process? </p><p>All these requirements should lead the a process strategy plan, giving goals and objectives on: run targets-KPI's, specific improvement targets, maturity targets and people development targets. These lead to the fourth PDCA. </p><p><b>8. Develop people and process (management) maturity</b></p><p>We don't build products, we help people grow to build our products. We develop people in two areas: their craftmanship in the process and their ability to support the management and improvement of the process. The culture should be: you hire people for 3 things: to deliver value, to help improve the value and to grow as a human being. </p><p>In addition, based on the process strategy plan, specific steps should be taken to adopt, professionalize and innovate practices in the other process management building blocks. </p><p><b>9. Engagement, personal leadership and culture</b></p><p>A true winner organization needs people that are committed and that are coached in taking ownership. It's helping them learning to see, and manage to learn. The culture should be supporting: errors are seen as opportunities, not a reason to blame. We improve together - using our collective knowledge. We measure to learn, not to evaluate. And we dare to experiment. </p><p>What do you think? Are these the building blocks you see as critical in a process managed organization? Or do we miss vital capabilities? Let me know!</p><p><br /></p><br /><p><br /></p>Roeland Loggenhttp://www.blogger.com/profile/02744153944427657174noreply@blogger.com0tag:blogger.com,1999:blog-36915254.post-20876769243111717032019-07-18T21:23:00.000+02:002019-07-18T21:23:06.968+02:005 critical capabilities of organization systemsIf you view an organization as a (complex) system, there are five key capabilities the system must have to successfully thrive in it's environment.<br />
<br />
<b>Capability 1: The ability to deliver and exchange value </b><br />
This is of course essential: if you are not able as an organization to produce and actually deliver value to the environment and receive value back, your organization will not have a long continuity. But beware, a nice quote "Profit is like oxygene, it's required for survival, but it's not the purpose for people" (quote varies just like the supposed authors).<br />
Value is defined in the eyes of the environment and is the value for a specific customer job to do but just as well the customer experience throughout the customer journey and life cycle. And you find it through rapid cycles of lean startup, customer development and operating model approaches.<br />
<br />
<b>Capability 2: The ability to optimize the delivery and value exchange</b><br />
This is were we see the likes of Lean and Six Sigma mainly operate: Can we do things faster, better, cheaper. Here starts competitive advantage - are we able to learn quickly enough to improve faster than our competitors doing business as usual.<br />
<br />
<b>Capability 3: The ability to adapt to changing needs of the environment </b><br />
This is where Darwin would say "Survival of the fittest". Are we able to understand changing needs, changing markets. Do we have the connections to monitor and detect changes and do we have the agility to respond to these changes and adapt our offerings and operating model.<br />
<br />
<b>Capability 4: The ability to innovate and deliver value to new needs in the environment</b><br />
But I find simple 'Survival' a underestimation of human potential. We have so much more: we have creativity, idea-generation and new technology - soft and hard. By using Design Thinking and other techniques we can hunt for new emerging needs or innovative solutions for existing needs. Or we can even influence the development of new needs (did you 15 years ago realize you needed a mobile phone, with even a touchscreen?)<br />
<br />
<b>Capability 5: The wisdom to manage the previous four capabilities</b><br />
This is the tough one - most companies have limited leadership and capability to actually recognize the need for these capabilities. This is the area in which leaders are drowning in projects, programs, KPI's and struggling with sense making, problems of collective visioning and difficulties in the ability to execute. To perhaps there is a 6th capability needed - to develop the previous 5 capabilities<br />
<br />
From a process perspective, you need to understand how to assess, evaluate and organize these capabilities - in terms of people, governance, competencies, maturity. If they are missing - then be careful what you will be doing as internal of external help....<br />
<br />Roeland Loggenhttp://www.blogger.com/profile/02744153944427657174noreply@blogger.com0tag:blogger.com,1999:blog-36915254.post-60921790679542261002019-03-27T17:56:00.001+01:002019-03-27T19:27:38.357+01:00Improvement? In the end, It's about learning to be resilientIn my <a href="https://process-transformation.blogspot.com/2019/01/systems-thinking-for-process.html" target="_blank">last post</a>, I defined process from a systems thinking perspective as "<i style="background-color: white; color: #333333; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.524px;">th</i><i style="background-color: white; color: #333333; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.524px;">e behavior of people and machines, in which clear patterns exist in the execution of activities and the relation between these executions and that converts certain inputs to certain outputs and produces value". </i><br />
<i style="background-color: white; color: #333333; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.524px;"><br /></i>
Funny: I have been working with architecture for some years already (still learning), and manage to overlook the Archimate definition of a process: "<a href="http://pubs.opengroup.org/architecture/archimate3-doc/chap08.html" target="_blank">A business process represents a sequence of business <b>behaviors </b>that achieves a specific outcome such as a defined set of products or business services.</a>"<br />
There we have it again: behavior.<br />
Socio-technical systems show behavior, leading to certain outcomes.<br />
A great book on systems thinking is the "Thinking in Systems - a primer" by <a href="http://donellameadows.org/" target="_blank">Donella Meadows.</a> She taught me that to help a system towards other outcomes, you need to learn to dance with it. It made me realize my mission in life: to learn to dance with systems of people and technology, and help create movement in these systems towards outcomes with more value and meaning for all stakeholders.<br />
<br />
In the book, she explains that there are different properties that a system can have - and explains that changing these characteristics can have an effect on each other. An vital property is <b>Resilience </b>- "a system’s ability to survive and persist within a variable environment." So: if changes occur (temporarily or permanent) in the environment, is the system than able to respond effectively and find a new way of operating.<br />
<br />
Meadows writes "I see resilience as a plateau upon which the system can play, performing its normal functions in safety". She writes "As a system loses its resilience, its plateau shrinks,
and its protective walls become lower and more
rigid, until the system is operating on a knife-edge, likely to fall off in one direction or another
whenever it makes a move. Loss of resilience can
come as a surprise, because the system usually is
paying much more attention to its play than to its
playing space. One day it does something it has
done a hundred times before and crashes."<br />
<br />
Now, as process consultant I am often asked to help the system to improve in terms of efficiency and productivity. Thanks to Meadows I now start to deeper understand that interventions in a system, aimed at short-term improvement of efficiency, can have a <u>negative</u> effect on resilience.<br />
So perhaps we made the system better, faster, cheaper, but made it less able to respond effectively to changes in its environment in the long run!<br />
Meadows states: "Systems need to be
managed not only for
productivity or stability, they also need to be
managed for resilience—
the ability to recover from
perturbation, the ability to
restore or repair themselves."<br />
<br />
Now I want to make the link to process improvement. I think when helping to improve socio-technical systems, it is important to keep an big eye on the resilience. That's not easy, Meadows: " Because
resilience may not be obvious without a whole-system view, people often
sacrifice resilience for stability, or for productivity, or for some other more
immediately recognizable system property."<br />
<br />
An important property that a system needs for Resilience is the ability to self-organize: to reorganize itself when changes in the environment require this. But how do you enhance the self organization capability of a system?<br />
<br />
Well, I think it's the ability of the people in the system to collectively learn and adapt!<br />
<br />
It suddenly dawned on me: process improvement efforts should never just focus on improving efficiency - it should be also, or even primarily be focused on helping the organization build a capability of learning and self-organizing. And perhaps you can develop the capability to learn, by helping people practicing process improvement (how can we do things right), and then help them to learn (through customer/market orientation) to further learn them stay effective (find the right things to do).<br />
<br />
Concluding: applying Lean, BPM, Six Sigma just for efficiency can be a dangerous thing: we make the system more productive/efficient in the short run, but might negatively effect resilience. So: help the system by strengthening their learning capability to do the right things right now - and later.<br />
<br />
(I guess the next post will require me to dive into first & second order learning)<br />
<br />Roeland Loggenhttp://www.blogger.com/profile/02744153944427657174noreply@blogger.com0tag:blogger.com,1999:blog-36915254.post-47618098929544667912019-01-16T12:44:00.001+01:002019-01-16T13:50:37.054+01:00Systems thinking for process professionals<b>Systems thinking </b><br />
The last months I have been in the luxurious position that I had time to study and learn. One of the subjects that I have taken up is <a href="https://en.wikipedia.org/wiki/Systems_theory" rel="nofollow" target="_blank">systems thinking</a>. I followed a number of engaging <a href="https://en.wikipedia.org/wiki/Massive_open_online_course" target="_blank">MOOC's</a>, read some great books and read many internet articles (more on this below).<br />
<br />
The reason for this choice was that I realized that I recently encountered certain organizational issues and I with my toolbox was not able to really understand, less solve these issues. By accident I followed one MOOC and it felt as if previous notions and new knowledge suddenly fell in place, giving me a better overview of, well, reality and the things I can, and can not do in it.<br />
<br />
As a process consultant, of course, I wondered that this systems thinking could bring to process analysis and improvement. I want to share some of my findings in this article.<br />
<br />
<b>My struggle with the current definition and views on the concept 'process'</b><br />
To start - a confession: I have always struggled with the definition of process. It's usually something like "<i>a series of activities, executed by people and machines that convert certain inputs to outputs and produce value". </i><br />
When i tried to make phenomenological sense of this, based on what I could observe, I was never able to see the direct truth and value of this view on reality.<br />
The first thing is: activities in the context of a process are primarily a logical concept. Sure, you can observe people and machines doing things, but that's not necessarily an activity in a process. We only start calling people and machines doing things a process, when these activities can be seen repeatable: when there is a pattern.<br />
In addition we only call this a process, if there are patterns that show that there are relations between these people/machines when doing work, in terms of some causal link that causes that when a certain event occurs (input arrives or a person/machine has finished an activity), there is some trigger that causes that the same or another/person or machine to start doing other things.<br />
<br />
<b>Towards a new notion of the concept 'Process'</b><br />
From that previous observations I define a process as "<i>the behavior of people and machines, in which clear patterns exist in the execution of activities and the relation between these executions and that converts certain inputs to certain outputs and produces value</i>"<br />
This definition directly leads to a number of better perspectives on process analysis, process change and process management/ownership.<br />
1. If you want to <u>understand</u> a process, you need to first find the patterns of behavior of people and machines - what do they do, and how are these patterns related, to understand how input is converted to output and how this produces value for whom<br />
2. If you want to change a process, it means that you have to find a way to influence the behavior of people and machines. It means that change management is an essential skill set<br />
3. We often talk about process as 'things'. 'This organization consists of the following processes'. 'I am the manager of the following processes, .....' I am the process owner'. But...Is an organization a set of behavior-patterns? Can you own patterns of behavior of people/machines? What do you own in that case? The people/machines themselves? The capability? The process descriptions (e.g. the descriptions of the patterns of behavior as is or as wanted)? The power (or illusion) that you can influence or even dictate the required behavior?<br />
You see, when you use my proposed definition of process, things became tricky. You will suddenly realize that process as a concept in the classical sense is an abstraction of a fairly unclear aspect of a much more complex system of people, machines and interrelations. And that a new, system-view based definition of process can help people to deeper understand what processes really are, how they can be analysed and what it takes to improve the socio-technical systems that perform the behavior.<br />
<br />
<b>A very short introduction to systems thinking</b><br />
A system is defined as: <i>A set of elements or parts that is coherently organized and interconnected in a pattern or structure that produces a characteristic set of
behaviors, often classified as its “function” or “purpose" (<a href="https://wtf.tw/ref/meadows.pdf" target="_blank">Donnela Meadows</a>, page 188)</i><br />
<br />
Some aspects:<br />
- Components can be things, people, machines, ideas, policies/laws, etc)<br />
- Interrelations are ways that parts influence each other - through certain flows, such as chemical, electricity, material, money, information, power-influence<br />
- The behavior of each part has an effect on the behavior of the whole. The system has properties that are created by the parts and their interrelations. Properties of the whole system can often not be linked to properties of parts.<br />
- Systems often behave in dynamic and non-linear ways, due to feedback loops. Systems as a whole can even develop unexpected behaviors (processes of emergence)<br />
<br />
Systems thinking in essence is:<br />
- <a href="https://www.youtube.com/watch?v=GPW0j2Bo_eY" target="_blank">Learning to zoom out</a> and see the greater whole (holistic/synthesis and abstraction)<br />
- Identifying useful boundaries (what is the system, what is outside the system)<br />
- Understanding the function and relations that the system has with it's environment (what are inputs/outputs in terms of energy, money, material, power-influence, information)<br />
- See the parts and interrelations of the system itself (what is there and how do these things influence each other) (analysis)<br />
<br />
Some great insights I found:<br />
- Every system as a deeper purpose that drives the behavior of the system. But this is not the same as the stated mission/vision/strategy by management. It can only be deducted out of the behavior of the system as a whole. Practical example: nobody wants people to be homeless, yet our society produces these outcomes...<br />
- Every system simply works towards its purpose and produces certain outcomes. There is no right or wrong, there is nothing broken. Whether we <i>like</i> these outcomes, <i>want them</i>, is another question. If not, we will need to understand and intervene in the system.<br />
- The reason that certain (unwanted) outcomes are produced is often not a linear chain of causal effects (e.g. a <a href="https://www.intrahealth.org/opq/wp-content/uploads/2014/05/Five-Whys-Technique.pdf" target="_blank">why-why tree</a>) but a more complex interrelated set of causes that have loops in them. Most issues in our world are caused by deeper issues - wicked problems. Practical example: we build roads to reduce traffic congestion, but this leads to more congestion, and other 'side effects', such as polution.<br />
- Our ability to create the perfect system is very limited. In many cases, due to unforeseen dynamics and our limited understanding of the system's inner working, our interventions may not lead to a system that produces the required outcomes, or might even make things worse! If we intervene and get unwanted side-effects, it's basically a sign that we didn't understand the system and perhaps even more, the limits of our mental model.<br />
- Systems are always in flux, so our views on "as is situation" and "to be situation" is an illusion. Our "as is" are essentially vague moving pictures. And our "to be" is never really done - we are never done helping systems to keep producing the right outcomes and the intervention that worked yesterday might not work today. The lesson: unlock change, instead of imposing it, and learn & stay flexible.<br />
- Systems don't exist. What we define as a certain system (e.g. what is in and out of the scope, what aspects/parts do we identify) is purely in the eye of the beholder/purpose of our research. In essence there is no system in the universe - all is connected and we are the ones that draw borders.<br />
- We use models of systems to understand, but maybe even more to learn -together- other ways to see the system and help us challenge our mental models.<br />
<br />
Systems Thinking has come with great analysis tools. Some techniques (and ways of views):<br />
- <a href="https://en.wikipedia.org/wiki/Force-field_analysis" target="_blank">Force field analysis</a>, helping to define enablers and inhibitors for helping the system produce wanted outcomes<br />
- S<a href="https://thesystemsthinker.com/step-by-step-stocks-and-flows-converting-from-causal-loop-diagrams/" target="_blank">tocks and flow diagrams</a> (for process specialists relatively easy cake)<br />
- <a href="https://beyondthisbriefanomaly.org/2013/02/15/driving-in-circles-road-building-and-causal-thinking/" target="_blank">Causal (loop) diagrams</a> (think 5Why / Root Cause times 10: issues that reinforce other issues that create the first issues...)<br />
<br />
<b>Learning to look from a systems thinking perspective</b><br />
If you learn to look through the systems lens to processes, I predict that....<br />
- You will develop a deeper understanding of the system that 'performs the process'<br />
- You see the parts<br />
- You see the interconnections<br />
- You see the patterns of behavior and (hopefully) the purpose through that<br />
- You will be able to intervene and influence a much more subtle and powerful ways, identifying <a href="http://donellameadows.org/archives/leverage-points-places-to-intervene-in-a-system/" target="_blank">leverage points</a> where, with limited effort strong change results can be reached<br />
There is even a <a href="http://www.thwink.org/sustain/glossary/SystemsThinking.htm" target="_blank">maturity model</a> for understanding your ability to see from a systems perspective! And you might even want to check out your <a href="http://psychology.wikia.com/wiki/Systems_intelligence" target="_blank">systems intelligence</a> with a <a href="http://systemsintelligence.aalto.fi/" target="_blank">test here</a>.<br />
Key lesson: the more people participate in systems analysis, the better understanding...<br />
<br />
<b>One very useful model for understanding (systemic) reality with a short story</b><br />
I found the following model very helpful in looking at reality:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgfyjdUeQwPuIH_9xJBC12D8thzMUZlyGPcT41syUNfZCO_q3pSP8myLzZeRZTvfI0ebfSAOyEGiiGqdDV90E5IJzuMA414DZwrbAvuFZfNKSxNX2hsHGcJqrcFORdEPF9rcMhHKA/s1600/Iceberg.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="542" data-original-width="608" height="285" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgfyjdUeQwPuIH_9xJBC12D8thzMUZlyGPcT41syUNfZCO_q3pSP8myLzZeRZTvfI0ebfSAOyEGiiGqdDV90E5IJzuMA414DZwrbAvuFZfNKSxNX2hsHGcJqrcFORdEPF9rcMhHKA/s320/Iceberg.jpg" width="320" /></a></div>
<br />
(A good explanation can be found <a href="https://nwei.org/iceberg/" target="_blank">here</a> and <a href="https://thesystemsthinker.com/connecting-systems-thinking-and-action/" target="_blank">here</a>)<br />
<br />
An example: suppose you are called by a manager. They had a major issue with a client (quality of a product was not good). You come in, and find out that somewhere an error was made. You see this as an unfortunate event and suggest to add a quality inspection.<br />
Sometime later you get called again. Many clients are now angry - there are too many delays. You can not see these as single events any longer, and research the patterns. It turns out that the error is made often, that the added inspection increases lead time, and that correction of the error also increases lead time. You perform a root cause analysis (what deeper patterns cause the error) and find that new employees make the error the most. So you introduce training for new people. You monitor for a week the effects, and great - the errors disappear.<br />
Some weeks later, the manager calls again. He sees costs growing and still delays. You analyse the cost situation and find out that many people are taking your proposed training, which lowers productivity and increases cost. In addition, you realize that the quality inspection lost its purpose. With great effort you find a way to fully improve the step that used to cause the errors. Now the error is prevented! Proudly you present the results and indeed - the error disappeared and delays seem to have vanished.<br />
Two years later, the company goes broke. Clients have repeatedly complained on next upcoming issues. You wonder what happened - and find out quickly: the manager's mindset saw people as simple replaceable resources. Morale was low, employee turn over was high and the employees mindset was that they never saw process problems as their issue, someone else would fix it...<br />
Conclusion: Don't focus on events and simple if-then's, but learn to see the patterns, structures and mindsets.<br />
<br />
I hope you enjoyed the article!<br />
<br />
<b>Some great resources on Systems Thinking</b><br />
For me, my Systems Thinking journey has lead to many new insights and questions. I hope that with this mindset and toolbox I can address complex issues and intervene more successfully. What about you?<br />
<b><br /></b>
MOOC's:<br />
- Acumen's <a href="https://www.plusacumen.org/courses/systems-practice" target="_blank">Systems Practice</a> (highly recommended)<br />
- Futurelearn's <a href="https://www.futurelearn.com/courses/systems-thinking-complexity" target="_blank">System Thinking and Complexity</a><br />
- Open University's <a href="https://www.open.edu/openlearn/science-maths-technology/computing-and-ict/systems-computer/systems-thinking-and-practice/content-section-0?intro=1" target="_blank">Systems Thinking and Practice</a><br />
<br />
Books:<br />
- Donella Meadow's <a href="https://wtf.tw/ref/meadows.pdf" target="_blank">Thinking in Systems</a><br />
- Fritjof Capra's <a href="https://www.goodreads.com/book/show/18554985-the-systems-view-of-life" target="_blank">The Systems View of Life</a><br />
- John D. Sterman's <a href="https://www.goodreads.com/book/show/808680.Business_Dynamics" target="_blank">Business Dynamics - Systems Thinking and Modeling for a complex world</a><br />
<br />
On the internet, including Youtube, there is ton's of material to be found!<br />
<br />Roeland Loggenhttp://www.blogger.com/profile/02744153944427657174noreply@blogger.com0tag:blogger.com,1999:blog-36915254.post-72849764504137526832016-03-19T21:46:00.001+01:002016-03-19T21:46:12.378+01:00Towards personalized processes (for employees)My assumption is that if we dive deeper in human centered process design (as described in my previous post), and research people that work in processes, we will find similar findings as user-centered designers do when they research customers:<br />
> People are different in many ways, for instance in terms of needs, preferences, skills and behavior<br />
<br />
Product and service delivery companies have struggled with this, and the big shift from industrialized homogeneous delivery to modern days have been personalisation and mass customization. You might argue on the extent that companies have been able to really reach this, but I think that this shift towards personalized services will continue. And also that the human centered approach to design of products and services will further grow - to meet personal individual needs of people in better ways.<br />
<br />
Now, that's interesting. As BPM-consultants we typically define processes aimed at standardization. We want processes to be simple, consistent, the same for all (in the same role & swimlane of our nifty process models). Some process designers do not even have a clear picture of the employees, and will design jobs from a very generic perspective.<br />
<br />
But if we want to help create work environments which engage, motivate and even help employees thrive, we need to take the individuality of employees into consideration, even put in central.<br />
My assumption is that if we look deep into humans in the role of employee, we will find:<br />
1. Generic human traits and needs that apply to all<br />
2. Traits and needs for particular groups of people (persona's)<br />
3. Pure individual traits and needs (the individual employees in your process)<br />
<br />
As process designers, if we strive to fully engage each and everyone employee in process execution, we will need new methods and approaches to design processes that can address all these 3 levels.<br />
In my opinion, this could be the dawn of the <b>personalized process</b>: processes that are able to tune in to each employee's unique traits and needs, and create a working environment that triggers that person's motivation, need for meaning, engagement and perhaps happiness.<br />
<br />
<br />
<br />Roeland Loggenhttp://www.blogger.com/profile/02744153944427657174noreply@blogger.com0tag:blogger.com,1999:blog-36915254.post-64497163287476509642016-03-19T16:55:00.003+01:002016-03-19T16:55:29.902+01:00Towards human centered process designWe spent a considerable part of our energy and life-time at work. That makes it painful to see the typical statistics on employee engagement. Some organizations even talk about a<a href="http://www.gallup.com/businessjournal/188033/worldwide-employee-engagement-crisis.aspx"> worldwide employee engagement crisis </a>. And I think change is needed. As BPM/Lean consultants I think we should research this, and perhaps also discover that we are part of the problem.<br />
<br />
A simple question you might want to ask yourself: when you design processes, and would need to pick the key 2 or 3 goals you or the organization wants to reach, which ones would win from the following list:<br />
- Cost reduction<br />
- Value for the customer<br />
- Employee motivation<br />
- Quality improvemen<br />
- Improved Customer Experience<br />
- Efficiency<br />
- Employee engagement<br />
- Agility<br />
- Reach strategy alignment<br />
- Increase Employee happiness<br />
- Reduced cycle time<br />
<br />
And? I bet that most people picked cost, efficiency, cycletime, perhaps quality, and perhaps customer experience. The reasons? I don't know, but my assumption is that we never really developed the vocabulary and methods on designing processes for employees. And that's maybe also because our BPM-assignments never included employee experience. Sure, as any Lean expert will tell you: the employees ARE the process, so you need to involve them, empower them and support them to create a improvement culture. But that's just one part of employee engagement.<br />
<br />
We live in a time where using design thinking, human centered design we learn more and more how to engage people with products and services. We learn about behavioral economics to influence behavior. And we research how to help people thrive with findings from positive psychology.<br />
And how much of these methods and findings have entered the field of BPM? Lean? My assumption, based on keeping on track on most literature and websites is: surprisingly little.<br />
<br />
My key question is this: is it possible, and if yes, in what way can we, process designers, help create working contexts that are desirable for employees, that engage, perhaps motivate or even increase happiness?<br />
<br />
I think this question is very relevant. Mainly because I think it is a waste of precious lifetime to work in disengaging work contexts. It kills spirit and creates waves of negativity in our societies. And of course there are business stakes as well: low retention, not to speak of the consequences on customer experience and thus, profit.<br />
<br />
That's why I have decided to start a research project into 'Human centered process design', focused on finding ways to help design processes and work environments that help people thrive. <b>Tips and help very welcome!</b> I assume (as always standing on the shoulders of giants) that must be current and earlier researchers on this question. My hope: to contribute to BPM & Lean with new vocabulary, inspiration and methods to help our world forward.<br />
<br />
<br />
Roeland Loggenhttp://www.blogger.com/profile/02744153944427657174noreply@blogger.com2tag:blogger.com,1999:blog-36915254.post-3563728819259516172015-04-16T20:39:00.001+02:002015-04-16T20:39:15.658+02:00Six lessons on the art of changeOh, irony, how many times I meet process consultants (including me) that often forget that changing processes is changing humans and their behavior. That think that creating a 'process design' document is a major step, forgetting that the influential power of a process diagram is about as strong as sending an LinkedIn invite to someone you don't know at all....<br />
<br />
So, just for me, not to forget, six key lessons on the art of change (and no, I won't call it change management).<br />
<br />
<b>Be part of the change</b><br />
So doing a number of interviews, and then writing a report is valuable? No. That's safe distance consulting. Step inside the system, influence and be influenced. Be prepared to not know AND strong enough to dare to take a stand. Get out there, organize workshops, discussions, and other interactions, and try to make them meaningful for the people involved: meaningful interactions and conversations that touch both you and other stakeholders. Out of comfort zone? Yes.<br />
<br />
<b>Get out with incomplete analysis and ideas</b><br />
So you want to lock yourself up to create the perfect analysis, the perfect design, the perfect to-be? No. Think back when you received a 99% complete report, and someone asking you if you agree. Most of us either try to ignore it, or just give up at page 20/143 and say 'Sure, good ideas, ...I guess' and simply get on with our lives hoping that someone else will pick up the actions in the report. The key is: get out as consultant with your analysis and ideas when they are at 40%, 50%. It opens up a valuable feedback channel, because people get triggered by the openings, the vagueness, the incompleteness of your ideas. It stirs feedback, and most important: if people have the opportunity to add value to ideas, it becomes their ideas: ownership and support included.<br />
<br />
<b>Know the value of interventions</b><br />
As a consultant, there are many ways to analyse and influence people and their behavior. First of all: try to fill your toolbox and experiment/learn what works when. If you only have a hammer and nail, your reflex will be to hammer on. Second: understand the power of an intervention. From interview, to workshop. From online survey to focus group. From newsletter to report. From think tank to management summit. What does it do with who.<br />
<br />
<b>Don't confuse means and goals</b><br />
Yes, I used to think that a brown paper session was successful if I had enough stickies, with a reasonably clear process, and enough pain points and perhaps even some suggestions. The model was my goal. But to transform processes, to change behavior of people in groups, such workshop results are merely a side effect. The true value lies in bringing people together, having meaningful conversations, build trust and cohesion, influence each other, create awareness, etc. <br />
<br />
<b>Ask, listen, observe</b><br />
I sometime meet great change specialists. Wow. These people see and feel in X dimensions. Are at meetings and read currents, moods, old pain, policies, stakes. And dare to ask, listen, reflect. The better you can be there, be mindful, really see, hear, feel, separate observations and interpretations, and build up intuition and cause-effect knowledge, the better you know what's going on, and what's needed.<br />
<br />
<b>Every change is a personal change - and goes through phases</b><br />
A successful process transformation is done, if all process participants have changed behavior - one at a time. So 'process transformation' is a confusing word. It's behavior change of a group of people, of individuals (and often some IT-systems as well). It's essential to remember that change in time goes through phases. From awareness (is there a problem with my current behavior?) to desire (all right, perhaps it's good to change) to knowledge (so, what is it that I should do') to ability (ah, so this is what I should and now can do) to reinforcement ('and with these interventions I help me and others not to laps back to old behavior patterns when in stress). The secret: each phase requires different interventions. Don't send someone to training or give a 500 page manual of the To-Be process, if the person is still struggling with desire and motivation.<br />
<br />
<br />
<br />Roeland Loggenhttp://www.blogger.com/profile/02744153944427657174noreply@blogger.com0tag:blogger.com,1999:blog-36915254.post-22309138088360651862014-12-22T21:58:00.000+01:002014-12-22T22:19:35.157+01:00Design, UX, Flow, o dear.I have gotten myself into a discussion @ twitter, and found myself with the following question, asked by <a class="js-nav js-initial-focus" data-send-impression-cookie="true" href="https://twitter.com/wareFLO" style="background-attachment: initial; background-clip: initial; background-image: initial; background-origin: initial; background-position: initial; background-repeat: initial; background-size: initial; font-family: Arial, sans-serif; font-size: 22px;"><span style="color: blue;">Charles Webster MD</span></a>: "<span style="background-color: #f5f8fa; color: #292f33; font-family: Arial, sans-serif; font-size: 14px; line-height: 18px; white-space: pre-wrap;"> what is the relationship between interaction design, user experience, workflow & process-aware technology" </span><br />
<span style="background-color: #f5f8fa; color: #292f33; font-family: Arial, sans-serif; font-size: 14px; line-height: 18px; white-space: pre-wrap;"><br /></span>
It's a broad question, but I like it, because it forces me to create a coherent view on a number of items I have closely been working on in the last years.<br />
<br />
A challenge is that by reading Charles' blog, I noticed that certain concepts we use might have different names and definitions. And, that we had another discussion going through this, dealing with the limitations of 'workflow' versus case management.<br />
For starters, I encountered the definition 'Workflow': <span style="background-color: white; font-family: Georgia, serif; font-size: 15px; line-height: 22px;"><i>Workflow is what actually happens when work is done. It is a series of steps, or tasks, that consume resources (money, time, effort, attention), and achieve one or more goals (see </i><a href="http://chuckwebster.com/2014/08/usability/confusing-workflow-technology-with-workflow-is-like-confusing-your-database-with-your-data" style="font-style: italic;">here</a><i>). </i>In my eyes this is a perfect definition for 'Business Process'. Perhaps due to my BPM-technology background, I typically associate workflow by a process that has been implemented and can be run in a BPM-Suite.</span><br />
<br />
And a later definition of workflow came along by a reaction to the discussion by InformIt:<br />
<h1 style="background-color: white; color: #333333; font-family: 'Lucida Grande', Arial, Helvetica, sans-serif; font-size: 22px; margin: 0px 0px 0.5em; padding: 0px;">
<a href="http://www.informit.com/articles/article.aspx?p=2193839" style="color: #2e87b2;">First Sketches of an App: Planning the Design of a Mobile Application</a>. </h1>
<div>
It did not provide a clear definition, but deriving it from the text should give something like: a workflow is a series of steps a user follows when trying do a certain job, while using an IT-application. Hmmm.</div>
<div>
<br /></div>
<div>
Ouch. Let's get back to the basics of the question, and let's start with the end in mind: a situation in which we have found a way to support, let's say medical staff, with a great process aware information system. A system that:</div>
<div>
1. Provides the right user experience: people using it can reach their goals (primarily diagnosing, monitoring and curing patients) in an effective, efficient and pleasant way, in the context and conditions they do their activities</div>
<div>
2. The system is aware of pre-defined medical protocols and best practices, yet has the flexibility to deal with unforeseen events (symptoms), and can coordinate people's work, based on these protocols and practices. It means that the system can trigger people to perform certain activities </div>
<div>
3. While doing their activities, people can enter, and find/access appropriate information, that is related to all the work that is going on. Outside of the activity perspective, people can access the status of a patient (and the status of all ongoing and completed 'workflows').</div>
<div>
<br /></div>
<div>
(Note that I take a strictly medical staff perspective, just to limit the scope of this blog-item. If I would include a patient (and family/supporting network) perspective, I would also need to dive in to patient journeys, service design and patient experience. Another time. Also note that I have not included worker experience design and process redesign, something I wrote about <a href="http://process-transformation.blogspot.nl/2014/07/five-approaches-and-maybe-six-to.html">here</a>, for now, but limit it to the design of the IT-system)</div>
<div>
<br /></div>
<div>
Let's assume that the system is based on a modern BPM-Suite, with appropriate flexibility (e.g. advanced case management/dynamic process support). This is essential, as cure and care processes are often not completely predictable in terms of possible events, routes and outcomes. For more information, see <a href="http://process-transformation.blogspot.nl/2013/12/on-capgeminis-cto-blog-i-posted-this.html">this blog item</a> or <a href="http://www.nl.capgemini.com/resource-file-access/resource/pdf/Capgemini___s_Public_Sector_Case_Management_Solutions_1.pdf">read the whitepaper</a> on case management that I wrote together with a colleague when working at Capgemini (and that was referenced by Gartner), and where we use the '<a href="http://process-transformation.blogspot.nl/2011/05/future-process-app-think-navigator.html">navigator</a>' versus workflow metaphor.<br />
<br />
Using a BPM-suite, this means that a large part of the software design is fixed (the building blocks, such as the portal, modelling facility, process execution engine, human activity coordination - inbox, form handlers for activity screens, document management module for documents, etc).</div>
<div>
<br /></div>
<div>
Now let's try to answer: how were we able to design the IT-system?</div>
<div>
A number of actions needed to be taken. I am trying to take these apart, from two perspectives: the subject matter expertise, and the design expertise. Often, in reality, the actions are done in parallel, with the full team.</div>
<div>
<br /></div>
<style type="text/css">
.tg {border-collapse:collapse;border-spacing:0;margin:0px auto;}
.tg td{font-family:Arial, sans-serif;font-size:14px;padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;}
.tg th{font-family:Arial, sans-serif;font-size:14px;font-weight:normal;padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;}
</style>
<br />
<table class="tg">
<tbody>
<tr>
<th class="tg-031e">Action</th>
<th class="tg-031e">Deliverable</th>
<th class="tg-031e">Context Expertise</th>
<th class="tg-031e">Subject Matter Expertise</th>
</tr>
<tr>
<td class="tg-031e">1. Understand the medical staff and their the working context</td>
<td class="tg-031e">Empathy maps persona's, contexts of use</td>
<td class="tg-031e">UX</td>
<td class="tg-031e">Medical Staff</td>
</tr>
<tr>
<td class="tg-031e">2. Understand the activities that needs to be done, when, where, why. Understand the processes, triggers, exceptions.</td>
<td class="tg-031e">Process maps</td>
<td class="tg-031e">Process analysis</td>
<td class="tg-031e">Medical staff</td>
</tr>
<tr>
<td class="tg-031e">3. Understand information usage - for each activity,<br />
determine information needs, information produced. Understand information requirements<br />
from compliancy and management needs.</td>
<td class="tg-031e">Objects/attributes</td>
<td class="tg-031e">Information analysis</td>
<td class="tg-031e">Medical Staff</td>
</tr>
<tr><td class="tg-031e">4. Design the 'workflows': the series of activities that the system should support. </td>
<td class="tg-031e">Executable Process models</td>
<td class="tg-031e">Process designer</td>
<td class="tg-031e">Medical Staff</td>
</tr>
<tr>
<td class="tg-031e">5. Design the user interaction in general: how do people work with the system in general, in terms of access to patient information, inbox of work-items, search, etc., using the contexts of use (mobile workers, administration behind desk, operating room, etc) </td>
<td class="tg-031e">General UX concept</td>
<td class="tg-031e">UX</td>
<td class="tg-031e">Medical Staff</td>
</tr>
<tr>
<td class="tg-031e">6. Design the activity forms: when performing a certain activity, how should information be presented, accessed, entered. </td>
<td class="tg-031e">UX design of activity</td>
<td class="tg-031e">UX</td>
<td class="tg-031e">Medical Staff</td>
</tr>
<tr>
<td class="tg-031e">5. Design the technical interactions (activities or process fragments that need to interface to technical equipment) </td>
<td class="tg-031e">Technical interfaces</td>
<td class="tg-031e">Integration expertise</td>
<td class="tg-031e">Technical staff</td>
</tr>
</tbody></table>
<br />
<div>
The creation of these deliverables is often done using the BPM/ACM-technology (in combination with other tools - such as plain Office, but also Business Rules models, Data modelling tools, etc).<br />
With the emergence of 'Business Technology' we see the trend of 'The specification/model IS the application' as I wrote about early <a href="http://process-transformation.blogspot.nl/2014/05/evolution-in-business-application.html">here</a>.<br />
<br /></div>
<div>
Key in these actions is to work iterative, and test test test. Testing from multiple perspectives:<br />
- the process/workflow: is the set of activities correct in terms of flow, exceptions, decisions?<br />
<br />
<div style="-webkit-text-stroke-width: 0px; color: black; font-family: 'Times New Roman'; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px;">
</div>
<br />
<div style="-webkit-text-stroke-width: 0px; color: black; font-family: 'Times New Roman'; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px;">
<div style="margin: 0px;">
- the information perspective: can I work with the right information, record the right results?</div>
</div>
- the user experience: can I as a user, in a certain context, perform the activity in an effective, efficient way, and does the system support me in a pleasant, perhaps even motivating way?<br />
- the technical integration</div>
<div>
Testing requires different perspectives and associated competencies/skills: a process/workflow perspective, a UX-perspective and a technical perspective. The people possessing these skills will typically organize / facilitate sessions with medical staff, guiding them, monitoring them and so finding ways to improve the system in terms of UX, workflow/data or technical integration. As BPM-Suites and Adaptive Case Management systems allow most parts to be <i>configured</i> refinement cycles can often be done quite quickly (hours to days).<br />
<br />
Now, part of the discussion I have with Charles dealt with the notion ' Human Centric Design is dead', pointing to sources such as <a href="http://www.jnd.org/dn.mss/human-centered.html">here</a> and <a href="http://www.jnd.org/dn.mss/logic_versus_usage_the_case_for_activity-centered_design.html">here</a>. First of all, I don't disagree with the notion of activity centered design, as my actions above clearly show.<br />
The activity centered design is for me a (welcome!) merging of BPM-expertise and UX-expertise.<br />
The BPM-perspective has always placed activities as the center. What needs to be done when, why and by who. And.. what information comes in, is needed, and goes out. But what we have missed as BPM-specialists is often the UX: really understanding the people using it, the context of use (where? how?), e.g. taking a more psychological perspective, in terms of quality of use. As BPM-specialists we dropped BPM-suite driven applications to users, based on sound process analysis and information analysis, that were logically correct. But often not user-friendly. Too rigid. Too complex.<br />
In my last program (a flexible BPM/Case management solution for a Ministry - with lots of adhoc processes, for 1200+ users) we involved a UX-specialist. The value of this UX-perspective (understanding users, their context, ability to prototype, test, and bringing in other ways of looking at forms-designs) has brought enormous advantages.<br />
<br />
My notion of Human Centric Design has been formed by my work and various trainings of IDEO and other organizations (Service Design), see for instance <a href="https://novoed.com/hcd-acumen">here</a> and <a href="http://www.ideo.com/work/human-centered-design-toolkit/">here</a>.<br />
I think these HCD-approaches did not evolve from a strict user interface design perspective (as I would position D Norman), but much more from a holistic view on people using artifacts and services to collaborate and reach certain goals. These HCD-approaches have a rich toolkit, in which context-of-use, design for emotion and motivation, journeys/jobs to be done and process/workflow perspectives are all seen as essential elements). So from that notion I would be far from declaring HCD as harmful. Activity Centered design is essential part of HCD.<br />
In the end, I think Charles and I are in agreement.<br />
<br />
To conclude: a small dive into the limitations of many BPM-tools. I<a href="http://www.nl.capgemini.com/resource-file-access/resource/pdf/Capgemini___s_Public_Sector_Case_Management_Solutions_1.pdf">n the whitepaper</a> (with the model I designed, positioning various types of processes and associated forms of coordinations), I showed that there are types of processes that are more structured and predictable (doing your expenses) versus more adhoc/less predictable processes. Actually you could see a scale:<br />
1 Structured process, where the full process model is known and all execution paths are known at design time<br />
2 Less predictable, but the activities can be predicted/predefined, just not the sequence/possible paths<br />
3 Even less predictable, the process might even require activity not predefined<br />
The key issue with certain workflow technology or BPM-suites is that they can only support type 1 processes. I predict that in health care many type 2 and 3 processes exist. So to integrate a BPM-engine in an EHR, that supports type 1 only, will severely limit the EHR's value! And however great the process or UX design, it won't fix the key issue: users will be locked in ' hard' workflows that will not support all the possible events and paths.<br />
<br />
<br />
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<br />
<br />Roeland Loggenhttp://www.blogger.com/profile/02744153944427657174noreply@blogger.com0tag:blogger.com,1999:blog-36915254.post-51843651323400385022014-08-05T22:05:00.001+02:002014-08-05T22:05:37.662+02:00O dear, what will we do with the data?In my previous post, I wrote about the possible scenario's to deal with integration with existing data-centric applications. In this blog-post, I want to cover situations, in which we want to digitize the process (with a BPMS/ACMS) and there is data, but <b>no</b> existing data-centric applications to store it.<br />
<br />
Let's first investigate the typical data one encounters when analyzing a process that needs to be digitized...<br />
<br />
<table><tbody>
<tr>
<th>Type</th>
<th>Description</th>
</tr>
<tr>
<td>Customer data</td>
<td>Names, addresses, contact persons, etc.</td>
</tr>
<tr>
<td>Product/transaction data</td>
<td>Type of service or product, certain service / product specifications, pricing, other conditions and agreements</td>
</tr>
<tr>
<td>Decisions</td>
<td>Specific decisions (what what the decision, who took it, when, and why was this decision taken/on what grounds)</td>
</tr>
<tr>
<td>Process and task performance data</td>
<td>Durations of process and tasks (or even effort and costs associated with it)</td>
</tr>
<tr>
</tr>
<tr>
<td>Audit trails</td>
<td>What was done, when, why and by who</td>
</tr>
<tr>
<td>Other process linked data</td>
<td>Comments/communication between process participants, certain checklists/QC outcomes</td>
</tr>
</tbody></table>
<br />
<div>
All this data is crucial for the stakeholders around a process:<br />
- The customer wants their service or product first time right, on time delivered<br />
- The process participants need it to know what to do, and do it correctly<br />
- Process management wants to manage the flow, work-distribution, work-load and compliance<br />
- Responsible managers want to be able to report outcomes, performance and compliance<br />
- Accountants / Audit / QA-people want to understand what happened, and see if it was compliant to regulations<br />
- Future generations (Public sector mainly) want to historically research what happened<br />
<br />
When we digitize a process, this data is, in the as-is situation, usually scattered in various forms:<br />
- In unstructured forms, on paper, in folders, or in e-mails<br />
- In semi-structured form, in (often) Excel files<br />
<br />
And the user requirements are typically:<br />
- We don't want Excel anymore, the new BPMS/ACMS solution should help us to digitize the process<br />
- We want to store and report on all of this data somehow<br />
<br />
Many times, I encounter organizations that are mostly paper-based, sometimes with low-volumes. So when implementing a BPMS/ACMS solution, we do not have the luxury of a CRM-system, and ERP-system (or other Product administration), a Datawarehouse. Sure, organizations should have these systems in place, but often, introducing these technologies are not in our scope. Then the inevitable question comes: O dear, what will we do with the data? Ouch.<br />
<br />
From a solution architecture point of view, we have a number of paths.<br />
<br />
<b>1. Let parts of the data behind in existing office automation</b><br />
Pro's:<br />
- Simple<br />
<br />
Con's:<br />
- Separate files that need to be updated manually (more effort)<br />
- If the data is also stored in other places: risk of becoming out of sync<br />
- Not addressing client needs<br />
- Hard to query<br />
<br />
<b>2. Store parts of the data in office automation and integrate with it </b><br />
Pro's:<br />
- Data is updated, no need for manually updates<br />
- Less risk of becoming out of sync<br />
- Low cost<br />
<br />
Con's:<br />
- Usually quite risky, as business users can access the files and change structures<br />
- Not suitable for large data volumes<br />
- Technically unstable sometimes, and transaction integrity/locking issues<br />
- Hard to query<br />
<br />
<b>3. Store parts of the data in structured form in the process instance</b><br />
This scenario is tricky. My design rule is: keep the process instance very light, as:<br />
- Performance might get bad, when too much data per instance<br />
- Often hard to query on specific items (usually stored as XML/blobs)<br />
<div>
- You never know when the data gets cleaned out (you need strict rules on instance archiving)</div>
<br />
With very light I mean:<br />
- Customer/transactional data is only temporarily stored in the process instance, but as quick as possible stored in a other structure<br />
- Data that is really process instance specific (a contact person name for this order)<br />
- Only keys to the data (customerid, productid) are stored<br />
- Only data is stored that is needed to execute business rules (preferably retrieved from other structure just in time).<br />
<br />
<b>4. Store parts of the data in digital documents (unstructured)</b><br />
Pro's:<br />
- Simple (you will need a Document Management solution, and often a 'Case' concept)<br />
<br />
Con's:<br />
- No reporting on structured data possible (Text mining too difficult)<br />
<br />
<b>5. Store parts of the data in a custom database-structure (linked to a case)</b><br />
Pro's:<br />
- Clear structured place to store data<br />
<br />
Con's:<br />
- Depending on complexity of data, can grow large and complex in terms of effort and architecture<br />
- If the BPMS needs to support multiple processes, each with their own set of data, complexity can become even more<br />
<br />
What I sometimes encounter is that scope explodes, because customers would like access to this data through a non-BPMS user interface: a new data-centric app is born and included in the project. Usually not a nice thing.<br />
<br />
<b>6. Store parts of the data in structured form in a generic Case data - solution</b><br />
In this scenario, we create (of buy) a component in which one can define meta-data schemes per process-class or case type. In each scheme, one can define possible data-elements, <key conditions="" datatype="" possible="" some="" values="">. When creating a process instance or case, the BPMS/ACMS allows users to maintain the defined data-elements. </key><br />
Pro's:<br />
- Flexible, quick to configure and deploy<br />
<br />
Con's<br />
- Can be hard to query<br />
<br />
<b>7. Store parts of the data in a (small/custom) Datawarehouse</b><br />
For some types of data, I would recommend to create a small custom set of Star-scheme tables with the relevant dimensions. This allows to query on performance of processes and tasks, by dimensions as process / case type, period, organization unit, etc. In addition, it would be possible the extent the star-scheme with more transactional data (order volume, price, certain decisions) to allow more complex queries ('In period X what was the total of orders in Euro, in which we refused to deliver')<br />
<br />
<b>Conclusion</b><br />
Data governance can be a tricky question in BPMS/ACMS projects. It not properly handled it can require lots of effort, effort that we rather would focus on the process and BPMS-advantages. If a project is oversold in terms of BPMS/ACMS promises (and we all encounter this from time to time :-)), it can be hard to manage client's expectations and influence the client to select and implement additional components, such as a CRM-system.<br />
As BPMS-specialist I think we need to be honest to the clients on the risks and limitations of the possible scenario's, and help them to make a sound decision.<br />
<br />
<br />
<br />
<br />
<br />
<br /></div>
Roeland Loggenhttp://www.blogger.com/profile/02744153944427657174noreply@blogger.com0tag:blogger.com,1999:blog-36915254.post-83319425066119406652014-08-03T00:42:00.004+02:002014-08-03T00:42:46.999+02:00Need for better standard for integration between BPM/ACM and data-driven applicationsIn many of the projects that I worked in teams with BPM or ACM (Case Management) technology, we encountered the integration-issues with other data-driven systems.<br />
<br />
Typically this would be the result of the following factors:<br />
- The users wanted to perform work on a certain activity, based on a work-item trigger (from a BPM or Case Management solution). They liked the 'inbox' concept (of work to do), sometimes in combination with a Case view.<br />
- As part of that activity, data needed to be retrieved, stored, updated in another existing data-driven application<br />
- The existing application had a fine user-interface (a number of pages dealing with that information), and often exposed through that user-interface were many complex business rules.<br />
<br />
The possible paths for the Solution Architecture are not optimal:<br />
<br />
<b>Path 1. Manual activity </b><br />
Just create a work-item that tells the user to go to the application to perform a certain transaction. Present the right data, if possible, that the user needs to enter/update. Ask the user to report the activity ready when done.<br />
<br />
Pro's:<br />
- Very simple, low investment/low risk from a project-scope perspective<br />
<br />
Con's:<br />
- No contextual frame (see below)<br />
- Risk that activity is declared 'done', while the transaction was not completed<br />
<br />
<b>Path 2. Duplicate the transaction in BPM/ACM, and call a service for the application</b><br />
Design a user interface (1 or more screens, wizards, etc) for the activity, and implement this in the BPM/ACM solution. Create some type of service for the application, to support the transaction from the BPM/ACM solution (if needed, published on an ESB).<br />
<br />
Pro's:<br />
1. Contextual framing of data and functionality<br />
> With a data-driven application, the user needed to assess an activity - what do I need to do - and then translate this to - how do I navigate to the right screens in the application. This takes time and learning, and is not value added (Lean) in the execution of a process. With a BPM/ACM solution, the system 'knows' the context and can present the right contextual frame<br />
<div>
2. Uniform user interface</div>
3. Usually better looking than the 'legacy' datadriven app<br />
<br />
Con's:<br />
- Duplication of user interface and possibly business rules. See below.<br />
- More complex (development work on two sides)<br />
- Possible transaction faults (requiring roll-backs)<br />
<br />
With path 2, a key question is: what are we going to do with the business rules around the data-driven transaction?<br />
A number of scenario's:<br />
<br />
<b>2A: All relevant business rules are duplicated in the BPM/ACM layer</b><br />
Pro's:<br />
- Good user support in the user interface, while working on the transaction (data-checks, lookups, allowed values and value-combinations, etc), reducing or preventing errors or in Lean terms: Poka Yoke.<br />
<br />
Con's:<br />
- Maintaining business rules suddenly requires updates on two places, requiring good business rules governance and risk that business rules will start to differ over time.<br />
<br />
<b>2B: Only direct user interface rules duplicated</b><br />
Only the direct User Interface driven business rules are duplicated, the harder more back end rules are kept in the application, and are used in the service (which may lead to a reject in the service, because certain rules are not met)<br />
<br />
Pro's:<br />
- Less business rules to duplicate<br />
<br />
Con's:<br />
- Hard to sometimes decide what are 'user interface' rules and back end rues<br />
- A work-item that is completed could lead to a failed transaction, requiring error handling functionality, that will lead to additional work-item loops to the user ('Your work-item lead to errors, please correct'). This is not value added.<br />
<br />
<b>2C: No business rules are duplicated</b><br />
In that case, a rather 'dumb' workitem set of screens are presented. All business rules are checked as part of the service call, on the application side.<br />
<br />
Pro's:<br />
- Business rules on one place<br />
- More simple<br />
<br />
Con's:<br />
- Can create user confusion, and higher risks that people enter wrong data<br />
- Requires error handling functionality, that will lead to additional work-items loops (not value added, not first-time-right)<br />
<br />
<b>Path 3: User interface inclusion</b><br />
I have actually never seen this in real life (we always dropped it as a viable solution). In this scenario, in some kind of way, the user interface of the application is included in the BPM/ACM user interface. As soon as a user opens a work-item, the appropriate screen from the application is shown (if possible with populated data from the application and the BPM-work item & process instance data). As soon as the user performs a certain triggering activity, either the BPM-system closes the application screen, committing the transaction in the application, or the application detects the transaction-completion and triggers BPM so that the work-item can be reported ready.<br />
<br />
Pro's:<br />
- No duplication of screen and business rules<br />
- Contextual framing<br />
- User recognizes the well-known screens of the application<br />
<br />
Con's:<br />
- Complex. Most presentation-layer technology has a hard job here<br />
- Triggering to mark the completion (or errorstates) is very complex<br />
- Risk that triggers are lost and application and BPM get out of sync (application has commited data, BPM is not informed)<br />
- User interface variations in the BPM user interface<br />
- Strong coupling<br />
<br />
I have seen various implementations for path A and B. But I am never really happy. What would be a great way out, is that the technology vendors come up with a better integration standard: a standard to expose each user interface from their applications (ERP, CRM, etc) as a service, with some type of metadata exchange on functionality, presentation, and business logic/rules. This would allow BPM/ACM systems on design time or run time to present the right user interaction (but in the UI of the BPM/ACM system itself) ,while using all functionality, data and business rules on the application side.<br />
<br />
Is JCA supporting this? I am not a Java-technie, but I don't think so. Not to this depth.<br />
Of course, there are still complexities, for example what if the transaction granularity and focus in the back-end application is different from the required transactions from the BPM application?<br />
<br />
But a standard in this area would lead to a path 4, that would have a lot of advantages:<br />
- Contextual framing (Value Added)<br />
- Direct checking of business rules (Poka Yoke)<br />
- State consistency (in terms of data, transaction and work-item completion)<br />
- No duplication of business rules and business logic<br />
- Consistent user interface<br />
<br />
Key question: are vendors of data-driven applications open for this? Especially vendors that have their own BPM-layers? I doubt it. Old-world thinking Application vendors might think: 'I don't want my application to become some black-box behind a BPM-layer! How will I compete in terms of brand recognition?'.<br />
But perhaps I am too cynical here, and can Application vendors see the value of providing strong building blocks of data/rules centric functionality, that fit in 'plug & play' in modern BPM-based architectures.<br />
We will see...<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />Roeland Loggenhttp://www.blogger.com/profile/02744153944427657174noreply@blogger.com0tag:blogger.com,1999:blog-36915254.post-38248872701996901322014-07-27T23:04:00.000+02:002014-07-27T23:04:23.699+02:00Five approaches (and maybe six) to process designAs a BPM-specialist, one can encounter different situations for improving processes. These situations will require you to choose wisely from your BPM-toolbox, depending on various aspects such as client strategy, capabilities, trust and risk-appetite. One aspect is the approach you choose to improve a process. In my process improvement projects, I have encountered five different approaches (as shown in the diagram):<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhEAVIF14RhincgljihAZF88L1SBjqOODplXjDrwCAE0C20RJMdIbSBhZc4QKyktuNTonG6wq4psrcSQjH6sWiKZnFb5L0D4yh_6vg1UdArwLICbkoS6eRmUEaGrgK6g7N8X6H3-Q/s1600/5+approaches+to+process+design.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhEAVIF14RhincgljihAZF88L1SBjqOODplXjDrwCAE0C20RJMdIbSBhZc4QKyktuNTonG6wq4psrcSQjH6sWiKZnFb5L0D4yh_6vg1UdArwLICbkoS6eRmUEaGrgK6g7N8X6H3-Q/s1600/5+approaches+to+process+design.jpg" height="398" width="640" /></a></div>
<br />
Let's dive in:<br />
<br />
1. Common sense - incremental<br />
This improvement approach is used quite frequently: gather process participants, analyse the current process and pain points (from outside in, and inside out) and come up with improvement ideas. Pick the ones that deliver most value, in regards to the investment of implementation, and implement. Iterate.<br />
Key characteristics: it starts with was is, and with the people involved, and relatively small steps are taken.<br />
<br />
2. Improvement practice based - incremental<br />
In this approach, a specific improvement practice is selected. Typical examples include Lean, Six Sigma and ToC. Depending on scope and adoption of the improvement practice, various techniques are used on a certain process (such as Value Added Analysis, Root Cause Analysis, Leveling, Kanban, Bottleneck identification, etc). Key characteristics: it starts with what is, with the people involved (trained or guide by a improvement practice specialist), and relatively small steps are taken.<br />
<br />
3. Best Practices / Reference model based - blueprint<br />
This approach is often used, if, besides improvement goals, there are also harmonization goals (multiple locations running comparable processes). The organisation picks a certain reference process and replaces the current process with the reference process (often supported by specific IT solutions, such as ERP solutions). Examples of reference process models include eTom, SCOR, VSM, Scrum, ITIL, the dutch municipality GEMMA processes and SAP's reference processes for various industries and process domains.<br />
Key characteristics: it starts with the to be, more top-down, often less influence of the process participants involved, a relatively large step is taken (although organizations can pilot a process in one location first).<br />
<br />
4. Innovation driven (new business concept or IT) - blueprint<br />
<div>
In this approach a new innovative concept has been adopted. This could be a new business concept (self-organizing teams, case management role, self-service supermarkets, mass customization), a specific technology (cloud, internet of things, BPM/Case Management solutions, digital documents/ECM, eCommerce, mobile, social) or a mix. Typically, as a team you would asses a certain set of processes, and come up with new designs, by asking what the innovation(s) could do for the processes and the involved stakeholders. </div>
Key characteristics: it starts with innovation,specialists assess and come up with the new to be process(es) blueprint, with top support, and implement. Business cases may play a large role, if the innovation requires extensive investments.<br />
<br />
5. Architectural driven Re-engineering - top down<br />
In this approach, a thorough analysis takes place, from a new fresh perspective. All key questions around a business area is re-addressed, often in combination with a renewed strategic positioning. What is our strategy, who are our customers, what value do we want to provide, what capabilities does this require, what functions are needed, what competences, leading down to the to-be processes. <br />
Key characteristics: is starts with the question why what, and through strategy, principles, and implementation decisions leads top-down to a process design, that is implemented.<br />
<br />
So, here are 5 tools for your toolbox. Are there better or weaker approaches? No, it depends on the client situation and requirements. Can you manage all of these? That's a tough question. In my 20 years of process work, I think one can cover these approaches fairly well, but it takes time, effort and opportunity. <br />
<br />
I actually think there is a sixth approach. It's called Design Thinking applied to process design. I am still investigating this approach. More to follow!<br />
<br />
In addition, it's good to know that as part of the approach, as a BPM-specialist you will always need to figure out the type of role you need to take. This could vary from:<br />
- Specialist/Key designer - you bring in the knowledge on improvement and design practices + the know-how on the specific process and possible improvements<br />
- Facilitator, you help key process participants and stakeholder to discover the to-be process<br />
Of course, typically elements of both roles can be needed. I most like the situations were clients want to learn the stuff themselves (as it's their process, their asset!), and I shift over the time from specialist to facilitator / trainer.<br />
<br />
Last, it's also important to understand the change dynamics in the client organization. Is there a pragmatic go-try it and improve culture (promoting incremental - developmental approaches), or a more blueprint driven, think and align before trying (which asks more for a blueprint - approach)<br />
<br />Roeland Loggenhttp://www.blogger.com/profile/02744153944427657174noreply@blogger.com0tag:blogger.com,1999:blog-36915254.post-13484324030673413392014-05-24T23:36:00.003+02:002014-05-24T23:36:52.502+02:00Evolution in business-application alignment<div class="separator" style="clear: both; text-align: left;">
In the 20 years that I have been working in IT, I have seen a shift in the way we try to align business needs and applications. The following diagram visualizes this shift and gives a prediction on what's trending. Note that I see various organizations still working in one of the earlier steps. </div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgFYQp6f3hFZO55sLwHbSbEntnQsAMASCDU7ng1Xg-mePP4cbY9R9PbYJqnEWX-J1Z9tr2dMe3qIZFNo_BE_i3pL3r4JSf6wCnd0pomZL3YzqO5sFvb3s_-4ARyN9916vttMpAp_A/s1600/Evolution+Business-Application+alignment.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgFYQp6f3hFZO55sLwHbSbEntnQsAMASCDU7ng1Xg-mePP4cbY9R9PbYJqnEWX-J1Z9tr2dMe3qIZFNo_BE_i3pL3r4JSf6wCnd0pomZL3YzqO5sFvb3s_-4ARyN9916vttMpAp_A/s1600/Evolution+Business-Application+alignment.jpg" height="316" width="640" /></a></div>
<br />
At level 1, we see organizations that struggle with issues (or have new objectives), that require changes in the application-landscape. At level 1, these issues are directly translated in solutions. Typical situations: business managers with enough power to order direct implementation specific solutions linked to these issues and needs: 'We want system XYZ installed' or 'Please give us 3 new tables in Oracle DB XYZ, so that we can store data XYZ'. In these situations alignment risks are quite high: IT gives the solution, but this solution might likely not solve the business issues (surprise). (Hence the difference between the purple triangle - 'what we wanted', versus the blue circle 'what we got')<br />
<br />
At level 2, we see the first decoupling, where IT-requirements are used. As business analysts, we try to understand the issues, their cause and effect, and come up with traceable implementation independent requirements (functional, non-functional), that than can lead to application design and development.<br />
Working with requirements also supports creating clear priorities. However, depending on the requirement process and content, multiple translations might be required, leading to possible information loss and assumptions. IT-requirements can also result in analysis-paralysis, and Big Design Up Front.<br />
<br />
At level 3, we choose a process analysis focus. We try to understand the issues and needs, from a end-to-end process perspective, and looking from various angles: customer, employee, management giving better context and cause & effect analysis of the issues. Various business and process requirements are defined, leading to various process designs, and possible process - application support scenario's and requirements.<br />
I would call this the BPM-approach. Clear process governance / ownership can support this step, but not all organizations are at this process maturity level. I find that risks of information loss and assumptions is relatively small - business people and IT people can understand the process design and the IT-requirements, through a better contextual perspective,<br />
<br />
At level 4, we see organizations adopting agile model driven technology (BPMS, BRMS, MDA). The big advantage is typically that in very short time frames, applications can be created, evaluated and adapted : what you see is what you get. However, the optimal use of this technology, does require this level of alignment and sufficient process maturity. Otherwise, expensive technology will end up being used in level 1 or 2.<br />
<br />
Level 5 is something new for me, and I am slowing seeing this level appear in some organizations (but still in infant mode, typically). This level is based on Human Centered Design, where customer experience, user experience and employee experience are put centrally. This is still about starting with business issues, but then focusing on human behavior (why are this issues occurring), to what experience do these issues lead, and then trying to find alternatives, test them and iterative refine them, until involved people report sufficiently improved experience and show behavior more in line with business expectations (but these expectations may have shifted, based on new insights during these iterations). As human behavior is difficult to predict, agile research is needed, based on various Design Thinking approaches. It leads to applications that engage. <br />
<br />
Where are you in your organization? And perhaps the answer is: at various levels, depending on the business area and type of application. Here Capgemini's Application Layers come into focus, see http://www.capgemini.com/blog/cto-blog/2013/11/technovision-2014-from-train-to-scooter-0<br />
But perhaps we all end up in 5 and 6. And what's 6? What do you think?<br />
<br />
<br />
<br />Roeland Loggenhttp://www.blogger.com/profile/02744153944427657174noreply@blogger.com1tag:blogger.com,1999:blog-36915254.post-5694561139116467002014-02-27T22:29:00.000+01:002014-05-24T21:02:32.297+02:00Collaboration models for business (process) analysis en design<div class="separator" style="clear: both; text-align: left;">
When doing business analysis and process/solution design, I have encountered various situations with clients. Each of these situations required me and my team to come up with smart ways to come up with a desired future view, with the right consensus from the key stakeholders of the client. </div>
<div class="separator" style="clear: both; text-align: left;">
Some of these ways failed terribly. Some succeeded. Which, of course, triggered me to try to understand what may have caused this. My preliminary analysis has brought many points, and I want to cover one of these in this blog-item: how to pick the right analysis & design approach for the given stakeholder situation.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
Recently I was interviewed, and the interviewer asked me when I would choose what type of analysis & design approach. We came up with the following model: </div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjVBkBWMgj5Qb_vcymAsrXjJSPeqHbJsFLpvW9RuU9kkhOie0d5BVhvKBf1sB2tGLiEPgPtI3wuddebwuorIroCQhmZf63f8TBrY9SQX6fvx6R-ug6tCC8_26O1vIKUB9yZpopf8A/s1600/Models+for+analysis+and+design.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjVBkBWMgj5Qb_vcymAsrXjJSPeqHbJsFLpvW9RuU9kkhOie0d5BVhvKBf1sB2tGLiEPgPtI3wuddebwuorIroCQhmZf63f8TBrY9SQX6fvx6R-ug6tCC8_26O1vIKUB9yZpopf8A/s1600/Models+for+analysis+and+design.jpg" height="467" width="640" /></a></div>
<br />
Two axis (how I love these models :-)):<br />
<br />
<b>1. Stakeholder availability</b><br />
This one is a clear one, and often an issue for process or solution design teams. In many situations, the time we want from our stakeholders is more than they can or are willing to give us, due to other priorities.<br />
<br />
For instance, in a previous project, the department we were working for, was also struggling with a reorganization, a management change and various changing legislation, that all needed attention. The result: we had limited access to key subject matter experts. Trying to schedule long workshops would not have worked.<br />
<br />
<b>2. Stakeholder ability to envision what they want and to formulate it</b><br />
This one is more tricky. It has to do with the complex mix of people involved in your project. How much knowledge do they have of the current situation? How open are they to innovation? How much knowledge do they have of their pain points? How much capability to see other ways/possible improvements?<br />
<br />
For instance, in a previous project, a bank wanted to adopt a document management systeem, with scanning software, to digitally route documents and create more complete customer views. Their knowledge and experience in document management, and in these IT-changes was very limited. Asking them what they wanted would not have given valuable answers. Even in terms of requirements, they needed a lot of work.<br />
<br />
My belief is that in the combination of these two variables, one can find four main approaches for analysis and design of a desired future.<br />
<br />
<b>A. High ability, High availability: co-creation</b><br />
A dream for many designers. Working with people that know what they want, and might even know how they want it, and enough time to dive into details. For me, the approach in this situation is co-creation, in which the competences of the stakeholders combined with the A&D-team are leveraged to come up with the desired future. I usually work with groups and iterations, using facilitated sessions and various work-forms.<br />
In some cases, the A&D-team could even revert back to a pure facilitation-position, but many times still will need to bring in feedback around feasibility.<br />
In my days of BPR/Rapid Application Development, we often could run 2 - 3 week workshop weeks, where we had a full team of stakeholders. Great times, but I see less and less of this, unfortunately.<br />
<br />
<b>B. High ability, Low availability: rapid elicitation and design validations</b><br />
This situation I encountered at a Investment department of an insurance company. These people were security traders, were earning lots of money per hour for the company, and could hardly be missed. They fortunately had a very sharp eye on the issues and required changes in processes and IT-systems.<br />
In this model I choose for one-on-one short interviews and quick validation sessions using very concrete results (prototypes).<br />
<br />
<b>C. Low ability, High Availability: Empowerment and stepwise 'Co-invention'</b><br />
This is a situation I am currently in with a client. We are getting time from a number of people, with sufficient knowledge of the current situation, some knowledge of pain points, but also a lack of understanding of possibilities. And even: in same cases they have gotten used to certain pain points and take them for granted.<br />
Their ability to envision and formulate a desired future is limited (but growing!)<br />
The key point is: people can, and often like to grow. Another key point: all people can contribute value. It is easy to fall in the consultant arrogance-trap 'They don't know, so we will tell them what they want'. This often fails. And if it succeeds, certain gems that the stakeholders could have brought, are lost.<br />
The approach we have chosen in this situation: empower these people with knowledge (solution concepts, technology, requirements formulation, etc.). And work with them, to define, in steps, the desired future, firmly from their perspective and starting points. Make them discover parts of it, by feeding them with concrete possibilities, and then translate back to requirements. In our situation this approach has given many new insights, that were also unknown to us!<br />
<br />
<b>D: Low ability, low availability: Trust based best practice injection</b><br />
So you are given a client, with no time, a burning need, but no real capacity to define the desired future (only to a certain high level extend). Ouch. In this case, the key factors are trust and the availability of certain best practices, proven to work in the client's context. The approach is to adopt a certain best practice framework, and simply go do it. Implement, perhaps in pilot forms, and then learn, adapt, and extend.<br />
<br />
<b>A third factor: the domain/technology knowledge of your team</b><br />
A factor that also influences these choices is the knowledge and experience in your analysis&design team.<br />
If the knowledge in your team is high, all approaches above will work.<br />
Is the knowledge in your team low, then....<br />
- Option A is only possible, if the client accepts your team as purely facilitating (and your team learns very quickly) <br />
- Option B will become demanding. Challenge: how to get the respect of these visionary professionals?<br />
- Option C will become time-consuming, as both the client and your team will need to learn. Challenge: do you have the time, and does your client have the money and willingness?<br />
- Option D will become very risky, don't go there.<br />
<br />
My conclusion: pick the right approach for the right condition! And tell me what you think....<br />
<br />
<br />
<br />
<br />Roeland Loggenhttp://www.blogger.com/profile/02744153944427657174noreply@blogger.com0tag:blogger.com,1999:blog-36915254.post-14998561218691743662013-12-12T00:06:00.003+01:002013-12-12T00:07:31.973+01:00No Process (cross-post from Capgemini CTO Blog)On Capgemini's CTO Blog, I posted this blog-item on 'No Process', as part of Capgemini's TechnoVision 2014.<br />
<br />
<em>Process On The Fly #3 - No Process<br /><br />Building on the next generation of Business Process Management, Business Rules, Event Processing and Case Management platforms, new flavors of process can be modeled, executed, monitored and managed. Guided by context-sensitive and analytics-driven support many fixed, inflexible processes can be replaced by concurrently executed activities that optimize the time of human resources and their knowledge by having them ‘swarm’ around cases and results that need to be produced, never following a predefined path. So in the end, the ultimate Process might be No Process at all.</em>For quite some time, process models, procedures and process-based work instructions have been used to attempt to influence the behavior of employees, in the hope that this creates efficient, customer-friendly and compliant processes. And, as part of IT innovations, Business Process Management technology has been used to create process-aware systems, in the form of workflow systems, that coordinate the execution of processes using these process models.<br />
<br />
Although these process models have their power, they have two serious problems.<br />
<br />
First problem: As an instrument for influencing behavior, process models are not very motivating. Quite the opposite. Most people prefer to leave process models in dusty binders as long as possible. And if they use them, often hesitantly to try to find how to deal with a situation, they frequently get lost (as these models are often incomplete, sometimes quite abstract, and not organized towards the contextual situation-specific approach).<br />
<br />
Second problem: Process models are rigid. When a customer request is delivered following the process model, the model is usually deaf and blind for unexpected events, new insights and needs for other activities or paths. Thankfully, most of the time, employees are smart enough to work around the process when needed, but unfortunately we all encounter enough employees who are not.<br />
<br />
You might compare the use of these process models to driving towards a certain location using a prescribed route that you brought along on paper. You enter a large traffic jam, but don’t know an alternative. You pass a beautiful forest, but don’t want to leave the route as you are scared to get lost. You realize you want to buy some food on the way, but again are afraid to detour. The process model limits your freedom. And then the inevitable happens: An exit has been blocked due to roadwork. The paper process model is suddenly useless.<br />
<br />
Of course, one can attempt to create the all-encompassing model, with all possible events, rules, activities and routes. But this path won’t work. First, the process model will explode in complexity. Second, some situations simply cannot be fully prepared at ‘design time.’ Think of a complex diagnosis and treatment in a hospital – the possible symptoms, causes, possible treatment interventions and patient reaction to treatment. You just won’t know upfront; the process path will emerge, patient by patient.<br />
<br />
In modern car driving, the technology (not perfect, but quickly maturing) to better deal with these ‘process model aspects’ is of course the navigation system. Modern navigation systems offer the strength of a process model (direction: what’s the next move to get from A to B), without the limitations:<br />
<br />
- Context driven: The system knows where you are, and gives you only the relevant information.<br />
<br />
- Responsive: The system offer insights (traffic jams, road blocks) and suggest other routes.<br />
<br />
- Goal driven but flexible: The system doesn’t impose the route – if a driver decides to take another direction, it simply adapts and determines a new route to B.<br />
<br />
- Support compliance: These systems are capable of advising against certain actions (for instance, driving wrongly into a one-way street) using signals and smart routing suggestions.<br />
<br />
Does the driver feel he or she is part of a process? No, not really. That’s why we call the trend that we see in these solutions ‘<a href="http://www.noprocess.org/">No process</a>’!<br />
<br />
These ‘No Process’ solutions are proving their value in business as well. In a business context, they can be seen as flexible case management systems that have swarms of possible activities floating around customer cases. Based on technology for rules and events, for a specific customer case, the system can suggest possible ‘next best actions.’ This supports the employees to handle (navigate) the situations they encounter. In a way these solutions offer ‘just enough process,’ helping employees to pick the best (goal-driven) activity, but allowing the employee to choose another activity or path to deliver the best value.<br />
<br />
No process - The perfect solution for today's knowledge worker times. Have a nice trip to your destination – happy customers and engaged employees!Roeland Loggenhttp://www.blogger.com/profile/02744153944427657174noreply@blogger.com0tag:blogger.com,1999:blog-36915254.post-90913526974754576312013-12-01T23:52:00.001+01:002013-12-01T23:52:12.095+01:00Patterns of coordination (part I)In my<a href="http://process-transformation.blogspot.nl/2013/11/patterns-of-work-and-their-dos-and-donts.html"> last blog item</a>, I described a number of typical work patterns, that people usually pick when faced with the need to work together, in some type of (process) way. The main patterns that I will work in this blog item are:<br />
- Procedure delivery: a pre-defined procedure can be established, which needs to be executed. The procedure might contain various decisions and paths, but all are known beforehand.<br />
- Dynamic adaptive delivery: a set of typical activities (most standard) are known, but the path is emergent (due to unforeseen events, needs or insights). Many possible paths exist, too many to capture effectively in a procedure.<br />
<br />
In this article, I will describe a number of typical coordination mechanisms that people pick how to coordinate the execution of the process, e.g. how are people triggered to get work done, and relate them back to the work patterns.<br />
<br />
<b>Pattern 1: 'Relay race' (Dutch: estafette)</b><br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh9bjscgkwy2GZZ1GejBVATtXhbAfEV5dMxgi1Bv3JE8s8ejMon47D5c5Wwh1AHjCKy4AJCvv8tsaLayRGGT4i8tTy7ODWwTaxrEv8pWZoOl8lAhaTjDz_zNkPNqTwWJBOc88ondA/s1600/RELAY+RACE_905.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img alt="" border="0" height="267" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh9bjscgkwy2GZZ1GejBVATtXhbAfEV5dMxgi1Bv3JE8s8ejMon47D5c5Wwh1AHjCKy4AJCvv8tsaLayRGGT4i8tTy7ODWwTaxrEv8pWZoOl8lAhaTjDz_zNkPNqTwWJBOc88ondA/s320/RELAY+RACE_905.jpg" title="Relayrace" width="320" /></a></div>
<div>
In the coordination pattern 'Relay race', there is someone that starts the process, following a certain trigger (an incoming e-mail, order form, etc). The person executes a number of tasks, and then hands over the execution to a next person, and so on. </div>
<div>
<br /></div>
<div>
This patterns works great for:</div>
<div>
- Procedural delivery(see my previous blog-item)</div>
<div>
Here, each person can find out the next in line, using the procedural agreements (process model / workinstructions)</div>
<div>
- Dynamic delivery</div>
<div>
Here, each person can decide, based on case specifics to whom he or she will hand over to. </div>
<div>
<br /></div>
<div>
Advantages of this pattern: </div>
<div>
- There is always clear ownership </div>
<div>
<br /></div>
<div>
Disadvantages of this pattern: </div>
<div>
- All activity usually takes place serially (where some parallel activities could speed up through put time)</div>
<div>
- It takes time to find out 'where' a case is and what the status is</div>
<div>
<br /></div>
<div>
<b>Pattern 2: 'Cloverleaf' (Dutch: klaverblad)</b></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh-Fh1tMILbY4drAb7BP-oLoyHZkHIrsUewubarxz_GrIPfYQEynZ3b1bsudc_H-AZMrcC45gqQUiYeSQtjfUKbii3nRTv7b_WyVh3MyKBAlTAd-b1UWfXkHxTV-oCtb_TnLpRxng/s1600/Cloverleaf+Process.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="260" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh-Fh1tMILbY4drAb7BP-oLoyHZkHIrsUewubarxz_GrIPfYQEynZ3b1bsudc_H-AZMrcC45gqQUiYeSQtjfUKbii3nRTv7b_WyVh3MyKBAlTAd-b1UWfXkHxTV-oCtb_TnLpRxng/s320/Cloverleaf+Process.jpg" width="320" /></a></div>
In the Cloverlead pattern, there is someone centrally coordinating the execution of the process. This coordinator or case manager will step by step perform certain tasks, then give an assignment to someone, wait, perform some tasks, and then again assign someone a certain activity, until the coordinator decides the work is done.<br />
<br />
This pattern can be used for procedural delivery, but this pattern is expensive, as the procedure is known but in every step, the coordinator needs to take action (e.g. many hand-overs)<br />
<br />
The pattern is great for dynamic delivery, as the coordinator can assess the state of the case, and dynamically decide who should do what next to move forward in the case.<br />
<br />
<div>
Advantages of this pattern: </div>
<div>
- There is always clear ownership</div>
<div>
- The coordinator knows what the status is </div>
<div>
<br /></div>
<div>
Disadvantages of this pattern: </div>
<div>
- All activity usually takes place serially (where some parallel activities could speed up through put time)</div>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhxOpGXysMmH9sYBCQbPFmAWam-waf5sxARhHEKo7s2zH_lX-STsC-53mYdE7-vsBgFcrHhPSU-_04c8v3Ksel2nAYNZaAw1GiKheNbZLb-Y9HJGDG1avoSGGU2jb93Lqf2HI8ghw/s1600/Casusoverleg.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhxOpGXysMmH9sYBCQbPFmAWam-waf5sxARhHEKo7s2zH_lX-STsC-53mYdE7-vsBgFcrHhPSU-_04c8v3Ksel2nAYNZaAw1GiKheNbZLb-Y9HJGDG1avoSGGU2jb93Lqf2HI8ghw/s1600/Casusoverleg.jpg" /></a></div>
<b>Pattern 3: 'Collaborative Planning & Monitoring'</b><br />
In this pattern, a group of people, often multidisciplinary assesses a certain case, and together come to an agreed activity plan. The people will each perform their activities, and will update each other on the status and results.<br />
<br />
This pattern can be used for procedure delivery, but again is expensive, as the procedure is known.<br />
The pattern is great for dynamic execution, if the knowledge required to assess the situation and to decide on actions is advanced, and requires more people.<br />
<br />
<div>
Advantages of this pattern: </div>
<div>
- The team knows what the status is</div>
<div>
- Progress is monitored and social controls can be used to adhere to rules and agreements</div>
<div>
<br /></div>
<div>
Disadvantages of this pattern: </div>
<div>
- It requires quite some time of various people (cost, productivity) for the planning, status reporting and monitoring</div>
<div>
- Disagreements might cause delays</div>
<div>
- Unforeseen events require the response of the group, but people might not be (timely) available, causing delays or risks</div>
<div>
<br /></div>
In a next article I will cover:<br />
Pattern 4: 'Predefined Workflow Driven Orchestrator'<br />
<div>
Pattern 5: 'Situation Specific Configurable Orchestrator'</div>
Pattern 6: 'Flexible Next Best Action Advisor'<br />
Pattern 7: 'Garbage can'<br />
<br />
Roeland Loggenhttp://www.blogger.com/profile/02744153944427657174noreply@blogger.com0tag:blogger.com,1999:blog-36915254.post-70103245886688905282013-11-27T21:33:00.002+01:002013-11-27T21:33:47.032+01:00Patterns of work and their do's and don'tsBased on an <a href="http://process-transformation.blogspot.nl/2008/03/i-read-number-of-recent-postings-on.html">earlier blog-entry</a>, I defined 4 typical patterns of work. In this article, I repeat these patterns of work, as I want to use them to position (in a next article) when discussing various coordination patterns in processes.<br />
<br />
These patterns of work are derived from my observations on how people tend to organize the execution processes that have different characteristics.<br />
<br />
<b>Direct Execution</b><br />
<table border="1">
<tbody>
<tr> <th>Aspect</th> <th>Work pattern</th> </tr>
<tr> <td>Number of employees<br />
involved in specific execution</td> <td>One single employee</td> </tr>
<tr> <td>Process</td> <td>No process (in terms of coordinating activities among multiple employees,<br />
but a single direct set of tasks, performed in coordination with the customer by one employee at one time one place (otopop)</td> </tr>
<tr> <td>Activities</td><td>One standardized activity (which will be composed of various standardized tasks, done by one person directly)</td> </tr>
<tr> <td>Responsibility</td> <td>Clear (based on the job title and responsibilities of this one person, or persons with the same role)</td> </tr>
<tr> <td>Typical situations</td> <td>Call center - answering a question<br />
Buying item in a store</td> </tr>
<tr> <td>Do's and don'ts</td> <td>Do: Provide all data and usable systems the employee needs, and make sure these systems are fast enough. Make sure they have a 360 view on the customer.<br />
Don't: Put them in situations where they can not meet customer expectations</td> </tr>
</tbody></table>
<br />
This work pattern is typically used in service delivery where:<br />
- The service is simple (but might be knowledge intensive)<br />
- The service can be done by one person<br />
- Interaction with the customer can be low to high<br />
<br />
<b>Procedural Delivery</b><br />
<br />
<table border="1"><tbody>
<tr><th>Aspect</th><th>Work pattern</th></tr>
<tr><td>Number of employees<br />
involved in specific execution</td><td>More than 1. People each perform certain activities (as part of their role). A limited number of roles.</td></tr>
<tr><td>Process</td><td>A clear, predefined, process (based on a clear procedure, that defines trigger, activities, roles, decision points with their business rules, and all possible paths). </td></tr>
<tr><td>Activities</td><td>Multiple standardized activities.</td></tr>
<tr><td>Responsibility</td><td>Clear, using roles. </td></tr>
<tr><td>Typical situations</td><td>Processing of incoming invoices, expense claims<br />
Simple insurance claims<br />
Opening a bank account, closing a commodity based insurance contract<br />
Standardized service delivery (McDonalds, simple Public services)<br />
Simple IT-incidents and changes</td></tr>
<tr> <td>Do's and don'ts</td> <td>Do: Create workflow driven solutions, that provide the right contextual information when an employee performs an activity. Use business rules technology to support routing and decision making. Create process visibility<br />
Don't: Force people to go and try to find the status of a certain customer request or force them to manually collect and report performance data</td> </tr>
</tbody></table>
<br />
This work pattern is typically used in service delivery where:<br />
- The service requires people with different skills<br />
- The service can be laid out as a series of predictable steps<br />
- The service is standardized<br />
- Interaction with the customer is low to moderate<br />
<br />
<b>Dynamic Adaptive Delivery</b><br />
<br />
<table border="1"><tbody>
<tr><th>Aspect</th><th>Work pattern</th></tr>
<tr><td>Number of employees<br />
involved in specific execution</td><td>More than 1. Various people with various roles may be involved dynamically. </td></tr>
<tr><td>Process</td><td>An emergent process, as the path at run-time is not clear. Based on inputs, data, new insights and events, new activities might be required, assigned to currently involved employees or other employees, leading to new information, leading to new activities, etc.</td></tr>
<tr><td>Activities</td><td>Multiple standardized activities, and possibly some ad-hoc activities.</td></tr>
<tr><td>Responsibility</td><td>Usually clear, using roles. However, sometimes people need to handle ad-hoc activities that may not be part of their role & typical responsibilities.</td></tr>
<tr><td>Typical situations</td><td>Medical diagnosis and treatment<br />
Invoice disputes<br />
Complex claims processing<br />
Coordinating more complex IT-problems<br />
Legal trial<br />
Handling complex life events of customers (death of partner of customer)<br />
Case management of unemployed citizens </td></tr>
<tr> <td>Do's and don'ts</td> <td>Do: provide an information rich, case based environment, in which case managers can easily plan activities, supported by patterns and next best action suggestions driven by events, data and rules. Think <a href="http://process-transformation.blogspot.nl/2011/05/future-process-app-think-navigator.html">navigator</a>. Provide easy access to the case status, history and information for all participants.<br />
Don't: lock people in with rigid workflows, as they will be forced to 'tweak' the system or place valuable information and work-activities outside of the system</td> </tr>
</tbody></table>
<br />
This work pattern is typically used in service delivery where:<br />
- The service requires people with different skills<br />
- The service can not be laid out as a set of predictable steps, but emerges<br />
- The expected value of the service is (fairly) standardized<br />
- Interaction with the customer is typically high<br />
- During the service process, expected and unexpected events and insights might require unanticipated activities (and support of certain people/roles)<br />
<br />
<b>Collaborative Coordination</b><br />
<br />
<table border="1"><tbody>
<tr><th>Aspect</th><th>Work pattern</th></tr>
<tr><td>Number of employees<br />
involved in specific execution</td><td>Many</td></tr>
<tr><td>Process</td><td>A very dynamic and emergent process, that might (or not) converge to a certain desired outcome, that might not be fully know yet</td></tr>
<tr><td>Activities</td><td>Many ad-hoc activities, very limited are standardized</td></tr>
<tr><td>Responsibility</td><td>Usually unclear, but in some cases supported by roles. People may shift in or out the process, as a result of new insights. A clear owner of a specific execution might lack (when multiple organizations need to collaborate) or might shift due to evolving circumstances.</td></tr>
<tr><td>Typical situations</td><td>- Crisis management<br />
- Creating a strategic plan<br />
- Complex negotiations<br />
- Severe and urgent IT-problem</td></tr>
<tr> <td>Do's and don'ts</td> <td>Do: create clear objectives (and let these evolve over time, and communicate them often), define clear roles and mandates, and let people self-organize where possible. Make sure all information (including decisions) is available in real-time for everyone.<br />
Don't: overstructure the process</td> </tr>
</tbody></table>
<br />
This work pattern is typically used in service delivery where:<br />
- The service requires many people with different skills but also different mandates (for instance partner-organizations)<br />
- A lot of collaboration is needed to converge to a certain result<br />
- The service or expected outcome is not standardized and not clear at the beginning<br />
- Many new insights, events or partner policy / strategy changes can be expectedRoeland Loggenhttp://www.blogger.com/profile/02744153944427657174noreply@blogger.com0tag:blogger.com,1999:blog-36915254.post-87960451777034590622013-11-16T14:59:00.002+01:002013-11-16T15:02:55.612+01:00The 4+2 model for understanding and changing processesWhen you work in the area of process-analysis and improvement, the beginning of process analysis can be complex. There is a lot of aspects one wants to understand. And there is a risk either to miss important aspects, or to be overwhelmed and get lost. The same applies when you improve and implement a process.<br />
Based on these insights some years ago I created the 4+2 model for processes. This model makes it clear that in and around a processes, various areas of activity are present (or need to be implemented).<br />
In addition, it makes clear in what typical areas, some often overlooked, large potential for improvement exists.<br />
<br />
The 4+2 model in a diagram:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgiPwSD26hS4X1djpAdyHmnh8RvaCk2N5ulhN9Fq-S4TVixww3aXuBLnUyy7tYOInFikysDN5QZjy9t5-sTnhUw8yjvrQE5fIjKvtb1tIN8UqiUvvArMSPfo4X0xvHLBpg6y3kMjw/s1600/4+2.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="374" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgiPwSD26hS4X1djpAdyHmnh8RvaCk2N5ulhN9Fq-S4TVixww3aXuBLnUyy7tYOInFikysDN5QZjy9t5-sTnhUw8yjvrQE5fIjKvtb1tIN8UqiUvvArMSPfo4X0xvHLBpg6y3kMjw/s640/4+2.jpg" width="640" /></a></div>
<br />
Let's go through the areas...<br />
<br />
<b>Essential part of the process</b><br />
This is the area that most analysts, especially beginners, start to analyse and understand. These are the core activities required to deliver specific value (in terms of delivering a product or service). The key question here: what is needed to deliver a product or service? It's about value added work.<br />
<br />
For example, let's take the process of requesting a grant, the essential area would be about:<br />
- Receive request<br />
- Review request<br />
- Decide on request<br />
- Inform the requester<br />
- (if positive decision) Pay the grant<br />
<br />
This area is of course essential. But to often this is the area that gets the most attention, and sometimes is even the only area that is addressed. This severely limits your power as analyst/designer.<br />
<br />
<b>Logistical part of the process</b><br />
What is often forgotten is the logistical part of a process. The key question in this area is: what is needed to get the right person to perform the right task, with the right inputs and materials, at the right time. It's about flow, how do we let a request flow efficiently through the organization? Sadly, often this area (and the complex activities that need to take place) is buried in process models in the arrows.<br />
<br />
For example, let's continue to grant process:<br />
- Receive the request by mail, sort them by customer, and distribute them (once a day) to the right team<br />
- Distribute the requests in the team<br />
- Work on the stack of requests in FIFO order, except when Prio 1 requests have been signaled<br />
- Collect all decisions per week (in a folder) and bring this to the financial department.<br />
- Bring the payment tape (weekly produced) to the bank. It takes 3 days for processing.<br />
<br />
This area has often the potential for large improvements (my estimate: 30 - 50%, in terms of time and costs). I encountered one time a situation in which a analyst team had been given the assignment to shorten delivery time of a insurance transaction. Weeks had been spent on trying to cut time, but only looking at the essential part of the process. The progress: several minutes of activities could be saved. But when we started to address the logistical part, we discovered that certain arrows between the activities took 3 - 5 days. What was the matter? They needed to fetch the paper client-folder from another location, and the truck that drove between the locations had a limited schedule, resulting a long wait. <br />
This is the area that deals with queuing, first in first out, and waiting for resources for inputs or inputs waiting for resources.<br />
<br />
<b>Customer journey</b><br />
When understanding a process or improving it, it is important to understand what is required (or what actually happens) of the customer to keep the process going. In many process analysis I still see the swim lane/pool of the customer missing. Optimal alignment of the customer activities/process and the essential + logistical process is required to create a customer friendly delivery.<br />
Note: the customer journey often goes through various processes, as the journey travels through phases such as 'orientation', 'selection of supplier', 'transaction', 'aftercare'.<br />
<br />
<b>Supplier process(es)</b><br />
For certain parts of the process, inputs might be required from suppliers/value chain partners. Again, also in this area it is important to understand the activities and inputs that are required from suppliers, and how these align with the essential and logistical areas of the process.<br />
<br />
<b>Operational and tactical management of the process</b><br />
Where the essential and logistical areas are about 'do', this area is about plan, check and act. This area deals with the management within the boundaries of the process. The key question is: are we doing the process right? <br />
This question is on two levels:<br />
- Operational: how to make sure a specific delivery (such as one specific grant-request) is delivered on the right time, place, quality and cost (as defined in the required process).<br />
<b>- </b>Tactical: how to make sure that the flow (the set of current work in progress) is within acceptable ranges.<br />
Sometimes, analysts take this area into account, but limit themselves to only define key performance indicators, norms and create solutions for dashboards, so that involved people are sufficiently informed on the operational and tactical status. However, this is not enough. One needs to also consider the steering-instruments (what can you do if all the signals are in the red zones?): what interventions can we do to (for instance):<br />
- Operational: make sure that a delayed request is prioritized?<br />
- Tactical: decrease the average waiting time, due to seasonal influences, by adding resources?<br />
Often, there is quite some waste involved in this area of the process. We often see many resources that need to collect, administer/maintain, and report performance data manually. And we see confusion and additional work, when different reports from different automatic and manual systems differ...<br />
<br />
<b>Strategic management of the process</b><br />
The last area we focus on the key question 'are we doing the right process?'.<br />
This is what I would call process management. It's about analysis and interventions in aspects such as:<br />
<u>Alignment</u><br />
- Is the process aligned with evolving customer expectations?<br />
- Is the process aligned with strategy?<br />
- Is the process aligned with IT? Can it be innovated?<br />
- Is the process aligned with HR policies?<br />
- Is the process sufficiently harmonized with other, comparable processes?<br />
<div>
<u>Performance</u></div>
- Is the performance of the process acceptable? Can it be improved? Should we apply Lean?<br />
<u>Experience</u><br />
- What is the experience of the customer (during interactions)? Can it be improved?<br />
- What is the experience of the employees? Does this process create a motivating and engaging environment?<br />
and <u>Maturity</u><br />
- Does the process have the right level of maturity?<br />
(For instance: is there a clear process owner, is it documented, are activities and roles sufficiently established and implemented, are KPI's defined and measured, is there a clear incident/problem & change procedure for the process? etc).<br />
In this area improvement is also possible. Often this part is not implemented (often as a result from, but also amplifying functional silos). And this leads to various inefficiencies, loss of customers, and loss of employee engagement (for instance: if certain process issues have been reported, but never resolved)<br />
<br />
The 4+2 model is one of my key tools to explain, understand and improve processes. I hope you like it too!Roeland Loggenhttp://www.blogger.com/profile/02744153944427657174noreply@blogger.com0tag:blogger.com,1999:blog-36915254.post-86398696797793643792013-11-13T17:30:00.001+01:002013-11-13T17:54:10.666+01:00Images of ProcessWe live in dynamic times. New images of organization appear. New business models. New organization operating models and cultures. New roles. And a growing shift to knowledge workers, dynamic processes and increased autonomy of employees.<br />
What is surprising that in the midst of this all, the images of 'Process' are staying quite fixed. I think this deteriorates the power of process driven interventions. It limits us, through the limited lenses that these images provide, in seeing broader pictures. As more and more organization questions are turning 'wicked', solutions can not be developed in isolation. Other process images are needed, that should help us recognize and integrate key elements of the broader context processes are part of. In the years I have been involved in process innovation and improvement, I have been pondering on this one question - what's a process. What other viewpoints can we find, other images that help us enhance our perspective?<br />
I want to discuss 6 images of process I found, using 6 different definitions. Each of these definitions help us see various of these key elements.<br />
<br />
<b>Definition 1: <i>A process is a chain of activities, executed by various actors, to transform input to output, to provide a service or product to a customer. </i></b><br />
This definition, and tons of comparable ones form our most common image of process. It creates an automatic focus on activities: what happens when why how where and by who. In it's essence, it's fine - it has helped many organizations to increase efficiency and improve quality. It's one of the foundations of the industrial revolution. But it is also limiting us. Let's explore other additional definitions.<br />
<i>Key elements: activities, efficiency, quality</i><br />
<br />
<b>Definition 2: <i>A process is the stuff we do to delight the customer, by providing the right value and experience</i></b><br />
I like this definition, because it helps us to focus on one of the process stakeholders that is critical for the success of people's work within an organization: the customer (internal or external).<br />
This helps us to think outside-in in two ways:<br />
- From a value perspective : what is the need of the customer? How do we provide the right value?).<br />
This is one of the key elements in for instance Lean, to help us focus on understanding the voice of the customer, provide the right value and get rid of waste.<br />
- From an experience perspective : how does the customer want to be treated? What types of interactions during the customer journey (the moments of truth) create a positive experience? <br />
Note that using the phrase 'The customer' has a risk leading to generalization of our customer view. Remembering that customers are all different people is an important step - and segmentation and use of persona's can help us to keep this in mind. Even better - co-creation of process designs is even a better step.<br />
<i>Key elements: customer, outside-in, customer journey, interactions, value, experience</i><br />
<br />
<b>Definition 3: <i>A process is the behavior of a specific group of people and machines, in response to a certain trigger</i></b><br />
This definition reminds us, that in the end, it's about behavior of specific people. We can create great to-be process models, but in the end successful process-transformation is about changing behavior of people. It helps us to discover the value of change management, of personal transformation, learning processes.<br />
It requires us to understand people. And it prevents us from the illusion that you can design a process and roles and then simply 'shove' people in the boxes, arrows and swim lanes. <br />
<i>Key elements: people, behavior, learning, psychology of change</i><br />
<b><br /></b>
<b>Definition 4:<i> A process is a specific game in which various people, with various interests and stakes, attempt to reach certain objectives (which may be be derived from personal, departmental, company or other goals)</i></b><br />
Every process analyst and designer know that improving processes can be tricky business. Various stakeholders around a process have different interests. Perfect alignment is difficult to achieve, but one needs to be aware of these interests and stakes, to be able to come to consensus. Both process design and execution are stakeholder games.<br />
I also like the word 'Game'. Webster defines it as '<span style="background-color: #e8ecf5; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 13px; line-height: 20px;">a physical or mental activity or contest that has rules and that people do for pleasure'. </span>It opens the perspective of gamification, where we can introduce game-like constructs in processes to make them (more) fun.<br />
<i>Key elements: stakeholders, stakes/interests, alignment, consensus or compromises, games, gamification</i><br />
<br />
<b>Definition 5: <i>A process is a social and mental structure in which people can position their activities and collaborations, and in which people might find motivation, safety and meaning through their experiences. </i></b><br />
This definition I am still working on - to sharpen and to digest. It's about an intuitive feeling that processes can help us to create meaning and motivation. To help us find and understand our place in society, organization and various contexts. For me, this is about employee experience en engagement. I see processes that do not create safety (people unsure, insecure and under pressure), do not create motivation (struggling people, with repeated boring tasks and repeated problems) nor (positive) meaning. This definition resonates little with current BPM-thinking, which is, in my view, a shame.<br />
<i>Key elements: people, meaning, motivation, (social/psychological) safety</i><br />
<br />
<b>Definition 6: <i>A process is a living work of art, in which people are in flow and their work and interactions form a choreography with aesthetic value</i></b><br />
Have you have been part of a team-effort, in which you felt a deep appreciation of the beauty of good collaboration? Where activities almost had a musical rhythm? The feeling of 'check check check'. The feeling of 'yes yes yes'. Perhaps you have seen it in sports, where certain games transcended winning or loosing, to pure fun and flow. Or when you where dancing with someone (salsa, tango), and the moves of you and your partner blended in beautifully.<br />
Maybe, deeply, this is what we all are looking for - creating the conditions for people to thrive, to be able to work in deep flow, and create beautiful performances of experience for all stakeholders that are involved.<br />
<i>Key elements: flow, beauty, thriving</i><br />
<br />
These are the images I have at this stage in my development. I have felt that all of them have enriched my work as process consultant. Seeing broader perspectives and bigger contexts. Adding more value.<br />
<br />
What images of process do you have? How have they helped you to see new perspectives?Roeland Loggenhttp://www.blogger.com/profile/02744153944427657174noreply@blogger.com1tag:blogger.com,1999:blog-36915254.post-68992911047805589062013-11-08T17:27:00.001+01:002013-11-08T17:29:01.577+01:00The role of Design Thinking for creating optimal experiences through your channels and processesI posted an entry on the Capgemini CTO blog about the importance of Design Thinking<br />
<br />
<a href="http://www.capgemini.com/blog/cto-blog/2013/11/technovision-2014-think-design">http://www.capgemini.com/blog/cto-blog/2013/11/technovision-2014-think-design</a><br />
<br />
Do read the other entries on TechnoVision 2014, interesting concepts and insights!<br />
<br />
My article: <br />
<br />
<em>Design For Digital #7 – Think Design<br /><br />Customers and employees interact, transact and work with organizations through a growing myriad of channels. Their experience during these interactions make them loyal to an organization or leave them forever: it’s a key differentiating element. And indeed, for consistent positive experiences to happen, they need focused attention from you. To create the right stage for customer and employee experiences, turn to Design Thinking. Make sure that you apply Design Thinking in your digital transformation efforts, including the design of your services and processes. Build the right consciousness, desire and capability to design and deliver compelling experiences, from an radical outside-in perspective. Delight!</em><br />
<br />
Let’s start with a definition: ‘Compassion: sympathetic <u><a href="http://www.merriam-webster.com/dictionary/consciousness">consciousness</a></u> of others' needs and experiences, together with a <u>desire</u> to fulfill the needs while creating a positive experience’ (Webster dictionary, with some twists). How is compassion doing in organizations? Quite some research, including from Capgemini / MIT shows that customer experiences are far from optimal. In addition, various research shows that many employees are disengaged. That these two findings relate is only logical.<br />
<br />
Yet, most organizations truly have the desire to fulfill the needs of their customers and employees. The key issues they encounter:<br />
<br />
- Most services and processes develop stepwise, without looking at the whole and without being sufficiently consciousness of the needs and experiences of customers and employees.<br />
<br />
- It’s not easy to design and create integrated and consistent customer experiences over various functional units and channels.<br />
<br />
If you want to differentiate, turn to Design Thinking as a key, foundational element in your digital transformation.<br />
<br />
A number of essentials elements that make up Design Thinking:<br />
<br />
<strong>- Purposeful</strong> – Customers and employees have needs and want to fulfill them. In their own way. The steps they will take for this are often referred to as the ‘Customer Journey’ (but don’t forget the Employee Journey..). During this journey, they will typically interact with many of your channels, functional silos and IT solutions. And they will go through various emotions. You will need to understand their end-to-end journeys, their emotions and you will need to understand how to respond to them, with an integrated design.<br />
<br />
<strong>- Human centric</strong> – Forget ‘customer’, ‘user’, ‘employee’. We are all humans, not pegs that want to fit an organization’s services or internal process. Everybody has various needs and emotions, different beliefs and values. If you want your customers and employees to have great experiences, you will need to understand them (personas), and even better: collaborate and co-design with them.<br />
<br />
<strong>- Iterative</strong> – Customers and employees can’t tell you precisely what they want. As understanding humans and designing optimal experiences can be complex, you will need an iterative approach, in which you mix research, creativity, intuition and experimentation. Take a fresh, outside-in perspective on existing websites, mobile applications and other digital channels, and the other moments of truth. Apply a mix of craft, art and science, to come to the right enough answers (designs) and new insights to improve them.<br />
<br />
Building a design thinking capability requires new skills (human research, creative design, concept testing, co-creative dialogues), new roles (UX designer, service designer) and new innovative approaches. Invest in Design Thinking and use it to reshape your services, channels and your Business Technology Landscape. Your first step: start with piloting Design Workshops for defining and designing new products, services and enabling IT capabilities.<br />
<br />
Trust us, it will give you a new experience. And don't forget: it's all about compassion.Roeland Loggenhttp://www.blogger.com/profile/02744153944427657174noreply@blogger.com0tag:blogger.com,1999:blog-36915254.post-24295454765050732572013-04-02T20:46:00.001+02:002013-04-02T20:46:40.579+02:00Towards meaningful and motivating workplaces, delivering great serviceLately, I have been diving a lot in a number of very interesting area's:<br />
- Service Design<br />
- Positive Psychology<br />
<br />
What does this have to do with BPM?<br />
<br />
In my view, we might be looking at something that is going to converge towards a new view on organizations, processes and workplaces.<br />
<br />
Let's start with Service Design: a growing field of insights in how to create services. Service that deliver value for the customer and the organization. Services that create the optimal customer experience, personalized where possible. Service designs that are co-created, tested, improved. Service designs that are based on really investigating people behaviour and dialogue, to understand reasons, cause and effect. Service design bringing key concepts of Experience, Moments of Truth, Customer Journey, etc.<br />
My big discovery was that Service Design focus is not only on customer and value for the organization. It is also focuses on employees. And that's strong. Employee experience, employee motivation and engagement are key to drive customer experience and people's happiness in general. Employees have moments of truth as well. And within bad systems, employees can have a lot of bad moments of truth. This not only creates unhappiness (and potential exits, illness, etc) but leads in general to unhappy customers. We all have had our share of service delivered by grumpy people.<br />
<br />
Now, would it be possible to create happiness in organizations? Based on a growing set of research on positive psychology (<a href="http://en.wikipedia.org/wiki/Positive_psychology">http://en.wikipedia.org/wiki/Positive_psychology</a>) I think yes. Many books have been published, and check out Ted.com and the internet for great findings in this area (Seligman, Achor, Fredrikson, Boyatzis). Positive psychology, as the evidence based sequel to humanistic psychology, delivers quite some insights in what can make us happy. According to Seligman: <span style="background-color: white; font-family: sans-serif; font-size: 13px; line-height: 19.1875px;">Positive Emotions, Engagement, Relationships, Meaning and purpose, and Accomplishments.</span><br />
<br />
I think it is time for incorperating these new views in our toolbox as process designers. BPM as a discipline for process design and innovation has typically had its focus on factors as efficiency, compliance, productivity, quality, and customer satisfaction. Nodding? Well, where is the employee?<br />
I think it's time to link BPM back to Organisational Development. Helping employees to create positive, engaging, meaningful workplaces. Using service design and positive psychology.<br />
<br />
And to conclude, don't do it for them, do it for yourself: The typical process designer comes in and tries to find bottlenecks, issues, problems. Literally every day we train our brain to see what's bad, what's missing. Well, that does not help you to become happy....<br />
<br />
<br />
<br />
<br />
<br />Roeland Loggenhttp://www.blogger.com/profile/02744153944427657174noreply@blogger.com0tag:blogger.com,1999:blog-36915254.post-79063211977866025082013-01-22T23:38:00.002+01:002013-01-22T23:42:55.374+01:00APMG's Organizational Change Management Certification relevant for BPM specialistsRecently I followed a training at my employer to get certified (through two exams) for the APMG (Organizational) Change Management practioner-role. More information on the training <a href="http://academy.capgemini.nl/opleidingen/projectmanagement/change-management">here</a> (Dutch).<br />
<br />
For more information on the certification, check <a href="http://www.apmg-international.com/en/qualifications/change-management/change-management.aspx">the official site</a>. APMG is also the institute for other well known certifications such as PrinceII and MSP.<br />
<br />
(Note: this training of Change Management is not related to ITIL change stuff, or processes that deal with scope change in projects. This is oriented at changing people in organisations - Organization Change Management/OCM, or "Veranderkunde" in Dutch)<br />
<br />
The course and exam is primarily based on the book "Making Sense of Change Management" (<a href="http://www.makingsenseofchange.com/">link here</a>).<br />
The strength is that it is a eclectic exploration of different views, schools and approaches. So not a simple "follow these 10 steps", but much more contingency oriented, with a broad view on approaches, and (mostly) honest discussions on applicability, strengths and weaknesses.<br />
<br />
Contents include:<br />
- Views/approaches on individual change (each organization change requires individual people change)<br />
- Team development<br />
- Metaphores of organizations<br />
- Organization change<br />
- Styles of leadership for change<br />
- Change readiness assessments<br />
<br />
In my opinion, a very relevant training and certification for BPM specialists. Why?<br />
From some distance, most what we do as consultants is influence behavior:<br />
- To make people aware<br />
- To help people (power) to decide change<br />
- To help people adapt to changes<br />
In that light, BPM can be seen as a set of interventions to help decide, direct and change behavior.<br />
Because in the end, most processes in my opinion, can be defined not so much as "a series of activities transforming input to output", but much more as "the behaviour that a set of people show, after a certain trigger". If you want to improve processes, you (hope to) change behavior in real people, not diagrams or (just) BPM engines.<br />
<br />
Seeing the enormous amounts of failed innovation, IT and process improvement projects, knowledge of the change part is essential for a BPM specialist. Any BPM project is a change project. This training will broaden your view, make you aware of various approaches and will fill your toolbox!<br />
<br />
Did I miss things - sure. The book and the course did not go into (for instance):<br />
- Various types of interventions in more detail<br />
- Process centric change<br />
- Typical BPM interventions<br />
- Motivational theory<br />
- More modern approaches on team & artifact development (service design, SCRUM, etc)<br />
- More modern approaches on personal development (ACT, Mindfullness, Appreciative Inquiry)<br />
<br />
And the book is UK/US focused. In the Netherlands (and likely in other countries too) there is a wealth of research, views and approaches that were not covered in the exam (but were, high level, provided in the course by Capgemini).<br />
<br />
Eye opener for me: many of the modern approaches are simple repeats and refinements of ideas that have been around for ages. We are (often unaware) standing on the shoulder of giants!<br />
<br />
A good course and good exam. Recommended.Roeland Loggenhttp://www.blogger.com/profile/02744153944427657174noreply@blogger.com0tag:blogger.com,1999:blog-36915254.post-65216501600009720272012-12-15T03:20:00.002+01:002012-12-15T03:20:20.563+01:00My BPM prayer for 2013Prayer? No, I am not religious. But in the coming months there will be the lot of BPM prediction lists from the various blogs. Always fun to read. Take a basket, throw in the current buzzwords (social, big data, cloud), mix with some insights and publish.<br />
I wanted to take another approach this year. Not so much what I expect to happen, but more what I really hope to happen. Comments welcome! And an early: happy holidays. <br />
<br />
<strong>Design for experience</strong><br />
I do processes, because for me it's one of the core interventions to focus on value. And I love that value is getting a broader sense in BPM. Nut just the end product, or efficiency, speed. But the realization that people that want a service are complete whole people, that experience interactions. And that hope that these experiences are positive, helpful. So, I pray that we design for positive experience. Because there are still quite some bad experiences out there. <br />
And I hope that we don't pidgeonhole people in "customer", "user" or worse "some abstract entity that submits data, and is send the product", but as whole people. <br />
I would love to see more psychology and antropologhy enter the field of BPM.<br />
<br />
<strong>Design for meaning and motivation</strong><br />
I also do processes, because for me it's one of the core interventions to create meaningful workplaces. Workplaces should be rewarding, educating, fun, places for growth. Often they are not. Face it, we all spent major parts of our lives in workplaces. Valuable life time that we can spent only once. And the deeper needs that we have are often not well understood or addressed. <br />
The machine-like concepts behind many of the BPM-thinking stiffle our ability to design for meaning and motivation. KPI's motivating? Come on. Process models that thrill us to all change? Come on. <br />
I would love to see new language appear on concepts in BPM around motivation, inspiration. How to design processes, that support people to do the things they like. <br />
<br />
<strong>Co-create, on staying out of the silo</strong><br />
Be honest, ever found yourself in an office, cubicle, some remote place, far away from the complexity of the workplace? In front of your screen, with the assignment to "improve the process". And busy clicking in some tool, making a beautiful process-diagram, that is just going to awe the manager to the max? Stop. You are living in a dream. It's never going to fly. <br />
Go to the complexity. Dive in. Be shy, scared, but still go on. Talk to the people. Involve. Ask. And let them decide on what the improved process is. Be the facilitator. Influence. Help them to see new possibilities. Even better: let them see you even better possibilities. Be confused. Learn. <br />
I am reading a beautiful book on Organization Development (and it's history). This is not new - this co-creation stuff has been there for decades. But we all, personally, have to give up the illusion that we can sit there, in our silo, and create perfect solutions. <br />
<br />
<strong>Real working software, as opposed to ACM/BPM battles</strong><br />
A lot of discussions the last years on ACM/BPM. Don't get me wrong, I learn a lot of the likes of Max Pucher et al. Insights in complexity of work. Of people interaction. And let's make things simple: things are never simple. Any piece of software will be based on an abstraction of the complexity of work & interaction. Thus will have it's limits. And while the discussions on the views and concepts behind this abstraction are valuable, let's not forget that in the end, the value is in the eye of the beholder: the actual users. And the typical manager/user I speak, does not really care for these abstract discussions. They want software that supports their work. Not perfect, but good enough. Real working software that is, not abstractions. So let's go out there, make it work, and share the lessons on what (not) worked, not the rants. <br />
<br />
<strong>On economic crisis, carreer perspective and ethics</strong><br />
In the BPM automation projects I am involved in, the patterns are quite simple: use BPM automation to cut cost, cut cost, cut cost, and add some quality and flexibility please. In the labour-intensive service processes I am involved in, this means cutting work. Using straight through processing and performance optimizing tools to make people more productive, and thus more people redundant.<br />
Technology might be neutral, applying it is not. BPM automation projects have real effects on real people: typically, I see major cuts in lower educated administrative workers. And it worries me. Sure, from a business case perspective we understand. From a public services perspective also: we all want to have lower prices, and more effect from our taxpay. But the cause-effect is simple: apply BPM automation, fire people. And I wonder: if all organizations will be doing BPM automation, what work will be left for these people? What can society offer? Are we growing towards a society in which we have highly oiled, well functioning small units of service delivery, with highly paid managers, knowledge workers and IT-staff? The upper class? And the rest trying hard to make ends meet? <br />
We need a vision on future work. On the ethics of BPM automation. And on meaning & dignity & perspective of the "lower" workforce. <br />
<br />
Roeland Loggenhttp://www.blogger.com/profile/02744153944427657174noreply@blogger.com0tag:blogger.com,1999:blog-36915254.post-25425450142975250622012-10-03T22:16:00.001+02:002012-10-03T22:16:09.356+02:00BPM replacing ERP? I think not.To start - I am not a fan of "old school" ERP. The massive, late 90's, ERP implementations with dozens of eager Accenture consultants, and endless "customize or standardize" never impressed me much. And the control and agility promisses were highly overrated. So when anyone comes with a tool that can replace ERP, I am much interested.<br />
However, if I read blogs stating that ERP is being replaced by BPM technology, I shiffer.<br />
Don't get me wrong, I love BPM technology, and the changes that it's bringing in Business-IT alignment.<br />
But a simple comparison of functional features of a BPMS versus an ERP shows that there are many ERP components that are not, or not well covered by BPMS. Of course, there as BPMS vendors that have BPMS solutions with larger featuresets and smaller. But on average, there is still a gap.<br />
<br />
In that light we have been working at Capgemini at defining what could replace ERP. Our first focus was the services industry (and even more specific: Public administration). Based on our own experiences in platform renewals, and by studying many tenders, we were able to define a quite complete set of functionalities required to support public administrative service processes in a complete, yet agile way.<br />
<br />
The combined set we call our "Model Service Delivery Platform". I can't go into all details at this stage, but here are a number of typical functionalities required in public service delivery:<br />
<br />
- Customer portal - submitting requests, track & trace<br />
- Customer contact center portal - answering questions, track & trace<br />
- Knowledge worker portal - allow workers to access cases and perform tasks, manage performance<br />
- Process engine - for straight through processing and human tasks coordination<br />
- Decision management engine<br />
- Case management - services for gathering and presenting case information, and coordinating processes and adhoc tasks<br />
- Scan & indexing facility - for paperbased request<br />
- Document management solution - for storing digital documents/cases, to support service delivery and comply with records regulations<br />
- Document generation - to generate documents (and also technical messages)<br />
- Value chain integration - to request information from other parties, or update other parties in the value chain<br />
- Operational management information - for workers and supervisors to manage service delivery<br />
- Improvement management information - for analysing and improving process performance<br />
- Data storage, query and management services for storing customer, request/product data, decisions<br />
- Identity & Access Management<br />
<br />
Interesting to see is that there are quite a number of technical implementation scenario's possible to support these functionalities. And that's what we see and do for clients. Examples: CRM centric, ECM centric, BPMS centric, Bespoke parts.<br />
But the key conclusion: we do not see any BPMS covering all these area's well.<br />
<br />
It leads of course to a discussion: what is a BPMS? What are it's boundaries? My point: If I buy a BPMS, that also contains a well integrated Java development environment, and I implement the functionalities above with 10% process automation, and 90% Java, be honest: I can't say BPMS replaces ERP.<br />
<br />
So for now, BPMS is not replacing ERP in my opinion. It's bringing very strong components that are very powerful and play a central role in our service delivery platforms. But most service delivery platforms are still a larger set of technical components, and BPMS is just one of them.<br />
It's the reason why many isolated point solutions, based on BPMS centric implementations, stay small, or in the end get eaten by a larger architecture, with other technologies.<br />
<br />
What the future will bring?<br />
I see three directions:<br />
- BPMS as platform for strong, but small point solutions (which needs integrations)<br />
- BPMS vendors growing towards completer service delivery platforms (as we see in the Oracle Fusion approach)<br />
- ERP vendors that innovate, and adopt these strong business technology components (ACM, BPM, BRM)<br />
<br />
If scenario 2 and 3 do not happen, the larger IT-transformations/innovations at service organizations will stay complex programs with quite some integration work. This may seem of benefit for system integrators, but believe me, we rather see integrated platforms in which we can only focus on value for the business. Hence, our "model service delivery platform". (or in my language "Model Uitvoeringsplatform").<br />
<br />Roeland Loggenhttp://www.blogger.com/profile/02744153944427657174noreply@blogger.com2tag:blogger.com,1999:blog-36915254.post-90152252982687523712012-09-23T22:34:00.001+02:002012-09-23T22:38:44.194+02:00Service design and BPM - a great matchFor a number of years, a lot of new language and concepts have been developed covering something we now call "Customer Experience".<br />
<div>
<br /></div>
<div>
Think of...</div>
<div>
- Channels, multichannel strategy</div>
<div>
- Touchpoints</div>
<div>
- Moments of truth</div>
<div>
- Customer value</div>
<div>
- Customer expectations</div>
<div>
- Customer experience</div>
<div>
- Outside in thinking</div>
<div>
- Customer journey</div>
<div>
<br /></div>
<div>
A number of these concepts we already knew from Lean, especially Voice of the Customer.</div>
<div>
<br /></div>
<div>
For the services industries, these terms have been blended into an approach, set of powerful tool : service design (sometimes also called Service Innovation). A great development: design thinking as approach for creating great customer experiences through services. </div>
<div>
<br /></div>
<div>
In my opinion, Service Design and BPM have a lot of added value to each other, and to service businesses. </div>
<div>
At this stage Service Design is not very strong in process design from an efficiency/operational excellence perspective. And it is unaware of questions around process governance, process maturity, ongoing process improvement (from an inside out and outside in perspective). BPM can help here, including Lean. </div>
<div>
<br /></div>
<div>
BPM is not very strong in the outside in thinking area. Yes, we do have VOC (from Lean). And the general notion of customer orientation and outside in thinking. But in it's discipline, it has missed the language, concepts and (evidence based) approaches. How many process diagrams I see, where the customer swim lane is missing....</div>
<div>
Service design is a great help to help us understand for who we design processes: for the end-customer primarily.</div>
<div>
<br /></div>
<div>
For all BPM-specialists, do check out "This is Service Design Thinking". </div>
<div>
<a href="http://thisisservicedesignthinking.com/"><b style="background-color: white; color: #009933; font-family: arial, sans-serif; font-size: small; line-height: 15px;">http://thisisservicedesignthinking</b><span style="background-color: white; color: #009933; font-family: arial, sans-serif; font-size: x-small; line-height: 15px;">.com</span></a>
</div>
<div>
<br /></div>
<div>
For all Service-design specialists, do check out BPM (and it's many books and websites!)</div>
<div>
<br /></div>
<div>
An interesting development (as far as I understood in my meetings with service design agencies) service design is also attempting to address on of the missing links in BPM: How to design processes that not only create a great customer experience, but also a motivating and rewarding employee experience...</div>
<div>
<br /></div>
<div>
And a last observation: as BPM-specialists we are in the services industry ourselves. We work with many stakeholders attempting to help design and implement great processes. Every thought about the customer experience of that work? Service design can help us there as well. It explains why and how we can pick interventions that are motivating and value adding for our stakeholders, in their customer journey to great processes.</div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
Roeland Loggenhttp://www.blogger.com/profile/02744153944427657174noreply@blogger.com0tag:blogger.com,1999:blog-36915254.post-4538166202942807482012-09-14T23:33:00.001+02:002012-09-14T23:33:11.650+02:0010 OCM-consequences of introducing a BPMS/ACM solutionI am currently quite busy guiding the implementation of a Case Management Solution for a public sector client. My focus is the Organizational Change Management (OCM). And I have been working with this client to prepare them on the business & IT side for all consequences of introducing BPMS/ACM based solutions for various processes, realized on a generic shared platform. This OCM approach is vital, as many BPM/ACM projects tend to focus most attention to IT-aspects, and forgetting the business & IT-support side.<br />
The last weeks we have simply been identifying and discussing consequences and critical succes factors that need to be taken into account when introducing BPMS/ACM solutions. Note that the implementation we are doing, includes digital documents (ECM, scanning solutions).<br />
<br />
Here is a list of consequences and CSF's that we have identified. It serves in my opinion as a good checklist for most BPMS/ACM implementations.<br />
<br />
<b>1. The daily routine of workers and managers will change a lot. </b><br />
Most organizations come from a situation, where they work with a mix of paperfiles and data entry IT-systems. The switch to full digital documents and a process guiding system is quite a change for people, and requires the right change approach, with various interventions (from involving the users in Agile/Scrum to training and other enablement activities)<br />
For coordination and management things also change considerably. Typically management information is collected using various meetings, spreadsheets and IT-queries. The modern BPMS/ACM solution has near-realtime dashboards.<br />
The best practice: have a OCM-stream in your BPMS/ACM project/programme.<br />
<br />
<b>2. The possible service concepts and customer facing processes can be innovated</b><br />
Many organizations are working with modern eBusiness/eGovernment channels (web, mobile), as well as Customer Contact Centers (phone, email). With the right linking, case handling can be linked to these channels, creating more possibilities - for instance for customers to digitally submit requests, track & trace cases and get automated alerts when status changes (through SMS, email, etc). And for customer contact centers, these BPMS/ACM platforms are great to quickly determine status or to fire questions to the back office employee handling a certain case. In the silo-based architecture, this was all often quite difficult to achieve. <br />
Best practice: review your service concept, and if needed, apply service design / service innovation.<br />
<br />
<b>3. Capacity demand for various competences will change</b><br />
Many organizations have people dealing with administrative tasks around paperfile handling. Storing, searching, finding, distributing, adding documents, archiving. All this work can be reduced significantly, using ACM solutions with digital documents. This leads to cost saving opportunities, reducing FTE's. But to actually realize these savings/business case, FTE reduction needs to be started.<br />
Best practice: have a clear business case and FTE-reduction plan<br />
<br />
<b>4. A lot of operational management data will be available. But correctly used as well?</b><br />
As said, BPMS/ACM solutions can provide quite some insight into the operations: cycletime, workload, utilization. This requires a good steering model: what do we want to measure and why, and what do we do if measures signal potential issues. It also requires competences on the management level to handle this data and act correctly, and a clear responsibility model.<br />
Best practice: improve the maturity of measuring & steering<br />
<br />
<b>5. Have a clear scope for process analysis and improvement</b><br />
To implement processes in the BPMS/ACM solution, process analysis is mandatory. But this analysis can also be done to identify improvements. It is important to have a clear, and shared understanding of the process scope:<br />
- 1 on 1 transfer to the BPMS/ACM solution<br />
- Standaardize / harmonize only<br />
- Improve minor things<br />
- Redesign, with innovations such as straight trough processing, business rules<br />
- Redesign, with co-creation, Lean and outside in Service Design approaches<br />
Best practice: have a clear scope<br />
<br />
<b>6. Standardization versus TCO</b><br />
When using a shared platform, re-use can potentionally bring a lot of value to the BPMS/ACM efforts. This can be standardisation for processes, for management info/steering model and for IT-components. However, harmonizing and standardizing these items require strong governance, and requires negotations. If this is not management, variation and complexity will drive up cost of the solution (TCO)<br />
Best practice: standardize where possible, local variation where needed<br />
<br />
<b>7. Process management maturity will facilitate the BPMS/ACM efforts</b><br />
When introducing an BPMS/ACM solution, the more mature processes and process management is, the better. Process management maturity is linked to items such as:<br />
- Processes are identified and have been documented<br />
- Documentation is being kept up to date, and compliance is checked regularly<br />
- KPI's have been identified, and are measured<br />
- There is clear ownership of the operational management of processes<br />
- There is clear ownership for the tactical / strategic management of processes (strategy alignment, reactive and pro-active process improvement)<br />
- A PDCD cycle has been implemented<br />
- A process culture has been established<br />
Best practice: implement BPMS/ACM solutions as part of BPM as a discipline, or try to start a linked effort<br />
<br />
<b>8. Using a shared BPMS/ACM platform for multiple processes requires different IT-governance model</b><br />
In most silo based organizations, IT governance is also silo based. When a company switches to a central platform for (in the future) all processes, another type of IT governance (demand-supply) needs to be implemented.<br />
<br />
<b>9. BPMS/ACM solutions bring agily - but only with agile people and processes</b><br />
BPMS/ACM solutions make use of business technology: what you model is what you execute. Part of the solution becomes maintainable by people that have a combination of business & IT-skills (instead of the hardcore techies). By making sure that the most changing aspects are implemented in agile business technology and by placing these people close to the business, surrounded by fast processes, agility can be achieved.<br />
<br />
<b>10. A shared solution creates depencies and risks</b><br />
As a company moves from silo IT-solutions to a shared BPMS/ACM solution, the dependency of single point of failure/frustration is created. This requires a strong focus on non-functional technical aspects - availability, recovery and performance, as well as focus on useability (advice: add an interaction designer to any BPMS/ACM effort).<br />
<br />
Input welcome!Roeland Loggenhttp://www.blogger.com/profile/02744153944427657174noreply@blogger.com0