WEEK 3

Session 5

DEVELOPING NEW
BUSINESS
PROCESSES
“As-Is” and “To-Be” Modelling

BCO5501
BUSINESS PROCESS ENGINEERING

Updated: 4 September 2020

Acknowledgement of Country

We acknowledge the Ancestors, Elders and families of the Kulin Nation and Eora Nation
who are the Traditional Owners of University land. We also acknowledge all Traditional
Owners of Country throughout Victoria and NSW and pay our respect to their culture, and
their Elders past, present and future.

As we share our own knowledge practices within the University may we pay respect to the
deep knowledge embedded within the Aboriginal community and their ownership of Country.

We acknowledge that the land on which we meet is a place of age old ceremonies of
celebration, initiation and renewal and that the Kulin people’s living culture has a unique role
in the life of this region.

2
Copyright Notice
• The images used in these notes/papers have been reproduced either under Part VB of
the Copyright Act 1968 for educational purposes only, or under the terms of other sections of
the Act, or with permission of the copyright owner.​
• Please note that the Copyright for each work in the materials is owned by the author/s and/or
the publications listed.

Source: These slides are based on the following book:

•BruceSilver (2011): BPMN Method & Style, with BPMN

Implementer’s Guide. 2nd Edition and
•August-Wilhelm Scheer, Henrik von Scheel, and Mark von Rosing (2014), The Complete Business

Process Handbook: Body of Knowledge from Process Modelling to BPM, Volume 1

3
Models

4
 Quality of a Model
Investigate injury

Legal Support
required

Determine type
Investigate
liability Adhoc Legal

Legal Support is a service process that can

be triggered by more than one other process.
When jumping to Legal Support keep in mind where
you came from. After you went through
Legal Support you have to jump back to that process.
At various stages other than
the explicitly shown
Support required events/interfaces Legal Support
might be required.

Quality of legal
advice from
the Pane...
Legal Support
(post CC)
Coming from Claims Management

File referred to Claim not settled

/ Litigation
commenced
File referred to
Legal Support
(post judgement)

Legal Support is a service process that can

be triggered by more than one other process.
When jumping to Legal Support keep in mind where
you came from. After you went through
Legal Support you have to jump back to that process.
File referred to
Legal Support
prior to CC

Model
Syntactic
of legal support

Legal Support Legalbase

Legal Access
Last change: 2004-05-13 17:06:13

Semantic
required Legal
Receipt file
Assistant
All functions in this process are carried
out by a Solicitor if not shown otherwise.

Discuss issue
Legal
Categorise file
Assistant
Referral
Files to Procedure is relevant
Legal for the whole process
Services

Legal Referral File is

required File is Legal File is Limitation Compulsory
Issue does not File is Litigation File is SETT
Referral Review Conference
require legal
Review
referral
Legalbase Legalbase
Refer claim to
Legalbase Legalbase Legalbase
Legal Services
Allocate file
Allocate file to Allocate file to Legal
Provide verbal File is allocated Allocate file
Legal Panel Legal Panel Assistant
advice to Claims Claims Handler
Handler

Legalbase Legalbase MS Outlook

Record
Determine if
Record litigation compulsory
Legalbase research is
Record

Quality
drivers conference
required Legalbase
Legal Access consultation drivers Agree to meeting
Liasion with Liasion with
Record details with Legal
iDocs Claimant / Agent Claimant / Agent iDocs
internal Assistant
not required required
Generate letter of Legal Generate letter of participants
instruction Assistant instruction Legal
Legal Access Letter of Letter of Assistant
QMS
completed Instruction Instruction
Contact
Research is not Research is Send letter to claimant/agent

Quality
required required Legal Panel Generate Legal
Allocation Allocation Form Assistant
Form

Send file and

Undertake legal Legal
letter to Legal
research Assistant
Panel Review file
Resolution
Resolution
without court Legal Services
requires court CC Review
application File Review
application
possible
Receive CC
review from
Generate letter Legal Panel
Legal
confirming Additional Additional
Standard 03 Assistant
agreement Information not Information
letter
required required
CC Review
Check quality of
legal advice
External External Quality of
Gather
Assistance is not Assistance is Legal advice
Legal Brief Information
required required 50% no...
(CD07)
Receive court
Court
iDocs application from
Standard 03 application
claimant
letter Engage External
Provider
Quality is Quality is not
Agree on SETT Lawyer
appropriate appropriate
Action Plan in
Receive legal meeting
CTP Claims
advice from External External Legalbase
Supervisor
external provider Assistance is not Assistance is Telephone Legal
Record return of
Legal Advice required required Provider to
file
from external discuss Claims Handler
Legal Brief
provider
(CD07)
Senior
iDocs
Standard 03 Engage External Manager
Court attendance Court attendance letter Provider
not required required CTP Claims
Team Leader
Legal Advice Receive legal
from external advice from
Liase with
Attend court provider external provider Legalbase
claimant/agent Complete SETT
Action Plan
SETT Action
Plan
Confirm outcome
in writing
iDocs
Attend court Perform other
actions if
required
Generate letter to Legal
claimant/agent Assistant
Standard 03 Receive court
letter decision
Court Order
Receive court
decision
Court Order

MSR
Compulsory
Conference
Provide written Procedure
advice Complete
Legal Services compulsory
Advice conferencing
QMS
review
CC Review

Legalbase

Record date of
Legal
referral
Assistant
completion

Return file to Legal

claims handler Assistant

Comes back to where it was initiated

At various stages other than the

Legal Support Legal Support Legal Support Legal Support Legal Support Legal Support Adhoc Legal
explicitly shown events/interfaces
(Injury) (Liability) (post CC) received (post (post Litigation) prior to CC Support
Legal Support might jump back to that
completed completed completed judgment) completed completed completed
process.
Go back to Claims Management

Investigate injury Investigate liability

Reality
Pragmatic
Quality
Meta
Model

Domain Model Technique

Knowledge Knowledge

Modeler
5
Modelling Techniques
Pay
A
Customer ment c
ct Management
Invoi s

ce
C1
Sales Order
Orde Clerk

Work flow diagrams

r Invoi
ce
Sal Sales C2
es
Ag
Order Dis
Customer
Deliv
ent
pat
Form ch ery

Paint Required

Determine colour

Event-Driven Process Chains (EPCs) White Blue Red

Apply Cover Coat

Cover Applied Apply Colour Coat

Painting Complete

Business Process Model

& Notation (BPMN 2)

BUT: other documentation is required as well.

6
Participants in the Process
◆ Representatives from all
◆ Suppliers, customers
relevant areas ◆ IT & IS staff (but avoid
◆ Consider: geography, detail!)
product type, market, ◆ Best organised as a group
customer types
◆ Must play a role in the (vs individual interviews)
process ◆ JAD type sessions
◆ Management, supervisors,
front line workers

7
‘As-is’ Modelling

The identification of the core processes of a company is followed by the

survey and analysis of the current situation.
This is the basis for identifying weaknesses and for localising potential
improvements
‘As-is’ modelling involves considerable effort, therefore first ask
Whether, and to what extent, as-is modelling is to be carried out.
There are both arguments for and against ‘as-is’ modelling.

Adapted from: Schwegmann, A. and Laske, M. (2011): As-Is Modeling and Process Analysis.
and Speck, M. and Schnetgoeke, N. (2011): To-Be Modeling and Process Optimization.
In: J. Becker et al. (eds): Process Management, Springer, 2011, pp. 133-185

8
Arguments for
‘As-is’ Modelling
Modelling the current situation and the resulting as-is models can
Be a basis for identifying weaknesses and potential improvements;
Be a prerequisite for developing a migration strategy to the target situation;
Provide an overview of the current situation for new and external participants in the
reorganisation project;
Be used to train and introduce the project members to the tools and modelling
techniques to be used;
problems with the tools or techniques will be detected before the to-be modelling
stage;
Project members can then concentrate on the improvement of structures and
processes in that stage;
Be used as a checklist in the to-be modelling stage in order to prevent relevant
issues from being overlooked;
Be reused as the main input for the to-be models to reduce the efforts for to-be
modelling
Assumption is that current situation at least partially conforms to the to-be models

9
Arguments against ‘As-is’ Modelling

The collection of data of the current status (as-is modelling) hampers the
creativity of the participating employees.
There is a risk that old structures and processes will enter the
subsequent to-be modelling phase without reflection.
Creating detailed as-is models can be very time-consuming and
expensive.

10
Procedure of ‘As-is’-Modelling

11
 Integrated Modelling Architecture
Organisation View
Who? Where?

What? How?
Data View Function View
When?
Control View

Product/Service
Why?
View
IDS (2005)

12
Preparing ‘As-is’ Modelling

Define the goal for ‘as-is’ modelling.

What do you want to use the ‘as-is’ modelling for?
Select the relevant views in your modelling architecture and use features
to determine the targeted detailing of the as-is models.
E.g. the “Architecture of Integrated Information Systems (ARIS) distinguishes
between 5 descriptive views
Organisational view and process (control) view are of primary relevance for
improving organisational structure and business processes.
Also: create the modelling conventions
Identify potential information sources and evaluate them in terms of
relevance and how current they are.
E.g. organisational manuals, documentation of application systems in use,
qualified experts

13
Identifying and Prioritising
Problem Areas To Be Collected
Identify the problem areas that represent an enclosed unit.
Partial areas can be better handled, prioritised and processed by the modelling team.
For splitting, various alternatives are possible, e.g. function-oriented, object-oriented.

Describe the problem areas or the processes by means of adequate features.

E.g., process name, objectives, owner, participants, application systems, average processing
time, costs, frequency of occurrence, error frequency, etc.

Maintain a glossary that contains the definitions of relevant technical terms.

Collecting technical terms is necessary in order to detect differences in the use of the
terminology within the same company and to arrive at a standardised terminology for the as-is
models.
Source for data models

Prioritise the problem areas with the help of the features, and stipulate the areas to be
considered in the as-is modelling.
Current or future core processes, cost-intensive support processes,
ineffective processes

14
Collecting and Documenting “As-is”
Models
Group the problem areas into modelling complexes to be
processed by a team.
Assign team leader, method experts, subject matter experts
Train the project participants in the modelling techniques and tools.
Model the processes and structures regarded as relevant in individual
interviews and group workshops.
Make sure that similar situations are mapped with analogous structures.
In addition, make sure that the terms in the glossary are used consistently and
updated continuously.
Follow the modelling conventions when modelling.
Document obvious weaknesses and potential improvements, and avoid
long discussions about the to-be state.

15
Consolidating the “As-is’ Models

Work out analogous structures for different partial models, and

standardise the terminology used in the models.
Very important in the case of object-oriented splitting of problem domain
Integrate the partial models created by different teams into a global
model at an early stage.
This will/can cause inconsistencies that require the partial processes
to be reworked and agreed upon again.
Structure the global model according to the business
process framework and model typical business
transactions, where applicable.
The business process framework is the top-level model
Serves as starting point for navigation through the
consolidated as-is models.

16
Analysing ‘As-is’ Models

Set criteria for the evaluation of the as-is models.

Functional (performance), financial (profitability) and
Pa
int
Re
quir
ed
De

social goals (employees/groups)

t er
min
Wh ec
ite olo
ur
Ap
ply
C ov e Blu
rC e

Check whether reference models for the surveyed areas

oat
Co
v er
Ap
plie
d Re
d

exist, and use them as a basis for the evaluation.

Compare as-is models with best practice captured in reference models Ap
ply
C olo
ur
C oat
Pa
intin

Analyse to what extent process benchmarking is practical and initiate

gC
om
p lete

corresponding actions.
Identify the weaknesses of the actual status on the basis of the
evaluation criteria, and document these sufficiently.
Check to what extent identified weaknesses or potential improvements
exist that can be realised with a minimum short-term effort.
Arrange and supervise the elimination of weaknesses or the
implementation of the potential improvements.

17
 Evaluation of IT Support and
Technical Infrastructure
‘As-is’ models must be analysed for the following potential ICT system-
related problems
A lack of functionality in existing application systems;
A lack of, or insufficient, facilities for managing relevant data and/or for managing
data that is not required;
Redundant storage of data in different application systems;
Risk of inconsistent databases; requires multiple entries;
Low performance of ICT systems;
Poor operability and/or inconsistent user prompts;
Results in high training costs and erroneous entries;
Use of different ICT systems for the same task in different company areas;
Results in high administrative costs, incompatible interfaces, communication
problems;
No electronic data exchange with business partners;
E.g. orders, delivery notes or invoices;
Lack of application of new technologies;
such as WFMS, electronic document management, web services etc.

18
Evaluation of Process Organisation

‘As-is’ models must be analysed for the following potential

weaknesses of the quality of the process organisation
Identification of superfluous processes;
Considerable rationalisation can be achieved by identifying processes
that can be eliminated altogether by replacing them by another organisational solution;
E.g. order entry by customer using the Internet or
outsourcing of certain tasks to external service providers;
Identification of potential acceleration.
Identify potential for parallelising and continuously processing activities;
Identify potential for acceleration by better use of application systems;
Localisation and optimisation of internal and inter-operational process interfaces;
Rationalisation by reduction of internal process interfaces; reduces idle times and
familiarisation times;
Optimisation of inter-operational interfaces to business partners;
Localisation of workflows with the same contents but different structures
Uniformity and standardisation of processes facilitate the IT support of these processes
Review of the forms system;
Badly designed or too many forms can impair the efficiency of the processes.

19
Evaluation of Organisational
Structure/Personnel
‘As-is’ models must be analysed for the following potential weaknesses
of the organisational structure and/or the personnel area
Deficiencies through unclear, unsuitable and/or inconsistent assignment of
decision-making and processing responsibility;
Unclear assignment of tasks from the customer’s point of view;
Too many hierarchical levels that extend decision-making and communication
channels and prevent the employees from exercising their own responsibility;
A lack of incentive systems to
sufficiently motivate employees;
Expecting too much or
too little of employees
in their daily work.

20
Implementation of Immediate Measures to
Eliminate Weaknesses
Not all detected weaknesses require comprehensive reorganisation
efforts.
Immediate measures could lead to success in the following situations:

No change or only minor structural changes to processes

No adaptation or only minor adaptation of the existing IT infrastructure
No new technical infrastructure
No approval of measures by staff council required
Consensus among the participating managers and employees

21
To-Be Modelling

Depending on the purpose for which the model is prepared,

to-be modelling is carried out on the basis of the as-is models
and the weaknesses analysis that originate from the as-is modelling.

Internal expectations from both management and employees

Increase in profits
Cost savings •Shortening of process times
Streamlining of processes •Information that is more up-to-date
Reduction of planning times •Better communication via defined interfaces
•Minimisation of idle times
External customer- and/or market-oriented requirements
Higher process/product quality
Closer proximity to customers • Greater process transparency for customers
Faster communication with partners • Increase in market shares

22
Procedure of ‘To-be’-Modelling

23
Preparation of ‘To-be’ Modelling

Map the corporate strategy and/or project goals for individual purposes.
No to-be modelling if goal of modelling was training of employees or the
certification of the company;
To-be models are created if there is a need for action on reorganisation;
Selected purposes could include:
Organisational documentation
•Benchmarking •Software development
Process-oriented reorganisation
Continuous process management•Knowledge management •Workflow management
Certification, e.g. ISO 9000 •Selection of ERP software •Simulation of processes
•Model-based customising •Activity-based costing
Determine the modelling views to be used (data, processes, functions,
and organisation) as well as the degree of detailing.
The installation of a workflow management system, or the development of IT
systems, normally requires greater detailing than for example the use of
models to design a new organisational structure.

24
Collection and Documentation
of ‘To-be’ Models
Identify the services relationships between the core processes and the
support processes.
Identify the interfaces between the modelling complexes.
Work out rough process structures and present them in a simple format,
e.g. as value chain diagrams.
Create the to-be models for the individual modelling complexes and
evaluate them by means of the catalogue of criteria drawn up for as-is
modelling.
Distinguish between ideal model and to-be model.
Take the short-term to mid-term implementation of the to-be model into
account.
Check the fit-for purpose hierarchisation of the process models.
Adequate structuring of (sub-)processes over multiple levels

25
Consolidation and Editing of ‘To-be’
Models
Consolidate the to-be models of the individual modelling complexes into
an entire process model at an early stage and continuously during
modelling.
Ensure the syntactic and semantic quality of the process models.
Document the work done and edit the models for further use, e.g.
modelling the organisational structure.

26