Table Of ContentProcess 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.
