Setting the Granularity or Appropriate Level of Detail for Modeling Business Processes

Transcription

1 Setting the Granularity or Appropriate Level of Detail for Modeling Business Processes Applies to: Enterprise architects, BPXers, business analysts. Cross industry and not product specific. Summary In a previous article (Modeling Business Processes Using BPMN and ARIS) I dealt with modeling business processes using the Business Process Modeling Notation (BPMN), which is a relatively easy task. A more complex task to deal with is finding the right level of granularity (or level of detail) to guide you when modeling your business processes. In this article, I suggest several criteria that you can follow to define what level of detail to use. Author: Natty Gur Company: SAP Created on: 28 January 2007 Author Bio Natan Gur has 13 years of experience in the IT field. Recently, he has been working for SAP on the SAP enterprise architecture (EA) framework. Natan has eight years of experience running EA in companies and governmental bodies. Natan also serves as the technical director of the International Association of Software Architects (IASA) and is a member of the IASA board of directors. He has been elected by Microsoft as an MVP for the last four years SAP AG 1

2 Table of Contents Applies to... 1 Summary... 1 Author Bio... 1 Introduction... 2 Level of Detail for Modeling Capabilities... 2 Solution Composer... 2 Business Process Master List - BPML... 5 Reference Models... 6 Level of Detail for Modeling Business Processes... 6 Process Actors... 7 Events... 8 Tasks... 9 BPMN... 9 Information Summary Related Content Copyright Introduction In a previous article (Modeling Business Processes Using BPMN and ARIS) I dealt with modeling business processes using the Business Process Modeling Notation (BPMN), which is a relatively easy task. A more complex task to deal with is finding the right level of granularity (or level of detail) to guide you when modeling your business processes. In this article, I suggest several criteria that you can follow to define what level of detail to use. While modeling your enterprise business domain, you must to deal with capabilities (what) and business processes (how). Therefore, this article will provide you with granularity criteria for both of these building blocks. If you choose to use a top-down approach (which is the common approach in business modeling), you will probably start by modeling capabilities, followed by modeling business processes to describe how each one of your capabilities is carried out by your enterprise. Using this approach, let s start by dealing with criteria for modeling capabilities. After that, we will discuss criteria for modeling business processes. Level of Detail for Modeling Capabilities Solution Composer SAP has predefined criteria accompanied by predefined content for modeling capabilities. This definition includes business scenario groups, business scenarios and business processes taken from the Solution Composer. If you have ever had a look at the Solution Composer, you probably noticed that the lowest level of detail represented by it is still too abstract. Therefore, we recommend breaking down the Solution Composer processes to the level that reflects your needs. The most common criteria by which to break down Solution Composer processes is along the enterprise hierarchy. By doing this, you break processes into subprocesses by finding out what the tasks are that every organizational unit (according to the hierarchy) performs SAP AG 2

3 Let s take an automotive original equipment manufacturer (OEM) as an example. When you open the Solution Composer s automotive OEM solution map, you see the higher level of capabilities, which are called business scenario groups (Figure 1). Automotive OEM business scenario groups include: Time-to-Market, Supplier Collaboration, Build-to-Order, Sales and Marketing, Customer Service and Enterprise Management and Support. Figure 1.0 Automotive OEM Business Scenario Groups Choosing the expand all checkbox reveals the business scenarios that make up each business scenario group. For example, Customer Service is composed of Warranty Management, Interaction Center, Service Parts Planning and Service Parts Execution (Figure 2) SAP AG 3

4 Figure 2 Business Scenarios Each of the business scenarios is composed of business processes. Service Parts Execution is composed of Parts Purchase Order Processing, Parts Inbound Processing and Receipt Confirmation, Warehousing and Storage, Physical Inventory, Parts Cross Docking, Returned Parts Quality Control, Sales Order Processing, Parts Outbound Processing, Parts Transportation Execution, Billing, Complaints Processing, Product Service Letter Processing, Supply Chain Monitoring and Control (Figure 3). Figure 3 Business Processes 2007 SAP AG 4

5 As already mentioned, processes are too abstract. Physical Inventory is a high-level capability that can easily be broken into subprocess such as Cycle Counting Physical Inventory Preparation, Definition of Scope of Periodic Inventory, Determination of Scope for Periodic and Continuous Inventory, Inventory Count, Physical Inventory Analysis, Post Inventory Differences, Printout of Physical Inventory Document, Recount, Specification of Cycle Counting Physical Inventory. These sub-capabilities begin to be more concrete capabilities. Business Process Master List - BPML Another approach you can take in order to classify capabilities is to use the Business Process Master List (BPML). BPML suggests five levels of hierarchy: Area, scenarios, group, processes and business process procedure. If you look at one of the BPML sheets ( you ll find that business process procedures are more concrete than the process levels in the Solution Composer. If you find business process procedures too abstract, you can still follow the organizational hierarchy or a business reference model, as described below SAP AG 5

6 Reference Models The last criterion that you can follow is to use any business reference model, such as SCOR ( ) or VCOR ( ). VCOR, for example, defines five levels of hierarchy: 1. Strategic processes (the macro business processes) 2. Tactical processes (a subset of the enterprise strategic processes that can be assigned to applicable business tactics) 3. Operational processes (general processes that establish a link between activities) 4. Activities (decomposition of operational processes into specific activities) 5. Actions (individual work instruction items) VCOR defines content only to the three first hierarchy levels in the reference model; so you still need to define the fourth and fifth levels of capabilities yourself. Relevant VCOR levels for Inventory Management: SCOR has four levels: 1. Top level (process types) 2. Configuration level (process categories) 3. Process element level (decompose processes) 4. Implementation level (decompose process elements). Level of Detail for Modeling Business Processes Having a list of your enterprise capabilities is a huge leap forward for getting you current and target business architecture. But most of the time capabilities are not enough, and we want to get the how perspective of capabilities by modeling how the process or processes that support that capability are carried out in the enterprise. There are several aspects in terms of level of detail that you need to decide on for modeling business processes. While modeling, you need to deal with organizational hierarchy, events, tasks, business rules, and information needed to perform process tasks and transactions. Before we start modeling processes, we need to consider and decide on the usage rules for these business process ingredients. These rules will set the level of detail along which we will model the processes. The rules may be the same for all of the business process modeling, or they may differ between the different levels of capability SAP AG 6

7 Process Actors The first decision to make involves the hierarchy level of the participant in the process modeling. It can start from a higher level of abstraction, such as board members, and go down through the organization unit s hierarchy to the employee level. Going down to employee level may be a very time-consuming effort. Therefore, you usually make the enterprise the lowest level of participant in the processes. As stated earlier, the level of actors in the process modeling should differ between different levels of capability. Process modeling according to high-level hierarchy: OEM Car production Importer Order Car Car Shipment Request for car End event Dealer Order Car Car delivery 2007 SAP AG 7

8 Process modeling according to low-level hierarchy: MRP Controller Carry out reservati... OEM REM-Production Planner Production Strategic locating... Importer Operative Process order Shipment tracking Transport Manager Transport control Request for car Dealer Operative specificati... Order tracking End event Warehouse Worker Goods receipt... Events Events that start or change business flow, tasks that are performed by actors, and business rules that shape the process are all essential to modeling a process. Although you can omit rules and/or events to reduce the level of detail the business process models have to deal with, I think that they are essential for modeling processes at the lower levels of capabilities. It s possible, however, to drop the details (roles and events), and it might even make sense if you are modeling processes of high-level capabilities SAP AG 8

9 Process modeling with rules and events: MRP Controller Carry out reservati... OEM REM-Production Planner Production Strategic locating... Production status Importer Operative Process order Shipment tracking Finished message Transport Manager Transport control Request for car Dealer Operative specificati... Order tracking End event Warehouse Worker Goods receipt... Tasks You cannot model a process without tasks being taken by actors, but you can limit the tasks by various criteria. One common criterion is defined by Alec Sharp, Patrick McDermott in their book Workflow Modeling: Tools for Process Improvement and Application Development. The workflow modeling approach suggests three levels of granularity that you can assign to each one of the actors that you describing. You can model handoffs, milestones or individual tasks. BPMN Another method you can use to define the level of detail is defined by the BPMN standard. BPMN distinguishes between 3 types of business processes: private, abstract and collaboration. Basically, these methods define what should be modeled in lanes (actors) that take part in the process. Private denotes a single private business process usually performed by a single participant. Abstract represents interaction between a private business process and another business process. Only those activities that are used to communicate outside the private business process, plus the appropriate flow control mechanisms, are included in the abstract process. All other internal activities of the private business process are not shown. Thus, the abstract process shows the outside world the sequence of messages that are required to interact with that business process (BPMN standard). Collaboration represents interaction between a private business process and another business process, but this time all of the participant activities and the flow control should be depicted by the model. Private business process: 2007 SAP AG 9

10 Abstract business process: Collaboration business process: Information Information that can be input or output for a task described in business process modeling can also be used for setting the process modeling level of detail. You can decide to model your processes without any reference to information, with limited information, or with just inputs or outputs. If you already have conceptual and logical information models, you can also limit the information to conceptual or logical levels of abstraction. You can also determine whether your business process modeling will include transactions or not SAP AG 10

11 Business process modeling with information: Info (schedule, quantity, configuration) about planned vehicles MRP Controller Carry out reservati... OEM REM-Production Planner Production configuration Current order status Delivery documen t Strategic locating... Production status Importer Operative Process order Shipment tracking Finished message Transport Manager Transport control configuration Dealer Request for car Operative specificati... Order tracking End event Warehouse Worker Goods receipt... Summary In this article, I have tried to summarize the different criteria you can use to set the level of detail to use for modeling both capabilities and business processes. These are the most common criteria that I use. Although I list all of the criteria, keep in mind that combinations of these criteria can be used as well. The key for successful process modeling is to determine in advance the capability level and the level of detail for each of those capability business processes, and to follow those rules. Related Content 01.pdf - OMG Final Adopted Specification, February 6, 2006 Workflow Modeling: Tools for Process Improvement and Application Development, by Alec Sharp and Patrick McDermott, copyright 2001, Artech House Publishers. - Business Process Master List (BPML) Management Guide, December SAP AG 11

12 Copyright Copyright 2007 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iseries, pseries, xseries, zseries, z/os, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix, i5/os, POWER, POWER5, OpenPower and PowerPC are trademarks or registered trademarks of IBM Corporation. Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. MaxDB is a trademark of MySQL AB, Sweden. SAP, R/3, mysap, mysap.com, xapps, xapp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. These materials are provided as is without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. SAP does not warrant the accuracy or completeness of the information, text, graphics, links or other items contained within these materials. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third party web pages nor provide any warranty whatsoever relating to third party web pages. Any software coding and/or code lines/strings ( Code ) included in this documentation are only examples and are not intended to be used in a productive system environment. The Code is only intended better explain and visualize the syntax and phrasing rules of certain coding. SAP does not warrant the correctness and completeness of the Code given herein, and SAP shall not be liable for errors or damages caused by the usage of the Code, except if such damages were caused by SAP intentionally or grossly negligent SAP AG 12