Monday, November 17, 2014

Does Design by Doing Eliminate Good Design?

We are moving from a world with centralized processes that are designed in a holistic fashion to processes that are built for change and collaboratively assembled to achieve optimal balanced outcomes. There are two extremes "Doing by Design" and "Design by Doing", but I believe there is a balancing act between these two extremes that we as process professionals need to seek. Each use case needs to be examined for the right balance. With the advent if the "Internet of Every Thing" and the need for speedy analysis and response, puts a premium on processes built for change and fast development. Design is more important than ever, but it is different than the era of BPM that we just went through in the last decade.




















Doing by Design:

Traditionally we  use process models to visually depict existing process flows. This allows process to be shared and worked on in a collaborative basis. Analysis of current practices are brought to light with this approach. When designing new flows that are more stable, this approach works for designing a process. When these processes maps become large and unwieldy or are to rigid for business needs then employing other approaches make sense. One is by adding dynamic rules in the process so some adaptation can be supported as this allows some deviation of action. Another is by simulating alternative paths and actions to ensure behaviors under many, but not all situations.  Another is design by doing.

Design by Doing:

Quickly emerging is another approach that allows for dynamic assemblage of processes that are created as the need arrives. It's kind of like a "lego" approach for processes and some times the process builds itself because of embedded machine intelligence, dynamic human collaboration or a combination of both. In this way the process model now becomes an audit trail of what really happened and can be studied for improvement, governance issues and the need for new constraints on the assemblage. These are known as emergent processes and are supported quite well in adaptive case management, agent and IOT technologies; quite often used together. The issue here is the granularity of the pieces and their specific roles in a resulting action.

Designing the Balance:

The problem is there are always camps of belief to deal with in designing processes. It is important to understand the attributes of the specific part of a process. There are portions of  process (snippets) that are unlikely to change as they are specific patterns of work that endure. There is nothing wrong with the "doing by design" approach for these, but just make sure you have thought through a great number of scenarios. With the advent of customer control, that is coming down the line, we will see more emergence in our processes. With these actions deigning the granularity and assemblage of these granules, will be the challenge. In fact some emergent processes will have little design, but will use constraints to keep processes from "breaking bad" or emerging in an undesirable fashion. In these cases, additional models will have to be considered.

See:

http://jimsinur.blogspot.com/2014/09/behavior-modeling-key-missing-context.html
http://jimsinur.blogspot.com/2014/08/the-missing-models-in-process.html


Net; Net:

There is no one fool proof way of designing processes. It depends on the expected volatility, but it is clear that things are changing for more emergent behavior in processes. You will see vendors headed in this direction and watching their success will be interesting to watch in the coming years.