White Paper – IDEF for Business Process.
Update from Treepad Igrafx database
Clear to business rules, strategy and constraints – does not look at processes in isolation from the
WHY of the organisation
Introduction
business process modelling is one of the first steps in business process improvement. By making the
process steps and their interactions and transfers visible via a diagram, their operation can then be
understood and that understanding developed by a group of people. How this model communicates
is critical to the success of the project. Process models must be consistent, simple to understand and
be ideally readable without reference to any supporting documents.
The purpose of all business process models is to provide a representation of reality. The
effectiveness of those these models depends on their accuracy, completeness and understandability.
A model that is not quickly understood has negligible business value and reflects poorly on the
person presenting it. If a business analyst has to spend time explaining what is diagram means then
he is wasting the time of his audience.
Messages and sequences are shown the same for IDEF – out of one element and in to another
<REWORD>
A good process map can be read as easily as a map. In the same way that a map can have levels of
detail ranging from a map of the world to a local street map or a plan of a house, process maps it
should be organised in a hierarchy to allow the user to access the level of detail they need.
Business process documentation within an organisation can be difficult to navigate. To do this
requires simple process models that allow you the user to navigate down to levels of detail and up to
levels of abstraction or conception <reword>
Criticism of BPMN
The prevalence of BPMN modelling tools, and the free availability of excellent tools such as BizAgi
and ARIS means it is very easy for people to create the PMN process models. However, a lot of
people produce models that are over detailed and fail to communicate. I’ve recently seen BPMN
process maps with over 100 elements on one page, inconsistent use of symbols and no common
business language. It’s quicker to produce a simple well thought out process map that
communicates, but the author must be able to visualise processes in an abstract way <REWORD>.
Producing effective process maps is more is dependent on the author and not the tool. Creating
process models with limited number of symbols forces clarity and consistency. With over 100
symbols in the BPMN library understanding and using these appropriately requires training for the
creator and user.
A developed BPMN diagram contains too much detail to be easily read < CHECK WEB COMENTS>
Increasing use of business process management suites which use BPMN to describe business
processes (to then enable these by IT) are
The specification itself is depressingly overlong, at 550 pages
Comparison
BPMN
Flowcharting
Number of symbols
4?
100? But reduced
set can be used as
long as this is agreed
as the modelling
standard.
Availability of free
drawing packages
Very limited
Very good.
Complexity
Low – taught to
school children
Readability for
untrained users
Low
High
Clear visibility of
controls and
mechanisms
Not shown
Yes
Use swimlanes?
Yes
Yes
<Add example of process map if this is available from FSCS>
Various modelling languages – flowcharting, BPMN, UML, IDEF. BPMN is the dominant language
and works well as a common approach between business and IT. However, the notation is complex
and non intuitive. Lot’s of bad BPMN is produced by people who don’t have a clear idea of what
they are doing and how to communicate it <REWORD> I’ve seen BPMN maps with over 100 blocks
on one page, thus unusable. Good mapping practice is to use hierarchical levels, with no more than
ten activities per page.
A
A good example of a hierarchical process modelling system is the APQC business process
classification framework. This shows the value chain and supporting processes functions at top level
within an enterprise.
ADD DIAGRAM by default, a good IDEF0 modelling tools such as IGRAFX will by default provide
seven process elements per page.
Any more than this makes maps difficult to understand and therefore use. <EXAMPLE OF MAP FROM
FSCS?> Maps produced by people with low understanding and approved by others with limited
understanding.
IDEF is simple and intuitive notation which makes it ideal for business.
Process maps are a model of reality which communicate an understanding. If that understanding is
not shared because the language is not understood, then they fail.
Process mapping should be performed to provide an understanding and confirmation of business
processes, not as an way of implementing an IT solution <REWORD AND DEVELOP>
Examples of making a sandwich in all of these notations
Simple example
The origin of IDE
IDEF, standing for Integrated DEFinition Methods was developed in the 1970s by the United States Air
Force. The IDF family of methods contains six categories:
ADD LIST
for business process modelling we are only interested in
IDEF0. This for functional modelling
IDEF3. For process modelling
Both of these categories defined purpose and description
Root definition of purpose/requirements:
Must be able to safely and reliably transport family of four and luggage at reasonable cost <DEFINE>.
Skills to operate car must be within reach of normally physically and intellectually capable person.
Abstraction. WHAT
Detail. HOW
At the top level, the concept of a car is abstract. The lowest level contains the detail of how this
concept is realised i.e. with an engine, transmission, wheels, chassis and subcompents.
Each subcomponent is clearly identified and where it fits into the higher levels is defined. ‘What is
what, and what goes where’.
Need same for process organisation – need classification and numbering scheme.
1
Car
1.1
Engine
1.1.1
Ignition
1.1.1.1
Spark
plugs
1.1.1.2
Coil
1.1.1.3
Timing
circuit
1.1.2
Starter
1.2
Chassis
1.1.3
Carb.
3
Fuel
1.1.n
Etc.
1.1.1.n
Etc.
The same principles apply to mapping the processes within an organisation
1.n
Etc.
IDF zero the IDF method uses simple black box models which are quick to understand and thus use.
No complex notation needs to be understood unlike BPM and with over 100 different symbols which
result in process maps that cannot be understood without reference to supplementary documents.
Function modelling in IDEF0 could not be simpler:
Controls
Inputs
Function name
<REWORD>
Outputs
Mechanisms
when I use this technique with business users I do not use the term mechanisms as this requires
explanation and is not as clear as using resources. Resources are people materials equipment power
etc anything that is consumed to make the process work I also talk about controls and constraints to
include budget and time limits etc.
Can be redrawn as problem solving map:
Copy of this on Barclays
Update below from Igrafx arrow setup
Inputs
Controls
Mechanisms
(resources)
Outputs
what starts the activity. There may be multiple inputs add example from
AJHuntleigh
These guide or regulate the process
The results of performing activity
Show decomposition numbering
Creating a model
IDEFO Arrow Table
Inputs
Outputs
Controls and Constraints
Resources
11111111111111111111111111111111111111111111111111111111111111111111111111111111
111111111111111111111111111
Purpose:
Enter purpose here.
Oven capacity
Dough rising time (24 hours)
Available working hours
Kitchen workspace
Sale of food regulations
Sold bread
Ad hoc Orders
Unsold bread
Bake bread for
public sale
0
Forecast orders
Ingredients
Waste
Heat
A0
Staff
Electricity for lighting and production equipment
Gas supply to ovens
The (|) symbol means that the arrow is tunnled and therefore not seen in the child diagrams. This
reduces clutter – so we can tunnel staff as a resource/mechanism that applies to all activities.
However, we leave Gas supply to ovens untunnled as this is specific to the child diagram <REWORD>
This level zero model then decomposes down to a ‘wiring diagram version’
Oven capacity
Dough rising time (24 hours)
Ad hoc Orders
Forecast requirements
Kitchen workspace
Receive orders
Forecast orders
1
Variation to requirements
Bulk ingredients
Manage
inventory
2
Make bread
3
Ingredients
Fresh loaves
Unsold bread
Sell bread
Gas supply to ovens
Waste
4
Sold bread
Each element can then then be decomposed futher e.g. make breat.
To make that easier to read, the connections can be shown as another layer <REWORD> try – show
lines as layers
Decomposition of Make Bread, Step 3.
Start
Mixing
Mix igredients
Allow to rise
Knead dough
Kneading
Allow to rise
Baking
Preheat oven
Bake bread
End
Dough rising time (24 hours)
Oven capacity
Available working hours
Kitchen workspace
Sold bread
Ad hoc Orders
Unsold bread
Bake bread for
public sale
0
Forecast orders
Waste
Heat
Staff
Ingredients
Gas supply to ovens
Electricity for lighting and production equipment
Creating a click through model
Publishing model
Visio approach
Edraw approach
Igrafx IDEF approach
Conclusion
IDEF notation has a high number of benefits over BPMN, but, while the DVLA in modelling tools are
very easy to find and free tools such as BizAgi and ARIS XXX are sufficient for much of business
process modelling, modelling tools for IDF are limited and expensive stop whilst they can be created
using drawing diagramming strategies such as Visio an Graffletooia, producing a large quantity of
mass can be time-consuming and less dedicated drawing is available.
Some dedicated drawing packages are listed below
Product
Igrafx
IDEF0
Comments
Simple and effective, this
tool creates a library of
Supplier
Cost
process elements while
the IDEF 0 and IDEF 3
model is being created.
Edraw
Free 30 day trial
Edrawsoft.com