This guide illustrates the key BPMN process types (models) to consider before you start modeling. Choreographies and Conversation have been excluded in this overview. The focus is also on what Business Analysts need to model (non executable) in order to give a quality handover to System Analysts who will transform the models to an executable standard.
Yesterday, I gave you an overview of the software development method Scrum. My previous post included a high level view of the overall Scrum process. Missing in this picture were any details on the Sprint phase. During a Sprint, a new version of the product is developed. At the end of each Sprint, a new shippable version of the product is ready, which is completely tested and documented. In case of small projects, a Sprint should not be longer than four weeks. In larger projects, a Sprint can be up to three months long.
Each Sprint must have the same length, because Scrum is based on the idea of fixed time-boxes. This concept is also used in other reoccurring meetings. For example, at the beginning of each Sprint a Sprint Planning Meeting is conducted. In the first four hours of the meeting, the Product Owner together with the Team defines "what" should be developed during the Sprint. Afterwards, they define "how" to achieve the goals of the current Sprint. The outcome of this planning session is documented in the Sprint Backlog, for example as user stories.
Items in the Sprint Backlog are assigned to different developers of the Team. An assigned item should be small so that it can be implemented in one or two days. Each developer first develops a test case for a given feature. As the feature is not available yet, this test case will fail. In a second step, the feature is implemented so that the test case defined before is passed. This kind of approach is called test-driven development. The test cases are used instead of writing a documentation of the software design. This approach includes continuous refactoring of the code. Refactoring means restructuring the code without changing the behaviour. Effective refactoring is possible, because the test cases ensure that no functionality gets broken by changes. If the implementation of a feature is done, the feature is removed from the Sprint Backlog and the belonging Sprint Burndown chart is updated.
Each day at the same time (fixed time-boxes again!) a Daily Scrum meeting is conducted. Every member of the Team presents what he has achieved in the past 24 hours and what he plans for the next 24 hours. Obstacles are discussed and solved during the meeting. In the BPMN diagram, I attached an interrupting timer event to the implementation sub-process to model the occurrence of the Daily Scrum meeting. If needed, the Scrum Master can be involved in the Daily Scrum meeting, for example to mediate problems between team members. The Product Owner participates in the Daily Scrum meeting, too. For example, the product owner can clarify items in the Sprint Backlog or discuss with team members the priority of items.
At the end of a Sprint, there should be no items left in the Sprint Backlog. If items could not be completed during a Sprint, they should have been removed from the Sprint Backlog by the Product Owner before, because development progress is transparent due to the Daily Scrum meetings. This is an important point, because in non-Scrum projects it often happens that delays are only discovered at the end of the development cycle resulting in delays of product shipment. In case of Scrum, product management can change priorities early on ensuring that the most important features are shipped on time.
A Sprint is concluded with two meetings:
Both meetings are important to ensure continuous process improvement. They serve as a knowledge transfer between all involved participants. Again, both meetings are time-boxed, for example every meeting being half a day long.
As we can see, the Scrum Sprint phase is quite unique, because:
I think my BPMN model of Scrum could be further extended. For example, it would be interesting to model the details of the Daily Scrum meeting or refine the implementation sub-process. I hope this little excursion in the software engineering domain showed how to use business process modelling for defining and understanding software development processes.
Since the end of the 1990th, we see an ever growing interest in agile methods in software engineering. At the beginning of this movement, radical methods like Extreme Programming (XP) were proposed. Even though you might need a radical move to kick-start a revolution, it is usually not the radical approach winning the hearts of the many. Nowadays, Extreme Programming plays only a minor role in software development, but the methodology Scrum is very fashionable. But hey, what has a software development method like Scrum to do with business process management?
Well, there are many connections. For example, business processes get implemented as software and so you need a way to manage the belonging software implementation project. I call that "application of software engineering in business process management". But of course software engineering itself is a process and therefore a valid subject for business process management. I call that "business process management of software engineering". Finally, some people suggested using Scrum to manage BPM projects. I call that "buzzword bingo by some consultants in the BPM space" trying to get more attention by mixing their stuff with another fashionable topic :-)
Here at IDS Scheer, we use various development methods. Among them, different teams employ Scrum, which is one of the hottest topics nowadays in software engineering. Our new colleagues at Software AG also use Scrum in their projects and in the ARIS Community development team, we also use a flavour of Scrum.
I took up the challenge to document the Scrum process using BPMN 2. Attached to this post, you can find the first part of the result. I intended to create a single model documenting the whole process of Scrum. However, I soon noticed that the picture would get too complex to be useful. Therefore, I will show the details of the Sprint phase in a second post tomorrow.
Scrum defines three major roles, which are represented as lanes in my BPMN model:
My BPMN model of Scrum shows the main interaction of the different roles. If everyone follows the process and no problems arise, the Scrum Master is hardly needed. I modelled the different tasks of the Scrum Master as collapsed event sub-processes. Those sub-processes are only triggered if problems occur. Each event sub-process must begin with an event, which can be interrupting or non-interrupting.
The main action happens between Product Owner and Team. In most cases, both parties collaborate, but as it is impossible in BPMN to model that different parties work together on an activity, I assigned the activity to the party responsible for it. For example, the Product Owner defines the overall product goal during the Release Planning Meeting, but he needs the input of the Team to come up with meaningful estimates to base his release plan on.
The BPMN model of the Scrum process contains a loop. During each iteration, a new version of the product is implemented. An iteration is called Sprint. A lot of additional things happen during a Sprint. I will detail the Sprint phase in my second post tomorrow. After each Sprint, the Product Backlog and Release Burndown chart is updated.
In Scrum, everything happens within fixed time-boxes. For example, a Sprint should always have the same length. It is not allowed to extend the length of a Sprint to implement additional features. Instead, features are postponed to the next Sprint. Such time-boxes are also used for all other activities like meetings. The idea is to establish a rhythm everyone can breathe. It is the task of the Scrum Master to enforce this. I think the use of time-boxes is one of the major strengths of Scrum, because in software development it happens way too often that features for "an important client or prospect" are included delaying the release of the whole product. It also forces product managers to think in advance what is important. On the other hand, flexibility is maintained by Scrum, because Sprints should not be too long. In smaller projects, a Sprint is up to four weeks long, in larger projects not more than three months.
As we can see in my model, the Scrum process runs infinitely. It only terminates if no additional requirements must be implemented (this never happens in reality!) or if the product is abandoned.
So far, Scrum looks like an ordinary incremental software development process. However, we will see tomorrow that the Sprint phase is quite unique allowing a complete realignment of the product during each Sprint.
Note: Go to the second article describing the Scrum Sprint phase.
In spite that the risk is well known, it seems we quite often encounter the happy-path-only syndrome. My recent one was with easyJet airlines.
The online check-in is not to be missed, although in that particular case it is not the most pleasant web experience, it's worth a few extra clicks. And really it's such a simple win-win scenario. Apart from the obvious direct and indirect benefits for the airlines, online check-in saves a lot of time both to those who do it and those who don't (especially when the first group is a majority).
So I did it. But this time I had an extra bag. That's not something extraordinary. I fell into the category of "bag-droppers". But that's in the virtual part of the process only. In the check-in hall, only the sequence for online checkiners with hand baggage existed. There were three check-in counters - one for speedy boarding and two for regular. Bag-droppers can't go to speedy boarding unless they paid for that service leaving them with no other option but to go to the regular queue. That of course was the main thing they wanted to avoid by doing online check-in...
Isn't it strange that the happy-path-only problem, which has been in the BPM classic mistake charts for years, is still among the top? Rob Davis in his excellent "Before you start modelling" online course lists "modelling only success" among the common modelling pitfalls together with incorrectly modelling decisions, false assumptions, mixing viewpoints, not modelling inputs and outputs, and forgetting measures.
But it's not just in modelling where it happens. Yes, alternative paths are often missed during analysis, but sometimes they are caught during analysis, and then somehow forgotten during implementation. In the easyJet case, it was implemented but only in the automated part of the process. And that is how this story brings up another thing of equal importance. I looked and asked around and it's not just me seeing a trend of contemporary business process management to be actually a disguised application process management. The BPM today 1) goes away from Enterprise Architecture loosing its integration capability and 2) the non-automated part of the processes are being neglected, thus loosing the power of end-to-end process improvement. In the context of the story, a missed alternative path in a (to-be) automated process, especially when it's a matter of just going "off-road", could be easily identified and exception handling added. That's not the case when the process continues with little or no IT support as most processes do. In the end, it's a matter of awareness -> informed decision -> implemented decision.
So call me old-fashioned but I believe that a process should be adequately modelled to enter and be processed by an old and sometimes neglected execution engine - the human brain.
But OK, let's talk about automation. As I mentioned in the beginning, the online check-in was not itself the most pleasant IT experience. Again, it's not only me that noticed that. Gary Comerford in his post "The Tao of online processes" compares the Amazon order process with guess what - online purchasing of a cut-price airline ticket. You can imagine the result; if not or in any case read the post. Here I definitely agree with Gary that "many companies have designed their processes around an existing bricks-and-mortar method of dealing with customers and have then transferred that directly to the web". This brings us again to the need to process things through the same old and sometimes neglected execution engine - the human brain.
In many areas, patterns are used to codify best practices. A pattern describes a solution for a problem. Originally, patterns were used in architecture to describe architectural design ideas. In software engineering, patterns are used to describe typical software design solutions, for example like client-server architecture.
In business process management, the so called workflow patterns by Prof. van der Aalst and friends exist. In their original description, they described the most important 20 workflow constructs like loops, decisions, and sequence flows. Later, Prof. van der Aalst and other research fellows extended the list of patterns and revised the initial description (see workflow pattern homepage). Still, the original 20 workflow patterns are valid and a useful tool to learn a modelling language such as BPMN.
Attached to this post, you find my ARIS Express model showing how to do the 20 workflow patterns in BPMN 2. Please consider this to be work in progress. From a theoretical point of view, some of the patterns are not supported by BPMN, but if possible, I tried to come up with a work-around. Please comment this post if you think my way of modelling the 20 workflow patterns in BPMN 2 is incorrect or if you know alternative ways of doing it.
Note: See this post for a list of other articles about BPMN 2, e.g. a comparison of EPC vs. BPMN. You might be also interested to join the BPMN discussion group at ARIS Community.
The ITIL Process Connections Map shows most important connections between ITIL processes along the different ITIL Service Lifecycle Phases
Nowadays for some manufacturers it is still usual to determine their plan budget on sales forecasts instead of realistic utilized capacity forecasts. The result is often an unrealistic plan budget. So how do you get realistic utilized capacity forecasts and therefore a realistic plan budget? With the use of a well structured planning process it is possible to determine a realistic budget step-by-step and from the bottom up for the following year(s). A planning process is nothing else but a logical sequence of partial planning processes, like sales planning, procurement planning, capacity planning, human resources planning and so on, which have to be identified, analyzed and standardized.
Example for a planning process with its partial plannings:
The first step is to find out, which partial plannings exist and which are relevant for the company. The planner must determine how the planning steps correlate. After that, the planning steps can now be put in the correct order (see above). For establishing the several planning steps, it is essential to analyze the as-is situation. The information needed for this can be extracted out of SAP (for example: the annual output of a defined product, the existing production capacities and their production volume and so on). On the basis of the as-is data the properly planning takes place. The won information and accordingly the results (in fact the several plans like sales plan, production material plan and so on) will then be put into SAP.
Now, the several partial plannings are identified and developed as well as the planning is accomplished. But because there are a lot of processes, transparency and clarity are missing. The processes have to be structured anyway. ARIS enables describing the processes of these partial plannings in a business process model in an easy way. SAP provides proven reference process models indeed, but they are static and do not always comply with the requirements of the company or in this case of the planning respectively. But nevertheless this reference models can of course be used. ARIS Business Architect for SAP for example enables to add additional business-relevant aspects to these reference processes and makes them more transparent. By using the interface between ARIS and SAP Solution Manager, the SAP reference processes can be transferred to ARIS. Within ARIS the reference processes models will be adapted to the company’s business process architecture. After adapting and describing the process with its several steps and their coherences in ARIS, the new process structure can now be easily transferred back to SAP Solution Manager. Only the configuration-relevant information and documentation will be transferred back.
So, now the planning process is established and described in a process model – wonderful! But the best planning process is useless, if it is not used and “lived”. Therefore the modeled processes can now be published over ARIS Business Publisher, so that all relevant people, who are affected by the planning process, can take a look on it and see how the several processes work. ARIS Business Publisher enables communication between the IT-side (process modeler) and the people from the business side (in this case the planner as well as the responsible departments). From the published process models, you can directly start the corresponding SAP transactions and documents from SAP Solution Manager and achieve transparency and acceptance.
The whole planning process and its sequenced partial planning processes help to make realistic utilized capacity forecasts and therefore finally determine a realistic planning budget.
Because of the complexity of the planning process, using the SAP reference process models and just adjusting them to the company-specific characteristics is to the best advantage. It provides an enormous saving of cost and time, because the processes don’t have to be modeled completely new. The process models established with the help of ARIS and SAP help to standardize and optimize the partial planning processes and make them more transparent and hence easier to understand. Furthermore they are an important basis for the company to make decisions in the planning projects.
What is your opinion? Do you agree that process models established by ARIS and SAP are suitable for describing planning processes? Do you have other experiences?
See attached a capacity planning process in detail!
Будучи вписанным в общую структуру управления предприятием, управление бизнес-процессами помимо повышения уровня стабильности оперативного управления, так же способствует более четкому формированию стратегической политики предприятия, то есть обладает прогностическим потенциалом. Соблюдая отраслевые технологии и применяя системный подход в анализе деятельности, можно будет не только своевременно внедрять в ход процессов управленческие новации, но прежде проверять сами эти новации на заявленную жизнеспособность, то есть избегать рисков сбоя системы управления.
