UML Activity Diagrams

UML (Unified Modeling Language) activity diagrams are graphical representations used to model workflows, processes, and behaviours within a system. They provide a visual overview of the steps involved in accomplishing a task or achieving a specific outcome. Generally most UML diagrams are appropriate for software design, however a few can be leveraged to understand systems from both a human as well as technology perspective. In the previous example on simple flow charts we created a high level model of a checkout experience, for this example we'll focus on the cash register process.

Symbols

Activity diagrams unlike simple flow charts, have a more stringent set of symbols, this is because UML is much more standardised, whereas flow charts are much more pragmatic. Generally activity diagrams are not appropriate for all audiences, they are a great way for business analysts and software engineers to collaborate and ensure that they have a shared understanding.

Symbol	Description
	A solid dot represents the start of the process
	A solid dot with a circle around it represents the end of the process
	A circle with an X in the middle represents the end of a branch or activity
	A diamond indicates that a branch is created, or that two branches merge into one
	A rectangle with rounded corners represents an activity, something that is done
	A bar with a flow going into it and a number of flows exiting depicts parrallel processes
	A bar with multiple flows entering and only one exiting depicts a pause point, where all parallel process must converge
	The note symbol allows the diagram creator the opportunity to annotate their diagram with some contextual information for the reader
	The send signal notation, indicates that the process is outputting a message to another process
	The receive signal notation, indicates that the process is waiting for input from another process
	Timer notation, how long a process is suppose to wait before Continuing
	Frequency notation, indicates a timer job, how long before triggering an action
	Interrupt notation, indicates that something has occurred which needs to branch to a different flow
	Call other process, indicates that the activity is actually a sub process

Example

Previously we created a simple flowchart depicting a checkout process, this time let's create an activity diagram laying out the cash register process.

again this is a quick contrived example that only touches upon this process, there is no doubt in my mind that if you sat down with a cashier you would find many more nuances and improvements to this process, however notice that if you showed this diagram to a cashier, they most likely would be confused, however a simple flow chart would most likely facilitate a discovery workshop

Swim lanes

Swim lanes are not exclusive to any particular business processing technique, and can in fact be used with simple flowcharts, activity diagrams, BPMN 2.0 or almost any other process modelling technique. Swim lanes are visual containers that partition a business process diagram horizontally or vertically. They represent different participants, roles, departments, systems, or organisational units involved in the execution of a process. Swim lanes provide clarity and structure to process diagrams by categorising activities based on their performers or responsibilities.

The above is called a 'Pool' this pool has swim lanes, in the above I've depicted vertical swim lanes, but there is nothing wrong with using horizontal lanes. I generally choose vertical ones, because, most mediums have more vertical space than horizontal, not to mention that no one likes reading sideways text, however the following is perfectly legitimate.

Whether the lanes or horizontal or vertical is completely in consequential, the value of the swim lane is two fold, it easily identity's the actor, and segments their contribution to the process.

One thing to keep in mind about the above is that it is very much a contrived example, once could argue that this is in fact multiple business process, that the stock clerk is a variation, etc. 

The take away here is simple, Swim lanes segment a process by actor, they represent different participants, roles, departments, systems, or organisational units involved in the execution of a process. They provide a clarity of who does what and at which point during a process.

Simple flowcharts

Flowcharts are visual representations of processes or workflows, often used in various fields such as software development, engineering, business management, and more. They provide a clear and structured way to illustrate the sequence of steps within a system or a procedure. 

Symbols

Simple flowcharts have a number of standard symbols and notations, however they are a pragmatic approach to process modelling, and often times incorporate symbols outside their loosely defined standard set of symbols. This pragmatism is as much a benefit as it is drawback, it is very easy to overuse flowcharts; this is because anyone can understand them and often times initial drafts become finalised documents, even though there are other notations that maybe more appropriate for the particular thing being modelled.

I generally look at simple flowcharts as rough sketches, an easy and quick way to discuss a process, but by no means the finished deliverable.

Symbol	Description
	The start stop symbol is exactly what it sounds like, it indicates that the process is started or terminating
	An action or step is something that happens during the process, this is generally where the work is done
	The input or output, represents a need by the process from a participant to continue, or an output which a participant needs to proceed
	Decision, a decision symbol is a split in logic, it just means that based on some condition, the process enters an alternative flow
	Merge, often times during a process there is a split, the process can have multiple flows which run in parallel, the merge represents the coming together of these flows, think of it as parallel actions that eventually must wait for each other to complete
	An artifact is similar to an output, however the difference is that the artifact will exist after the process is compelete
	Artifacts simply represents multiple artifacts
	The annotation is a simple decoration, it provides the viewer of the process some contextual inforamtion that may not be obvioulsy communicated via the diagram itself
	The process link out symbol indicates that this flow continues somewhere on the page, the content of the symbol is the key to look for in the porcess flow in counterpart
	The process link in symbol indicates that this flow is the continuation from somewhere on the page, the content of the symbol is the key to look for in the porcess flow out counterpart
	The off page link simply indicates that this porcess continues on a differnt page, generally the content of this symbol indicates the continuation page
	The subprocess indicates that this step is actually its own sub process, and generally contains where this process is indicated

The above are the eleven basic symbols one could use to to model just about any process. These symbols are simple to understand, and though they may not get into the granular details of technical implementations, they are an excellent way to simply depict a process for the purpose of a general discussion.

Grocery store checkout example

keep in mind that the following is a is a simplification, there are a large number of sub processes that are not depicted, things like what if the person client does not have the means to pay, what if they will soon return to pay, what if the item doesn't have a price, there are so many more variations that could exist. however the following does serve the purpose of a simple depiction.

Business process scoping

The core idea of Business Process Modelling (BPM) is to understand the outcome, sequence and  activities needed to achieve a specific result. To define the rules of interaction between all participants.

Any business process is an end-to-end set of activities which collectively respond to an event and transform information, materials, and other resources into outputs that deliver value directly to the customer(s) of the process. This value may be realised internally within an organisation, or it may span several organisations.

When looking to automate a process, at a high level there are only four  aspects to any process:

1. Trigger: What starts the process
2. Result: what does the process accomplish
3. Steps: What are the steps in the process
4. Needs: What are the specific needs for each step

If you can identify all of the above, you can successfully map any business process, this may seem simple enough on paper, however in real life this is generally where murky waters start. Often times organisations do not have clear cut business processes, most processes are born out of necessity and start relatively simple, however over time they tend to grow and mutate into something that started pragmatically, but has over years transformed into a behemoth. Many times these 'organic' processes are never documented, and more often than not reside in someone or a group of peoples heads. In the latter, often times various stakeholders understand part of the processes or worse yet they have varying opinions on what the actual processes is. For this reason before modelling anything it is important to lay out the boundaries of the process. 

There are a number of business process scoping methods, these methods help you understand the environment around the process, the value of the process, and a high level overview of the process. By understanding the 

SIPOC (seabook)

SIPOC is an acronym that stands for Suppliers, Inputs, Process, Outputs, and Customers. It is a high-level process mapping tool used in business analysis and process improvement.

• Suppliers: These are the entities that provide the inputs needed for the process to function.
• Inputs: These are the resources, materials, or information required to initiate the process.
• Process: This refers to the series of steps or activities that transform inputs into outputs.
• Outputs: These are the results or products generated by the process.
• Customers: These are the individuals or entities who receive the outputs of the process.

SIPOC diagrams help to identify and understand the relationships between these key elements of a process, providing a clear overview that aids in analyzing and improving processes within an organization.

Suppliers	Inputs	Process	Outputs	Customers
These are from where all of your inputs come, there could be one or dozens of suppliers	This represents all of the tangible or intangible things you get from your suppliers, and you need for your process to produce outputs	This is a list of all of the steps you need to take your inputs, and transform them into your output(s)	These are the outputs of your process, ideally each process should be mapped to one output, however every rule has its exceptions	This column represents your customers, these are the people/organisations/departments, etc who will benefit from the outputs.

Keep in mind that the SIPOC is not a tool meant to model your process, this tool's purpose is to have a broader conversation around the upstream and downstream aspects of your process, understand the suppliers and their inputs, as well as the outputs and their customers. 

IGOE

The IGOE (Inputs, Governance, Outputs, and Enablers) framework is a method used in systems thinking and analysis. It breaks down a system into four main components:

• Inputs: These are the resources, materials, or information that are utilized by the system.
• Governance: The rules, regulations, and decision-making structures that guide the system.
• Outputs: These are the results or products generated by the system in pursuit of its goals.
• Enablers: Factors that facilitate or support the achievement of the system's goals

The IGOE framework places the 'Process' at the centre and then looks to the left and right of it, as well as other factors which impact the process. 

This approach again has it's short comings, however the two analysis approaches together provide a strong understanding of the process.

Process scoping

Process scoping is a hybrid of the previous two approaches, it creates a holistic view of the particular process, the advantage of merging the two is a holistic overview in one model, then downside is that this model is complex to create as well as understand, for this reason it may make more sense to use the previous to models to gain the necessary understanding, but then to combine the two into one model for a cohesive representation. It is made up of seven parts.

1. Outcomes: the result of the process
2. Process steps: the chain of granular steps which result in the outcome
3. Triggers: anything which starts the process
4. Participants: every individual or group who's input is required for the process
5. Variants: Any edge or alternative flows to the main process. 
6. Governance: The rules, regulations, and decision-making structures that guide the system.
7. Enablers: Factors that facilitate or support the achievement of the system's goals

Generally when creating a model such as this, one would work backwards, from the outcomes through to the triggers, than to work out from the participants, variables, governance and enablers, this provides a high level overview of the process and the all of the influencers surrounding it.

Establishing granularity

Regardless of scoping technique, you always end up asking yourself the question is this a process of processes, that is are any steps within my process, processes themselves? Let's take a look at the following process steps:

• Register a lead
• Score a lead
• Update status of a lead
• Sign a contract with a lead
• Register service request
• Dispatch a field worker
• Process payment
• Assess Service quality
• Apply correction
• Produce report

We can ask ourselves, is this one process? or are there multiple process here? Though all of the above are granular steps in an overall flow, however these could be segmented into four different processes.

Token analysis

In token analysis a business process should only handle one thing at a time, the token; meaning that each step should impact the token in some way or form, transform it, capture some information about it, route it. If there is a change in token between steps, then you are most likely dealing with a separate business process.

Process a lead

• Register a lead
• Score a lead
• update status of a lead
• Sign a contract with a lead

Process a request

• Registeres service request
• Dispatch a field worker
• Process payment

Assessment of services

• Assess Service quality
• Apply correction

Generation of report

• Produce report

As. you can see the 'macro' flow deals with four different tokens, hence it can be segmented into multiple process each time there is a change in token.

Takeaway

As you may recall we have four parts to a business process:

1. Events: Things that happen outside of the process, but have an effect on the process
• Triggers: an action that starts the process
• Timers: an interval which starts the process
• Messages: information which the process receives
• Error: a fault that impacts the process flow
2. Outcomes: what does the process accomplish
• Every process exists to deliver a specific repeatable outcome
• A process must have at least one outcome if not several
3. Actions: What are the steps in the process
• Each action is an activity carried out by an agent; it may be a person, organisation or an automated solution.
• Actions represent an activity used to product a final ore intermediate result
• Actions may be standalone steps, or the may represent a sub-process
4. Participants: Who or what performs the actions within the process
• The executors as well as any relevant parties of the actions or process:
• Supervisors
• Informed party
• Decision maker
• Operator

At a macro level every process should consist of the four key elements above