Process Modeling Style PDF
Preview Process Modeling Style
Process Modeling Style Process Modeling Style By John Long OMG Certified Expert in BPM (OCEB) AMSTERDAM(cid:129)BOSTON(cid:129)HEIDELBERG(cid:129)LONDON NEWYORK(cid:129)OXFORD(cid:129)PARIS(cid:129)SANDIEGO SANFRANCISCO(cid:129)SINGAPORE(cid:129)SYDNEY(cid:129)TOKYO MorganKaufmannisanimprintofElsevier MorganKaufmannisanimprintofElsevier 225WymanStreet,Waltham,MA,02451,USA Copyrightr2014PublishedbyElsevierInc.Allrightsreserved. Nopartofthispublicationmaybereproducedortransmittedinanyformorbyanymeans, electronicormechanical,includingphotocopying,recording,oranyinformationstorageand retrievalsystem,withoutpermissioninwritingfromthepublisher.Detailsonhowtoseek permission,furtherinformationaboutthePublisher’spermissionspoliciesandourarrangements withorganizationssuchastheCopyrightClearanceCenterandtheCopyrightLicensingAgency, canbefoundatourwebsite:www.elsevier.com/permissions. Thisbookandtheindividualcontributionscontainedinitareprotectedundercopyrightbythe Publisher(otherthanasmaybenotedherein). Notices Knowledgeandbestpracticeinthisfieldareconstantlychanging.Asnewresearchand experiencebroadenourunderstanding,changesinresearchmethodsorprofessionalpractices, maybecomenecessary. Practitionersandresearchersmustalwaysrelyontheirownexperienceandknowledgein evaluatingandusinganyinformationormethodsdescribedherein.Inusingsuchinformationor methodstheyshouldbemindfuloftheirownsafetyandthesafetyofothers,includingpartiesfor whomtheyhaveaprofessionalresponsibility. Tothefullestextentofthelaw,neitherthePublishernortheauthors,contributors,oreditors, assumeanyliabilityforanyinjuryand/ordamagetopersonsorpropertyasamatterofproducts liability,negligenceorotherwise,orfromanyuseoroperationofanymethods,products, instructions,orideascontainedinthematerialherein. LibraryofCongressCataloging-in-PublicationData AcatalogrecordforthisbookisavailablefromtheLibraryofCongress BritishLibraryCataloguing-in-PublicationData AcataloguerecordforthisbookisavailablefromtheBritishLibrary ISBN:978-0-12-800959-8 ForinformationonallMKpublications visitourwebsiteatstore.elsevier.com TypesetbyMPSLimited,Chennai,India www.adi-mps.com DEDICATION AND THANKS This book is dedicated to the One who started all processes by pro- claiming, “Let there be light!” Thanks to the following individuals who helped review my book: (cid:129) Chris Finden-Browne (cid:129) William Powell (cid:129) Tim Rogers (cid:129) Phil Withers AUTHOR’S INFORMATION John Long is a process architect who has worked in the banking, energy, software, telecommunications, defense, and research industries. He has a Master of Science in Computer Science from the University of Tennessee. He has published two other professional books: (cid:129) ITILs Version 3 at a Glance: Information Quick Reference (cid:129) ITILs 2011 At a Glance He has also self-published a number of other books. He has a ter- rific wife of 26 years, with whom he enjoys spending time now that all four of his children are out of the house. He can be reached at johno- [email protected]. ABSTRACT Process modeling often seems simple enough. How hard can it be to create a workflow diagram? After decades of creating and reviewing process models, it has become clear to the author that there are good practices and bad practices. These practices greatly influence how their models are interpreted and understood. Modelers need guidance for the “style” of their models. This style includes many different style ele- ments that focus on structure, relationships, consistency, and identifi- cation. You may find that some of these style elements do not work for you. Some style elements also might not work with your tooling. Adopt the style elements that work for your team. By starting with awareness of all of these leading practices and making conscious deci- sions regarding which to adopt or not, your projects will avoid the common pitfalls in process modeling. INTRODUCTION I.1 WHY A STYLE BOOK ON PROCESS MODELING? Process modeling is a leading practice that has been growing in impor- tance for organizations pursuing increased operating efficiencies. Established process-based capabilities become repeatable, training becomes easier, quality is improved, and process outcomes are more reliable. Many businesses and enterprises look at their processes for a number of reasons: (cid:129) To understand all functions that are performed within the business (cid:129) To understand the context for proposed solutions within the business (cid:129) To understand how to improve the performance of the business As a result of the increasing interest in process models and process modeling, there are many process models, and results are often very disjoint. A process model created in one project often is not compatible with processes from a different project. The result is processes that do not work well together, wasted effort, rework, inefficiency, and delayed organizational benefits from improved processes. This is similar to the confusion within software design decades ago. There were different ways to create design models, and everyone had their favorites. If you had to integrate systems with different types of designs, you had to spend considerable effort understanding those dif- ferences and reconfiguring the software and systems. The advent of the Unified Modeling Language (UML) greatly reduced that. Now, many designers can look at and understand design models from other teams because of their adherence to UML. (Of course, many people still use other non-UML approaches, and UML is not without its limitations.) The general effect is predictable and beneficial. By standardizing on the form and format, developers have a constraint. All new designs must be expressed within the constraint of theUML. xvi Introduction Having a standard constraint for the format forces developers to innovate in other areas. Innovation in the format is a nonvaluable innovation and in fact reduces interoperability with other solutions. Innovation in function, reliability, security, or other aspects is valuable and that value is enhanced by having improved interoperability with other solutions. The process modeling world thus far has been in a chaotic state. There are many different ways to produce process models. In Chapter 2, I will describe some of the different notations that exist. Although there has been some convergence within the industry, there is still dis- agreement on whether converging is the right thing to do. For exam- ple, Business Process Modeling Notation (BPMN) is a standard process modeling notation created by the Object Management Group (OMG), the same organization that manages UML. Unfortunately, not all modeling tools use BPMN, and those that claim to use BPMN do not necessarily adhere to the entire standard. Thus, we’re still in a bit of a Wild West situation concerning process modeling. This nonstandardized environment reduces overall effi- ciency, interoperability, time to value, and total value realization for new solutions. Industry standardization may one day reach Process Modeling, but until then, organizations should adopt standards inter- nally for their own benefit. This publication will provide the informa- tion these organizations should be aware of as they seek process modeling standardization and the resulting efficiencies and improved time to value for new solutions. I.2 A LOT OF PEOPLE JUST ARE NOT “PROCESS PEOPLE” The other day, I ran across the workflow shown in Figure I.1. It was created by people who were serious about their work, but it was not a serious workflow. It contained numerous problems, including: (cid:129) The flow of work sometimes went backward. Note the arrows that are two sided. (cid:129) The flow of work appears to start multiple threads at the same time. Is the task entitled “Payment received” supposed to be a decision, or two parallel threads that occur simultaneously? The time required to clarify this confusion delays time to value. Introduction xvii Requests Send to Contact. sent to outstanding Clear entries reconciliations customer claims DB Customer Update Update item validates Payment item on No Request Yes on claim and received manual sent? reconciliation remits funds list form Download Payment Validate each payments credited report report Yes No Investigate and Is credit Is credit No assign credit for XYZ for ABC appropriately charges? charges? Yes Report to management FigureI.1Arecentbadexampleofstyle. (cid:129) It’s difficult to tell where the workflow stops. Note that circles are sometimes used to indicate the end of a flow, but not always. Does the designation of a circle mean something or not? The confusion delays enterprise adoption and time to value. (cid:129) What do the task labels mean? Would everyone in their organiza- tion understand the workflow with such cryptic information? (cid:129) What is taking place in the connection to the box labeled “Report to Management”? Is that coming from one of the deci- sions above it? This example reminded me that not everyone actually “gets” what a workflow is. Anyone can draw boxes with arrows between them. But there aren’t that many who can draw such diagrams so that they repre- sent a flow of work that is consistent, understandable, and can be followed. I have seen many people be given the responsibility of creating a process workflow, and I have seen many bad results. I hope that this book will help transform well-intentioned process modelers into better process modelers that deliver organization value more quickly. xviii Introduction I.3 THE NEED FOR STYLE When an organization selects a specific tool set for creating process models, there will still be significant ways to vary how processes are described. For instance, BPMN specifies how tasks look, but there are no rules on the following: (cid:129) How tasks are named: If I call a task “Print Report,” will that clash with other tasks that basically do the same thing? (cid:129) How big a task is: Should “Design Software” be considered a task, or is that something larger than a task, like a process? Should a task called “Enter Data” be considered a task, or is too small to be a task? If a task in a workflow encompasses work passed to multiple people, is it really a task? (cid:129) How tasks relate to roles: How do I indicate whether other roles can participate in a task? Can more than one role be responsible for a task? Modeling teams need guidance for the “style” of their models. The style includes many different characteristics that help different process elements appear to be part of an integrated and fully interoperable sys- tem. This includes: (cid:129) Naming and numbering (cid:129) Structure (cid:129) Relationships This book provides a “style” for process modeling that I have devel- oped based on my experience over the past 25 years in many projects, in many organizations. Based on the results that I have been able to assess after the projects have ended, I have concluded that there are in fact core leading practices that enable projects to produce value more efficiently. Projects that do not adopt these practices will tend to have waste, rework, and delayed time to value. This style includes many “style elements,” which include leading practices, rules, or conventions to adhere to. You may find that some of these style elements do not work for you. Some style elements also might not work with your tool- ing. Adopt the style elements that work for your team. Use the appen- dix at the back to identify which style elements your team will use. By starting with awareness of all of these leading practices and making conscious decisions regarding which to adopt or not, your projects will avoid the common pitfalls in process modeling and time to value.
The list of books you might like
