I have written 6 posts explaining why a manually created business process models are simply not agile enough for today’s organizations. What should we do instead? Glad you asked. A different approach I am calling Emergent Synthetic Processes avoids the problems of a hand drawn process model, and still can offer a path to continual improvement.
The Main Concept
The ESP approach to supporting business processes represents a radical departure from the way that business process models have been created in the past. Instead of requiring a manually created business process model, ESP collects and organizes information about the people who are playing roles in the process and uses that information to construct the right business process at the right time. Each potential participant in a business process publishes what we call a service description. Each person (or robot) who performs a task is providing a service. The service description describes the task along with conditions around when they will perform the task.
An ESP system will take these service descriptions and assemble them into a business process. It starts with the ultimate goal to be accomplished. For instance, if your goal is to purchase something, then you start with the agent who is actually able to purchase the item in question. That person’s service description will say something like: “I will purchase equipment up to this value as long as there is an approval from the department heads and the manager of the person purchasing” or something like that. The service description refers to other activities that must be done before this activity will be done. An ESP system then looks for someone who can perform those activities, for instance department manager approval. The system might look through all department managers but find that only the department manager of the department where the request came from can provide the service. That service description then controls further elaboration of the process.
A standard service description represents the job that an employee normally does for an organization. A journalist would normally write articles on specific topics. An investigative reporter might also have the task to investigate a particular situation to gather the background information and possibly to write the article as well. An employee performs a task, but we will call it a service when we are talking about the relationship that exists between the person performing the task and the circumstances that receive the benefit of the task. All task performers can be similarly dubbed service providers.
Some organizations today make the services that an employee provides explicit in one way or another. Many organizations leave the description of the services that people do to be defined simply by the job title and by the (unwritten) customs of the organization. The ESP approach makes the services explicit and makes them available through an information system which can then generate the process models.
Service descriptions are defined independently for each person in the organization. When a person takes a particular role in the organization or they adopt a particular job title then there is an expectation that they will fulfill a set of services for the organization. So you might think of the service description as a formal definition of the job title or role that they play. However the service description can be unique to the individual to take into account where that individual is located, that person’s particular skills and capabilities, and otherwise account for the individual differences between workers.
The department manager service might can conditions that we call requirements. For example there might be a requirement to file a particular form—maybe a capital spending plan—or perhaps something that points to the budget where the money is going to come from. The requirement may be a task back on the original submitter causing the generated process to include the tasks that the original submitter must perform. Or the requirement might be for a third person to do yet another task.
The system would then look for a service provider for that task, bring it into the generated process, and recursively then that service description’s requirements. Each service description is examined for its requirements and the system finds people who are able to deliver those requirements in their service descriptions. It does this in a backwards chaining way and it works all the way through until all requirements are satisfied. The resulting set of activities as well as the dependencies between them become the business process for this instance.
ESP can finds the optimal path through the organization, suited to the current time, current opportunity, current personnel, and the latest desires of how people want to accomplish the work.
There is a Lot More to it…
That is the main concept. In the coming weeks, I will post a lot more about the details: how the service descriptions are constructed, how a change in a service description can change the entire process, and most about how this solves all the problems with a fixed, static manually created process model.
I like the diagram (i.e data conditions, data requirements . . /resources -> task to do -> choices).
Proof of concept is easy. Take a traditional workflow, cut all of the links and you end up with processes of one step each.
Add Dr Bertrand’s “Design by Contract” method (a pre-processor and a post-processor), encode all steps on the basis of performance capability (not individuals, but skills that are encoded many-to-one for humans and typically one-to-one for robots/software) and let your run-time platform loose.
Each step will be performed as soon as it can (within the practicalities of scan testing of read-to-launch cycle timing) and if you track the date/time of start/end of each task you will be able to construct a flowgraph. It will probably be more efficient from your starting workflow but watch for unwanted queuing. A manual fine-tune is almost always going to give a better than the generated flowgraph.
As for “choices”, on exit presumably from a task, these appear to refer to branching decision boxes where decision support comes from data analytics (i.e. you can show “they went this way 60% of the time”, “they went that way 40% of the time). Just watch out for ‘creep’ where because most will pick 60%, you will soon start to get 70/30 recommendations and then 80/20. . .
See any holes in this?