Process Discovery on a Rainy Day

You are probably aware that Business Process Management is all about processes. Fine. Do you know your processes? What do they look like? Can you please document them for us?  Organizations have an unprecedented number of opportunities available to change and improve their processes. Advances in organizational research, mature supporting information systems, and complementary service offerings allow you to create compliant processes, improve their performance, simulate, automate, and monitor them. But one key challenge remains: You need to find your processes first.

In a recent survey by Wolf and Harmon, organizations reported that more than a third of the time spent in their BPM projects went towards “process discovery.” This is surprising, given that your processes are composed of the things you do on a daily basis. Shouldn’t you know what you do?

So how do you identify your processes? Process discovery requires asking the right people the right questions. Who are the right people? First, people with knowledge about the current processes. Their role is to report on current ways in which the process is performed, into which steps the process breaks down, which data is required to complete these steps, which exceptions occur, and who is involved, etc. Second, people who guide and direct the processes. What is the overall objective? Are we allowed to think out-of-the-box? What are the constraints? Who will be responsible for the process? Who is in charge of the change process? Third, people who provide ideas. They are not necessarily involved in the current process but have a deep understanding of the overall direction of the organization, know about underutilized capabilities, common practices, and new developments.

So what do you do with these people? Typically, you go and ask them about the “Sunny Day Scenario”: What do you normally do in the process? Where are the regular hand-offs? Which resources do you require? What are the decisions and which business rules govern these decisions? Sounds simple, right? The result of this exercise is a process description that represents what happens if everything goes right. Yet, these processes often represent the “As-If” rather than the “As-Is”. In reality, clocks tick differently. And people handle things differently – often for good reasons. A VIP customer order arrives after the shipping deadline? Create a rush shipment! Received multiple invoices from different departments? Call accounts receivable and have them consolidated! In essence, there are exceptions to the regular process that you discovered. But here is the catch: These exceptions don’t represent failures of the regular process. Rather, they are valid business cases that simply don’t fit the model of your discovered process. If you stick to your standard model you will have to manage these exceptions, not only in your process models but also in your process management systems – a tedious, cumbersome, and often frustrating endeavor. Not only is this type of exception handling poorly supported by process management systems, but also do the models we use for describing processes get utterly complex and messy, with additional decision points and alternate pathways. As a result, the models become too complex to effectively communicate the process to the stakeholders involved.

What should you do instead? Try uncovering the “Rainy Day Scenario”. The right questions to ask during process discovery are questions such as How did you handle your most difficult customer? Or: What was the most difficult case you worked on? The idea is to collect a number of detailed process scenarios that contain as many exceptions as possible. You can then combine these descriptions into a common “Rainy Day Scenario” that includes the important exceptions from the start. You will find that you in most cases you didn’t uncover exceptions from a regular process, but merely identified important variants that treat different business cases. Knowing the major variants allows you to identify the type of business case early in the process, and allow for appropriate tool support.

One simple rule of thumb in ordering these variants is to structure the process pathways according to execution frequency. The most common variants are your #1 candidates for process automation – either in form of straight-through processing or through human-supported Business Process Management Systems. The less frequent process variants occur, the more likely they can be supported through collaborative technologies such as groupware or shared workspaces. Their structure may change, and investing in automation infrastructure may not pay off because the support systems are not used frequently enough to provide a return on investment. Rare exceptions are often candidates for case handling. Put a competent person in charge of these cases and let them handle them on an individual basis.

Michael Hammer once said “If it doesn’t make three people angry, it isn’t a process” . Start with the cases that make people angry, not those that everyone agrees on. The result may surprise you.

1. Wolf, Celia; Harmon, Paul: The State of Business Process Management – 2006. BPTrends, June 2006.
2. Hammer, Michael: Beyond Reengineering. How the Process-Centered Organization Is Changing Our Work and Our Lives. Harper Collins, 1996.

 

About The Author(s)

Michael zur Muehlen

Michael zur Muehlen is Assistant Professor of Information Systems at Stevens Institute of Technology where he directs the SAP/IDS Scheer Center of Excellence in Business Process Innovation. Michael is an internationally known expert in the Business Process Management area and has conducted various pr

Contact The Author Center of Excellence in Business Process Innovation

Jan Recker

Jan Recker is a senior researcher at the Business Process Management research group at Queensland University of Technology in Brisbane, Australia. His research areas focus on the acceptance of process modeling in practice and the design of flexible business processes. Jan has published more than 35 p

Contact The Author Business Process Group, Queensland University of Technology