If you have been modeling processes for a while, you have probably experienced the situations where nothing seems to work. Suddenly, when discussing a particular process with your audience, your tips and tricks don’t work anymore. And you think “What’s wrong with me?” or “What’s wrong with these people?”.
Here is a potential answer: may be there’s something wrong with the process!
More and more voices are stating that not all processes can be captured as fixed, pre-defined flows. Some processes, mostly characterized as ‘knowledge worker processes’ have an inherent flexibility that cannot be described with traditional BPM techniques.
How to distinguish between an adaptive and an prescriptive process
First question that popped up in my mind was: “How can I recognize these processes when I’m discussing them with my customer?” (Because I don’t want to run into problems again.) I found a potential answer in Jacob P. Ukelson’s chapter of the book ‘Mastering the Unpredictable’ (Meghan-Kiffer Press, ISBN 978-0-929652-12-2, www.masteringtheunpredictable.com ). Here is my transcript of his ideas. I now use this frequently to check the type of process I am dealing with; it consists of a set of statements in 6 categories of characteristics of a process:
Type of interaction:
– The activities of the process mainly entail interactions with IT applications to capture information and data, without much interaction with other people.
– The activities of the process mainly entail human interactions (e.g. to ask for assistance, collaboration, or to negotiate).
Type of information:
– In the process mainly structured data is filled out on formatted (electronic) forms.
– In the process mainly documents, excel files and other unstructured information is created or received and processed.
Type of control:
– After the completion of an activity in the process, the system decides what the next (prescribed) step is.
– The actors in the follow decide on the next step based on the information they have.
Type of ownership:
– The process has a process owner who decides on the standard (prescribed) flow.
– Every instance of the process has an owner who can decide on the flow, deliverables and timing for that instance.
Type of objective:
– The objectives, time line and deliverables are defined once for all instances of the process.
– The objectives, time line and deliverables are defined separately for every instance of the process.
Type of process description:
– The process documentation describes how the process’s deliverables should be produced.
– The process is described by defining what the outcome of the process should be.
Before starting a discussion on a process, I ask my audience to score each statement of the 6 categories on a scale of 1 to 5, where 1 = ‘I agree completely with the first statement’ and 5=’I agree completely with the second statement”. The answers give me an indication like “This is more of an adaptive type of process” or “This is more of a prescriptive type of process.” (I made a simple Excel file that, magically, comes up with the conclusion after you filled out the answers).
How does this help?
First of all it helps me during the process modeling to adapt my style of modeling: it doesn’t make sense to try to force the users to define a predefined process flow when you are dealing with an ‘adaptive’ process. In an adaptive process the possible activities may be known, but the sequence in which they occur cannot be defined in advance. (In many cases not even all activities can be identified upfront.) So for adaptive processes, the process model should say: these are the possible actions (activities), but it is up to the actor to decide what to do next.
Secondly, it also helps to define requirements for the underlying ICT systems. It the past, traditional ICT has neglected processes and process support as a basic requirement (see also the article ‘BPM Misconception: the back-end database doesn’t need to know everything’ that was published in the Architect Newsletter of Microsoft Belgium), and more recently you see that BPM is concentrating on “prescriptive” flows and is neglecting the “adaptive” processes. This is all the more surprising because tools like Microsoft’s SharePoint are ideal to support adaptive processes. If collaboration tools like SharePoint would be integrated more in the traditional software applications (e.g. by creating automatically a workspace or a case for every instance of an adaptive process) users would get a much better support during the execution of the process. I will come back to that in another blog post.
For more information: firstname.lastname@example.org
What is Task Assignment?
Task Assignment (aka Role Resolvement) is the mechanism that decides ‘at run-time’ to which user a work flow task should be assigned. It is an essential part of every process engine. If the process defines that a request needs to be approved by the Head of Procurement, then the Task Assignment Mechanism will try to find at run-time a user with the role ‘Head of Procurement’ and assign the approval task to that person. And if that person is on holiday at that moment, then the Task Assignment function may even look up his replacement, and assign the task to that person.
In more technical terms therefore the Task Assignment mechanism is a set of rules, policies and trimmers executed by a rule engine to decide which user is the right person to execute a task at a given moment in time.
Why is Task Assignment important?
Take the example of an Expense Report Approval Flow. The flow will probably state that the expense note needs to be approved first by the Head of Department of the employee who submitted the expense note, and secondly by the Accounting Clerk. Without a Task Assignment function, the logic to determine which Head of Department needs to approve the expense note would have to be modeled in the process flow itself. In a simple organization with 3 Departments, that might look like this:
It is obvious that in a more complex organization (and which organization isn’t?) this is not a workable solution.
When you are modeling for a workflow environment with Task Assignment, the same process would look like this:
In a process modeling project, everyone focuses mainly on the process flow and les (or not at all) on the allocation of human resources to the steps in the workflow. That may be OK, until the moment you really want to execute the process in a workflow or process engine.
Conclusion: Task Assignment is important because it allows you to keep the logic
to assign a task to the right user outside your process flow by defining it in a separate set of business rules and policies.
You can do more with Task Assignment Rules
Another reason for adopting a process engine with a Task Assignment function is that you can do so much more with it.
Imagine a Task Assignment function that would balance the work load automatically over the available resources. Or that would include resources from other departments during peek hours. Or that follows a different logic in emergency cases (when availability of resources is much more important) than in normal cases (when delays are acceptable).
With a rule-based Task Assignment function, you can adopt different scenarios, depending on the context of the workflow. And none of it would influence the clarity of your process model.
Many commercial workflow or process engines ignore to a large extent the importance of resources and task allocation. And although that may be acceptable for simple workflows, it will become a major problem once you want to automate real business processes.
SharePoint’s workflow engine doesn’t have a Task Assignment function. That is why Spikes have developed such a mechanism as part of the SpikesTogether product, to operate on top of workflows in SharePoint. For more information: email@example.com
Automating workflows is becoming more and more popular (and I’m, of course, glad for that). Every workflow implementation project starts with documenting the underlying business process. (I am not going to elaborate on the definition of workflow and process here, that is a subject for a separate blog.) The big question is: how should I document my business process to provide the right input for the workflow project.
This blog entry is part of a series of blog entries on the basics of process modeling. In fact this post gives the overview of what was already published, or what is still to come. (Yes, I agree, this is nothing more than a list of subjects I could blog about, but maybe you can find some information in it too. In the mean time, subscribe to this blog … and wait for the rest to come.)
Categories of processes: management, core, supporting
BPM (Business Process Management) traditionally makes the distinction between Management, Core and Supporting Processes. What are they, and is the distinction relevant to process modeling?
Levels of the Process Model
One of the most important rules for achieving readable, usable process diagrams is to model the right level of detail at the right place. This can be realized a.o. by defining different levels in your process model.
Two crucial definitions: what is an activity, what is a trigger?
Business processes are about information that is flowing between people (the process actors) and that is enriched in each process step. This blog post offers very clear definitions for the flows and for the process steps.
Process boundaries: where does it start, when does it end
You have probably also seen these wall covering process diagrams that try to describe everything in one diagram. Are they readable? Do they identify the business process correctly? Probably not. So how can you delimit process in a correct way?
Roles and functions
The actors in a process are people in a specific role. But people have also functions (by the look of their business cards). How do you deal with that in a process model?
Not just a picture: document it!
Many people only think of diagrams when they talk about a process model. And although a picture tells a 1000 words, they may be 200 words from 5 different people. One way to take away the ambiguity of the process diagram is to a text.
Yes you may bend the rules!
Every business process documentation project has its specific objectives. And although it is important to respect some rules when modeling processes, you must also see to it that the model serves the objectives. Bend it!
What are Management Processes??
Many people will argue that management cannot be captured in processes (mainly managers will say that). Maybe they are right. But that doesn’t mean that management processes don’t exist. Here are some examples of management processes that are useful to document.
2 Kinds of Supporting processes?
Although BPM only talks about Supporting Processes, I see at least 2 kinds: Core-supporting & Supporting-supporting (I couldn’t find a better name – every suggestion is welcome.) What are they?
Process modeling tools
My father-in-law used to say: the right tool is half the work done. Which tools are on the market to support the process modeler?
Process modeling with Visio and SharePoint
About a year ago I would have rejected Microsoft Office as an acceptable tool for processing modeling. But since the release of Visio 2010 and SharePoint 2010 I changed my mind: today they are my favorite tools for modeling processes.
What is a workflow, what is a process?
The words workflow and process are used as synonyms. But do they mean the same thing?
Triggers: formalized communication versus informal
The glue of processes are the triggers: they make activities, and processes, stick together. They represent the information that flows between people. But which communication should be modeled and which not?
Triggers: time trigger!
When modeling processes, many people ignore the most common trigger to start a process: time!
Something on process flexibility
Process models give the impression that every process nicely follows the prescribed path that is described in the diagram. But in reality, processes need to be much more flexibility.
Process performance: measuring quantity and quality
Process modeling and process performance stich together like birds of a feather. How can implementing processes help to measure process performance?
From Process to Workflow
Business Process and Workflow: the same thing … or not?
The implementation of Digital Business Processes
Something on process engines
What is the role of a process engine when implementing Digital Business Processes?
aka Role Resolvement: is the mechanism that assigns process steps (tasks) to the right user at run-time. If your process engine doesn’t support Role Resolvement, then you’re bound to include the assignment logic in you process model. And believe, you don’t want to do that. Read more about this topic here.
What does it mean for the user?
The whole picture: a process steps is a workflow step is a task on a task list
The relation between a digital archive and content management, not clear to everyone
Many organizations talk about digitalizing their (paper) archive. But how does that affect their content management?