The 9 building blocks of process management

 

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? 

In our organization, but probably many more, we have had many discussions about these questions. 

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!

Our process management framework / 9 building blocks: 

1. Clear overview of processes, clear roles & governances and... committed ownership

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. 

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. 

Then roles need to be assigned, people need to be trained and coached. Key requirement: really committed people that want, can and do. 

2. Standards

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. 

3. Execute process

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. 

4. Manage the execution

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. 

5. Manage improvements

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. 

6. Deliver improvement  

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. 

7. Plan and manage alignment

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? 

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. 

8. Develop people and process (management) maturity

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. 

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. 

9. Engagement, personal leadership and culture

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.  

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!

5 critical capabilities of organization systems

If you view an organization as a (complex) system, there are five key capabilities the system must have to successfully thrive in it's environment.

Capability 1: The ability to deliver and exchange value 
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).
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.

Capability 2: The ability to optimize the delivery and value exchange
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.

Capability 3: The ability to adapt to changing needs of the environment 
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.

Capability 4: The ability to innovate and deliver value to new needs in the environment
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?)

Capability 5: The wisdom to manage the previous four capabilities
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

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....

Improvement? In the end, It's about learning to be resilient

In my last post, I defined process from a systems thinking perspective as "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". 

Funny: I have been working with architecture for some years already (still learning), and manage to overlook the Archimate definition of a process: "A business process represents a sequence of business behaviors that achieves a specific outcome such as a defined set of products or business services."
There we have it again: behavior.
Socio-technical systems show behavior, leading to certain outcomes.
A great book on systems thinking is the "Thinking in Systems - a primer" by Donella Meadows.  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.

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 Resilience - "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.

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."

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 negative effect on resilience.
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!
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."

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."

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?

Well, I think it's the ability of the people in the system to collectively learn and adapt!

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).

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.

(I guess the next post will require me to dive into first & second order learning)

Systems thinking for process professionals

Systems thinking 
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 systems thinking. I followed a number of engaging MOOC's, read some great books and read many internet articles (more on this below).

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.

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.

My struggle with the current definition and views on the concept 'process'
To start - a confession: I have always struggled with the definition of process. It's usually something like "a series of activities, executed by people and machines that convert certain inputs to outputs and produce value". 
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.
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.
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.

Towards a new notion of the concept 'Process'
From that previous observations I define a process as "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"
This definition directly leads to a number of better perspectives on process analysis, process change and process management/ownership.
1. If you want to understand 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
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
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?
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.

A very short introduction to systems thinking
A system is defined as: 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" (Donnela Meadows, page 188)

Some aspects:
- Components can be things, people, machines, ideas, policies/laws, etc)
- Interrelations are ways that parts influence each other - through certain flows, such as chemical, electricity, material, money, information, power-influence
- 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.
- 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)

Systems thinking in essence is:
- Learning to zoom out and see the greater whole (holistic/synthesis and abstraction)
- Identifying useful boundaries (what is the system, what is outside the system)
- 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)
- See the parts and interrelations of the system itself (what is there and how do these things influence each other) (analysis)

Some great insights I found:
- 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...
- Every system simply works towards its purpose and produces certain outcomes. There is no right or wrong, there is nothing broken. Whether we like these outcomes, want them, is another question. If not, we will need to understand and intervene in the system.
- The reason that certain (unwanted) outcomes are produced is often not a linear chain of causal effects (e.g. a why-why tree) 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.
- 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.
- 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.
- 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.
- 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.

Systems Thinking has come with great analysis tools. Some techniques (and ways of views):
- Force field analysis, helping to define enablers and inhibitors for helping the system produce wanted outcomes
- Stocks and flow diagrams (for process specialists relatively easy cake)
- Causal (loop) diagrams (think 5Why / Root Cause times 10: issues that reinforce other issues that create the first issues...)

Learning to look from a systems thinking perspective
If you learn to look through the systems lens to processes, I predict that....
- You will develop a deeper understanding of the system that 'performs the process'
      - You see the parts
      - You see the interconnections
      - You see the patterns of behavior and (hopefully) the purpose through that
- You will be able to intervene and influence a much more subtle and powerful ways, identifying leverage points where, with limited effort strong change results can be reached
There is even a maturity model for understanding your ability to see from a systems perspective! And you might even want to check out your systems intelligence with a test here.
Key lesson: the more people participate in systems analysis, the better understanding...

One very useful model for understanding (systemic) reality with a short story
I found the following model very helpful in looking at reality:

(A good explanation can be found here and here)

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.
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.
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.
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...
Conclusion: Don't focus on events and simple if-then's, but learn to see the patterns, structures and mindsets.

 I hope you enjoyed the article!

Some great resources on Systems Thinking
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?

MOOC's:
- Acumen's Systems Practice (highly recommended)
- Futurelearn's System Thinking and Complexity
- Open University's Systems Thinking and Practice

Books:
- Donella Meadow's Thinking in Systems
- Fritjof Capra's The Systems View of Life
- John D. Sterman's Business Dynamics - Systems Thinking and Modeling for a complex world

On the internet, including Youtube, there is ton's of material to be found!

Towards 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:
> People are different in many ways, for instance in terms of needs, preferences, skills and behavior

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.

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.

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.
My assumption is that if we look deep into humans in the role of employee, we will find:
1. Generic human traits and needs that apply to all
2. Traits and needs for particular groups of people (persona's)
3. Pure individual traits and needs (the individual employees in your process)

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.
In my opinion, this could be the dawn of the personalized process: 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.

Towards human centered process design

We 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 worldwide employee engagement crisis . 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.

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:
- Cost reduction
- Value for the customer
- Employee motivation
- Quality improvemen
- Improved Customer Experience
- Efficiency
- Employee engagement
- Agility
- Reach strategy alignment
- Increase Employee happiness
- Reduced cycle time

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.

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.
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.

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?

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.

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. Tips and help very welcome! 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.

Six lessons on the art of change

Oh, 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....

So, just for me, not to forget, six key lessons on the art of change (and no, I won't call it change management).

Be part of the change
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.

Get out with incomplete analysis and ideas
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.

Know the value of interventions
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.

Don't confuse means and goals
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.

Ask, listen, observe
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.

Every change is a personal change - and goes through phases
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.

Design, UX, Flow, o dear.

I have gotten myself into a discussion @ twitter, and found myself with the following question, asked by Charles Webster MD: " what is the relationship between interaction design, user experience, workflow & process-aware technology"

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.

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.
For starters, I encountered the definition 'Workflow': 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 here). 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.

And a later definition of workflow came along by a reaction to the discussion by InformIt:

First Sketches of an App: Planning the Design of a Mobile Application. 

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.

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:

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

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 

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').

(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 here, for now, but limit it to the design of the IT-system)

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 this blog item or read the whitepaper 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 'navigator'  versus workflow metaphor.

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).

Now let's try to answer: how were we able to design the IT-system?

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.

Action	Deliverable	Context Expertise	Subject Matter Expertise
1. Understand the medical staff and their the working context	Empathy maps persona's, contexts of use	UX	Medical Staff
2. Understand the activities that needs to be done, when, where, why. Understand the processes, triggers, exceptions.	Process maps	Process analysis	Medical staff
3. Understand information usage - for each activity, determine information needs, information produced. Understand information requirements from compliancy and management needs.	Objects/attributes	Information analysis	Medical Staff
4. Design the 'workflows': the series of activities that the system should support.	Executable Process models	Process designer	Medical Staff
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)	General UX concept	UX	Medical Staff
6. Design the activity forms: when performing a certain activity, how should information be presented, accessed, entered.	UX design of activity	UX	Medical Staff
5. Design the technical interactions (activities or process fragments that need to interface to technical equipment)	Technical interfaces	Integration expertise	Technical staff

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).
With the emergence of 'Business Technology' we see the trend of 'The specification/model IS the application' as I wrote about early here.

Key in these actions is to work iterative, and test test test. Testing from multiple perspectives:
- the process/workflow: is the set of activities correct in terms of flow, exceptions, decisions?

- the information perspective: can I work with the right information, record the right results?

- 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?
- the technical integration

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 configured refinement cycles can often be done quite quickly (hours to days).

Now, part of the discussion I have with Charles dealt with the notion ' Human Centric Design  is dead', pointing to sources such as here and here.  First of all, I don't disagree with the notion of activity centered design, as my actions above clearly show.
The activity centered design is for me a (welcome!) merging of BPM-expertise and UX-expertise.
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.
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.

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 here and here.
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.
In the end, I think Charles and I are in agreement.

To conclude: a small dive into the limitations of many BPM-tools. In the whitepaper (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:
1 Structured process, where the full process model is known and all execution paths are known at design time
2 Less predictable, but the activities can be predicted/predefined, just not the sequence/possible paths
3 Even less predictable, the process might even require activity not predefined
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.