BPMN Fundamentals: 4. BPMN Refactoring Romi Satria Wahono

28 Slides3.70 MB

BPMN Fundamentals: 4. BPMN Refactoring Romi Satria Wahono [email protected] http://romisatriawahono.net/bpmn WA: 6281586220090

Romi Satria Wahono SD Sompok Semarang (1987) SMPN 8 Semarang (1990) SMA Taruna Nusantara Magelang (1993) B.Eng, M.Eng and Ph.D in Software Engineering from Saitama University Japan (1994-2004) Universiti Teknikal Malaysia Melaka (2014) Research Interests: Software Engineering, Machine Learning Founder dan Koordinator IlmuKomputer.Com Peneliti LIPI (2004-2007) Founder dan CEO PT Brainmatics Cipta Informatika 2

Course Outline 1. Introduction 2. BPMN Elements 3.1 Swimlane 3.2 Connecting Objects 3.3 Flow Objects 3.4 Artifacts 3. BPMN Simulation 4. BPMN Refactoring 5. BPMN Guide and Examples 3

4. BPMN Refactoring Misconceptions, Fallacies, Errors, Bad Practices and Bad Smells 4

The BPMN Silver Bullet BPMN is not a BPM silver bullet, BPMN is only one tool in support of the practice of BPM There are other formalisms, methodologies or tools that are more adapted to and appropriate for certain specific BPM situations or engagements A business process specialist (analyst, architect, etc.) would be well advised to discriminately take full advantage of a diversified BPM tool set 5

BPMN is Complex BPMN complexity did, in fact, increase. It has to in support of expressiveness and executability. But, it is still possible to create a business process depiction that is simple to understand by anyone Using four shapes in BPMN, it is still possible to unambiguously and precisely describe the flow of activities within a business process We can show how the process starts, what activities take place, the logic of taking one path or the other, and the various states in which the process can end 6

BPMN Specification Document The specification document is not intended to be read by end users the intended audience of the specification document is the implementers, the software vendors that create tools implementing the BPMN standard Good examples of such segmentation in books are starting to appear: Bruce Silver, BPMN Method and Style Second Edition, Cody-Cassidy Press, 2011 (Diagram) Thomas Allweyer, BPMN 2.0, BoD, 2010 (Diagram) Bizagi Proses Modeler User Guide, Bizagi, 2012 (Tool) Layna Fischer (edt.), BPMN 2.0 Handbook Second Edition, Future Strategies, 2012 (Tips & Tricks) 7

Events vs Tasks Many people have trouble deciding whether to model the sending of a message as an event (intermediate message throwing event) or as a task (sending task) A notion of time can simply illustrate the difference: 1. an event map to a time point on a time line an event happens instantly at a particular point in time 2. a task map to a time interval to complete a task, some work effort has to be expended over a period of time (the time interval) 8

Pools, Participants and Processes A Pool depicts a Participant, in Bizagi a pool is a Process A Pool separates the Activities done by one Participant from the Activities done by another Participant A better practice is, to avoid this unintended perspective switchover, do not model the internal process under focus in a Pool Without a Pool to label, the modeler will not have opportunity to fall into this bad practice trap 9

Pools, Participants and Processes 10

Gateway The common practice of labeling BPMN Gateways with questions and outgoing Sequence Flows with potential answers tends to lead modelers to improperly believe that BPMN Gateways are decisions A Gateway is only used to control how Sequence Flows interact as they converge and diverge within a Process A BPMN Gateway does not perform any work or make any decision. It cannot be assigned or performed by anyone or anything 11

Gateway A better modeling practice is to always place an Activity labeled with the question just before the gateway and not to place a label on the Gateway That Activity can then be better specified by type (Manual, User, Business Rule, etc.) and be assigned to a performer 12

User Task and Manual Task User Task is a task where a human performer performs the Task with the assistance of a software application. A User Task can be any softwareassisted task such as calculating a sales commission using accounting system Whereas a Manual Task is a Task that is expected to be performed without the aid of any software application, such as placing order items in a box 13

Incosistent Naming Bad Smells Best Practice Noun based activity name – indicates that element is an event, data object, or process area as opposed to activity Strong verb domain specific noun – emphasizes achieving a discrete goal after performing work Gateway named as activity – indicates that a gateway represents a task, which determines the choice Unnamed gateway – it is merely a branching element that does not perform any work, so it should not be named (except for referencing) Words and/or in activity name – indicates multiple activities captured in one activity No conjunctions in names – raise name abstraction level or split into two subsequent/alternative activities Long activity name – indicates that details of activity are emphasized instead of the goal; orients diagram towards textual document Short name documentation – the name should emphasize the goal, and details of activity can be captured in comments or documentation 14

Noun based Activity Name X O 15

Large Process Diagram Decompose a very large business process into a simple process structured in several levels of detail. Use Subprocess to make the models simpler 16

Inconsistent Use of Gateway Bad Smells Best Practice Multiple incoming/outgoing sequence flows – makes it difficult to understand how many flows are required to come out/in. Always use gateways for branching/ merging – improves readability of the diagram and explicitly indicates control points. Event-based gateway with outgoing sequence flow unconnected to event – makes it ambiguous when the alternative sequence flow should be taken. Apply Deferred Choice pattern – all the sequence flows after event-based gateway should be connected to events. Use timer event to model cases when expected event does not happen Gateway unsynchronized with preceding subprocess ends – shows inconsistency between sub process details and its usage in a larger process. Apply Internal Business Error pattern with synchronized end/branch naming – makes it very straightforward to consistently use gateways and sub processes. 17

Inconsistent Use of Gateway 18

Inconsistent Use of Events Bad Smells Event outside and inside process – repetition makes it redundant; a formal interpretation would require the event to happen twice Best Practice Initiating event out of process description – it is easier to read a diagram and understand when/why a sub process needs to be performed A subprocess with attached event – enables to clearly define the scope of an event Repeating events – complicates diagram and its maintenance 19

20

21

22

23

24

25

26

27

Reference 1. Object Management Group, Business Process Model and Notation (BPMN), OMG Document Number: formal/2011-01-04, 2011 2. Object Management Group, BPMN 2.0 by Example, OMG Document Number: dtc/2010-06-02, 2011 3. Bruce Silver, BPMN Method and Style Second Edition, CodyCassidy Press, 2011 4. Layna Fischer (edt.), BPMN 2.0 Handbook Second Edition, Future Strategies, 2012 5. Tom Debevoise, Rick Geneva, and Richard Welke, The Microguide to Process Modeling in BPMN 2.0 Second Edition, CreateSpace, 2011 6. Bizagi Proses Modeler User Guide, Bizagi, 2012 7. Bizagi BPM Suite User Guide, Bizagi, 2013 8. Thomas Allweyer, BPMN 2.0, BoD, 2010 28

Back to top button