Notations for Business Process (Part 2) - Flowchart, FFBD and IDEFØ

Having looked at RAD, EPC and BPMN process diagrams in previous article, let look at other graphical representations for business processes which are around for quite some times. They are definitely the ancestors of process flow diagrams but still well and popular.

More Notations on Business Process

This article covers Flowchart, Functional Flows Block Diagram (FFBD), and Integrated DEFinition (IDEF) for Function Modelling (IDEFØ) Diagram. But first let revisit a common argument about using a Rich Picture diagram for representing business process.

What about Rich Picture Diagram?

A rich picture is a generic pictorial representation of concepts or issues related to a given situation. The diagram uses a wide range of user specified graphics or images (artefacts). Although it can be used to show some form of associations between these artefacts, the links could be of any type of associations.

Figure 1: Example of Rich Picture diagram
Source - Open University, UK

The lack of schematics introduces inconsistencies between diagrams. Even though it is a good problem analysis tool, it is not a standard that can be adopted for enterprise wide process model representation. It is at its best a concept map that represent a collection of issues and associated entities.

Flowchart

Originally developed as a flow diagram for describing software algorithms. There are approximately 32 elements or symbols depending on the purposes, variations and extensions. The notation is commonly used with swimlanes to depict cross-functional (roles) process diagram. When used to draw business process, the basic elements used include start/end nodes, steps, decisions, subroutines, labelled connectors and documents.

Figure 2: Example of Flowchart

In a flowchart, a decision (diamond shape) element represents a decision action. This is different to EPC and BPMN where the connectors (EPC) and gateways (BPMN) are not decision actions. As their names implied, they are - connectors and gateways - used to model causal ordering relations. They are used purely as split nodes or join nodes in the process flow logic. Nevertheless it is also not unusual to see that a separate step is used to depict decision making and use the diamond as gateway - a proliferation from other notations, I guess.

Functional Flows Block Diagram (FFBD)

The original aim of FFBD in systems engineering is to show the order of execution of system functions or functional flow of a system. It is also commonly used for representing business process within specific business function. The key elements of FFBD are function block, function numbering, functional reference, flow connection, summing gates, and GO/NO-GO paths.

Figure 3: Example of Functional Flow Block Diagram

FFBD is originally developed for functional analysis thus focusing on functions or procedural steps, and role is not in the schematic of the diagram. A FFBD defines only the sequences and relationships of functions or steps. Another important aspect of business process missing in a FFBD is horizontal interactions across functions from different business areas. Its aim is functional analysis and not cross functions analysis. So hands off between business areas remain as white spaces.

The use of a series of levels and display them in their logical, sequential relationship between the levels provides a functional decomposition view in FFBD. Each block in a diagram can be expanded to a series of functions in the next level down, creating a vertical sequential matching.

FFBD is the most commonly adapted notation in process documentation works and traditional waterfall SDLC works (pre-UML). The variations are mostly combinations of FFBD with elements of other notations such as swimlanes from flowchart to denote roles.

Also note that in systems engineering, the final output from a functional analysis is a functional architecture of a system. An interesting point to note is that most business process frameworks are derived from functional architecture or functional decomposition of business value chain which is a system. You can read more about business process frameworks in the other article - Business Process Architecture - From Value Chain to Process.

Integrated DEFinition (IDEF) for Function Modelling (IDEFØ) Diagram

IDEF refers to a family of modelling language derived from the Structured Analysis and Design Technique (SADT) for software development. IDEFØ is one of the 14 IDEF modelling standards. Similar to FFBD, IDEFØ diagram consists of a hierarchical series of diagrams, text, and glossary cross-referenced to each other. It is used for modelling functions or activities of an organization or system. There are only two key elements - functions as boxes and objects that interrelate those functions as arrows. The objects may include data, control, inputs, outputs, mechanism or call.

Figure 4: Example of IDEFØ diagram

It also has a node element that is used to build a node tree showing vertical relationships between parent and child functions, i.e. a functional decomposition view. A top-level IDEFØ diagram, also know as top-level context diagram, is used to depict the primary function to be decomposed and defines the scope of that function including input, output, control and mechanism.

Figure 5: Example of IDEFØ top-level context diagram

More about Process Context Notations in the next article.

While IDEFØ diagram provides the process context, IDEF3 (Process Description Capture Method) diagram is the complimentary process flow notation to IDEFØ. See the example below. However, IDEF3 diagram is seldom used nowadays.

Figure 6: Example of IDEF3 diagram
Source: Griffith University

Picking the Right Notation

BPMN process diagram is definitely my recommendation when selecting a process flow notation. First the current version of BPMN (BPMN 2.0 ) is developed based on a wide range of other notations incorporating the many features of these notations. BPMN is not only graph-based and Petri-net based process modelling notations, but it also absorbed features of UML activity diagrams and Event-driven Process Chains. Moreover, the introduction of BPMN 2.0 in business process modelling is very similar to that of UML for object-oriented design and analysis. It is developed with the aim of identifying the best practices of existing approaches and combining them into a new standard and generally accepted business process notation. Lastly, it offers a modelling notation that supports business level usage and all the way to operational and implementation levels. Hence ensuring a round trip engineering environment reducing lost of information or miscommunication between these layers.