Aligning IT Solutions With Business Processes

This page is intentionally left blank.
Preface
"If customers can check on the status of their orders on the Internet, we will
spend much less time dealing with inquiries on the telephone."
"If we can shorten our auto claims processing time, we can gain a
competitive advantage."
There is no shortage of good ideas like these. But incorporating these
ideas into business process and developing IT Applications to support the
process is often beset with difficulties. While organizations understand the
importance of using IT solutions to automate their business processes,
very few are able to effectively achieve this in practice. Most business-IT
initiatives taken up by organizations suffer from some of the following
problems:
An IT solution is defined from the perspective of the features it should
have rather than how it should help satisfy the business needs of the
organization
A big gap exists between the articulation of a business problem and
the articulation of requirements of an IT solution - business people
have difficulty understanding how an IT solution that is being built will
help the business requirements till it is finally implemented and
operated. Likewise, IT people have difficulty understanding the
business and designing a solution that adds value to the business
A best-fit IT solution cannot be decided upon or deployed rapidly
because of incomplete or imprecise requirements from the business
people
The reasons for such problems can be due to insufficient appreciation of
business processes by the IT team, evolution of systems in silos, lack of a
common language between business and IT, selection of a wrong IT
solution and the growing business and changing environment.
A good IT Professional must, therefore, possess the necessary
knowledge and skills to execute a methodological approach to translate
business requirements into clear IT solutions. In this book we present a
Business Process Engineering Methodology (BPEM) that brings in
formalization and repeatability into the process of translating business
iv
Preface
objectives into IT solutions through a collection of models, techniques and
tools. The BPEM is based on the proprietary InFlux methodology
developed by lnfosys Technologies Ltd. and adapted to suit the audience
of this book, namely, IT professionals and students.
Target Audience
This book is designed to adopt the active learning style practiced at the
School of Information Systems, Singapore Management University,
Singapore. It is used as the text book for the Process Modelling and
Solution Blueprinting course that aims to provide students with the
necessary knowledge and skills to ensure that they can methodologically
translate business objectives into effective IT solutions.
We wrote this book specifically for students and junior solution consultants,
who would work within a team in the proposal stage of an IT project. The
main focus is on being able to apply a methodological approach, to align IT
solutions requirements with business requirements. The book is set in the
context of IT -enablement of business processes. The book does not
require the reader to have in-depth IT technology experience. Additionally,
this book is also useful for those who are regularly involved in business
process change, such as business analysts, system analysts, junior IT
architects and project managers.
Layout of the Book
In Chapter 1, we discuss the importance of managing business processes
in an organization and how a process can be managed at the enterprise,
process and technology levels. At the end of the chapter, through a case
study we show how a business process is enabled through the use of IT
In Chapter 2, we discuss the importance of business and IT
alignment and how in the context of an IT project, the Business Process
Engineering Methodology (BPEM) helps to align IT solution requirements
with business requirements. We divide the BPEM into two phases, namely
Business Modelling and Concept Solution Blueprinting. Chapters 3 to 7
focus on the Business Modelling Phase of the BPEM and Chapters 8 and 9
on the Concept Solution Blueprinting Phase.
In Chapter 3, we describe the various activities of the Business
Modelling Phase. This includes As-Is Modelling, As-Is Process Analysis,
To-Be Modelling, To-Be Process Analysis and IT Solution Requirements
Definition. For each activity we describe the purpose, and define the inputs
and outputs.
v
Published by
Pearson Education South Asia Pte Ltd
23/25 First Lok Yang Road, Jurong
Singapore 629733
Senior Solutions Manager: Ang Teck Chuan
Project Editor: Sharon Nam
Prepress Executive: Kimberly Yap
Pearson Asia Pacific offices: Bangkok, Beijing, Ho Chi Minh City, Hong Kong,
Jakarta, Kuala Lumpur, Manila, Seoul, Singapore, Taipei, Tokyo
This eBook is derived from:
Aligning IT Solutions with Business Processes: A Methodological Approach by Venky
Shankararaman, Kar Way Tan, Srinivas Thonse, Mayank Gupta and Nivedita
Deshmukh. Copyright Pearson Education, Inc., 2007. ISBN: 9789810679231.
(232 pages extracted)
4 3 2 1
16 15 14 13
ISBN 978-981-45-2636-4
Copyright Pearson Education South Asia Pte Ltd 2014. All rights reserved.
This publication is protected by Copyright and permission should be obtained from
the publisher prior to any prohibited reproduction, storage in a retrieval system, or
transmission in any form or by any means, electronic, mechanical, photocopying,
recording, or likewise. For information regarding permission(s), write to: Rights
and Permissions Department.
PEARSON
www.pearsonapac.com
Contents
Preface iv
Acknowledgement vii
Chapter 1: Business Process and IT 1
Chapter 2: Business Process Engineering Methodology 29
Chapter 3: Business Modelling Activities 41
Chapter 4: Business Process Model 49
Chapter 5: Process Analysis- Static Analysis 84
Chapter 6: Process Analysis- Dynamic Analysis 112
Chapter 7: IT Solutions Requirements Definition 164
Chapter 8: Solution Blueprint 177
Chapter 9: Concept Solution Blueprint Activities 186
Summary 227
Preface
In Chapter 4, we present the various views of a business process
model such as Organization Model, Location Model, Collaboration Model,
Workflow Model, Process Catalogue Model and Business Rules Model,
that are developed during the As-Is Modelling and To-Be Modelling
activities of the Business Modelling Phase.
In Chapter 5, we describe the systematic methodology for performing
Static Analysis of a business process and then documenting the issues
and recommendations for developing the To-Be process.
In Chapter 6, we describe a systematic methodology for performing
Dynamic Analysis (simulation) of a business process and documenting the
analysis results.
In Chapter 7, we describe how functionalities from To-Be Models and
the Dynamic Analysis reports are mapped into functional and non-
functional requirements for the IT Solution.
In Chapter 8, we define the term Solution Blueprint and highlight the
difference between the Concept and Detailed Solution Blueprints.
In Chapter 9, we describe the various activities of the Concept
Solution Blueprinting Phase. This includes Solution Modelling, Application
Modelling, Domain Modelling, Service Modelling, Risk Modelling and
Concept Cost Modelling. For each activity we describe the purpose, and
define the inputs and the models that are developed.
Application of Concepts through a Case Study
At the end of Chapters 4, 5, 6, 7 and 9, through the use a case study, the
GigaByte Solutions Private Limited (GSPL) Travel Requisition Process, we
demonstrate how the concepts covered are applied to a real world setting.
This case study is based on a real project but has been substantially
modified and adapted to satisfy the purpose of this book.
Feedback
We welcome feedback and suggestions so that we can further improve the
book in its subsequent versions. Please send your feedback to
venky@smu.edu.sg.
vi
Acknowledgement
We thank the management of Software Engineering Technology Labs,
lnfosys Technologies Ltd., and School of Information Systems, Singapore
Management University for encouraging the partnership between
academia and industry and the support given to publish this book.
We express our sincere appreciation to the students of the School of
Information Systems, Singapore Management University, who undertook
the Process Modelling and Solution Blueprinting Course in the Academic
Year 2005-2006 for their contribution to the case study solutions.
Portions of this work relating to InFlux have been created by employees
of lnfosys Technologies Ltd. (InFlux Materials). All use of the InFlux
Materials is identified in the work and belong to lnfosys Technologies Ltd.
The copyright notice for the InFlux Materials is 2004 lnfosys
Technologies Ltd., Bangalore, India. lnfosys Technologies Ltd. has granted
the author and the publisher rights to publish the InFlux Materials in this
work.
vii
This page is intentionally left blank.
CHAPTER 1
BUSINESS PROCESS and IT
Chapter Topic List
1. What is a Business Process?
2. Example Business Processes
3. Business Strategies and Goals
4. Business Process Management
5. Process Architecture
6. Business Process Enablement and IT
References
Case Study- Grooming.com
Learning objectives
On completion of this chapter, you will be able to:
Describe a business process
Appreciate the importance of managing business processes in an
organization
Understand process architecture and explain the need for it
Develop a process architecture for specific industry domains
Understand the role of IT in enabling a business process
2 Business Process and IT
BUSINESS PROCESS and IT
1. What is a Business Process?
An Analogy
As an analogy, business processes in an organization can be compared to
the nervous system of the human body. The nervous system is made up of
your brain, your spinal cord, and an enormous network of nerves that
thread through your organs, muscles and various parts of your body; it is
the control centre for your entire body. Your brain uses information it
receives from your nerves to coordinate all of your actions and reactions.
Without it, you could not exist! Similarly, organizations have numerous
business processes that involve people, machineries and IT applications.
These business processes define the activities, events, rules, people and
the IT applications in the organization. Through these business processes,
organization is able to deliver goods, services or information to the
organization's employees, external customers and partners. Without
business processes an organization would not exist.
Definition of a Business Process
A business process may be defined as a repeatable series of activities
performed to deliver a service or product to a stakeholder. Following are
some of the characteristics of a business process:
Each activity comprises of a set of logical steps that is performed by
human or machines
The process transforms inputs into outputs according to guidance by
employing resources
The process is initiated by one or more business events
The process has performance indicators for which measurable
objectives can be set and performance evaluated
Example: Order-to-Cash Process
The order-to-cash process originates with the arrival of a sales order from
a potential customer and ends when the organization processes the
payment from the customer. Several activities are involved in the order-to-
cash process. These include receiving the order, checking the customer
credit, entering the order, fulfilling the order (production/shipping), invoicing
Business Process and IT 3
the customer and processing payment from the customer. Figure 1.1
shows a simplified example of an order-to-cash process along with the
sequence of activities. Each activity is typically conducted by an individual
or a system within a department. The Sales department receives an order
that is handed off to the Finance department for a credit verification that is
then handed off to Order Administration who enters the order into the ERP
system and on and on until the order is finally shipped to the customer and
the Accounting department sends an invoice and processes the payment.
SALES
Receive
Order
Activity 1.1
FINANCE
Check Credit
ORDER
ADMIN
Enter Order
SHIPPING
Ship Item
Figure 1.1: An example order-to-cash process
ACCOUNTS
Process
Payment
Examine the example order-to-cash process shown in Figure 1.1 and list
the key characteristics for this business process. For example, this
business process involves multiple departments in the organization.
Activity 1.2
Using the definition of the business process, identify for each activity, the
steps, the resources, the business events and the performance indicators
for the example order-to-cash process shown in Figure 1.1
Sub-Processes
In some instances, some of the activities within the process may be
referred to as sub-processes. For example, in Figure 1.1, it is conceivable
to view the activity "Check Credit" as a sub-process. When does an activity
becomes a sub-process is quite subjective. Usually, it is better to consider
an activity as a sub-process when the activity is quite complex and
involves a number of steps. The notion of process and sub-process is
iterative. A process may comprise of a number of activities and sub-
processes. A sub-process is a process which may further comprise of a
number of sub-processes and activities and so on. Figure 1.2 illustrates
this point.
Figure 1.2 Hierarchy of Process, Sub-Process and Activity
2. Example Business Processes
Table 1.1 shows examples of business processes for the
telecommunication industry domain. As discussed earlier, each process
may comprise of sub-processes and activities. For brevity, these are not
shown here.
Process Explanation
1 Billing Process This process encompasses provisioning
of billing to customers, supporting the
billing and assuring accurate invoicing
and collection of all revenues due to the
service provider. In addition, this
process also includes providing real-time
usage and charge information,
responding to and resolving customer
billing inquiries, identifying fraud and
credit abuse and taking action to
eliminate them.
2 Assurance Process This process encompasses the
management of service and resource
problems prior to them impacting the
customer, the correct resolution of
customer reported troubles and service
provider identified problems in a timely
fashion, and the management of service
and support to meet Quality of Service
and Service Level Agreement
commitments. In addition, it also
includes the collection of performance
data, correlation, analysis and reporting
of service performance to the customer
and network, service and enterprise
management.
3 Billing and Collections This process encompasses the
Management Process maintenance of a customer's billing
account, sending invoices to customers,
processing their payments and
performing payment collections. In
addition, this process includes handling
customer inquiries about bills, providing
billing inquiry status and is responsible
for resolving billing problems to the
customer's satisfaction.
4 Fulfilment Process This process encompasses the
provisioning of the requested products to
the customer in a timely and correct
manner. It translates the customer's
business or personal need into a
solution, which can be delivered using
the specific products in the
organization's portfolio. In addition, this
process includes informing the
customers of the status of their purchase
order, ensuring timely completion as well
as customer satisfaction.
5 Human Resource This process encompasses the
Management provisioning of salary structures by level,
coordinating of performance appraisal
and compensation guidelines, setting
policies in relation to people
management, employee benefit
programs, employee review policies,
training programs, employee acquisition
and release, retirement, resource
planning and workplace operating
policies.
6 Financial and Asset This process encompasses accounts
Management payable, accounts receivable, expense
reporting, revenue assurance, payroll,
tax planning and payment etc. In
addition, it also includes collection of
data, reporting and analyzing the results
of the firm. Asset Management
processes encompasses defining asset
policies, tracking assets and managing
the overall corporate balance sheet.
Table 1.1 Examples of eTOM Processes [eTOM]
Activity 1.4
Examine Table 1.1 and discuss how processes 1, 2, 3 and 4 are different
from processes 5 and 6. Also discuss the relationship between processes
1 and 3.
3. Business Strategies and Goals
Business strategy is defined as "a broad formula for how a business is
going to compete, what its goals should be, and what policies will be
needed to carry out these goals" [Porter1996]. Table 1.2 shows some
examples of business strategies and corresponding goals for an insurance
company.
Business Strategy Goal
Accelerate growth in the auto Achieve 30% increase in revenue
insurance business from auto insurance business
Improve claims processing for auto Support on-line auto insurance
insurance business claims processing
Maintain tight cost controls Cut auto claims fraud by 80%
within the next two years
Table 1.2 Business strategy and goals for an insurance company
Organizations generally derive job objectives from business strategies and
goals. However, the approach to arrive at the job objectives has changed
over time as shown in Figure 1.3.
1980s 1990s- Present
Define
Define
business strategy
business strategy
l
l
Establish goals to achieve
strategy
l
Establish goals to achieve
strategy
l
Convert goals into objectives
Convert goals into functional for cross-functional processes
/department goals
l
l
Convert process objectives
Convert functional goals into
job objectives
into activity objectives
+
l
Relate activity objectives to
job objectives
Establish measures to track
performance against job
objectives
+
Establish measures to track
performance against job
obiectives
Figure 1.3 Relationship between business strategy and job objectives
(adapted from [Harmon2003])
Activity 1.5
Figure 1.3 shows how the business strategy is translated into job
objectives in the 1980s and from 1990s-Present. Discuss how these two
approaches differ and examine the implications on the organization.
Activity 1.6
How is business strategy defined? What influences the definition of
business strategy?
4. Business Process Management (BPM)
Business processes are valuable corporate assets since they directly
support the business strategies. Business processes, therefore, need to be
managed and optimized just as any other business asset.
Business Process Management (BPM) is a field of knowledge at the
intersection between management and information technology,
encompassing methods, techniques and tools to design, enact, control,
and analyze business processes involving human, organizations,
applications, documents and other sources of information [Aalst2003].
The ultimate goal of BPM is to help organizations improve their
business processes. Organization needs to manage processes at three
levels.
Enterprise
At this level, the concern is the overall composition of the various business
processes in the organization. For example:
What are the different processes that are required to achieve the
business strategies? How are these processes interrelated?
Which of these are core to the organization?
What are the sub-processes in a process?
How does a change in one process affect another process?
These are addressed by developing process architecture or process
framework for the organization which will be discussed later in this chapter.
Process
At this level, the concern is the individual process in an organization. For
example:
In the insurance domain, how can the claims process be optimized to
reduce claims turnaround from four days to two days?
What happens if we reduce the staff resource allocated to the fraud
detection process?
However, since no process usually stands on its own, the concerns within
a process may affect other processes in the organization. For example, in
order to reduce the claims turnaround it may be necessary to optimize the
fraud detection process since this may be a sub-process within the claims
process. These are addressed by modelling and performing static and
dynamic analysis of the process, which will be discussed in the later
chapters of this book.
Technology
At this level, the concern is the technologies that enable the business
process. For example, to enable the order-to-cash process, a number of
different technologies will be used, such as a database to hold product
information, a credit verification application that determines the credit
worthiness of the customer, an order management system that captures
and stores the new customer order, etc. The technology level may further
be subdivided into namely, blueprinting, implementation and operations.
Blueprinting
During blueprinting, the concern is the design of a high-level concept
solution for satisfying the business requirements. For example, to execute
the order-to-cash process, a solution blueprint has to be developed.
Amongst other things, the blueprint will define the role of various
applications such as order management application, customer
management application, credit verification application and the services
that are required from these applications. For example, the credit
verification application provides credit verification service by taking in
customer credit card number as input and returns the credit worthiness of
the customer, i.e. good credit or bad credit.
At this level the concerns may be:
What information needs to be stored in the customer management
application?
What security measures have to be in place to ensure the information
stored in the customer management application is not tampered with?
What mechanisms are to be put in place to ensure that customer
information is not replicated and remain consistent such that it can be
accessed by the various people and applications in the process?
What existing application functionality can be reused within the new or
modified process?
How can mobile technology be leveraged in the order-to-cash process?
What regulations are to be satisfied when performing a particular
activity in the process?
These are addressed by analyzing the business requirements and
developing the solution blueprint for satisfying the given set of business
requirements.
Implementation
During the implementation, the concern is the execution of the process by
implementation across various people and applications. For example, to
execute the order-to-cash process, the process has to be implemented in a
process engine to orchestrate it. Appropriate user interfaces have to be
designed and implemented for allowing the various people to interact with
the process activities. Various applications, such as the product
management application, customer management application, credit
verification application and order management system have to be
integrated in the context of the process.
How to invoke functions from other applications?
What is the most appropriate middleware for integrating the
applications?
How to represent the business documents such as a purchase order or
shipping order in an electronic format, which are to be exchanged
between the various applications?
How to handle performance issues when a number of process
instances are initiated?
How to implement the required security measures using technology?
The above concerns are addressed by designing and implementing
appropriate IT based solutions. Some of the solution includes using
enterprise systems such as ERP and CRM, middleware, portals and
business-to-business applications, which will not be covered in this book.
Operations
During operations, the concern is the day-to-day operation of the process;
this includes monitoring, analysis and response. For example, once the
order-to-cash process is implemented, various metrics can be collected
such as number of orders processed in a day or week, average time for
processing an order, average time spent on credit verification activity and
so on. These metrics provide valuable insights into the business. In some
instances, alerts may be set. For example, when the number of pending
orders exceeds 20, an alert as an email or SMS may be sent to the
operations manager in charge of the order-to-cash process. The collected
metrics can be analyzed and used for context based decision making. For
example, it may be seen that the number of pending orders usually
exceeds 20 every year during Christmas period and, therefore, it is a
normal occurrence and nothing needs to be done immediately to address
this problem. In some instances, however, the analysis may lead to
decisions that include review the process architecture and/or a particular
business process, re-engineer the process, outsource some parts of the
process, etc.
What are the metrics that must be collected?
What alerts need to be set?
How to invoke automated actions based on alerts?
These are addressed by designing and implementing event monitoring and
processing solutions. This includes business activity monitoring tools,
middleware and real time data warehousing, which will not be covered in
this book.
Relationship between the BPM Levels
Each level has it own set of concerns. As shown in Figure 1.4a, a business
strategy will define one or more business goals. Each business goal will
drive the need for a process change, which will then impact the business
processes at each of the three levels. Any decision taken in one level will
most likely impact the other levels. In Figure 1.4b, some of the impacts for
business strategy - "improve claims processing for the auto insurance
business" are shown. This figure does not explicitly show the impact on the
blueprinting, implementation and operations for the technology level.
Usually the enterprise level impacts the changes in the technology level
through the process level rather than directly impacting the technology.
This is because in most cases, technology becomes more apparent only
when looking at specific activities required for executing the business
process.
Define Establish
business __. goalfs to I Process
achieve change
strategy strategy

: BPM Enterprise i
Develop concept solution
blueprint
Develop process architecture
Define process strategy matrix
Design and implementation of
solution
Design and implement event
monitoring and processing
solution
Process
Model the process
Perform static analysis
Perform dynamic analysis
Figure 1.4a Impact of business strategy on the three levels
Enhance
customer's
claims
experience
Support
__. online claims -+
processing
Improve
claims
processing

BPM Enterprise
How does the new claims process
affect the quote process?
Can we leverage on some activities
which are currently used by the
online home insurance claims
process?

Process
How can mobile technology
be leveraged to expedite the
auto claims process?
What information need to be
captured for the auto claims
process?
How can information be
transferred from one
application to another
Impacts
If we remove the number of
approvals required from 2 to
!,what is the impact on the
process duration?
What impact does reusing the
customer verification activity
from home insurance have on
the process duration?
---------------------------------------------------------------------------------------------------------------------------------------------
Figure 1.4b Example: Impact of business strategy on the three levels
Benefits of Business Process Management
Following are some benefits of implementing BPM at the enterprise,
process and technology levels:
Enables continuous process improvement
Once a process is implemented, change is inevitable - users submit ways
to improve or business conditions change. In most cases, processes are
upgraded every 6-8 weeks until they stabilize. With BPM, it is now possible
to ensure the process improvements are carried out in a methodological
manner by studying the overall impact of the process on the other
processes in the enterprise. Performing the static and dynamic analysis at
the process level, using the data that emerges after running processes for
some time can allow better refinement of the process.
Provides Visibility and Control
Currently, many managers cannot understand what is happening in their
processes because metrics are difficult to obtain. Using appropriate
technologies, BPM makes a business process transparent, greatly
improving visibility and efficiency. Bottlenecks can be identified and
removed. It can show where the most delays are occurring, and where
each transaction is stuck as it passes from one sub-process/activity to
another. Managers can view process reports in real time - and learn how
the process is performing now instead of what happened after the fact.
Enhances Partnership between Business and IT
BPM creates a strong partnership between Business and IT. IT
applications can be related to the business process that they support. With
current BPM technologies available, the business process can be
simulated and tested at any time. So business managers can see, test and
give feedback before the business process is implemented. This improves
the productivity of the IT department as it can provide a completely new
level of service to the business - proper alignment with business, allowing
greater change and flexibility.
Activity 1. 7
Following is a table that highlights some of perceived benefits of BPM. For
each of the points listed, discuss how BPM achieves that benefit.
Business Benefits
Reduces costs and enhances
productivity
Ensures tighter control and compliance
Provides better visibility
Improves customer service
Enable continuous process
improvement without overly
depending on the IT department
5. Process Architecture
IT Benefits
Enhances the value of IT as a business
enabler
Makes better use of existing IT
applications
Removes silos of applications
Increases IT productivity
The Process Architecture is a collection of description of the processes
and sub-processes for the entire organization. Since it is impossible to
capture the details of all processes and sub-processes in one diagram, a
Process Architecture is usually represented at various levels. Figure 1.5
shows the hierarchy of levels that can be used in a Process Architecture.
An alternative name for the Process Architecture is Process Framework.
The Process Architecture can be used as a tool for analyzing an
organization's existing processes and for developing new processes. The
analysis may result in identification of duplicate processes that deliver the
same business functionality, gaps between the processes and possible
new process design that improves overall business efficiency.
In any organization, processes may be divided into core and
supporting processes [Harmon2003]. Core processes embody critical
corporate expertise and usually produce products and services that are
delivered to external customers. The supporting processes facilitate the
operation of the core processes and provide outputs which are inputs to
core processes. However, this definition is not strictly applied in the real
world, and organizations may decide according to their business needs.
Sub-processes can exist within both core and supporting processes. In the
Telecom example shown in Table 1.1, Billing, Assurance and Fulfilment
are core processes; Human Resource Management and Financial and
Asset Management are supporting processes; Billing and Collections
Management is a sub-process within the Billing Process.
Executive View
(overall view of all the processes/sub-processes and the business units)
Level 1
1
Process Hierarchy View
(hierarchy of processes/sub-processes related to a process/sub-process)
Level 2
1
Process Flow View
(logical flow of a process showing the sequence of the activities)
Level 3
Figure 1.5 Three Level Process Architecture
Executive View
This view shows all the processes and sub-processes along with the
various business units in the organization that are involved. The processes
and sub-processes shown at this level are large and complex. An example
template for this view is shown in Figure 1.6a which is adapted from
[Harmon2003] and a partial instantiation of this template for a Logistics
company is shown in Figure 1.6b. In Figure 1.6a, the business units are
shown as the columns and the processes are the rows. The process
groups may be split into core processes and supporting processes. Within
each process group, the different processes and sub-processes are
shown. In Figure 1.6b, the two core process groups are Logistic Processes
and Strategic Management and Control Processes. One supporting
process group shown is Operations Support Processes. The Logistic
Processes comprises Collection and Delivery Process, Shipment Process
and Warehouse Management Process. The Collection and Delivery
Process has four sub-processes, namely, Order Handling, Collection and
Route Planning, Dispatch and Delivery and Package Collection. The Order
Handling sub-process involves the Finance, Sales and Marketing business
units. The Collection and Delivery Process involves the Resource
Management and Operations and Transportation business units.
Business Unit 1 Business Unit 2 Business Unit 3 Business Unit 4
Core Processes Group 1
I
Process 1
I
Sub-Process
I I
Sub-Process
I
I
Process 1 1
Sub- Process
I
Core Processes Group 2
Process 1
I
Sub-Process
I
I
Sub-Process
I
I
Sub-Process
I I
Sub- Process
I
Process 2
I
Sub-Process
I I
Sub-Process
I
Supporting Processes r o u ~ 1
I
Sub- Process
I I
Sub-Process
I
I
Sub-Process
I
Figure 1.6a Executive View: Example Template
Finance I Sales and Marketing
I
Warehouse
I
Resource Management
II
Transportation
and Operations
/(ogistics Processes \
Collection and Delivery Process
I
Collection Route Planning
I
I
Order Handling
I
I
Dispatch and Delivery
I
I
Package Collection
I
Shipment Process
I
Packaging
I
I
Shipment Route Planning
I
I
Customs Clearance
I
I
Fleet and Package Assignment
I
Warehouse Management Process
I
Inventory Management
I
I
Supply Chain Management
I
"----
I
/
/strategic Planning Processes
\
Strategic Sourcing Management
I
Strategic Warehouse Selection
I
I
3PL Vendor Management
I
I
Resource Data Collection and Analysis
I
Strategic Management Control Process
I
Performance Measure and Review
I
I
Policy Development and Administration
I
/
Operations Support Processes
Audit and Readiness Process
I
Fleet Management Process
I
Fleet Maintenance
I
I Fleet Procurement
I
I
Manpower Allocation
I
Figure 1.6b Executive View: Example for a Logistics Company (partially
complete)
Process Hierarchy View
This view shows a hierarchy of all the sub-processes that are related to a
process. An example process hierarchy template is shown in Figure 1.7a,
the process is shown at the top row and each sub-process is shown below
this. For each sub-process the various sub-processes are then shown as
subsequent rows. An instantiation of this Process Hierarchy template for a
Logistics company is shown in Figure 1. ?b. The Order Handling process
has six sub-processes namely Feasibility Determination, Credit
Authorization, Order Issuance, Order Tracking, Order Completion and
Order Satisfaction. The Order Issuance has four sub-processes namely,
Order Validation, Order Creation Order, Order Amendment and Order
Cancellation. However, it must be noted that some of these sub-processes
may be too small and be just activities.
In addition, this view also includes a description of the various
processes and sub-processes. An example Process Description Template
is shown in Table 1.3. An instantiation of this template for the Credit
Authorization sub-process of a Logistics company is shown in Table 1.4.
Process
(Ll)
I
I I I I
Sub-Process Sub-Process Sub-Process
(L2) (L2) (L2)
...
H Sub-Process
(L3)
H Sub-Process
(L3)
H Sub-Process I
(L3)
4
...
I
Sub-Process Sub-Process
- r--
(L4) Sub-Process (L4)
-
(L3)
Sub-Process Sub-Process
-
(L4)
Sub-Process

(L4) -
(L3)
I
Lx- Leve
Sub-Process
Sub-Process
'----
(L3)
-
(L3)
lx
Figure 1.7a Process Hierarchy View: Example Template
Figure 1. 7b Process Hierarchy View: Example for a Logistics Company
(partially complete)
Name Process Name
Purpose Brief description of the purpose of the process and its objectives
Triggering The event that initiates the process
Event
Input/From The inputs required for the process
Other organizations and systems that are involved in providing the inputs
Output/To The deliverable of the process
Other processes, organization and systems that will use this output
Process A diagram describing the sequence of the process showing the various sub-processes and
Sequence activities. This is usually a set of process flow diagrams
Responsibility The role that is responsible for managing the process
Roles Roles involved in the process
Performance Metrics that will be used to determine the effectiveness of the process
Measures
Table 1.3 Process Description: Example Template
Process Name Credit Authorization
Purpose To assess the customer's credit worthiness so as to manage the company's exposure to
bad debt
Triggering One of the following event: new account/new order/account renewal/update pervious
Event credit level
Input/From Credit Authorization Form containing: Customer Name, Phone Number, Address, Identity
Number
Credit score from Credit Agency
Analytics scoring system
Past bill payment from accounts system
Enterprise risk and policy guidelines from organization's legal department
Output/To Authorized credit request results or score
Order Issuance Process
Process See Credit Authorization Process Flow View
Sequence
Responsibility Credit Assessment Manager
Roles Finance Clerk, Credit Assessment Supervisor, External Agency
Performance Credit Authorization is completed within 1 working day
Measures
Amount of bad debt due to inability to pay by the customers
Number of inappropriate credit authorization
Table 1.4 Process Description: Credit Authorization Process
Process Flow View
This view shows the flow of the process along with the sequence of the
sub-processes and activities. Since the notion of process and sub-process
is iterative, this view can therefore, be represented at various levels of
detail by expanding each of the sub-processes. An example template for
this view is shown in Figure 1.8a. The process flow comprises sub-
processes and activities and the sub processes contain activities and sub-
processes. An instantiation of this template for the Credit Authorization
sub-process of a Logistics company is shown in Figure 1.8b.
20
Process A 8 I I
D
Sub-Process A
Sub-Process
B
D
Business Process and IT
Note
0 = Decision box
Activity
Sub-Process B
Figure 1.8a Process Flow View: Example Template
Credit Authorization
Process
Credit
Investigation
Credit Investigation
Sub-Process
Obtain
Appropriate
Approvals
j Yes
Receive Credit
Check Request
Advice
Credit Terms

).o
Obtain the
Necessary
Information
Calculate and
Assign Credit
Score
Figure 1.8b Process Flow View: Example for Credit Authorization Process
(partially complete)
Industry Specific Process Architectures
Process Architecture can also be developed for an entire industry. Some
examples are in Telecommunications and Supply Chain Management such
as eTOM, and SCOR respectively.
eTOM
eTOM business Process Architecture has been developed for the
Telecommunications industry and designed to be as generic as possible.
Examples of organizations that have implemented eTOM include Telstra,
Vodafone, TeliaSonera, Telecom ltalia, British Telecom, Telefonica
Moviles, and Orange etc. [eTOM]. Figure 1.9 shows the eTOM executive
view. In contrast to the executive view template and instantiation shown in
Figures 1.6a and 1.6b, in the eTOM executive view, the processes are
shown in the columns and the business units in the rows. For example,
Billing is a process that involves the business units Customer Relationship
Management, Service Management and Operations, Resource
Management and Operations and Supplier/Partner Relationship
Management.
Customer ---:=:::

strategy, lrtraslro..clt.re & Prcd.Jd Operatims
l::tntegy &
r rro.cl
Operatims
II Ft.Jfill rrert
I Assuan::e

Can nit Lifecycle Lifecycle
M <nagemert M <nagemert Read ness
MarkEii n;J & Offer Management D..!stcmer Rel:ti mstip Management
I I I I l I
Seroj ce Develcprrert & Management Sero.i ce Managerrert & Operatims
I I I II I I I I
Resoo..rce De vel cpmert & Managerrert Resa.rce M anagemert & cper:ti ms
(JlprJi caicn, CofllJUirg <11d crk)
(jpplic;;rtion, Cofllluting and N<i!work)
I I I I I I
O..in De11elcpment & M<nagemert SLWiier/Partner Relat imship Managerrert
I I I I II I
Erterprise Managerrert
l &. rpH a l l Ill
A a mlng l.tmagem ant
&.
1,\lnagem ant lo\lnagem ant
I Financial &A ue t

II Hllll an Re tcurce 1

I
Figure 1.9 The Enhanced Telecom Operations Map [eTOM]
Activity 1.8
With reference to the various views of the Process Architecture, discuss:
How each view can help an organization in designing and implementing
new processes or modifying existing processes?
What problems are associated with developing such a Process
Architecture?
What is the value in developing a Process Architecture for an industry?
What are the challenges in developing industry specific process
Architectures?
6. Business Process Enablement and IT
Early applications of information technology focused on automating
individual activities within a business process with the objective of
improving the efficiency and accuracy of the activity performed. For
example, automation using an IT application can be applied to the
Calculate and Assign Credit Score activity in the Credit Authorization
process shown in Figure 1.8b. Instead of calculating the credit score
manually, the Credit Supervisor will enter the required details about the
customer and the IT application will return a credit score. Traditionally,
there was very little use of IT, if any, for information exchange between two
different activities. It was usual practice to use the human to manually
transfer information between two activities. For example, once the credit
score is determined, the Credit Supervisor will pass the paper report to the
Approvals Clerk who is in charge of obtaining approvals.
Over the years, the application of IT in business processes has
evolved. IT began to be used in information exchange between some of
the activities though not in real time. That is, using the above example, at
the end of the day, once all credit reports are completed, the reports are
electronically sent to the Approvals Clerk. This, however, is still not ideal
for improving business efficiency.
The current trend is to extend this automation to the entire end-to-
end business process and move information in real time. That is, when
every credit report is completed, it is immediately sent electronically to the
Approvals Clerk. In order to understand this, let us look at the following
Grooming.com case study. This case study is adapted from [Roberti2004].
References
[Aalst2003]
van der Aalst, W.M.P, ter Hofstede, A.H.M. and Weske, M "Business
Process Management: A Survey", in Business Process Management,
Proceedings of the First International Conference. Springer Verlag, 2003.
[eTOM]
http://www.tmforum.org
[Harmon2003]
Paul Harmon, "Business Process Change: A Manager's Guide to
Improving, Redesigning, and Automating Processes", Morgan Kaufmann,
December 2002.
[Porter1996]
Michael Porter, "What is Strategy?", Harvard Business Review, Harvard
Business School Publishing Corporation, Nov-Dec 1996.
[Roberti2004]
Mark Roberti, "Gillette Sharpens", RFID Journal, April 2004.
Case Study
Grooming.com
Grooming.com is a world leading company in the manufacture of grooming
products such as razors, antiperspirant, perfumes etc. The company has
been around for nearly 70 years. Over the years, the company has
observed problems with its supply chain process, which typically involves
three processes, namely, manufacturing, packaging and distribution, and
retailing (see Figure 1.1 0). Millions of dollars are lost because products
are not shipped on time or in the right quantities to the right destination. In
order to overcome some of these problems, Grooming.com began to look
at a way to get better information about where its goods are in the supply
chain so that the company could ensure products are always where they
are supposed to be and could better manage demand.
Manufacturing Packaging and Distribution Retailing
Manufacturing Units Packaging and Distribution Units Retailing Units
Figure 1.10 Grooming.com Supply Chain Process
For our discussion, we will only focus on the Packaging and Distribution
process.
Before we discuss the process, we need to understand the existing
IT applications used in the Packaging and Distribution process. Currently,
two applications are involved in this process, namely, Distribution Centre
Inventory System (DCIS) and Order Management System (OMS)
The DCIS records the current inventory levels stored in the
distribution centre. The OMS keeps track of customer orders.
Business Process and IT
The current process is as shown in Figure 1.11 a.
Pack and Affix
Bar Code
Manually Scan
Bar Code
Manually Enter
Details into
DCIS and OMS
Manually Scan
Bar Code
Figure 1.11 a Packing and Distribution Process: Manual
(exceptions are not shown)
The current process comprises the following steps:
Current Process
25
1. The packaging unit receives the manufactured products and put
them into cardboard cases. A package attendant attaches a bar code
identifier to each case.
2. A trailer then moves the cases into the distribution centre. The
distribution clerk manually scans the cases then makes an entry into
the DCIS to confirm the inventory has been received in the
distribution centre.
3. When an order arrives, the distribution clerk manually scans the bar
codes on the cases and compares the items to those on the order,
which has details of products to be shipped for the customer. If the
items match, the distribution clerk makes an entry into the OMS to
confirm the order.
4. The distribution clerk instructs the shipping clerk to pick the
appropriate cases as per the customer order.
5. The shipping clerk then moves the collected cases to the loading
bays, and manually verifies the cases and contents by matching
against the appropriate order. The cases are loaded on the right
truck for shipment.
6. Finally, the shipping clerk updates the DCIS to confirm the items
have been shipped from the Distribution Centre and to reflect the
current inventory levels.
Grooming.com observed that the current Packaging and Distribution
process has a number of weaknesses, namely
It is time and labour intensive since the cases are to be manually
scanned
The time taken to match the products with an order before shipping is
too long
In many cases, mistakes such as wrong products being sent to
customers resulted in a lot of complaints
Therefore, Grooming.com decided to enhance the Packaging and
Distribution business process. An external consultant was invited to study
the current process and suggest how it can be improved. After an initial
study, the consultant submitted a report to Grooming.com.
Following are some excerpts from this report:
"Improve the Packaging and Distribution process as it is mainly manual
and data is not integrated. Therefore, suggest automating the Packaging
and Distribution process. In order to achieve this, Information Technology
will be leveraged. The specific technology proposed is Radio Frequency
Identification (RFID).
An RFID system consists of a radio-enabled reader that communicates
with, or interrogates a label which contains an embedded processor and
antenna. The RFID reader can be either fixed or portable.
Some of the advantages of RFID include:
It is fast and works without the need for any manual intervention or
physical contact between the readers and tags. Since RFID uses radio
waves, therefore, unlike a bar code, it does not require contact or line
of sight between the reader and the object to be identified
Multiple tags can be read simultaneously
RFID labels can carry more information than bar code labels
Use of RFID will increase information availability throughout the supply
chain process
Use of RFID allows enhanced security since the RFID labels are difficult
to be tampered with and will work in harsh weather conditions
"
Based on this report, the management at Grooming.com decided to modify
the Packaging and Distribution process using RFID. The modified process
is as shown in Figure 1.11 b.
Pack and Affix
RFID Label
Read RFID
Label
Automatically
Update DCIS
and OMS
Read RFID Label,
Check with Order
and Ship
Figure 1.11 b Packing and Distribution Process: Automated
(exceptions are not shown)
The modified process comprises the following steps:
Modified Process: IT Enabled
1. The packaging unit receives the manufactured products and put
them into cardboard cases. A package attendant attaches the RFID
label with a unique Electronic Product Code to the cases. Electronic
Product Code (EPC) is code scheme for universally identifying
physical objects via RFID tags. The EPC's digits identify the
manufacturer, product category and individual item.
2. A trailer then moves the cases into the distribution centre. As each
case enters the distribution centre, a fixed RFID reader automatically
reads the EPC encoded on the case and
a. Automatically makes an entry into the DCIS
b. Sends the information to the OMS. The OMS compares the
EPC assigned to the case with the orders. If it finds a match, it
automatically sends the pick list instructions to the shipping
clerk's handheld device specifying where the cases are located
3. When the shipping clerk receives the pick list information, he uses an
RFID enable forklift. By interfacing with the OMS, the RFID reader
mounted on the forklift helps the shipping clerk pick the cases
needed to fulfil an order.
4. Once the cases are collected, an RFID reader mounted to a stretch-
wrap machine reads all the cases as they are spun and wrapped.
The OMS then verifies the order by matching the EPCs to the order
being fulfilled.
5. Once each order is assembled, RFID reader at the dock door reads
the RFID label data on the cases and:
a. Send the information to the OMS, which ensures the correct
cases go into the right truck for shipment.
b. Updates the DCIS to confirm the items have been shipped from
the Distribution Centre and to reflect the current inventory
levels.
As seen from this case study, the Packaging and Distribution process at
Grooming.com was enabled through the effective use of IT. Some of the
manual activities were replaced by the automated activities, as shown by
the shaded activities in Figure 1.11 a and Figure 1.11 b.
In order to ensure that the final implementation of the modified
Packaging and Distribution process is a success, it is necessary to ensure
a proper methodology is followed from understanding the current business
process to designing and implementing an enhanced process through
appropriate use of IT. In the next chapter, we will examine the various
phases of a Business Process Engineering Methodology.
CHAPTER 2
BUSINESS PROCESS ENGINEERING METHODOLOGY
Chapter Topic List
1. Business and IT Alignment
2. Need for a Methodology
3. Requirements
4. Business Process Engineering Methodology (BPEM): An Overview
References
Learning Objectives
Understand the importance of business and IT alignment
Appreciate the importance of the need for a methodology
Understand the importance of clearly defining functional and non-
functional requirements
Understand the various phases of a Business Process Engineering
Methodology (BPEM)
30 Business Process Engineering Methodology
BUSINESS PROCESS ENGINEERING METHDOLOGY
1. Business and IT Alignment
Business IT alignment may be defined as a process through which the
organization's business and IT personnel collaborate to ensure that
[Macehiter2005]:
IT resources such as applications, information and technology support
business objectives and processes, and
business objectives and processes are influenced by an understanding
of IT capabilities and challenges
There are three important aspects of this definition, as shown in Figure 2.1.
IT capabilities
and challenges
shape the
Business Process
Business
Process
Figure 2.1 Business and IT alignment
Business Process
change
impacts IT
Firstly, business drives the investment in IT and hence IT must provide
services that support the business objectives and processes.
Secondly, as a direct consequence of the first aspect, IT is now an
integral part of the business and therefore, IT must play a strategic role
within the organization rather than a "back office processing" role. IT is now
contributing directly to the business processes which usually have close
Business Process Engineering Methodology 31
interactions with partners and customers. The current emphasis of IT is on
the automation of information exchange and collaboration.
Thirdly, there must be a close collaboration between business and IT
when initiating business process change. Both business and IT personnel
must participate as peers and adopt a systematic approach, where
business personnel understands the IT implications of any change and IT
personnel understands and highlights the business opportunities and
challenges arising from new technology.
When business and IT are not aligned, this is revealed through a
number of symptoms such as:
Non acceptance of the delivered IT application by the business
IT applications are unable to support the business functions
Existence of redundant IT applications
Project schedule and cost overrun
Poor response times and unavailability of IT applications
Insufficient automation of processes
Inability to change business processes due to inflexibility in IT
applications
The misalignment between business and IT is due to one or more of the
following reasons:
Lack of appreciation of business processes by IT
IT is concerned with technology problems. They solve one technical
problem, move to the next, and the same routine goes on every day.
They hardly have time to stop and think, "What business processes are
being supported by their applications and what impact do these
applications have on the processes?", "Are these applications
contributing to the business objectives?", "Can emerging technologies
enhance the business processes?".
Lack of appreciation of IT value by business
Business sees IT as a support tool to automate the storage, retrieval
and analysis of data rather than as one that provide strategic value to
the business. Though this perception is changing, business need to
work closely with IT to ensure that IT capabilities are converted to
business benefits.
Evolution of IT applications in silos
Over the years, tactical needs have driven organizations to develop or
buy IT applications to satisfy specific requirements; this has led to the
existence of independent applications often referred as application silos
or "islands of automation". When the organization grows rapidly the
number of silos increases and become unmanageable. There is no
clear sense of the purpose of the silo application and its role within the
context of a business process. This inevitably leads to misalignment
between business and IT.
Lack of a common language between IT and business
It is generally accepted that IT personnel do not understand business
and vice versa. This is mainly exacerbated by the lack of a common
language for business and IT to exchange their understanding of the
needs in the context of defining, designing, building and operating IT
applications.
Growing business and changing environment
As a business continues to expand and grow, the number of business
processes and the number of IT applications increase. Adding to this,
new technology and business trends constantly emerge. This makes it
extremely difficult to continuously ensure business and IT alignment.
Levels of Alignment
The business and IT alignment can be achieved at two levels, enterprise
and project.
Enterprise
At this level, the context is an enterprise, where a number of IT solutions
are deployed. The focus is on aligning the business objectives, the
business processes, the information, applications and technology across
the entire organization. This alignment is achieved through the use of an
Enterprise Architecture (EA). An EA is both a product and process. As a
product, EA is a strategic information asset base, which defines:
The organization's mission and business processes supporting the
mission
The information and applications necessary for organization operations
The technologies necessary to support operations
The transitional processes necessary for implementing new
technologies in response to changing business needs
As a process, EA:
drives continuous business and IT alignment, and
provides an overall plan for designing, implementing and maintaining
the underlying infrastructure to support information sharing and
resource optimization
In some instances, it may be worthwhile to reduce the scope and apply EA
within selected business units rather than the entire organization.
Project
At this level, the context is a specific IT solution. The focus is on aligning
the business objectives, the business processes, the information,
applications and technology with an IT project. This alignment is achieved
using a methodology that brings in formalization and repeatability into the
process of translating business objectives into IT solutions through a
collection of models, techniques and tools [lnfosys2004]. The main tenets
of this methodology include:
A business process driven approach to develop the IT concept solution
Smooth translation of enterprise business requirements into effective IT
concept solution through modelling
Neutrality towards implementation technology options
In this book, we will focus on enhancing alignment at the project level.
2. Need for a Methodology
Figure 2.2 shows the various IT applications that may be present in an
organization in order support the different business processes.
In such a complex scenario, it is difficult to understand the implication
of modifying a business process and its impact on other processes and
applications. Therefore, it is necessary to adopt a methodological approach
to clearly understand and articulate the requirements for the IT solution.
Figure 2.2 IT applications in an insurance company
Traditional Application Centric Approach
Traditional application centric approach to business requirements
gathering for IT solutions has predominantly been from application
perspective rather than a business process perspective. The focus is only
on the needs of the application by the local business unit rather than the
entire process. For example, the designers of the solution focus only on
specific applications requirements such as database structure, object
diagrams, etc. Approaching the solution like this does not consider all
stakeholders and as a result leads to incomplete identification of solution
needs. As a result of this, IT solutions developed using this approach may
not support the business process sufficiently and often result in failures.
Information System Methodologies
In order to overcome the above limitation of the traditional application
centric approach, a number of information system development
methodologies have been developed over the years to structure the
various phases of an IT Project. These system development
methodologies vary from traditional-structured (sometimes called waterfall
methods) through object-oriented and iterative methods to modern agile
methods and extreme programming techniques. The common
characteristic of all system development methodologies is that they are
deeply rooted in the IT side of the spectrum and have typically evolved
from modelling static and dynamic aspects of system design, data
structures and programming code. Therefore, in spite of extensions to
address the needs of business process modelling and analysis, they are
not well suited for the business analysts.
On the other side, the business camp has come up with its own
modelling techniques and analysis methods, which in their opinion are
much better and usually simpler representation of the business reality.
Even though this disconnect between the business and IT side is
obvious, it has persisted for decades and continues to cause frustration
among the business and IT personnel. One approach to solving this
dilemma is to employ a methodology that both parties can understand and
employ for sound, productive conversation regarding business processes.
This methodology must be employed to describe business processes and
the concept IT solution to automate this process.
In recent years, methodologies have been emerging to address the
business IT disconnect such as Business-Driven Development [Mitra2005],
RUP [IBM2005] and, InFlux [lnfosys2004].
3. Requirements
Requirements may be classified into the following two categories:
Business Requirements
It describes the requirements in terms of the tasks that must be done in the
organization within a business process (what the business needs).
IT Solution Requirements
It describes the functional and non-functional requirements of a system
(how the system is going to support the business requirements). This is
usually referred to as system requirements and may be further classified
into:
Functional requirements
It describes the intended features or behaviour of the system. These
requirements may be expressed as functions the system is required to
perform.
Non-Functional requirements
These requirements impose constraints on the design or
implementation of the system. They address attributes such as
performance requirements, security, reliability, or other design
constraints such as organizational policies and procedures,
interoperability requirements, domain specific requirements, external
legislative requirements, etc.
Requirements and Business-IT Alignment
Figure 2.3a Business-IT Aligned Figure 2.3b Business-IT Not Aligned
As shown in Figure 2.3a, when Business-IT is aligned, the IT Solution
Requirements is a subset of the Business Requirements. This is the ideal
situation where all IT Solution Requirements, both functional and non-
functional support the Business Requirements. Some of the Business
Requirements are supported by an IT Solution while other business
activities remain manual. For example, "Sales person needs to change the
order details" is a Business Requirement that is mapped to an IT Solution
Requirement - "Sales person updates the order details in the Order
Processing System".
However, in practice, as shown in Figure 2.3b Business-IT may not
be fully aligned. This is the situation when some IT Solutions do not
support the business, which results in wastage of resources.
Though achieving full Business-IT alignment is extremely difficult, it is
necessary to adopt methods to minimise the misalignment. One approach
is to elicit the Business Requirements and then translate them into IT
Solution Requirements. This is usually done at the Requirements Phase of
an IT Project.
In the Requirements Phase, the goal is to understand and articulate
what solution to build. The errors made in the Requirements Phase are
among the most difficult to detect and the most expensive to correct.
Therefore, sufficient time and effort must be allocated to this phase of the
IT Project.
Figure 2.4 shows an example of the cost of fixing a defect in various
stages of the project. For example, a requirement defect that is fixed during
the requirements phase cost only $100 whereas fixing the same defect
during the maintenance phase will cost $10,000.
ti
0
()
$3X
$100X
$50X
Requirements Arch & Design Build Test & Implement Maintenance
IT Project Phases
Figure 2.4 Cost of correcting errors in the various phases of an IT project
Activity 2.1
If on an average just 20 requirements defects per project get passed on to
implementation phase how much more would these errors cost for a
company running 40 projects a year, assuming each project is of similar
scope and complexity [lnfosys2004]?
Activity 2.2
Table below lists a set of example requirements. Label them appropriately
as Functional and Non-Functional Requirement.
Requirements Functional/Non Functional
The system shall be able to
perform the search on the
customer database and return
results within 10 milliseconds
The system shall provide
appropriate viewers for the user to
read documents in the document
store
Every sales order shall be allocated
a unique identifier which the user
shall be able to copy to the
account's permanent storage area
The system development process
must conform to the process and
deliverables defined in ABC
Company-ST ANDARD-24
4. Business Process Engineering Methodology: An
Overview
The Business Process Engineering Methodology (BPEM) described in this
book is adapted from the InFlux methodology developed by lnfosys
Technologies, Ltd.
The two phases of the BPEM are as shown in Figure 2.5; they are
Business Modelling and Concept Solution Blueprinting.
Figure 2.5 Business Process Engineering Methodology
Business Modelling
This phase comprises a step-by-step approach to identify business needs
and translate them into functional requirements of an IT solution. The
activities in this phase help both the business and IT personnel to
understand the current problem, analyse it, and then identify solutions to
overcome the problem. These solutions are then translated into IT solution
requirements. Each of the activities in this phase produces specific outputs
which are mainly models. These models help in providing a better
understanding of the current problem and the proposed IT solution
requirements. The final deliverable at the end of Business Modelling phase
is a set of documents that includes models and reports such as
Organization Model, Location Model, Workflow Model, Collaboration
Model, RCI Model, dynamic analysis reports and Use Case Model. The
models and reports set out the rationale and requirements for the proposed
IT solution.
Concept Solution Blueprinting
This phase comprises a step-by-step approach to specify the concept
solution architecture that will satisfy the requirements of the proposed IT
solution. The activities in this phase help the IT personnel to understand
and analyse the requirements of the proposed IT solution and then develop
appropriate high level views to represent it. Each of the activity in this
phase produces specific outputs which are mainly models. These models
are still at a higher level of abstraction to enable discussions with the
business and IT executives. The final deliverable at the end of the Concept
Solution Blueprinting phase is a set of documents which may be referred
as the Concept Solution Blueprint for the proposed IT solution. Examples
of such models are Solution Overview Model, Application Model, Service
Model and Risk Model.
The Concept Solution Blueprint is then further refined and analysed
to produce Detailed Solution Blueprint, which contains more detailed levels
of abstraction that are to be used during the design and implementation of
the proposed IT solution. These models are at a low level of abstraction
and provide the required information for the designers, developers and
operational personnel of the solution. For example, Detailed Application
Model, Performance Model, Deployment Model and Layer Model. In this
book, we will not cover these detailed models.
Chapters 3 to will focus on the Business Modelling Phase of the
BPEM and Chapters 8 and 9 on the Concept Solution Blueprinting Phase.
The various activities of both the phases and the methods and tools used
in these activities are discussed in the rest of this book.
References
[Boehm2001]
B. Boehm and V. Basili, "Software Defect Reduction Top 10 List," IEEE
Computer, IEEE Computer Society, Vol. 34, No. 1, January 2001, pp. 135-
137.
[IBM2005]
Rational Unified Process: Best Practices for Software Development
Teams,
http://www-128.ibm.com/developerworks/rational/librarv/253.html ,
July 2005.
[I nfosys2004]
InFlux Materials, lnfosys Technologies Limited, 2004. Please see the
acknowledgement for more details.
[Macehiter2005]
N.Macehiter and N.Ward-Dutton, "On IT-Business Alignment",
http://www.mwadvisors.com, February 2005.
[M itra2005]
Business Driven Development,
http://www-128.ibm.com/developerworks/webservices/librarv/ws-
bdd/index.html , December 2005.
CHAPTER 3
BUSINESS MODELLING ACTIVITIES
Chapter Topic List
1. Overview
2. As-Is Modelling
3. As-Is Process Analysis
4. To-Be Modelling
5. To-Be Process Analysis
6. IT Solution Requirements Definition
. Summary of the Activities
References
Learning Objectives
Understand the various activities of the business modelling phase
42 Business Modelling Activities
BUSINESS MODELLING ACTIVITIES
1. Overview
Figure 3.1 shows the various activities of the business modelling
[lnfosys2004] phase. The business modelling phase is usually triggered by
the need for a change in one or more business processes due to one or
more business objectives. The need for change can be due to a number of
reasons. For example:
Changes in business goals
Inability to satisfy existing goals
Organization changes such as merger and acquisition
External impacts such as change in government regulations
Obsolete technology
Depending on the scenario, one or more of the business modelling
activities are performed. In this chapter, we will briefly discuss the various
activities and in subsequent chapters, we will delve into the details of the
methods and tools used to perform each activity.
The activities first help in defining and understanding the business
problem space and then defining the solution space where the focus
moves to the IT systems that will be used in the context of the business.
The final output of this phase is a set of documents that specifies the IT
solution functional and non-functional requirements. As shown in Figure
3.1, the activities To-Be modelling and To-Be Process Analysis are usually
iterative, that is, the To-Be models developed are analysed and refined
based on the results.
Define Problem Space
(Business)
As-Is
Process
Analysis
..
Issues and
Define Solution Space
(Business to System)
.--------------------------------------
! To-Be ~ To-Be
: Modelling ~ ~ P r o c ~
l_----------------------- ~ ~ ~ ~ ~ ~ ~ ~
..
Recommendations
To-Be
Models
Figure 3.1 Business Modelling Activities
IT Solution
Requirements
Definition
l
IT Solution
Functional and
Non-Functional
Requirements
Business Modelling Activities 43
Table 3.1 shows the key roles that are involved in the Business Modelling
Activities. Together, they form the business and IT stakeholders. The team
that does most of the work within the Business Modelling Activities
comprises the Business Analysts, System Analysts, Business Subject
Matter Expert and IT Subject Matter Expert. This team may be referred to
as the Business Process Engineering (BPE) team.
Role Expertise
Business Analyst Understand both the business and IT
Ability to translate the business
requirements into IT solution
requirements
System Analyst Deep understanding of the system
design and implementation
Design and implement IT solution
Business Subject Matter Expert Deep understanding of the business
domain and processes
IT Subject Matter Expert Deep understanding of specific
technology
Users Understanding of the practicality of
performing the activities in a business
process
Sponsors Understand the business strategy and
the objectives of the change project
Table 3.1 Roles involved in the Business Modelling Activities
2. As-Is Modelling
As-Is modelling activity [lnfosys2004] helps elicit and document key
business processes and related information required to understand the
business problems. It also assesses the business need of an IT solution.
This information is captured in the form of various business models as
described later in chapter 4. The models help to identify the scope of the
business problem that is being addressed and results in documentation of
the current business blueprint for the identified scope.
The current business blueprint captured serves as an input for
discussions on future business needs. It sets the target for change and
leads to the creation of a common baseline understanding of the problem
space among all stakeholders in any IT solution development initiative.
The business analysts elicit and document information from the
business subject matter experts to understand the business related issues
such as processes, roles, policies, etc. The system analysts elicit and
document information from the IT subject matter experts to understand
existing IT systems in the context of the current the business problem
scope. The subject matter experts provide information to the analysts
during the elicitation sessions through interviews and workshops.
The output of this activity is a set of models that depict the current
business problem space.
Activity 3.1
You have been asked to capture information about an existing scenario
which would be required for developing a new IT solution or for enhancing
an existing IT solution. List down some of the questions that you would ask
to capture and document this information.
3. Asls Process Analysis
This activity helps to analyse the As-Is business models to elicit and
understand the issues or pain points [lnfosys2004]. Based on the results
of the analysis, it creates a set of recommendations to address these
issues by leveraging IT-enabled solution ideas.
This activity is carried out in order to systematically move from the
problem space into the solution space. The business issues and needs for
the yet-to-be defined IT solution are clearly delineated in this activity. This
creates a common understanding between the business and IT
stakeholders that accelerate the solution blueprinting phase of the BPEM.
This activity results in the generation of recommendations to fulfil the
business needs captured. It helps in identifying and prioritising various
business needs based on the severity of the business issues or pain
points. This can act as an input for prioritisation of areas for business
funding based on best return for investment.
Process Analysis of the As-Is process is usually achieved at two
levels, namely, Static Analysis and Dynamic Analysis. During Static
Analysis, the As-Is models are manually examined and the issues that are
elicited are analysed by identifying root causes and impacts. During
Dynamic Analysis, some As-Is models are dynamically simulated using
software to produce various data, which are then analyzed to understand
the issues and to identify scope for improvements to the existing business
situation.
The business analysts together with the system analysts study and
analyse the As-Is models and elicit issues or pain points from business
subject matter experts. They also generate recommendations to address
the issues in discussion with the business subject matter experts. In order
to arrive at these recommendations, standard industry practices in the form
of reference models are often used. For example, when making
recommendations in the Telecommunications domain, the eTOM reference
model is used. The system analysts validate the recommendations from
technical feasibility point of view. The subject matter experts discuss
business and systems related issues with the analysts during elicitation
sessions and validate and provide inputs to the possible solution ideas for
the issues documented.
The output of this activity is a document highlighting the issues and
appropriate recommendations based on the analysis.
Activity 3.2
Identify some improvements that an IT solution can bring about to a
business process.
4. To-Be Modelling
To-Be Modelling activity helps to translate recommendations into specific
changes at the business process level through creation of To-Be models
[lnfosys2004]. These models articulate the scope of the problem space
that is being addressed and documents the future business and high-level
system behaviour that would be required to implement the
recommendations suggested in the As-Is Process Analysis activity.
The information documented in this activity relates to the future
business processes and thus acts as a perfect validation point for all levels
of stakeholders. For example, using the same set of artefacts, a business
process owner can see his or her new process after implementation and a
business user can see the impact on the activities specific to his or her role
due to the changes.
To-Be modelling also brings business and IT stakeholders at a
common level of understanding on the scope of the IT solution and the
system behaviour required to support the To-Be business processes.
The business analysts and the system analysts study the As-Is
models and the As-Is Process Analysis document to determine the To-Be
business models. In addition, they discuss and validate the To-Be business
models with the subject matter experts.
The output of this activity is a set of models that depict the future
business behaviour.
5. To-Be Process Analysis
This activity helps to analyse the To-Be business models to understand the
behaviour of the To-Be models. During this activity, Dynamic Analysis is
performed to explore various what-if scenarios. Such an analysis gives a
perspective on the proposed business process and how it might behave in
various scenarios before implementing it.
The To-Be Modelling and To-Be Process Analysis activities are
usually iterative. Based on the dynamic analysis of the To-Be Process, the
To-Be models may be modified. Usually a few iterations are required
before the developing the final versions of the To-Be models.
The business analysts together with the system analysts study and
perform dynamic analysis of some of the To-Be models and discuss the
results with the business subject matter experts.
The output of this activity is a document that includes the analysis of
the various To-Be process alternatives and the derivation of the final
recommended To-Be process.
Activity 3.3
As a business manager, you have been asked to attend an IT solution
presentation from a consultancy group. List down three questions that you
would ask this group regarding the solution presented.
6. IT Solution Requirements Definition
This activity helps in mapping and detailing the functional and non-
functional requirements of an IT solution. Use Cases are used to represent
the identified solution requirements. The Use Cases symbolize the end
output of the Business Modelling phase and act as an input to the Concept
Solution Blueprinting phase.
The business analysts, together with the system analysts create Use
Cases for specifying the IT solution functionality. The technology subject
matter experts provide inputs for validating the Use Cases. Additionally,
the various Non-Functional requirements such as security, performance,
scalability are also defined.
The output of this activity is a document describing the Use Cases for
the IT solution along with a list of Non-Functional requirements for the
proposed IT Solution.
. Summary of the Activities
Table 3.2 shows the various activities of the Business Modelling Phase
along with a brief description, the inputs and outputs for each activity.
Activity Purpose Input Output
As-Is Modelling Elicit and Business goals, As-Is Models
document key change intent which identify and
business process describe the
and related current problem
information scope
required to
assess the
business need of
an IT solution
As-Is Process Analyse the As-Is As-Is Models and As-Is Process
Analysis models to elicit industry Static and
and understand reference models Dynamic analysis
the issues or pain document which
points. Based on discuss the
the results of the issues and
analysis create a propose
set of recommendations
recommendations
to address these
issues by
leveraging IT
enabled solution
ideas
To-Be Translate As-Is Models, As- To-Be models
Modelling recommendations Is process which documents
into specific analysis the future
To-Be business document, business and
models proposed high-level system
recommendations behaviour that
would be required
to implement the
recommendations
To-Be Process Analyse the To-Be Models, Dynamic analysis
Analysis To-Be business proposed document that
models to recommendations includes the
understand their analysis of the
behaviour. various To-Be
process
alternatives and
the derivation of
the final
recommended
To-Be process
IT Solution Map and detail To-Be Models Document
Requirements the functional and describing the
Definition non-functional Use Cases and
requirements of the non-functional
an IT solution requirements for
the IT solution
Table 3.2 Summary of the BPEM activities
References
[I nfosys2004]
CHAPTER4
BUSINESS PROCESS MODEL
Chapter Topic List
1. Overview
2. Organization Model
3. Location Model
4. Collaboration Model
5. Process Catalogue Model
6. Workflow Model
. Business Rules Model
8. Modelling Notations
9. Use of Tools
References
Case Study- GSPL Travel Requisition Process
Learning Objectives
Understand the various views of a business process model that are
developed during the As-Is modelling and To-Be modelling activities of
the business modelling phase
Develop appropriate business process models for a given business
scenario
50 Business Process Model
BUSINESS PROCESS MODEL
1. Overview
A business process model describes the business processes within an
organization. It is a general template that describes the sub-processes,
activities, locations, roles, interactions, sequence and business rules for a
given business process. These are captured through the views
[lnfosys2004] of a business process model as shown in Figure 4.1. Each
view in itself is a model. Within the context of an IT project, these views
help to define and understand the current scope of the processes that are
impacted. When developing an IT solution, as discussed earlier, a number
of stakeholders are involved during the various stages of the project and
the business process model provides a focus for sharing and discussing
the business problem that is being solved. The business process model
provides a common framework for the discussions through the use of
systematic approach to represent the various related information or in
other words a common language.
Organization Model
o Captures the roles
and the reporting
structures
Location Model
o Maps geographic
location of the
business
o Provides deployment
view for the solution
Business Rules
Model
o Captures the rules
that must be applied
when performing an
activity
Process Catalogue
Model
o Captures the sub-
processes within a
process
Collaboration Model
o Captures interaction
of various entities
within and outside
the organization
o Gives a high level
view of interaction
and work product
exchange
Workflow Model
o Captures sequence of
activities
o Provides the process
flow view
Figure 4.1 Views of a Business Process Model
Business Process Model 51
In the following sections, for each of the view of the Business Process
Model, a description, meta-model, usage guidelines on how to develop the
model is provided, and as appropriate, example questions for eliciting
information regarding the model are provided.
2. Organization Model
An Organization Model is a view of how the employees of an enterprise are
organized into departments, their reporting structure, and their
responsibilities in the context of business processes. The business
organization chart of the enterprise can be used as a reference to capture
this information [lnfosys2004].
This model is created in order to represent all constituents of the
stakeholder community for an IT solution. Thus it would represent potential
business users, potential user groups, business sponsor, potential IT users
and IT sponsor along with the current participants of the business
processes.
Figure 4.2 shows an example of the Organization Model for an order
fulfilment process for a catalogue sale retail organization.
I

Organization
Retai l
Company
t
I
j
do 0

Sales
Regional
Warehouse
Manager
i
0 0
Sales
I
Store
Manager Manager
T i
j
0
Q
Role J
Sales Store
Agent Keeper
Figure 4.2 Example Organization Model
A meta-model for each view of a business process model depicts the type
of information elements contained in that view and the possible
relationships between each information element.
Figure 4.3 shows the meta-model for the Organization Model.
Following are the elements of the meta-model for the Organization Model:
Organization is a legal entity that performs a business.
Department is a unit of an organization associated with related
functions.
Role is a logical group of responsibilities of a person. This may be
further refined as a Functional Role- an official role in the organization,
e.g., 'Sales Clerk' or a Process Role - the role required by a business
process, e.g., 'Requester' in a Purchase Requisition Process, where the
'Requester' can be any person in the organization.
l Organization
Contains 1
1..*
Contains
[ Department .....
Contains
I
Contains ll.. *
1..* .r
Role
Superio
l
I
Reports to
Subordinate
Figure 4.3 Meta-Model for the Organization Model
Activity 4.1
In the context of understanding the business and developing an IT solution,
what purpose does the Organization Model serve?
Usage Guidelines
Scope - The Organization Model should depict organization elements
that fall under the scope of the current IT project. If the potential impact
of an IT solution is within a department, it is sufficient to model roles for
that department and for any other departments it interfaces within the
process that will be supported partially or wholly by the IT solution
External Organizations -Additional organization models can be created
to depict stakeholders within the boundary of external organizations like
a customer, a supplier or a partner organization if they participate in key
activities for fulfilling a business process
Depiction - A big organization model can be broken down into multiple
smaller ones to detail the structures within departments in various parts
of the organizational hierarchy
Sample Elicitation Questions
Following are some questions that can be used for eliciting the required
information to develop the Organization Model:
How is the department (or organization) structured?
Who are the people working in the department (or organization)?
What are the roles and responsibilities of these people?
Who are the customers and suppliers?
What are the departments that a particular department interacts with?
Who in these departments would the interactions be with?
Who are the people in the customer and supplier organizations that the
department (or organization) interacts with?
Are any activities performed in teams? What do the teams do? How are
they structured?
Organization Model Extensions
As discussed earlier, the Organization Model represents the stakeholder
community of an IT solution. The stakeholder community can express
needs from multiple perspectives that may have a bearing on the design of
the IT solution. These specific requirements may be captured as
extensions to the Organization Model. Some examples of special
requirements may include:
Policies - An organization may specify policies at different levels of its
hierarchy that may need to be addressed in the business process.
These policies may manifest themselves in the IT solution as business
rules. For instance, the leave policy of an organization may be specified
by head of HR who is represented as a stakeholder in the Organization
Model. This policy will then manifest as a business rule in the
calculation of leave balances and leave eligibilities of employees
Privacy and Access Levels -An IT solution usually involves a variety of
organization roles as part of its user community. Each of these roles in
the user community needs a different level of access to functionality.
This type of information can be specified against each of the roles
depicted in the Organization Model. A typical example is to provide
access to the company level financial data to the corporate head of
Finance while providing access to only Line Of Business (LOB) level
financial data to a LOB head.
Staff Requirements - For an initiative that involves introducing
automation in existing business processes, a typical metric that may
need to be analysed is the staff savings realized by the automation
exercise. This metric is based on the staff strength of the various roles
in an organization and can be assessed by capturing the staff
requirements for both the As-Is and To-Be scenarios from the
Organization Model.
Activity 4.2
Create an Organization Model for a Telecommunications Company in the
context of a specific business process presented in the following scenario.
Scenario: A new IT solution is to be designed to help the company to
speed up the time taken to enrol a customer for a new service. This
solution is to reduce the time spent by the sales manager by 20% during
his/her sales interactions with the customer. The customer activation
information is passed on to the staff of Client Service and Support group by
the sales manager. All sales activities are done by the Product Sales team
(which has the business sponsor for the IT solution). The Client Service
and Support group, headed by an enrolment head, helps to book an
appointment for activation of the requested service and enrol the customer
onto the service. The enrolment officer coordinates the activities from the
booking coordinator to the Billing department and enters all the details into
a system. Upon successful enrolment, the customer's information is sent
to the Network Connectivity department who will liaise with the IT services
group (which has the IT sponsor) to obtain the file formats for the
connection to the customer's organization.
3. Location Model
A Location Model provides a view of the geographical locations where an
enterprise or its part operates, and the departments that operate out of
these locations in the context of business processes [lnfosys2004].
This model is created in order to map department level entities to the
physical location they are operating at. The physical location can be
represented through a hierarchy. For example, Australia may be further
subdivided into Sydney, Melbourne, Brisbane and Sydney can be further
subdivided into Corporate Office, IT Call Centre, etc. This model is very
useful when developing an IT solution for an enterprise that has offices in
different regions, within the same country or different countries.
Figure 4.4 shows an example of the Location Model for an order
New York
Offi ce
Sales

us
Dallas
Office
Atlanta
Offi ce

Figure 4.4 Location Model
Figure 4.5 shows the meta-model for the Location Model. Following are the
elements of the meta-model for the Organization Model:
Region is the geographical area corresponding to an organization's
stated area of operations
Location is the city or town where the organization is located
Office is the premise where the organization is located
Department is the unit of an organization associated with related
functions.
0 .. *
Hosts
Figure 4.5 Meta-Model for the Location Model
Activity 4.3
what purpose does the Location Model serve?
Usage Guidelines
Scope - The Location Model should depict location elements that fall
under the scope of the current IT project
Depiction - Start from the bottom most layers of departments and build
each successive layer on top. Stop when no more geographical
categorization can be done. If an organization is spread over a large
number of locations, it may not be possible to show all physical
locations in one view. In such a scenario it is recommended to reduce
the complexity of the model appropriately. For example, by only
showing location at the country level, making logical groupings of
locations hosting same departments instead of showing them
individually, etc.
External Entities - A Location Model may also be drawn for an
enterprise's customer organization or supplier organization if the key
stakeholder departments in these entities are stationed in various
physical locations and their location specific needs or solution
deployment have to be addressed
Following are some questions that can be used for eliciting the required
information to develop the Location Model:
In which places are the departments (from organization model) located?
Where are the customers and suppliers departments located?
What are the office locations and what is the location hierarchy above
them?
Activity 4.4
Create a Location Model for the Telecommunications Company based on
the scenario described earlier in Activity 4.3 and the following additional
information.
Additional Information: The customer activation is done for all customers
in Sydney, Melbourne and Tokyo. In Tokyo, the cycle time for activation or
enrolment is half that of cycle time in Australia. The sales managers are
spread across both Australia and Japan but they report to department
heads in Melbourne and Tokyo. The IT services group and Billing
department are centralized and operate only out of the corporate office in
Sydney. The folks responsible for network connectivity are spread across
both Sydney and Tokyo. However, they are neither in the same office as
the IT services folks in Sydney nor in the same office as the sales folks in
Tokyo. The server of the enrolment system is in Melbourne. The client
service and support staffs operate in two cities. They work from the same
office as the network connectivity folks in Sydney and share the same
office with the sales folks in Melbourne.
4. Collaboration Model
A collaboration model provides a view of the interactions among business
participants (role, department, organization and systems) within the context
of business processes [lnfosys2004].
This model is created in order to represent all business process
participants for a set of tightly linked business processes that are under
consideration for analysis and change. It explicitly represents boundaries
and shows work products that are exchanged during the interaction.
External entities like customer or supplier organizations are also shown
along with intra-enterprise participants.
Figure 4.6 shows an example of the Collaboration Model for an order

f'- , I
0 Valldate Q
Customer esponr
.___--.--'NeworM
OrderO tall
Sales
Agent
Sales
System
Interaction
N,ew

Order Details
Figure 4.6 Example Collaboration Model
I
I ll
1 Billing I
I System
Order
Detail
Invoice
Figure 4. 7 shows the meta-model for the Collaboration Model. Following
are the elements of the meta-model for the Collaboration Model:
Business Participant is the organization, department, role or system that
participates in a business process
Segment is the logical grouping of participants based on perspective of
analysis. The most common segments used are customers, suppliers
and business domains. Sometimes, we could have segments such as
competitors, partners, outsourced companies, regulators, customer
groups (buyers, sellers) and supplier groups (content providers)
Interaction is the transfer of a work-product between two participants
Work-product is the information artefact such as policy or invoice, or
goods such as book and shipment
Figure 4. 7 Meta-Model for the Collaboration Model
Activity 4.5
what purpose does the Collaboration Model serve?
Usage Guidelines
Scope - The collaboration model should depict a snapshot view of all
business interactions between participants for a given business process
or processes. However, in some instances the number of interactions
may be too large to legibly fit into a single view. In such a scenario, split
the interactions according to different sub-processes in a process and
create a collaboration model for each sub-process
Segments - Can be used to make logical groupings of various entities
like business user segment, IT user segment, customer channel
segment, etc
Which are the systems in the process scope?
What do the roles in the organization input into the system?
What do the systems send to the roles in the organization?
What are the human-to-human interactions within the process
boundary?
What are the system-to-system interactions within the process
boundary?
Do customers and suppliers have any interactions with the systems or
departments and roles? If so, what are they?
Activity 4.6
Create a Collaboration Model for the Telecommunications Company based
on the following scenario.
Scenario: The sales manager liaises with a customer to get a product
service agreement signed. The sales manager also collects activation
information from the customer in a client setup form that covers the basic
demographic details about the client. This information is collected in a
paper form and faxed or mailed to a booking coordinator. Apart from this,
the sales manager also fills up other customer details in the
communication profile form and the billing input form that are also sent to
the booking coordinator. The booking coordinator is a user of the call
center system and internally interacts with the enrolment officer and the
sales manager. This role is responsible for validating the customer
activation information with the customer and entering customer
demographic information and product information into the call center
application. The booking coordinator then sends all the details - client
setup form, communication profile form and billing form - to the enrolment
officer. The enrolment officer creates an ID for the customer and updates
the call center application with the customer ID and the status to denote
completion of the process. Additionally, the enrolment officer also updates
client details and product details in the product system and fax the billing
form to the Billing department.
5. Process Catalogue Model
The Process Catalogue Model provides the list of sub-processes that can
be extracted from a larger process [lnfosys2004]. The Collaboration Model
provides the necessary view for extracting the sub-processes. However,
this is not possible when the Collaboration Model is too small and only
depicts a process with no sub-processes. The Process Catalogue Model
allows a transition from the macro level view of the collaboration model to
the more detailed view of the workflow model for each business process
identified. The technique to identify the sub-processes is described in the
form of an algorithm as follows:
1. Select those participants who can trigger a process for fulfilment of a
well defined but independent need
2. Select the start of interaction from this participant to trigger the need
and identify all interactions that are necessary to fulfil the need
3. Name the process (sub-process) for this need fulfilment
4. Eliminate the transactions that have been identified under this
process from the collaboration model
5. Repeat steps 1 to 4 until all interactions in the collaboration model
are exhausted
6. Workflow Model
A Workflow Model provides a view of the business process flow for each
process in the Process Catalogue Model showing the business
participants, their activities, the sequence of these activities and the
interactions between various participants. A business participant can be a
system, a department or a role internal to the organization or external to
the organization [lnfosys2004].
This model is created in order to represent the detailed sequence of
flow among the various activities that form the business process. All the
activities performed by each participant are depicted in a 'swim lane'. These
activities are linked together in the order of execution of the workflow.
Usually, the work-products passed between activities are shown on the
arrows linking the activities. The work-product can be electronic
information such as an Invoice or physical good such as a book.
Figure 4.8 shows an example of the Workflow Model for an order
Figure 4.8 Example Workflow Model
Figure 4.9 shows the meta-model for the Workflow Model. Following are
the elements of the meta-model for the Workflow Model:
Business Participant is the participant in the workflow which can be a
role (worker, manager), organizations (bank, courier company),
departments (finance department, inventory department), or systems
(service centre system, order entry system)
Activity is a task or a unit of work performed by a participant. Three
types of activities can be considered from the automation perspective
Manual activities are activities performed by human effort, unaided
by systems, for example, "Pack Goods". Such activities should be
shown in the swim lane of the role (i.e. a human) doing the activity
Interactive activities are activities done by humans that involve usage
of systems, for example, "Enter Order". Such activities should be
shown in the swim lane of the role (i.e. a human) using the system
Automated activities are activities done by systems with no manual
involvement, for example, "Retrieve Orders". Such activities should
be shown in the swim lane of the system
Transition is the link between two activities
Decision Point is a set of alternative execution flows based on
associated routing rules
Swimlane is the region that encloses a set of activities done by a
participant in a workflow
Realized by
Sequenced by
Realized by
2 .. * 1.. *
Triggered by 1.. *
Figure 4.9 Meta-Model for the Workflow Model
Activity 4. 7
what purpose does the Workflow Model serve?
Usage Guidelines
Granularity of Activity - It is necessary that the activities are defined at
the right level, for example, an activity such as "select country code" is
too granular and may not be appropriate for it to be defined in a
workflow
Manual Activities - It is important not to ignore activities that are
manual. For example, customer calling the sales agent in a sales
process needs to be shown as a workflow activity, though the call is
outside the scope of system implementation. It is important that the
thread of the workflow appears continuous and with no breaks
Flow- Workflows should preferably flow from left-to-right. Link the right
of a predecessor activity to the left of the successor activity. Next
preference is the top/bottom connection
Transitions- Backward transitions should be kept at a minimum
Name- A workflow model name should be able to indicate the scope of
the workflow to the extent possible. One convention to follow is to
clearly indicate the start point and the end point in the workflow name.
For example, a workflow name as 'Procure-to-Pay Process' is more
indicative than to merely say 'Procurement Process'
Automation Level Categorization - Usually, confusion arises between
categorizing an activity as interactive versus automated. An activity that
is associated with the swimlane of a system should always be
categorized as an automated activity whereas an activity designated to
a role/department/organization swimlane that involves system as a
participant should be categorized as an interactive activity
Decision Boxes Status- It is important to recognise that decision boxes
depicted in a workflow model are not to be confused with activities
themselves. Decision boxes have to be used to show branching of a
process based on an outcome of an activity. The activity to generate the
outcome needs to precede the decision box
Exceptions - First draw the workflow with only a few or without
exceptions and then look for all possible exceptions and model them
Can you describe how this process works?
What does it achieve?
How does it start?
How does it end?
What happens in an activity?
What happens next?
Activity 4.8
Create a Workflow Model based on the collaboration model for the
Telecommunications Company developed in Activity 4.7 and the additional
information below.
Additional information: The sales manager collects client activation
information. The booking coordinator needs to first validate this information
for completeness and correctness and interacts with the customer to
confirm the technical details mentioned in the forms. After completing entry
into the call center application, the booking coordinator sends the
enrolment file to the enrolment officer. This triggers off the set of activities
that the enrolment officer has to perform.
. Business Rules Model
The Business Rules Model provides a view of the business rules that are
applicable to some of the activities in the Workflow Model. The Business
Rules are explicit rules that are written and expressed in plain language.
They depend on the business vocabulary, which consists of terms and
facts of the business that are commonly understood by people in the
business when they talk about the business. As such, business rules are
closely related to business processes and are used when activities are to
be performed either by humans or machines.
Activity 4.9
Examine the example business process shown in Figure 4.10 and identify
where business rules are used in this process. Describe some example
rules.
Sales
l Enter J l Reject Orde:
00
Finance
( o.t .. mioe
f
Discount
Credi t Bad
2
l Worthiness

3
Good
Accountant

l
Calculate Price
4
j
I
Delivery
r

l Deliver Ord:r J
Figure 4.10 Example business process
Figure 4.11 shows some examples of business rules that are commonly
encountered in the context of a business process.
IF a customer has a gold account
THEN discount is 20%
IF a customer has a gold account
THEN issue a gold credit card
ELSE issue a standard credit card
IF total miles earned is > 10,000
THEN change status from blue to silver
IF loan type is first mortgage
THEN occupancy status must be principal residence
IF borrower is student
THEN maximum number of books allowed is 10
IF travel is to overseas destination
THEN approval from Project Manager is required
If Claimant is an employee
AND injury occurred on premise
AND there is medical necessity
AND procedure is covered
THEN adjust amount billed
If Claimant is an employee
AND injury occurred off-premise
THEN reject claim
If Claimant is not an employee
THEN reject claim
Figure 4.11 Example Business Rules
The Business Rules Model comprises a set of rules for an activity within
the business process. Table 4.1 shows an example of a Business Rules
Model that is related to one of the activities of the process shown in Figure
4.10.
Name Deciding Credit Worthiness
Activity Using this Determine Credit Worthiness
Rule Set
Description This rule set provides guidelines in deciding credit worthiness of a customer before allowing customer to
buy product
Rule Set If existing customer If existing customer
And no debts And has debts
Then credit worthiness is good And debts> $1000
Then credit worthiness is bad
If existing customer
And has debts If new customer
And debts < $1000 And external rating is bad
Then credit worthiness is good Then credit worthiness is bad
If new customer
And external rating is good
Then credit worthiness is good
Related Rule Set None
Table 4.1 Example Business Rule Model
8. Modelling Notations
Currently, there is no single standard that supports all these models. As a
result, one has to mix and merge notations from number of existing best
practices. For example, the Collaboration Model and Workflow Model
notations may be derived from Unified Modelling Language (www.uml.org).
The Business Process Modelling Notation (www.bpmn.org) can also be
used for the Workflow Model. Various representations for the Organization,
Location, Process Catalogue and Business Rules Models are determined
by the tools used. For example, when drawing Organization model in
Microsoft Visio, one is restricted to the notations supported by Visio.
9. Use of Tools
A number of tools are available for developing the models. These includes
Visio (Microsoft), InFlux Workbench [lnfosys2004], Websphere Business
Integration Modeler IBM), etc. The models shown in this book have mostly
been developed using InFlux and some in Websphere Business
Integration Modeler.
References
[I nfosys2004]
Case Study
GSPL Travel Requisition Process
[lnfosys2004]
Background
GigaByte Solutions Private Limited (GSPL) provides consulting and IT
services to their clients globally. It has approximately 250,000 employees
worldwide. Its head office is located in Bangalore in India and has offices in
other parts of India - Bombay, Delhi, Pune, Calcutta, Chennai and Mysore.
It also has offices across the world in Dallas, Milford, London, Toronto and
Stockholm.
GSPL employees travel frequently to their clients' sites and other
offices for official purposes. In order to facilitate travel, GSPL has a travel
department that coordinates the travel activities of the employees in each
of its offices. Recently, GSPL has been receiving numerous complaints
about difficulties in travel related issues. Hence, it decided to overhaul the
travel related processes in the organization and appointed an external
consulting team specializing in Business Process Engineering (known as
the BPE Team) to study and suggest improvements to the travel related
processes.
As the head office has the highest population and most of the
complaints are raised from employees in the head office, the BPE Team
decided to first begin with the head office.
The section below contains excerpts of the interview scripts with the
stakeholders of the Travel Requisition Process.
Interview Scripts
Interview with the Travel Desk
(TO-Travel Desk Personnel; BP- BPE team member)
BP: Can you tell us about the activities at the Travel Desk?
TO: The Travel Desk helps the employees of GSPL to travel to their
location of work. We help in arranging the tickets by train, bus or
air. We book accommodation at the location and we also help in
coordinating with the travel agents, airlines and hotels to sort out
travel related issues.
Business Process Model
BP: Thanks. That gives a good overview of the responsibilities of the
department. Could you please give more details about each of the
activities that you've mentioned? Firstly, can you tell me about the
ticket booking process?
TO: Sure. Whenever an employee needs to travel, he comes to us
and takes the travel request form, which consists of 4 forms - the
blue form, the yellow form, the white form and the grey form.
These forms contain the same information and have carbon
sheets in between. The employee takes the form and fills in all
the details like name, employee number, date of travel, contact
number, from and to details, preferred mode of travel and all other
details. Then, he has to obtain approval from his immediate
superior and from his business manager or any one above that
designation.
Once that is done, he has to obtain approval from the Accounts
Department. The Accounts Department has a long checklist
before they would then approve the travel application.
Once that is done, the employee would come to us. We ensure
that the approval from Accounts Department and BM have
already been done before we would accept the form. If there is
nothing wrong with the application, we will send it to the Dispatch
Department.
We have identified four travel agents to whom we give all the
forms in the morning. We receive about 200 forms everyday. The
Dispatch Department will then distribute this to the four agents
who have access to the reservation system of railways, airlines,
hotels, etc. The agents are the ones who make the actual
reservations. Along with all the requests forms, the dispatcher
also give each of the agents a control sheet which contain a list of
all the forms that are given to that agent.
If the reservation is not available as per the request, the agent will
contact the employee directly and try to get an alternative date.
In the evening, the dispatcher brings the new forms raised on the
day and also collects the forms, tickets, vouchers and the control
sheet from the travel agents. The sheet will have the status of
each of the requests and also a summary at the end. The
69
summary shows how many requests were received, how many
were closed positively and how many are being returned due to
non availability of tickets.
When we receive from the dispatcher, we will do a quick
verification and then email the employees that their tickets have
been received and that they can come and collect.
BP: OK. Now as you know, we were told that the travellers face a lot
of problems with the Travel Department. Can you tell us
something about that and why it happens?
TO: One of the biggest issues that we have is that we can contact the
travel agents only once a day or twice a day. Generally this is
done in the morning and in the evening each day. All the requests
that come in between these times will have to wait for the next
dispatch. Because of this, we are not able to service urgent
requests properly. We will either have to wait although it is urgent
or if it is extremely critical, we will have to dispatch the request to
the travel agent just for this request. As such, one more person
will have to go to the agent's office; the nearest agent being 10
km from here. The dispatcher then again has to get the ticket and
bring it back to us. This takes about 2 to 3 hours, all for one single
ticket. We do get at least 2 to 3 urgent requests per day.
Another problem lies with booking accuracy. If a ticket is booked
incorrectly, we need at least 24 hours to get it corrected. In the
case that the travel is to be done within the 24-hour period, it will
then make the matter a lot worse.
BP: Thank you very much for your detailed description of the process.
There is indeed quite some manual work involved in the process.
Interview with Dispatch Department
(DO-Dispatch Department Personnel; BP- BPE team member)
BP: Hi. We are trying to collect information regarding the Travel
Requisition Process. We have just spoken to the travel desk and
we would like to spend some time with you. Are you available to
discuss?
DO: Sure. What do you want to know?
BP: Can you tell us your activities in the Travel Requisition Process?
DO: Our work is pretty simple. We collect all the request forms from
the Travel Desk in the morning and we hand it over to the
respective travel agents. They are the ones who actually book the
tickets. There are four travel agents currently but we are planning
to increase to six agents next month.
When we collect the request forms, they are already separated
into four bunches. We deposit each bunch at the respective
travel agent at 0930 every morning. At the same time, we collect
the previous days' tickets from them and a control sheet and we
hand it back to the Travel Desk. The same thing is done in the
evening at 1630 when we hand over the request collected that
day and get back the tickets that were booked from the morning's
requests.
The major problem that we face is that we get too many ad hoc
urgent requests from Travel Desk. Just for one or two tickets, we
need to send another person and the whole process takes such a
long time as the travel agents are at least 1 Okm away. Our
resource is already very scarce, having only 3 of us in the
department to handle dispatch to all the agents as well as attend
to all those urgent requests. To make the matter worse, the
Travel Desk keeps assigning the requests to different agents.
What happens is that, if we get 3 urgent requests, at least for the
urgent requests, we should hand over everything to the nearest
travel agent. What we do now is that we have to hand over one
request to each of the agents and that makes lots of delay and
consumes lots of our resources. This makes it very difficult for us
to manage.
71
We have already put through many suggestions such as we can
probably ask each of the travel agents to come to our office at
different times in the day to collect the request forms and return
with the tickets. We can probably have a fixed schedule or look
only at the extremely urgent requests.
BP: OK. Thank you very much for your time
Interview with the Travellers
(T-Travellers; BP- BPE team member)
BP: Hi. We are currently working on the travel related processes and
will then see if there could be any improvements to be done to
Travel Requisition Process so that you will find it easier to
perform your travel related activities. In this regard we would like
to get some inputs from you.
T: Sure. In fact, why are you doing this only for travel? Why don't
you also look into catering and facilities and more importantly
salary???
BP: Oh, it is a good idea and I'll convey it to your CEO. Could we start
with Travel Requisition Process first?
T: Well, you don't have to look so hard. Everything related to travel
is a problem. Every time we call the Travel Desk, the phone is
always engaged. If you want anything from them, there is always
a 24-hour or 48-hour wait and ends up getting half the details
wrong in the tickets. Then we have to send
BP: I'm sorry to interrupt you, but can you tell me the whole process
rather than the individual issues?
T: Oh! Sure. I'm sorry that I just kept pointing the issues, but the fact
is that every step of the process is full of issues. I just can't think
of anything much. I'll just try to explain the process to you.
First, what we need to do is collect the forms from the Travel
Desk. This is already the very first issue. I have to go all the way
to Building 10 which is almost km from where I sit. Then, I need
to fill it in quadruplicate - of course with carbon sheets and get a
lot of approvals from superior. I think that this is really
complicating the process. I need to get an approval from my
immediate superior, then my Business Manager, one from the
accounts department and another one from the Travel Desk.
Each of these people sits in different buildings and I need to walk
from one place to another. It takes a lot of time, usually 2 to 3
hours to get all the approvals done.
Then, when I go to the travel desk, they would tell me that the
dispatch person has already left for the morning or afternoon and
they can send it only the next day. In the end, it takes at least 24
hours to even know a tentative status of the request. This is very
frustrating and very disruptive to our travel and even project
plans.
To make the matter worse, our travel plans keep changing. Very
often, we need to change the travel dates by a day or two due to
business needs. This is almost next to impossible. The process
makes this very difficult.
When Travel Desk finally gets our tickets, we are notified by
email. We then have to make another trip to Building 10 to collect
our tickets. If we are travelling overseas, we also have to go and
get the foreign exchange and get the entry documents from Visa
Department and each of this group of people are situated in
different buildings
BP: I'm sorry to interrupt you, but how many buildings do you have?
T: We have about 42 buildings currently. We will have another 3 or 4
more in the next couple of months.
BP: OK. You can continue
T: Yes. Getting the Foreign Exchange is another headache for us.
After the Forex Desk verifies the travel details, they would provide
a sanction letter for the bank. It is our responsibility to submit the
sanction letter to the bank manually and wait for the bank to verify
and issue the foreign currencies.
So that's about it. We need to walk around the campus a lot.
Then we need to wait for everything for at least one day.
BP: You mentioned something about going to Visa department, what
do you have to do there?
73
T: Getting Visa is slightly more straight-forward. The Visa
department would just verify our travel details and help us to
obtain a visa accordingly based on individual country's
requirements. I guess they have some agreements with the
various embassies.
BP: OK. Thank you very much for your time.
Interview with the Accounts Department
(AD-Accounts Department; BP- BPE team member)
BP: Hi, I spoke with you on the telephone regarding the Travel
Requisition Process
AD: Oh yes! Please come in and sit down.
BP: Thank you. I wanted to know from you about your role in the
Travel Requisition Process.
AD: Yes. I'll tell you how it works. We get a lot of travel requests from
employees. We have to ensure that they have completed the
settlement process for their previous travel requests. Settlement
meaning, if they have collected currency from the company, then
they should have submitted the expense sheet and the relevant
receipts. If this is not done, we will ask them to complete it and
then ask for approval before their next travel.
Although the settlement information is captured in our backend
ERP System (ES), it is difficult to retrieve the relevant
information for this approval. As such, we don't really use the
system to do the checking. Put it in the simple way, we do not
have any automated way of checking the previous travel details.
We have to sift through a lot of paperwork to find out the details
of the previous travels. As a result, there is a high possibility that
the verification is incorrect. As a matter of fact, close to 30% of
the verification is incorrect, where we have issued fresh currency
while the employee is yet to settle thousands of dollars worth of
advances from the previous travel. Manually performing these
checks is a very cumbersome process.
From what I know, the best way of doing this is to have a system
where I can check all the travel details of the employee and see
if there is a pending settlement. With that, I guess we can then
clear each of the cases within minutes. This will save a lot of
time for the employees as well as for our group members.
BP: Thanks a lot for your input. It was great.
Interview with the Business Manager
(BM- Business Manager; BP- BPE team member)
BP: Hello, we are doing a study of the travel related processes and
we wanted to know your involvement in the process and the
issues that you face in it.
BM: Oh, ok. I can tell you from the project view point. Once a person
needs to travel, he gets the forms from travel and fills it up and
shows it to his immediate Project Leader (PL). The PL verifies all
the entries and puts in his initials that the details are correct and
justified.
The traveller then brings it to me and I'll just verify that the
project code is correct. This is important because all the billing is
based on the project code and we do not want to bill one
project's expense to another. I generally know the travel
requirements of various projects. In case I'm not aware of this
need, then I can call up the PL or the Project Manager and ask
them about the details. Once that is done, I sign the form and
give it back to them. However, in some occasion, especially with
the first-time traveller, if the traveller has some of the details
entered wrongly, he would be asked to amend the details. I may
have to review the same travel multiple times.
The issues in this process are that the traveller may not be able
find me if I'm on leave or in a different building. In case of an
urgent request, I will not be able to approve it. The second thing
is that the whole process is manual and there is sufficient scope
for error. So we cannot say we have a good process.
The way I see it we need an integrated travel management
75
system that will take care of all these trivial issues and make the
complete process easy and efficient.
BP: Thank you.
Interview with a Travel Agent
(TA-Travel Agent Personnel; BP- BPE team member)
BP: Good morning, I am representing GSPL and I'm trying to improve
the Travel Requisition Process. I wanted to know your view
points in this regard.
TA: Sure. Actually at our end we have a pretty good process. We get
around 30 - 40 requests in the morning and about 10 - 20 in the
evening. In between, we may get 1 or 2 urgent requests.
One of the problems that we face is that all the forms are hand
written and at least 20% to 30% of the time, we cannot even
understand in which language the forms are written. Secondly,
people do not write the destination properly. Come, have a look
at this form. This person says that he wants to go to Whitefield.
Now, how do I know where Whitefield is? Which country is it in?
We have asked for computer print out forms or typed forms to be
faxed or emailed to us since ages ago, but we do not get it at all.
Now, look at this form, he says that he wants to travel from BLR
to LXR. However, LXR is not a destination airport code. In this
case, where shall I book a ticket for?
Despite of all the illegible handwritings, we do manage to get
through most of the requests before the dispatch person comes
in the next time. We manage to book close to 80% of the
requests and the remaining is not booked due to unavailability of
tickets on those days. So this takes a day or two to resolve and
find a suitable alternative date or route.
BP: Thanks a lot for your time. Have a good day.
Business Models
Based on the above interview scripts, it seems apparent that there are
many problems with the Travel Requisition Process in GSPL. Some
obvious flaws include the use of paper-based forms, manual checking of
forms and settlement status and manually routing the form from one
building to another.
However, the exact problems and the approach GSPL should take in order
to address the issues are still unknown. A series of analysis needs to be
carried out to properly analyse the Travel Requisition Process and derive
the final To-Be Travel Requisition Process. The analysis is covered in the
case study sections of chapters 5 and 6.
The BPE team first examine the Travel Requisition Process from the
different views of the Business Process Model. The Business Process
Models are developed for the GSPL As-Is Travel Requisition Process as
shown in Figure 4.12, 4.13, 4.14, 4.15, 4.16a, 4, 16b, 4.16c and Table 4.2.
Organization Model

.
GSPL
t
I 1 J I

Visa Desk Travel Dispatch Forex
Desk Dept Desk

.
parties
External
Parties
who have a stake in
-
the travel process
Bank Embassies Travel
Agent
I J

Accounts All
Dept Employees
i
I I
Q Q
Business PL
Manager
--
Virtual dept to denote
ployees from
ations & depts.
mployee can be
er/PUBM.
all em
allloc
Any e
Travel
I
Q
Traveller
Figure 4.12 As- Is Organization Model
78
Location Model
Worldwide
Locations
Forex
Desk
Visa Desk
Virtual dept to ~ : : >
denote all
Al l employees in
Employees -- all depts
Figure 4.13 As-Is Location Model
The Organization Model in Figure 4.12 is limited to the organization
structure of the head office in Bangalore as it is the scope of our analysis.
The Location Model, however, shows the overall regional and worldwide
offices of GSPL with more details for Bangalore. Overall Location Model is
developed as it also helps the Team to consider localization requirements
for the process and eventual IT solution.
Collaboration Model
External
I
I
Internal

; Request form

Travel
Travell er
Travel Desk
Request form Reque !form Agents
Di spatch
Ti ckets Dept
I
Tickets

Ti ckr ts
Clarifications
Approval
li
PL
Approval
;
Business
Manager

Request Form
Accounts
Approval Dept
Visa Request, Travel Visa Request, Tr vel
Document Document I

!
I I
1 Embassies
Visa and Travel
Visa and Travel
I
Document
Document
Forex
I
Forex Request
Forex Desk
Request
Bank
Foreign Foreign
Curren cies Currencies
Figure 4.14 As-Is Collaboration Model
Process Catalogue Model
Through a close examination of the Collaboration Model of the Travel
Requisition Process, the following processes (sub-processes) are
identified.
,-------
1
Exlernal
Internal
Request I
I

0
Request form
Travel
Travell er
Travel Desk Dispatch
torm Agents
Tickets
cl Dept I
Tickets
L__
Tickets
Clarifi cabons
Approval
[;]
0
Approval
Business
Manager
o"O
Request Form
Accounts
Approval Dept
Ticket Requisition Process
Visa Request, Travel Visa Request, Travel
Document Document I
O:o
o"o
I
c I Embassies
Visa and Travel
I VI sa Desk I
Visa and Travel J
Document oacume\fiS? Requisition Process
o"o Forex
cl
-a"o
ForexRequest
ForexDesk
Request
Bank
Req
1
uisit.v,
n.
Foreign
IV\.."-ss

Figure 4.15 As-Is Process Catalogue Model
Workflow Model: Travel Requisition Process and Ticket Requisition Sub-Process
Traveller ' ( Sub requesttoTrave8
Desk_ Also to Forex and [ Collect tickets
If Flll thetravel Submlt toPLI:iilj ( VosaDeptit requlred TraveiDesk , ,f-----.-1 _ f.:\
ll requestrormt
2
)
4
J 8 18/ --.
: ( ... '" 1 "
_No ( Requests traveller
-l submltcorrect rorm
6
J-;m
l
Apprave
0 request 5 Legend
Atcounts -ye!es-rr --------1-----
Dept l Verify l settlement ) N e [tj] ManuaiActMly
statu s 7 '-
Travetoesk l - a::=:D Sub-process
r Verifytravet ( l details request to travel Email traveller to Fork to parallel
'---___:9_,., agents 1 0 If ' actM1ies
do 17 ,
I If overseas travel j
Dispatch
Dept I ( Receive forms from Dispatch rorrns :J tickets _
J. ll Travel Desk
13
Travel Agents ents and send backto Jo10 -Activity 1 & 2 needs
14 Travel Desk 16) l to be complet ed before

Travel ' starting Acti';ity 3
Agents j _
[

Tickets
15
)f-----_J
" If overseas
V travel
Forex Desk l-l ln
J 11[)r-------------------------------------------_j
Visa Desk
VIsa Appllcallon ll
Subprocess t------------------------------------
12 J
Figure 4.16a As-Is Workflow Model
0::1
c:::
(/)
::5"
Cb
(/)
(/)
\:)
(3
C")
Cb
(/)
(/)

C)
c.

CX)
--"
Forex Requisition Sub-Process
iTNMIIer
--..[
sanction IaUer 10
Bank 3
0
ForexOesk
Vertt,' travel detail Pnlide sanctlo
and assign requests 1ener to Bank
2 to agents 1
o"o
Bank
( Verifyandlalj
.(i)
Issue For,)

Figure 4.16b As-Is Workflow Model
Visa Requisition Sub-Process
Desk I
..
. r verify travel llssue Travel j_

-
land assign requests related
to agents 1 documents 3)
o-o
Embassies
J
d'o

2)
Figure 4.16c As-Is Workflow Model
co
"'
0::1
c:::
(I)
:::i'
Cb
(I)
(I)
\:)
(3
C')
Cb
(I)
(I)

C)
t:::l..

Business Rule Model
Name Verify Settlement Status
Activity Using Verify Settlement Status
this Rule Set
Description This rule set checks if the traveller has outstanding
settlement before allowing him or her to travel again.
Rule Set IF traveller has no previous IF traveller has previous
overseas travel record travel record
THEN settlement status is AND one or more foreign
good currency rendered is not
recorded in settlement
IF traveller has previous record in ERP system
overseas travel record THEN settlement status is
AND all foreign currencies bad
rendered has been
recorded in settlement
record in ERP system
THEN settlement status is
good
Related Rule None
Set
Table 4.2 As-Is Business Rules Model
Interpretations
The different views of the Business Process Model provide a good insight
into the Travel Requisition Process that is being studied. However, these
models serve no meaning if the process is not carefully analysed. In the
following chapter, we will see how static analysis techniques can be
applied to identify and document the problems faced by GSPL and then
derive some high level recommendations to overcome these problems.
CHAPTER 5
PROCESS ANALYSIS STATIC ANALYSIS
Chapter Topic List
1. Overview
2. Issue Elicitation
3. Issue Analysis
4. Recommendations Formulation
References
Case Study- Static Analysis for the GSPL Travel Requisition Process
Appendix A- Catalogue of Horizontal Process Patterns
Learning Objectives
Understand the methodology for performing static analysis of a
business process
Perform static analysis of a given (As-Is) business process and
document the appropriate issues and recommendations for developing
the To-Be process
Process Analysis- Static Analysis 85
PROCESS ANALYSIS STATIC ANALYSIS
1. Overview
The static analysis methodology provides a technique for systematic
analysis of the problem space to build recommendations for the solution
space. Figure 5.1 shows the various steps of the methodology
[I nfosys2004].
Interview Scripts
As-Is Models
l
Issue Elicitation
Problem Space
Issue Analysis
Solution Space
Patterns/ Best Practices
l
Recommendations
Formulation
Figure 5.1 Static Analysis Methodology
When the necessary information on As-Is process is gathered and the As-
Is business models are developed, static analysis can be performed to
understand the issues faced and then suggest recommended solutions for
mitigating the issues. This involves the following three steps:
Issue Elicitation
In this step, the various issues for the business process under study are
identified. This may include problem areas, limitations and improvement
opportunities that exist.
86 Process Analysis- Static Analysis
Issue Analysis
In this step, the identified issues are further analysed to determine cause
and impact of the issues and to thus identify opportunities and priorities for
change.
Recommendations Formulation
In this step, possible solutions that address the issues are identified and a
final set of recommendations that are tied to a set of desired business
outcomes are proposed. These business outcomes help to fulfil the
business needs. A catalogue of established practices or patterns can be
used to formulate recommendations for business process improvement.
2. Issue Elicitation
Issues constitute problems, pain points or limitations in any business area
at the organization, process, people or activity level. Issues exist due to
misalignment of business process capability with the operational objectives
of an organization. Issues for the static analysis can be identified through
the following techniques:
Elicitation from Subject Matter Experts - involves understanding of
issues from the business users and subject matter experts. This is
captured through interview sessions and documented as interview
scripts and As-Is models.
Passive process analysis - involves conducting an evaluation of the
process structure or design to identify areas of process strengths and
weaknesses. Here, the As-Is models are further analyzed to identify
issues.
The following guidelines can help elicit some of the issues from the
Business Users and Subject Matter Expert that relate to the discussion of a
business process.
When capturing a workflow activity, ask questions such as "Why",
"How", "When" (or how often) and "What Else".
Example: In capturing the workflow for invoice generation, ask how
often does an invoice get generated? Is there any staggered scheduling
for different profile of customers to ensure regular cash-flows? Suppose
all invoices are generated on a single day every month, there would be
an intense activity to meet the deadline for providing all transaction
information a day or two prior to invoice generation. There could be a
possible problem related to getting the transaction data ready at the
right time.
Capture error or exception statistics about any process or activity.
Example: In the context of invoice generation, ask about the proportion
of invoices that are erroneous or require rework. Then try to identify
what goes wrong and why.
While discussing the workflow for a process, check for process
monitoring and feedback mechanisms. Ask things like "How do you
know that this process is doing well or badly?"
Example: For a Customer Help Centre, the workflow for handling
customer calls could be perfect but still not meeting the key metric to
reduce customer waiting time for incoming calls. There could be a
problem with resources not being optimized as calls are not distributed
optimally to the other centres.
Can you identify some of the things you would like to change about this
process/ activity?
Example: In the process for invoice generation, the participant who
provides transaction information would like a higher accuracy in the
recording of transaction data so as to enable him to work on the
reporting faster without many review checks.
Would you be able to function properly if a newcomer suddenly replaces
the person who carries out this activity? What knowledge would you
lose with this person?
Example: In the process for quoting prices to customers, the participant
might be relying on one person who is very familiar with the profile of
the customers (which is not recorded in any system) and if this person
were to leave, it would be very difficult to perform this process
effectively.
Are there any customer complaints?
Example: Customers are not getting reports on how their business is
getting handled. This would typically raise a red flag that calls for
immediate remedial action.
What kind of data would you like to see to understand your process
better?
Example: The manager is unable to identify the most profitable
customers because of non-availability of reports.
3. Issue Analysis
In order to resolve the issues elicited, improvements that impact process
activities, people, underlying technology or organizational policies need to
be undertaken. Issue analysis allows identification of such improvement
opportunities and helps to understand the relative business impact of these
improvements.
Usually, the issue elicitation leads to capture of a large number of
issues and since all issues cannot be tackled simultaneously, a structured
approach is required to prioritize them based on the business impact. This
is achieved by using the Root Cause Impact Model (RCI Model).
RC/Model
The RCI model has issues, root causes, issue impact, business measures
and business factors as its main elements. It helps to narrow the issues to
focus based on:
High priority root causes to tackle
High priority business area (based on business measures) that requires
attention
A template of the RCI Model is shown in Table 5.1 and a brief description
of each element follows.
Process Name:
Issue Issue Category Cause Root Cause Impact Impact Business Business
#
Description
Description Level Measure Factor
Impacted Impacted
Table 5.1 RCI Model Template
Issue Description: Issue is a problem, pain point or limitation in any
business area at the organization, process, people or activity level that
needs to be resolved. This represents factual information about the things
that are done (or that exist) or things that are not done (or that do not exist)
in a business area.
Category: This element helps to categorize the scope of the issue to any
of the following:
Process Related: Problems that deal with non-automation, m1ss1ng
activities, missing participants, wrong activity sequences, extra
activities, etc. fall under this category. These problems do not usually
arise due to IT failures
System Related: Problems that relate to improper (performance,
interface, functionality related) systems are usually categorized as such
People Related: Problems that occur due to work attitude of participants
or lack of knowledge/ skills are usually categorized as people-related
Policy Related: Problems that have organizational or departmental
policies as a source are categorized here
Others: Problems that occur due to external parties and for which there
is no designated category are categorized here
Cause Description: This captures information on what causes the issue.
Considering the issue as the outcome or effect, the cause can be
identified.
Root Cause: This categorizes the cause into a certain type. The root
cause identifies the generic reason for the issue to exist. Though the
causes identified can be numerous, the root causes can usually be
minimized to only a few. This element allows meaningful analysis at a later
stage and helps formulate high-level recommendations that address one or
more root causes. The root cause, thus, helps in identifying a common
solution for multiple issues.
Impact: This element introduces another cause-effect relationship.
Considering an 'issue' as the cause, its effect is captured through 'impact'.
The impact described for the issue provides a view of how the performance
of business operations will be affected.
Impact Level: This captures the relative severity of an issue. If the issue
leads to a big financial impact directly or indirectly, or seriously affects key
business goal of the client organization, it can be categorized at maximum
impact level. Thus the level of severity would reduce in proportion to the
business goal impact caused by the issue.
The impact level can be represented through various scales as deemed fit
for the study. One illustration of the scale is (Very High - 5, High - 4,
Medium - 3, Low- 2, Very Low- 1 ).
Business Measure: This element captures the business metric that gets
directly impacted by an issue. This is the closest and the most direct
measure for quantifying the impact of the issue. For example, the issue
could impact the number of invoices processed in a given time or number
of invoice errors in a day. Or it could impact the cycle time or cost for
carrying out a transaction or an activity.
Business Factor: This qualifies and categorizes the business measure
with a factor that gets undermined or improved due to change in the
business measure. Examples for a business measure like 'Invoice Errors
per 100 invoices' would undermine the business factor 'Accuracy'. Other
examples include Cycle Time, Cost, Productivity, Throughput, etc.
Process Name: Enrolment
#
Description
Impacted Impacted
1 Enrolment Process Paper based Govt More High (4) No of Productivity
info is collection of Regulation resources are enrolments
captured, info gives to capture needed to
validated participants info on perform these
and input at liberty to paper non-value
different capture adding tasks
stages by incorrect or of error
different incomplete verification
participants info
in the
process-
thus leading
to errors
2 .. . .. . .. . .. . ... .. . ... .. .
Table 5.2 RCI Model Example: Process Category
Process Name: Order-to-Cash
#
Description
Impacted Impacted
1 Customer System Systems do Lack of Contribute to High (4) Measure 1: Factor 1:
information not talk with system a high elapsed Total Process Efficiency
needs to be each other integration time. Also it Time
re-keyed and thus the results in data
Factor 2:
into multiple same inconsistency
Measure 2:
Quality
systems information is across
entered different
No of
multiple times systems
inconsistent
data points
between
systems with
regard to
customer record
2 ... ... ... ... .. . .. . ... ...
Table 5.3 RCI Model Example: System Category
Tables 5.2 and 5.3 show two examples of RCI Models that is related to the
Process category and System category respectively.
4. Recommendations Formulation
Once the root causes are identified, the recommendations for mitigating
these root causes are proposed. These recommendations can include
automation of processes, changing the organization structure or locations,
use of information systems, etc.
Root Cause Recommendation Recommendation Impact Complexity of Implementing
Score Recommendation
1 1.
2.
2 1.
Table 5.4 Root-Cause Recommendation Model Template
Table 5.4 shows the template for documenting the recommendations for
each root cause and a brief description of each element follows.
Root Cause: The root cause identifies the generic reason for the issue to
exist. The list of distinct root causes is obtained from the RCI Model.
Recommendation: The recommendation describes the solution to mitigate
the root cause. It is possible that a particular root cause may have more
than one recommendation. The recommendations are formulated based on
expert knowledge, industry best practices, technology innovations or past
experience. A catalogue of established practices can be used to formulate
recommendations for business process improvement. An example set of
best practices is provided at the end of this chapter (Appendix A) and this
is referred to as the Catalogue of Horizontal Process Patterns.
Recommendation Impact Score: A particular recommendation may not
fully solve the root cause. Therefore, it is necessary to define the impact it
has on mitigating the root cause. This can be represented through various
scales as deemed fit for the study. One illustration of the scale is (Very
High - 5, High - 4, Medium - 3, Low- 2, Very Low- 1 ).
Complexity of Implementing Recommendation: Though a particular
recommendation may have a Very High level impact on the root cause, it
may not be easy to implement it. Therefore, it is necessary to define the
complexity involved in implementing the recommendations. This can be
defined through various scales as deemed fit for the study. One illustration
of the scale is (Highly Complex, Complex, Moderate and Easy).
In order to arrive at the Root Cause Recommendation Model, the following
steps may be followed:
1. Examine the RCI Model and identify the list of root causes
2. For each root cause, suggest one or more recommendations
3. For each recommendation, define the impact the recommended
solution will have on mitigating the root cause. That is, how effective
is the recommendation in overcoming the root cause
4. For each recommendation, identify the complexity of implementing it
Table 5.5 shows an example of the Root Cause Recommendation Model.
Root Cause Recommendation Recommendation Complexity of
Impact Score
implementing
recommendation
Govt. Regulation to capture 1. Form cooperation with 4 Highly Complex
info on paper other insurance
companies to propose
change to the Govt .
... ...
Table 5.5 Root Cause Recommendation Model Example
Recommended Solution
Finally, the list of recommendations is selected from the Root Cause
Recommendation Model. The selection can be based on analysing the root
cause, impact score and complexity of implementing recommendation. A
brief summary of the recommended solution that implements the chosen
set of recommendations is then presented to the stakeholders. At this
stage, when presenting the recommended solution, the As-Is models are
available and the To-Be models are yet to be developed. Therefore, it is
usual practice to use the As-Is models effectively when presenting the
recommended solution. For example, Figure 5.2 shows the use of the As-
Is Workflow Model and how it will be affected due to the recommendations.
Activity 5.1
Identify ideas that can lead to improvement of the workflow model for the
Telecommunications Company that was presented in an earlier chapter.
Hint: Use the Catalogue of Horizontal Process Patterns
Figure 5.2 Example Use of the As-Is Workflow Model
References
[I nfosys2004]
Case Study
Static Analysis for the GSPL Travel Requisition Process
(Adapted from Singapore Management University- School of Information
Systems, Student Assignments, Academic Year 2005/06)
This case study is a continuation of the GSPL Travel Requisition Process
case study detailed in chapter 4. In this chapter, we present a report that
outlines the Static Analysis conducted by the BPE Team using the
business models that were developed.
The "Issue Elicitation" is conducted by examining the interview
scripts and the business models presented in chapter 4. The team
identifies the issues and root causes using RCI model and create a high-
level recommendation model which addresses the problems with the
current process.
In this report, "we" represents the BPE team.
Root Cause Impact
We first begin analysing the process using the RCI Model based on the Collaboration and Workflow
Business Models. In this exercise, the root cause related to each issue is identified. Table 5.7 shows the
RCI Model. The l m p ~ c t Level uses the following scale: Very High - 5, High - 4, Medium - 3, Low - 2, and
Very Low -1.
Process Name: Travel Requisition Process
# Description Description Level Measure Factor
Impacted Impacted
1 Traveller has to Process Non-automated Paper-Based Wasted time High (4) Cycle Productivity
manually go to paper-based System in non time
many collection of info value-
departments to gives adding
verify and participants tasks
process forms. liberty to capture causing
This takes too incorrect or frustration
much time. incomplete info and reduce
employee
productivity
(0
(j)
~
C")
tb
en
en
)::::.
~
s:u
~
en
'?"
Cr)
~
~
)::::.
~
s:u
~
en
c;;
Issue Issue Category Cause
# Description Description
2 The business Policy Verification of
manager's role the project code
is trivial. All he is required
does is check before travel
the project desk would
code. proceed with the
bookings
3 Particular Process Employee has to
people must be do all the
in the office in legwork himself,
order for the since he cannot
process to flow. be in 2 places at
Otherwise the the same time.
process is The process
halted. becomes
sequential even
if there are parts
that can run
concurrently
Root Cause Impact
Separate Business
roles/depart Manager's
ments with time is
redundant wasted and
functions employee
has to seek
additional
approval
Paper-Based Employee's
System time is
wasted and
the process
cycle time
becomes
very long
Impact Business
Level Measure
Impacted
Low (2) Cycle
time
Medium Cycle
(3) time
Business
Factor
Impacted
Productivity
Productivity
~
C")
Cb
(I)
(I)
:b.
~
~
~
(I)
~
Ci')
~
~
:b.
~
~
~
(I)
Ci;
tO
""-!
4 Checking of System Settlement
settlement details are not
details is easily retrievable
inefficient, time- from the ERP
consuming and system, hence
prone to human relied on paper
error verification
5 Too many Policy Bureaucracy
levels of within the
sequential department
approvals delays travel
(project leader, approval
business process
manager,
accounts dept,
etc) required,
resulting in long
cycle time
6 Illegible writing Process The process is
makes forms paper-based, so
unreadable and the readabi lity of
error-prone each form is
dependent on
the employee's
handwriting.
Root Cause Impact
Business-IT Delays in
mis- processing
alignment in travel
existing approval
system result in
decreased
worker
productivity
Separate Delays in
roles/depart processing
ments with travel
redundant approval
functions result in
decreased
worker
productivity
Paper-Based Inaccurate
System results or
increased
processing
time due to
the need for
clarification
Impact Business
Level Measure
Impacted
Medium Cycle
(3) time
Medium Cycle
(3) time
High (4) Accuracy
of forms,
Cycle
time
Business
Factor
Impacted
Productivity,
Accuracy (of
data)
Productivity
Accuracy,
Cycle Time,
and Cost
(0
(X)

C")
tb
en
en
)::::.

s:u

en
'?"
Cl')

)::::.

s:u

en
c;;
7 Any mistakes Process The process has
made in the been designed
process would not to allow error
require the exception. In the
entire process case of an
to restart exception, the
entire scenario
will have to start
from the
beginning
8 Urgent request Process As dispatches
cannot be are done only
processed once or twice
promptly per day, urgent
requests that are
submitted
between these
times have to
wait for the next
dispatch which
resulted in long
processing time
Root Cause Impact Impact
Level
Paper-Based Time is High (4)
System wasted on
restarting
the process
and
inefficiencie
s occur.
Paper-Based Traveler is Very
System not able to High (5)
travel on
schedule as
required by
the
business
Business
Measure
Impacted
Cycle
time
Cycle
time
Business
Factor
Impacted
Accuracy,
Cycle Time,
and Cost
Productivity
~
C")
Cb
(I)
(I)
:b.
~
~
~
(I)
~
Ci')
~
~
:b.
~
~
~
(I)
Ci;
tO
tO
Issue Issue Category Cause Root Cause Impact Impact
# Description Description Level
9 Employees are Process Employees may Overdepen- Employee's Medium
unable to check take a long time dence on time is (3)
request status to get request phone calls wasted on
or update travel status and have making
details difficulties to several
update the calls;
Travel Desk of changes in
changes in their travel plans
travel plans as might not be
the phone is updated in
always engaged time
when they call
Table 5.6 RCI Model for GSPL Travel Requisition Process
Business
Measure
Impacted
No. of
travel
status
checks
supported
per day
Business
Factor
Impacted
Productivity,
Accuracy
0
0

C")
tb
en
en
)::::.

s:u

en
'?"
Cl')

)::::.

s:u

en
c;;
Recommendation
From the above root cause impact analysis and the business models
developed earlier, we made the following observations:
The majority of the root causes refer to a single root cause, i.e.
the travel process is using a paper-based system
There could be a problem with the current organizational
structure. There are too many departments involved in the
process, complicating the Travel Requisition Process. A few of
these departments have overlapping functions, such as the
Visa and Travel departments
There are too many manual and repetitive checks for the travel
request form that involve too many approvals regardless of the
nature of the travel (local or overseas, short trip or prolonged
trip)
To draft out a high-level recommendation plan, we combine our static
analysis and apply the horizontal process patterns to the root causes
we have identified. Table 5.7 summarizes the recommendation that
we are presenting to GSPL.
The Recommendation Impact Score uses the following scale:
Very High - 5, High - 4, Medium - 3, Low - 2, and Very Low - 1. The
Complexity of Implementing Recommendation uses the following
scale: Highly Complex, Complex, Moderate and Easy.
(based on Impact Score Implementing
horizontal Recommendation
process patterns)
Over- 1. Use an 2 Moderate
dependence automated
on phone telephone system
calls 2. Use an online 4 Highly Complex
system to provide
process-based
experience such
that it allows
employees to
update or check
the status of their
travel
arrangements
Paper-Based 1. Use an 5 Highly Complex
System employee self-
service online
system to handle
travel related
matters
2. Share 5 Moderate
electronic
information with
external partners
such as auto-fax
or email
electronic travel
request forms to
travel agents
Business-IT 1. Develop 5 Moderate
mis- interface to
alignment in retrieve relevant
existing data to facilitate
system settlement checks
2. Integrate new 4 Highly Complex
online system (if
any) withES to
perform
settlement checks
automatically
(based on Impact Score Implementing
horizontal Recommendation
process patterns)
Separate 1. Merge Visa 3 Complex
roles/ Desk with Travel
departments Desk
with 2. Cut down the 4 Complex
redundant need to work with
functions so many
departments
through
automation. E.g.
automate
settlement status
checks and
generation of
sanction letter
3. Streamline 4 Moderate
approval process
by cutting down
approval
requirements
such as getting
supervisor to
check project
code instead of
business
manager
4. Streamline 2 Easy
some activities to
allow some
functions to be
done in parallel ,
e.g. approval
Table 5.7 Summary of the recommendations
Our recommendation also includes some organizational change. We
suggest merging of the Visa department and Travel department. By
merging these departments together, not only would there be greater
productivity within the department, travel application processing
would also be accelerated. For instance, since the Visa department's
functions are closely tied with travelling, it would be better if staff from
both departments worked together to foster greater collaboration.
The diagram below shows the suggested new organization
model if Visa and Travel department are merged.
Visa Desk Travel
Desk
.,_
L_ _ _J ,__ _ ___, : -
1- ---- -- -------------J
~
..
External patti
External
who have as
es
take in
cess
Parties
--- -
the travel pro
t
~ ~ ~ ~ ~ ~
Bank Embassies Travel
Agent
Business
Manager
PL
-----------
1 I
-- : changes :
I I
- - - - - - - - - - ~
Traveller
Figure 5.3: Proposed organization structure for GSPL
Summary of Recommendations
The largest change that we recommend is to introduce an online
travel system. Many of the problems with the existing system stem
from the paper-based nature of the current system (human errors, in-
ability to do parallel processing). The online system provides a one-
stop-solution for employees to apply for travel.
Approvals can be automatically routed to the employee's
supervisor when an application is filled online and submitted to the
travel system, saving the employee the trouble of having to look for
their supervisor and accounts department just to get their forms
signed.
The travel system could auto-fax or emails the electronic
request form to the travel agents, which would resolve the problem of
the agents only getting the travel requests twice a day from the
Dispatch Department. Urgent requests can also be submitted to the
travel agents anytime of day in this manner.
The above recommendations however are based on
preliminary analysis through Static Analysis. Static Analysis does not
give any concrete information or proof that the recommendations are
feasible and indeed able to improve the current process. In the next
chapter, we will see how Dynamic Analysis can help us to verify our
recommendations and appropriately modify them to improve the
process.
Appendix A: Catalogue of Horizontal Process Patterns
[lnfosys2004]
This document contains a repository of horizontal process patterns
that act as reference during the Recommendations Formulation
phase when doing a Static Process Analysis.
1. Manual Task Elimination
Context: In a business where IT usage is very low, a lot of
inefficiencies are caused due to manual tasks, for e.g., manual
delivery of orders from building to building.
Solution: Mark manual activities in the workflow and consider
software solutions for automating them, for e.g., e-mail, custom
application and package.
Impact: Improves efficiency.
2. Self-servicing
Context: Customers have to call service representatives for resolving
their problems. Most of these are repetitive in nature. Customers are
frequently put on hold. Workers are frequently required to approach
departments concerned for many operational needs, e.g., booking
tickets, purchasing books. This takes a lot of time.
Solution: Provide a web-based self-servicing application that will
enable users to access services such as travel booking, tax payment,
booking facilities, etc. on their desktop. Look for activities in workflow
that involve users calling on others for service or operational needs.
Investigate how these services can be provided through the desktop.
Impact: Saves time, improves user satisfaction.
3. Role-targeted portals
Context: Employees frequently have operational and work
requirements that involve using many applications. An employee for
travel would have to communicate with travel, visa, finance and
business manager through various means.
Solution: Provide a portal where all activities relating to a given
business process for a given role are available. This should
aggregate services across applications and provide "single-window
service" to the user.
Impact: Improves efficiency and satisfaction.
4. Minimal checks and controls
Context: Frequently, many workflows have activities to do with
approval of a request by a superior.
Solution: Look for activities internal to departments that flow to
superiors. Avoid upward flows. Instead, provide for automated routing
to the role that is empowered to act on the request. Example, an
approval range concept (Role M for claim size < $1000, M's boss for
claim size between $1000-$10000)
5. Activity Parallelization
Context: Do work-product flow analysis on activities in workflows.
Activities do not necessarily have to execute in linear sequence.
Solution: Activities that do not depend on preceding activities are
candidates for parallelization. Dependency arises because an activity
requires as input, the work-products of a preceding activity. If there is
no such dependency between a pair of adjoining activities in a
workflow, there is an opportunity for parallelization.
6. Shared Information (One view)
Context: Frequently, many instances of documents are maintained in
paper-based or electronic forms. This leads to inconsistency.
Solution: Look for activities that create redundant information.
Collapse them. Keep a single instance of documents - electronic
form -that can be shared or used by multiple people.
Impact: Reduces inconsistency.
. Process-based experience (not transaction-based)
Context: Frequently, the customer's visibility into a service ends
when the order is placed. Hence, customer is not able to track his or
her order. For example, if a Travel Booking Request is placed, the
customer is unable to verify the status of the request or modify it.
Solution: Design customer interfaces from process viewpoint and not
on an individual transaction viewpoint.
Impact: Greater customer satisfaction.
8. Paper-form elimination
Context: Paper forms lead to tracking problems and increase
chances of loss in transit and damage. Transit times cause
inefficiency.
Solution: Eliminate paper forms. Use electronic documents.
Impact: Greater efficiency and reliability. Ability to work in parallel on
documents in shared mode.
9. Elimination of Excessive Information hand-offs
Context: A given document could be transmitted across several
systems and/or departments in a given business process.
Solution: Look at the workflow to see if the information or document
required can be shared.
Impact: Better maintainability and traceability.
1 0. Outsourcing
Context: Some non-core business functions have high cost-of-
ownership and high cost-of-automation.
Solution: Look for Application Service Providers (ASP-s) for
Commoditized business activities where business differentiator is not
relevant.
Impact: Improves efficiency and reduces cost.
11. Customer Supplier Integration
Context: Customer orders are often received by Sales department
and passed on to Production department. If materials are not in stock,
the Production department notifies Purchasing department that
originates a Purchase Order with the Supplier. The Supplier sends
the materials.
Solution: Link the customer order-taking systems with production
systems (e.g., ERP) and pass them straight to suppliers electronically
(e.g., EDI or ebXML). Also, look at Marketplace and Vendor Managed
Inventory paradigms.
Impact: Linking customers and suppliers improves fulfilment times
and betters customer service levels.
12. Automated HandOffs
Context: If a role is not available to perform a critical activity, the
workflow is held up.
Solution: The solution should route the work to peers who are
authorized to perform the same work.
Impact: Improves efficiency, allows critical work to be handled on
time.
13. Asynchronous Decision
Context: In many workflows, an activity is preceded by a decision
whether to do that activity. For example, doing an experiment may
require a decision on the need for that experiment. Applying for a
ticket may require that the need for the ticket be justified. In some
instances, the decision may take considerable time, especially if
multiple departments are involved.
Solution: Execute the activity anyway. The decision step can
proceed in parallel. Abort the activity if subsequently, a decision is
taken to cancel it. This is applicable for small inexpensive activities
where decision making may be laborious.
Impact: Improves turnaround time for the workflow.
14. Eager Exception Checking
Context: In many workflows, many checks and reviews (e.g., product
quality) are done on a work-product before it is input to an activity. If
the checks fail, work-product is rolled back and returned for
rectification. These checks increase the cost of the process.
Solution: Move the checks earlier in the workflow where the cost of
fixing the exceptions is low.
Impact: Lower costs
15. Exception Prevention
Context: In many workflows, many checks and reviews (e.g., product
quality) are done on a work-product before it is input to an activity. If
the checks fail, work-product is rolled back and returned for
rectification. These checks increase the cost of the process.
Solution: Look at means to eliminate the exceptions - by prevention
mechanisms, or by ensuring or negotiating better work-product
quality.
Impact: Lower costs.
16. Customer Focusing
Context: Workflows often involve activities such as quality check,
management, handling exceptions, (e.g., reporting). These add to the
cost of the process.
Solution: Characterize each activity of the process. If it is not adding
direct value to the customer, move those activities out of the critical
path into parallel threads.
Impact: Improves turnaround time for the workflow.
17. Broker elimination
Context: Many workflows involve roles that just forward work from
one role to another. These add to the cost of the process.
Solution: Remove the broker from the workflow and link the
predecessor and successor activities directly.
Impact: Reduces costs.
CHAPTER 6
PROCESS ANALYSIS DYNAMIC ANALYSIS
Chapter Topic List
1. Overview
2. Tools for Dynamic Analysis
3. A Methodology for Dynamic Analysis
4. Limitations of Dynamic Analysis
References
Case Study- Dynamic Analysis for the GSPL Travel Requisition Process
Learning Objectives
Understand a systematic methodology for performing Dynamic Analysis
Apply the methodology for performing Dynamic Analysis of a business
process and document appropriate analysis reports
Understand how process change impacts organization, customers and
partners
Appreciate the limitations of Dynamic Analysis
Process Analysis- Dynamic Analysis 113
PROCESS ANALYSIS DYNAMIC ANALYSIS
1. Overview
In Dynamic Analysis, the business process models, particularly the
Workflow Model, is analyzed and optimized through use of simulation. It
enables organizations to observe how a business process will perform in
response to variations of inputs to the process, just as in a real-life work
environment.
The Workflow Model may be based on an existing business process
(As-Is) or one that is being planned for the future (To-Be). The aims for the
As-Is and To-Be analysis are as shown in Figure 6.1.
As-Is
Identify key process issues (E.g. cost-
overrun, inefficiencies)
Identify the bottlenecks activities
Identify activities that are good to be
retained in the To-Be process
Gather statistics to serve as a basis for
comparison with To-Be process
To-Be
Analyze and evaluate "what-if" conditions
To derive at the most optimal solution
Estimate ROI & expected KPis
Help to plan for future resources required
by new process (e.g. human resource,
system, machineries)
Assess impact on the organization &
partners
Figure 6.1: Aims of Dynamic Analysis for As-Is and To-Be process
Some of the benefits of Dynamic Analysis are as follows:
Provides insights into the performance of the business process under
various conditions; helps in identification of bottlenecks, problems, as
well as improvement opportunities
Enables 'what-if' analysis to determine most efficient model changes
Accelerates production by reducing complexity by modelling before
implementation
Provides projections and shows business benefits (e.g. return-on-
investment) of streamlined business processes before retraining and
retooling
Enables organizations to quickly redesign processes or plan future
processes as business needs change
114 Process Analysis- Dynamic Analysis
2. Tools for Dynamic Analysis
As the concept of Business Process Management (BPM) gains popularity,
software vendors who formerly have positioned their products in other
categories such as workflow, rule-based system, enterprise application
integration (EAI), computer-aided software engineering (CASE), have
begun to reposition their products under the category of BPM tools.
A BPM tool generally includes, to varying extents, a combination of
some of the following capabilities:
Modelling - Design, document and revise business process flows
graphically
Simulation and Analysis - Execute and observe performance of
business process. Provide analytical reports that reveal bottlenecks,
redundancies, waste, circuitous flows and other opportunities
Integration - Allow interactions with both human touch-points and
application systems
Management - Monitor, control, track, review and provide exception-
handling capabilities for performance improvement
The above list is certainly not exhaustive. Of these, the first two capabilities
for a BPM tool are most important for performing Dynamic Analysis and
hence, we will only concentrate on these two in this chapter.
In general, a BPM tool that supports dynamic simulation and analysis
allows the enterprises to quantify the cost of the process in terms of time,
money and resources; simulate the various scenarios and collect statistics
about the process execution in search for the most ideal process before
the process is implemented.
In this chapter, the methodology presented is generic and is based
on the combination of features supported by a few BPM tools. Hence, one
has to adapt the methodology to suit a particular tool.
Following is a partial list of industry standard tools that support
process modelling, simulation and analysis to various degrees:
WebSphere Business Integration Modeller (IBM)
TIBCO Business Studio (TIBCO)
ARIS (IDS Scheer)
iGrafx (iGrafx)
Process Designer (Uitimus)
SIMPROCESS (CACI)
ProVision (Proforma)
3. A Methodology for Dynamic Analysis
There are plenty of ways to conduct Dynamic Analysis when redesigning
business processes. We will cover one generic yet systematic approach in
this chapter that we believe would serve as a guideline to arrive at the
most appropriate To-Be process.
The diagram below depicts the various phases and activities involved in
our methodology.
Ensure alignment and achievable targets
~ ~
Establishment of Process
Performance Targets
Start
End
Modelling Activities & Simulations
,--------------------
1
I
i ~
I
I
I
I
I
I
I
I
I
I
I
I
Identify Simulation
Parameters
1 Modelling Preparation Activities 1
L ~
4 1------------,
Final Selection of To-Be
Process for Implementation

Simulate &
Analyse As-Is process
Simulate &
Analyse To-Be Process
Alternatives
Revision if impact
is not acceptable
Impact Analysis of
the To-Be Alternatives
Figure 6.2: An Approach to Dynamic Analysis
The Dynamic Analysis may be split into four phases. The phases are not
carried out in a linear sequence as they closely interact with each other
and are iterative. Not all phases or activities within a phase may be
appropriate in all process redesign scenarios. Hence, one should
appropriately adapt the methodology for a given process redesign
scenario.
The four phases that we have identified are:
Establishment of Process Performance Targets
Modelling Activities and Simulations
Impact Analysis of Selected To-Be Alternatives
Final Selection of To-Be Process for Implementation
In the following section, we will go through some concepts within the
phases and the techniques to be used.
Phase 1: Establishment of Process Performance Targets
[Sawy2001]
It is essential that one begins the Dynamic Analysis with the end in mind.
That is, it is necessary to identify the performance targets for the To-Be
process that the organization would like to achieve such that analysis and
redesign could be steered towards achieving the targets.
Baseline As-Is process
Redesign based on
process performance
targets
To-Be process
Figure 6.3: Main aim of establishing process performance targets
At this juncture, some of the questions that would surface could be:
What are the important factors that one is trying to address in this
process? Is it efficiency? Is it quality?
Is lowering cost an important aspect for the process?
Is efficiency important over the cost?
What are the ideal employees' utilization targets?

The process performance targets can be derived by following the three
steps as shown in Figure 6.4.
Step 1: Identify the process redesign goals Step 2: Identify any binding organization policies
and their priorities or management decisions related to the process
/
Step 3: Derive the process performance targets
and measurement metrics for each of the targets
Figure 6.4: Steps to derive the process performance targets
Some examples of performance targets include:
Increase overall efficiency of the customer enrolment process by
reducing the processing duration for each enrolment by at least 15%
Reduce the overall cost for an enrolment by at least 5%
Reduce the number of exceptions in the enrolment process by at least
40%
For each performance target, the measurement metric must also be
identified. For example, the metric for "Reduce the overall cost for an
enrolment by at least 5%" is the "Average cost of enrolment".
Once the performance targets are derived, we can now proceed to
the next phase that is Modelling Activities and Simulations.
Phase 2: Modelling Activities and Simulations
In this phase, we study what is really happening currently in the process
(As-Is Modelling and Simulation) and attempt to predict what would happen
if the recommended changes are implemented (To-Be Modelling and
Simulation). It is to identify the critical areas where process redesign efforts
should be focused on and explores the various alternatives for the To-Be
process such that the best that matches the performance targets could be
identified. It also serves as a reality check for the performance targets by
revealing the potential problems that may surface if the new process is
implemented.
We split this phase into four activities. They are:
Collect Data
Identify Simulation Parameters
Simulate and Analyse the As-Is process
Simulate and Analyse the To-Be process
These activities serve as a guideline in our methodology when performing
Dynamic Analysis but are not mandatory. All activities may not be
applicable to all business process engineering scenarios, and the activities
are performed iteratively.
Collect Data
During this activity, the data required for simulation is prepared so as to
make the simulation realistic and hence provide the ability to properly
diagnose the issues faced in the process.
Table 6.1 shows a list of potential data that is to be collected. This list
is not exhaustive and should only be used as a guideline.
Process Wide What triggers the start of this process?
What is the start time of the process?
What is the arrival pattern of the triggers?
What is the rate of triggers?
What are the termination conditions?
Is there a one time process cost?
Are there any dependencies?
Activity Related What are the resource requirements (labour, machinery or system)?
Which role or individual resource is required?
What is the time required to complete the activity; is the time constant, exponential, or follows normal
distribution?
What is the cost incurred?
How will the queue be handled?
Resource Related What is the cost of each resource?
.
How many resources are required in each role?
What is the work hours of each resource?
What is the maximum utilization of each resource?
Decision Points What is the probability of each decision points based on past history or assumption?
Table 6.1: Example data required for modelling and simulation activities
Identify Simulation Parameters
In this activity, the data collected in the Collect Data activity is converted
into specific simulation parameters appropriate to the Dynamic Analysis
tool that will be used for performing the simulation. Depending on the tool
used, the parameters required to model the business process will be
different. For example, some tools allow the user to specify the work
schedule of a resource while other tools may not.
In Figure 6.5, an example of how the same data could be translated
to simulation parameters in two different tools is shown. Here the example
shown is the time duration for an activity which varies between 18-22
minutes and the average being 20 minutes. In Tool 1, the mean and the
standard deviation are to be entered. In Tool 2, it is necessary to enter the
minimum (18) and maximum (22) time for the activity.
Activity Fill the travel request form
Time taken to Normally distributed between 18-22 minutes, average of 20 minutes
complete activity
Simulation Distribution: Normal
Parameter using
Time unit: minutes
Tooll
Mean: 20
Standard Deviation: 2
...

1
General
Activity I
P<Yameters
Du' otio<1 OistrWoo: I :lliiila
l/isualzaloo
rmelri:
SirnJiotlo<1
Maxilun Delay SLA: r==
De<crlptlon
MeM: [20
Stondord Devlaloo: [2
Est mated mean cost ol actlvly Is: 100
Simulation Distribution: Normal
Parameters using
Time: 18-20
Tool2
Time unit: minutes
. , .. )(
GUde ActMtvTwe
IActivtv
3
Modefng
Input
l ine;
Resoo<ces
3 ra-- to IMm ..
3
Task

IN<>mal
3
Atbillutes
, __ .... ,___ ,_ .. __
Figure 6.5 Example of translating data into simulation parameters
Simulate and Analyse the As-Is Process
In this activity, the As-Is process is simulated and analysed. As described
in section 1 of this chapter, dynamic simulation of the As-Is process is
usually conducted in the case when it is not clear what are the exact
problems associated with the process from Static Analysis and hence there
is a need to run simulation to understand how well the process works and
identify where the performance bottlenecks are. It also helps us to collect
statistics to serve as a basis for comparison with the To-Be process
alternatives.
There are various techniques involved in analysis of the simulation
results. Table 6.2 shows a summary of some of the techniques. However,
each technique should be applied appropriately in accordance to the
process analyzed. More often than not, analysis of simulation results
usually requires a combination of a few techniques in order to make
sensible deductions. Again, different Dynamic Analysis tools provide
different functionalities and hence the ability to apply the techniques may
differ.
Capacity Analysis This involves measurement of the maximum capacity of the process based on a set of defined
operational conditions.
E.g. The order management process can handle up to 1000 transaction a day over a period of 8 hours.
Process Cycle This involves understanding of the duration (time) and cost of the process cycle.
Time/Cost Analysis
E.g. The order fulfillment process takes average of 20 minutes with standard deviation of 2.4 minutes.
Resource This involves understanding how the resources (human or machinery) are utilized in the process and
Utilization/Cost how much cost it adds to the process.
Analysis
E.g. Order entry clerk is over-utilized at 127%.
Activities Time/Cost This involves understanding of the duration (time) and cost of each individual activity in the process.
Analysis
E.g. The order entry activity takes an average of 10 minutes with standard deviation of 2.1 minutes.
Bottleneck Analysis This involves combination of process analysis, resource analysis, activity analysis to determine what is
causing the bottleneck.
E.g. The order entry activity has an average queue length of 8 and the order entry clerk is over utilized
at 127%. The bottleneck occurs at the order entry activity.
Path (or case) This involves analysis of the various paths that constitute the whole process. Paths are usually results
Analysis of decision points. Some Dynamic Analysis tools refer to this as a 'case'.
Unusual Event This involves analysis of events that may have a huge impact on the process but it does not occur
Analysis frequently.
E.g. Effect on the order fulfilment process when the warehouse gets flooded.
What-if Analysis This involves analysis of various possible scenarios for the process.
E.g. What effect does reducing the number of claim supervisors from four to two have on the overall
claims processing time?
Table 6.2: Analysis techniques
An example of how these techniques are applied to the As-Is process is
presented in the Case Study at the end of this chapter.
Simulate and Analyse the To-Be Process Alternatives
In this activity, the To-Be process is simulated and analysed. This is an
iterative activity as there may be a need to refine the simulation
parameters, rethink possible ways to improve the process further if the
initial To-Be model does not yield satisfactory results.
The techniques used in this activity are very similar to ones used in
the analysis of As-Is process (See Table 6.2). An example of how these
techniques are applied to the To-Be process is presented in the Case
Study at the end of this chapter.
Phase 3: Impact Analysis of the To-Be Process Alternatives
In this phase, we examine how changes in the process affect the
organization, the customers and business partners.
The impact of the changes introduced by each of the To-Be process
alternatives is analysed. As the various activities within a business process
may involve various stakeholders, it is inevitable that changes in the
process will have impact on the organization (internal impact), its
customers, business partners and even the industry or society (external
impact). An impact could be "hard" quantifiable benefits/loss (e.g. saving
10 minutes for each activity) or "soft" qualitative benefits/loss experienced
(e.g. lower morale) by the different stakeholders involved in the process.
Figure 6.6 shows an example business process and the various
stakeholders who are affected by changes to specific activities within the
business process. For example, changes to the activity "Issue packaging
instructions to the warehouse" impacts the Warehouse Department
(internal impact) and changes to the activity "Issue shipping instructions to
FedEx" impacts an external partner (external impact).
Impacts //
/
/
/
/

/
/

/
Issue packaging
instructions to
warehouse
Issue shipping
instructions to
Fed Ex
t
I
I
1 Impacts
Send shipping info
to customer
1 Impacts
Figure 6.6: Example of changes in the business process and its internal
and external impact
Importance of Impact Analysis
Impact analysis plays a significant role in Dynamic Analysis as it has an
influence over the final design of the process. There are times when there
are two equally beneficial To-Be alternatives and the final To-Be is
selected based on comparing their impact on the various stakeholders.
The greater the impact, the higher the risk and potentially higher
implementation cost and resistance to change. In some cases, the
apparently best To-Be alternative may prove to be infeasible to implement
since it has major internal and external impacts. In such situations, results
from the impact analysis may lead to further review of the process. This
review may continue until the To-Be process is feasible for implementation.
Phase 4: Final Selection of the To-Be Process for
Implementation
In this phase, we make a final decision regarding the most suitable process
that should be the To-Be process. This decision is arrived by selecting one
To-Be process from the list of alternatives based on the performance
targets set, simulation results and impact analysis. This process must be
feasible to implement and the benefits must out-weigh the loss due to
change.
4. Limitations of Dynamic Analysis
Although Dynamic Analysis has the benefit of providing insights into the
performance of the business process, it still depends on modelling and
simulation which may not truly reflect reality.
Different tools have different ability to fully model a business process.
Some examples of limitations in some of the tools are:
It is assumed that the human resources are 100% productive during the
work schedule
The activities take a fixed amount of time to be completed
No provisions for public holidays
No provision to model external factors that may influence the process
such as strikes, natural calamity, etc.
Cost and number of resources are fixed and are not subject to real
situations of resources (humans) not reporting to work for the day
In addition, modelling and simulation is effort and computationally
expensive. One must strike a balance between building the most accurate
model and the amount of time and effort invested into modelling and
simulating.
As such, there is no one perfect model and there is no one accurate
simulation result. The results give an indication of how the process might
behave but not how it would actually behave in the real world. Therefore,
the BPE team involved in the Dynamic Analysis must take these limitations
into consideration when performing the Dynamic Analysis.
References
[SAWY2001] El Sawy, OmarA. Redesigning Enterprise tore-Business,
McGraw-Hill, 2001.
Case Study
Dynamic Analysis for the GSPL Travel Requisition Process
We illustrate how each phase of the Dynamic Analysis techniques can be
applied through the GSPL case study. The simulation and process analysis
were carried out using IBM WebSphere Business Integration Modeler
(WBIM). Please note that some of the analysis done in this case study may
not be available if another Dynamic Analysis tool is used. Likewise, there
could be other functions and analysis capability available in other tools that
may not available in IBM WBIM.
Static Analysis of the Travel Requisition Process has indicated that
the main cause for frustration is the amount of manual work required for
each travel application. Automation of the travel process would help to
alleviate some of the problems faced by the travellers.
In the previous chapter, some recommendations were proposed
based on the Static Analysis. In this Section, Dynamic Analysis will be
conducted to verify these recommendations and propose the final To-Be
Travel Requisition Process to the GSPL management.
In this case study, "we" represents the BPE team who is working with
GSPL to redesign the Travel Requisition Process.
*
*
*
Phase 1: Establishment of Process Performance Targets
To start with, we work with various GSPL stakeholders to obtain the
performance targets. Firstly, we identify some of the goals for the To-Be
Travel Requisition Process as shown in Table 6.3.
Process Redesign Goals Priority
1. Achieve a more efficient Travel Requisition Process for High
all travellers
2. Reduce the manual activities involved in the Travel High
Requisition Process so as to reduce the time wasted and
errors made
3. To reduce the overhead of approval for the project High
leaders and business managers
4. To lighten the load of the various GSPL departments Medium
(e.g. Travel Desk, Financial Department)
Table 6.3: Process re-design goals for the To-Be process
Secondly, we examine some of the binding management decisions or
policies that must be taken into consideration when designing the new
travel process as shown in Table 6.4.
Binding Management Decisions or Policies
1. Use information technology to automate the business process
2. Costly overseas travel will only be granted when deemed appropriate
by business managers
3. Appropriately reuse the existing IT systems whenever possible
Table 6.4: Binding management decisions and policies
Finally, we derive the process performance targets based on the goals,
management decisions and policies as shown in Table 6.5.
Process Performance Targets Metrics
1. Increase overall efficiency by reducing the Average Duration of travel
processing duration for a travel request by requests for each
at least 25% individual path
2. Reduce the overall cost for a travel Average Cost of travel
request by at least 1 0% requests for each
individual path
3. Remove the bottlenecks that have been Number of bottlenecks
identified and the delays caused by
each of them
4. Reduce manual activity Number of manual
activities
Table 6.5: Process performance targets
Phase 2: Modelling Activities and Simulations
Activity 1: Collect Data and Identify the Simulation Parameters
We then initiate the data collection activity. The key data relevant to the
Travel Requisition Process is collected and tabulated as shown in Table
6.6. This data is then used as simulation parameters for the Dynamic
Analysis.
Key Data Value
Number of travel request per day 200
Work hours of GSPL employees 0830-1730 hrs Mon-Fri
Time between requests On an average about 144
seconds
Currency used to cost a transaction $ USD
One time cost for each instance of the $2
process
Table 6.6: General simulation parameters
Additionally, we collect data regarding each role, activity and decision
points involved in the Travel Requisition Process and tabulate them as
shown in Table 6.7, Table 6.8 and Table 6.9 respectively. We appropriately
use this data as simulation parameters within the Dynamic Analysis tool.
Role Cost Available Time Number and name of
resources in the Role
Traveller Not 830-1730hrs Mon- Unlimited
modelled Fri (lunch 1200-
1300)
Finance US$65 /hr 830-1730hrs Mon- 3 (Finance-1, Finance-
Advisor Fri (lunch 1200- 2, Finance-3)
1300)
Travel US$50 /hr 830-1730hrs Mon- 3 (Travel-1, Travel -2,
Advisor Fri (lunch 1200- Travel -3)
1300)
Project US$75/hr 830-1730hrs Mon- 50 (PL-1 PL-50)
Leader Fri (lunch 1200-
1300)
Business US$120/hr 830-1730hrs Mon- 5 (BM-1 BM-5)
Manager Fri (lunch 1200-
1300)
Role Cost Available Time Number and name of
resources in the Role
Visa Advisor US$50/hr 830-1730hrs Man- 1 (Visa-1)
Fri (lunch 1200-
1300)
Travel Agents N/A 0900-1900hrs 4 (Agent-1 Agent-4)
Distribution US$25/hr 830-1730hrs Man - 3 (Distribution-1
Personnel Sat Distribution-3)
(Urgent)
Distribution US$25/hr 930-1130hrs
Personnel
1630-1830 Man -
(Urgent)
Sat
Bank N/A 830-1730hrs Man - Unlimited
Fri (lunch 1200-
1300)
Embassy N/A 0900-1700hrs Unlimited
Table 6.7: Roles related parameters
Table 6.8 shows the information on the resource requirement and the
amount of time required to perform the activity. For example, the activity
"PL Approval" takes an average of 18 minutes with standard deviation of 3
minutes to complete. The Project Leader (PL) performs this activity.
Activity name Duration (minutes) Role
Resource
Bring Form to Project Leader (PL) Normal distribution Traveller
Mean= 15
Std D = 2
PL Approval Normal distribution Project
Mean= 18 Leader
Std D = 3
Bring Form to Business Manager Normal distribution Traveller
(BM) Mean= 15
Std D = 2
BM Approval Normal distribution Business
Mean= 12 Manager
Std D = 2
Activity name Duration (minutes) Role
Resource
Take Travel Request To Travel Normal distribution Traveller
Desk Mean= 15
Std D = 2
Check Settlement Status Normal distribution Finance
Mean= 10 Advisor
Std D = 2
Assign Request to Agents Normal distribution Travel
Mean= 10 Advisor
Std D = 2
Ticket Purchase Normal distribution Agents
Mean= 30
Std D = 10
Update Travel Request with Ticket Normal distribution Travel
Details Mean= 5 Advisor
Std D = 2
Dispatch Ticket (Urgent) Normal distribution Distribution
Mean= 20 Personnel-
Std D = 5 Urgent
Dispatch Ticket (Normal) Normal distribution Distribution
Mean= 20 Personnel-
Std D = 5 Normal
Dispatch Form (Urgent) Normal distribution Distribution
Mean= 20 Personnel-
Std D = 5 Urgent
Dispatch Form (Normal) Normal distribution Distribution
Mean= 20 Personnel-
Std D = 5 Normal
Update Travel Request with Reject Normal distribution Travel
Details Mean= 5 Advisor
Std D = 1
Verify Control Sheet Normal distribution Travel
Mean= 5 Advisor
Std D = 1
Visa Application 15mins Travel
Advisor
Process & Issue Visa Random Embassy
0, 3hrs, 6hrs, 1 day, (external)
2days
3days,4days, ?days,
10days
Provide Sanction letter to Bank 10 mins Forex Desk
Verify & Issue Forex Random Bank
30mins, 1 hr, 1.5hrs,
2hrs
2.5hrs, 3hrs, 3.5hrs,
4hrs
Collect Forex Normal distribution Traveller
Mean= 15
Std D = 2
Collect Visa & Travel Normal distribution Traveller
Mean= 15
Std D = 2
Table 6.8: Activity related parameters
Decision Points Yes (
0
/o) No (
0
/o)
Does PL approve the request 80 20
Does BM approve the request 98 2
Does traveller has outstanding 20 80
settlement
Is it an overseas travel 20 80
Is it an urgent travel request 10 90
Table 6.9: Decision parameters
Activity 2: Simulate and Analyse the As-Is process
In this section, we will apply a combination of a few analysis techniques
(process cycle analysis, resource utilization analysis, activities analysis,
bottleneck analysis and path analysis) to properly understand the As-Is
process.
We model the As-Is travel process in the WebSphere Business
Integration Modeler (WBIM), as shown in Figure 6.7a and 6.7b.
@
Having a
completed
travel
request form
. ~
,,,No
. ~
G)
BM Approval
G)
Check
Settlement
Status
L
Figure 6.7a: As-is Travel Requisition Process modelled using the WBIM- Part A
~
C")
Cb
(I)
(I)
:b.
~
~
~
(I)
~
~
~
~
::3
t=:;
:b.
~
~
~
(I)
c;;
"'
c.o
~
G)
l ~ ~ Is ll'gent ) ticket
request
G
"' Normal
Dispatch
ticket
~
Vet:'fy
control
sheet
Figure 6. 7b: As-is Travel Requisition Process modelled using the WBIM - Part B
~ @
VJ
0
\:)
C3
C")
Cb
en
en
):,
~
s::u
~
en
'?"
~
s::u
::3
~
):,
~
s::u
~
en
c;;
Results and Analysis
Normalize Data
The first few runs of the process showed that the travel request may take
as fast as few minutes to as long as 8 - 14 days with the average hovering
around 2 days. This output was very inconsistent and there existed a huge
deviation from the mean. As such, we suspected one or more of the
simulation parameters may have distorted the simulation output.
Looking carefully at the data and simulation parameters, we noticed
that the activities "Process and Issue Visa" and "Verify and Issue Forex"
have random duration and this is probably the cause for the data distortion.
As such, we decided to remove this inconsistency and excluded these two
activities from the model.
The lesson learnt here is that not all data are suitable to be modelled
in a simulation and we need to normalize the data as deemed appropriate.
After doing this, the subsequent results were more consistent and
ready for further analysis.
Process Analysis through Individual Path
Analysis of the As-Is baseline process is done by calculating and exploring
process performance while taking into account the multiple paths that
constitute the process. A path is a trace from the start to the stop activity
within the Workflow Model. A typical Workflow Model will have a number of
paths from start to finish depending on the number of decision points in the
model.
Each path differs in time, cost resources required, probability of
occurrence and exceptions. The paths can differ substantially in how they
impact the overall time and cost of a process as well as the resources
needed to perform the process. Each path has a probability of occurrence
that determines how much impact the path will have on the overall
process. One high-cost exception path can add much cost and time to a
process if its probability of occurrence is high enough. It is not uncommon
in many business processes that a "killer exception" path that occurs 5% of
the time that the process is executed may take 10 times as long to execute
and cost 5 times as much as the other paths.
There are a total of 7 different paths based on the 5 decision points
in the As-Is Travel Requisition Process. Table 6.10 shows the 7 different
paths and summarizes the results of the simulation. It shows that the cost
of processing a travel request averages $64.86, with a standard deviation
of $23.38 per request. The cycle from the time a travel request is prepared
until the process is completed averages about 21 hours 18 minutes. The
weighted averages are taken to ensure that the calculated averages are
meaningful.
Path Descriptions Distribution Average Average
# Elapsed Total
Duration Cost
1 Rejected: Request not 15.5% 1 day 57 $60.41
approved by Finance. minutes
Traveller has
outstanding settlement
2 Rejected: Request not 17.5% 35 minutes $18.75
approved by PL
3 Rejected: Request not 1.0% 1 hour 32 $38.75
approved by BM minutes
4 Success: Non-urgent, 45.5% 1 day 1 hour 16 $73.75
local travel request minutes
5 Success: Non-urgent, 13.5% 1 day 6 hours 44 $90.41
overseas request minutes
6 Success: Urgent, local 4.5% 23 hours 16 $80.75
request minutes
7 Success: Urgent, 2.5% 1 day 52 $97.41
overseas request minutes
Weighted Averages 21 hours 18 s 64.86
minutes 19.567
seconds
Table 6.10: Path analysis for the As-Is process
Most occurring path:
Although all of the paths took less than 2 days to complete, we should be
most concerned with the most occurring path (i.e. path #4 in Table 6.1 0) if
it deviates too much from the weighted average or costing too much.
Looking at the values, it is not seriously alarming as it is quite near to the
weighted duration and cost averages. However, we should focus on
maximizing benefit for the most occurring path while at least maintaining
others constant. Later, we will see how this situation can be improved.
Rejected travel requests:
Table 6.10 also indicates that the paths #1, #2, and #3 are paths that
resulted in rejection of the travel requisition application, that is, travel
request rejected by project leader, business manager or the traveller has
outstanding settlement respectively. The time and resources (cost) spent
on these 3 paths are in fact overheads or wastage and should be
minimized.
Path No of occurrences Average Total Cost
out of 200 request Cost
per day
Rejected due to 31 $60.41 $1872.71
outstanding settlement
Rejected by PL 35 $18.75 $656.25
Rejected by BM 2 $38.75 $77.50
Total Cost s 2606.46
Table 6.11: Cost spent on rejected requests in the As-Is process
From Table 6.11, just looking at the cost alone, $2606 is lost each day to
process travel requests that are rejected. This could easily accumulate to
more than $600,000 in less than a year's time. This should be something
that GSPL should be concerned with.
Bottleneck Analysis:
A bottleneck is a stage in a business process that causes the entire
process to slow down or stop.
In order to identify where the bottleneck in the process is, we could
look at the queue at each activity. If there is a large queue that builds up at
an activity, then most likely there is a bottleneck at that activity. In the tool
that we used, there is no report on the queue that is formed at a particular
activity. However, there is an activity duration report showing the average
delays at each activity. We have picked out the activities that have high
delays for further analysis. This data is shown in Table 6.12.
Activity Name Average Delay Resource
Duration Required
Assign request to Agents for processing 44 minutes Travel Advisor
Check Settlement Status 37 minutes Financial
Advisor
Normal Dispatch ticket 3 hours 12 Dispatch
minutes Personnel
Provide Sanction Letter to Bank 31 minutes Financial
Advisor
Update travel request with ticket details 48 minutes Travel Advisor
Verify Control Sheet 33 minutes Travel Advisor
Visa Application 34 minutes Visa Advisor
Table 6.12: Bottleneck activities in the As-Is process
We notice that the resources required for the most delayed activities are,
namely, Dispatch Personnel, Travel Advisor and Financial Advisor.
However, it is understandable that the "Normal dispatch ticket" activity has
high delays because this is a batch activity and each request has to wait till
the next dispatch time before the request could be sent out to the Agents.
Therefore, the real bottleneck of the process lies with the activities handled
by the Travel Advisor and Financial Advisor.
Let's look at the resource allocation to confirm this. Table 6.13 shows
the delay for each of the resources when the resource is being requested
for.
Resource Weighted Average Shortage Duration
Finance-1 9 minutes 59.693 seconds
Travel-1 24 minutes 53.895 seconds
Table 6.13: Resources that contribute to the bottleneck activities
With this, we confirm that the activities in Table 6.12 and the resources
involved in performing these activities form the bottleneck in the GSPL As-
Is process.
Conclusion tor the As-Is analysis:
With the above analysis, we now have a better understanding of the
problem with the As-Is process. At this juncture, we double-check against
the performance targets set earlier to ensure that the performance targets
are set according to the problem areas identified in the As-Is process.
With that, we now proceed to redesign the As-Is process to derive the To-
Be process.
Activity 3: Simulate and Analyse the To-Be process alternatives
In this activity, we will apply the Dynamic Analysis techniques to
understand the To-Be process alternatives.
Based on the performance targets set and the results of the Static
Analysis and Dynamic Analysis of the As-Is process, we approached the
stakeholders of GSPL again in attempt to further fine-tune our
recommendations. From this session, the following redesign initiatives that
may be suitable for the Travel Requisition Process have been identified:
Initiative 1 :
Introduction of a new IT system to automate the Travel Requisition
Process
Rationale:
Paper-based system was one of the major root causes for the issues.
To automate business process through the use of information
technology was one of the binding management decisions. Moreover,
the bottleneck of the As-Is process now lies in the activities in the
financial department and travel desk that are labour intensive.
Introduction of a new IT system would provide the employees of GSPL
with online travel requisition form, field validations and online
submission capabilities; it could also provide automatic routing of
approval to required parties such as project leaders and business
managers, checking of settlement status of the travel requests and
generation of sanction letter to bank if it is an overseas request.
We plan to automate or eliminate the following manual Activities in the
To-Be process:
Bring Form to Project Leader (Eliminate)
Bring Form to Business Manager (Eliminate)
Take Travel Request To Travel Desk (Eliminate)
Check Settlement Status (Automate)
Update Travel Request with Reject Details (Automate)
Provide Sanction letter to Bank (Automate partially by generating
sanction letter)
Verify Control Sheet (Eliminate)
Dispatch form (Automate)
Dispatch tickets (automate partially withe-tickets)
This is inline with the performance target set for redesign.
Initiative 2:
Enterprise Integration with backend applications
Rationale:
Integration will provide an opportunity for effectively reusing existing
systems.
Provide a way to integrate with and retrieve information from backend
ERP system to facilitate automatic checking of settlement status. With
automatic checking of settlement status, we can begin the process with
ensuring that the traveller does not have outstanding settlement. By
shifting this activity, naturally, we would save the PL and BM approval
efforts since traditionally 20% of the travellers would have outstanding
settlement from their previous travels.
Initiative 3:
Sharing of electronic information between partners
Rationale:
One of the bottlenecks is with the batch dispatch, making it
unproductive and unable to handle urgent requests.
Travel requests could be sent to travel agents via electronic means
such as email or auto-fax. In addition, we suggest the use of e-tickets
whenever possible. It is estimated that only about 50% of the travel will
not be able to usee-tickets facility as the traveller is travelling on train or
bus within India or an airline that does not have e-ticket facilities. For
those travel requests that involve normal paper tickets, standard
dispatch (normal batch dispatch and urgent dispatch) mechanism is
available.
Initiative 4:
Streamline approval process
Rationale:
Approval process takes up much overhead from the project leaders and
business manager.
There are a few schools of thought regarding this. One school of
thought feels the current way of approval is the best way and the project
leaders often filter out the unnecessary travel leaving only about 2% of
the request that the business manager may disagree on; another school
of thought suggests that approvals could be routed to both PL and BM
simultaneously; the final school of thought is that BM should not be
swamped with every travel request for approval and should only be
concerned with the expensive travel requests above US$2000.
Initiative 5:
Outsource the work of dispatch department to external courier company
Rationale:
With email, auto-fax to agent and use of e-tickets, the need to dispatch
forms and tickets is severely cut down.
There is a courier company that charges $5 per request to dispatch the
tickets through normal batch dispatch twice a day at 0930 AM and 0430
PM; the company charges $12 per request to dispatch the tickets at any
time during office hours if it is an urgent request. It may be more
sensible to redeploy the 3 resources currently in dispatch department to
other roles and outsource the dispatch work to the courier company.
The key features of the To-Be process are the use of electronic request
forms coupled with a comprehensive routing system that covers all aspects
of the Travel Requisition Process. We will verify these redesign initiatives
through dynamic simulation and analysis.
Identification of the "what-if" scenarios
Based on the above initiatives, the following "what-if' scenarios are defined
to identify To-Be alternatives, as shown in Table 6.14.
No Scenario Rationale
1 Begin the travel Comparing the three probabilities, it is noted
process with that the outstanding settlement check activity
checking of has a 20/o chance of rejection; while the PL
settlement status, and BM approval activity has 20% and 2%
followed by PL's and rejection rate respectively (see Table 6.9). With
BM's approvals the new initiative, checking of outstanding
(sequentially) settlement would no longer be resource-
intensive.
No Scenario Rationale
By shifting the settlement check as the first
activity, we would not waste the PL's and BM's
approval efforts that incur unnecessary costs
and time.
2 Check settlement This would attempt to test whether combining
status then rearrangement of activities together with
concurrently send to concurrency would reap benefits by having a
PL and BM for balance between time gains from concurrency
approval and cost savings from sequential processing.
3 Check settlement To determine whether the implementation of
status then check if such a policy would yield time and cost
the request is > benefits.
$2000. If yes, both
PL's & BM's
approvals are
required. If no, only
PL's approval is
required.
Table 6.14: Various "what-if' scenarios for the To-Be process
Note:
Scenario #3 requires change of company policy regarding travel approval.
Figures 6.8, 6.9 and 6.10 show the diagrammatic representation of the
three scenarios in Websphere Business Integration Modeller.
Scenario #1
@-=-.-.!
Receiv
completed
request f orm
~
Check
Settlement
status
l>-D-
Figure 6.8a: To-Be Travel Requisition Process Scenario 1 modelled using the WBIM - Part A
~
C")
Cb
(I)
(I)
:b.
~
~
~
(I)
~
~
~
~
::3
t=:;
:b.
~
~
~
(I)
c;;
VJ
c.o
!
vo--1
ROLte

travel desk
Ao.tanotk
l.l)datereject
detals

G
l.\ldatetravel

ticbt detois
[>-D---@
Figure 6.8b: To-Be Travel Requisition Process Scenario 1 modelled using the WBIM - Part B
.j::>.
0
\:)
C3
C")
Cb
en
en
):,

s::u

en
'?"

s::u
::3

):,

s::u

en
c;;
Scenario #2
@ ~
Receive
completed
request form
~
Check
Settlement
status
~
~
l>V
76.4% PL approve, BM approve
Figure 6.9a: To-Be Travel Requisition Process Scenario 2 modelled using the WBIM - Part A
~
C")
Cb
(I)
(I)
:b.
~
~
~
(I)
~
~
~
~
::3
t=:;
:b.
~
~
~
(I)
c;;
.j::>.
....>.
t>

Jprove
i
eject
app-ove

requestwlh
licketdet41s
Figure 6.9b: To-Be Travel Requisition Process Scenario 2 modelled using the WBIM - Part B
[>-D--@
.j::>.
1\.)
\:)
C3
C")
Cb
en
en
):,

s::u

en
'?"

s::u
::3

):,

s::u

en
c;;
Scenario #3
@ _ ~
{i}
Receive
completed
request form
~
G)
PL Approval
~
{$
Check
Settlement
Status
50.0% No
~
~ ~ ~
~
~
~ ~
Figure 6.1 Oa: To-Be Travel Requisition Process Scenario 3 modelled using the WBIM- Part A
~
C")
Cb
(I)
(I)
:b.
~
~
~
(I)
~
~
~
~
::3
t=:;
:b.
~
~
~
(I)
c;;
.j::>.
w

{i
Automatic
update reject
detais
RDW
r ~ t
travel desk
[)-D---8
Figure 6.1 Ob: To-Be Travel Requisition Process Scenario 3 modelled using the WBIM - Part B
.j::>.
.j::>.
\:)
C3
C")
Cb
en
en
):,
~
s::u
~
en
'?"
~
s::u
::3
~
):,
~
s::u
~
en
c;;
Estimations and Assumptions for the To-Be process
Assuming if we applied the various redesign initiatives and the process is
almost fully automated, Table 6.15 shows the estimates for the activities in
the To-Be model (only changes from As-Is model are listed here).
Activity Name Duration (min. if Role Cost
not specified) Resource
Check Settlement Normal distribution Not
Status Mean= 0.5 Applicable
Std D = 0.2
Route Request to Normal distribution Not
Travel Desk Mean= 0.5 Applicable
Std D = 0.2
Assign Request to Normal distribution Travel
Agents Mean= 6 Advisor
Std D = 1
Update Travel Request Normal distribution Travel
with Reject Details Mean= 0.25 Advisor
Std D = 0.08
Generate Sanction 30 seconds Not
letter Applicable
Email e-tickets 30 seconds Agent
Dispatch Ticket Normal distribution Not US$12 per
(Urgent) Mean= 20 Applicable request
Std D = 5 (outsource)
Dispatch Ticket Normal distribution Not US$5 per
(Normal) Mean= 20 Applicable request
Std D = 5 (outsource)
Table 6.15: Activity related parameters for the To-Be process
Note:
To be prudent, the time taken for some of the activities such as PL's
approval and BM's approval are kept the same although in reality, it is
likely to cut down the time required for the resources to perform the activity
when an online form is used instead of paper-based form.
Results from the various scenarios
There are now up to 15 cases (i.e. 15 unique paths through the process) in the redesigned process. The path
analysis for the various To-Be process alternatives are shown in Table 6.16.
Path Description Scenario #1 Scenario #2 Scenario #3
#
% Average Average % Average Average Description % Average Average
Elapsed Total Elapsed Total Elapsed Total
Duration Cost Duration Cost Duration Cost
1 Rejected: 20 1 minute $0.00 20.5 1 minute $0.00 Rejected: 20.5 1 minute $0.00
Traveller has Traveller has
outstanding outstanding
settlement settlement
2 Rejected: 14.5 22 $18.75 15 2 hours $38.75 Rejected: 14.5 23 $18.75
Request not minutes 34 Request not minutes
approved by minutes approved by
PL PL
3 Rejected: 1 1 hour $38.75 Rejected: 1 53 $38.75
Request not 34 Request not minutes
BM BM
4 Success: Non- 31 9 hours $52.80 31 12 hours $52.80 Success: 18 7 hours $32.08
urgent, local 18 22 <=$2K, local , 49
travel request minutes minutes non-urgent minutes
request
5 Success: 13.5 11 hours $52.08
>$2k, local , 26
non-urgent minutes
request
.j::>.
(j)
\:)
C3
C")
Cb
en
en
):,

s::u

en
'?"

s::u
::3

):,

s::u

en
c;;
6 Success: Non- 5.5 10 hour $56.25 5 17 hour
urgent, 44 26
overseas minutes minutes
request
7
8 Success: 2 6 hours $59.08 2.5 10 hours
Urgent, local 59 36
request minutes minutes
9
10 Success: 1.5 10 hours $68.75 1 18 hours
Urgent, 27 23
overseas minutes minutes
request
11
12 Success: 7.5 11 hours $59.58 8.5 15 hours
Overseas, e- 23 6
ticket minutes minutes
13
$56.25 Success: 3
<=$2k,
overseas. Non-
urgent
Success: 2.5
>$2k,
overseas, non-
urgent request
$59.08 Success: 1
<=$2k, local ,
urgent request
Success: 1
>$2k, local ,
urgent
$68.75 Success: 0.5
<=$2k,
overseas,
urgent
Success: 0.5
>$2k,
overseas,
urgent
$59.58 Success: 1
>$2K,
overseas, e-
ticket
Success: 6.5
<=$2K,
overseas, e-
ticket
8 hours
37
minutes
14 hours
8
minutes
2 hours
42
minutes
10 hours
35
mi nutes
1 hour
43
minutes
8 hour
16
minutes
9 hours
53
minutes
5 hours
8
minutes
$44.58
$64.58
$39.08
$59.07
$51.58
$71.58
$59.58
$39.58
~
C")
Cb
(I)
(I)
:b.
~
~
~
(I)
~
~
~
~
::3
t=:;
:b.
~
~
~
(I)
c;;
.j::>.
"'-I
14 Success: 17 12 hours $47.08 16.5 13 hours $47.08 Success: 8.5 10 hours $47.08
Local , e-ticket 8 33 >$2k, local , e- 8
minutes minutes ticket minutes
15 Success: 8 9 hours $27.08
<=$2k, local , 40
e-ticket minutes
Table 6.16: Results from what-if analysis of the To-Be Process
From Table 6.16, it is obvious that Scenario #3 is significantly better compared to any other scenarios.
Scenario #2 is the worst performing and in fact may not be logical to expose the business manager to all the
travel requests instead of only those that has been approved by the project leaders. Scenario #1 is not as well
performing as scenario #3. Therefore, we will use scenario #3 for further analysis and comparison against the
As-Is process.
With reference to Table 6.10 and 6.16, a comparison table (Table 6.17) is developed to compare
between the As-Is process and To-Be process Scenario #3.
.j::>.
co
\:)
C3
C")
Cb
en
en
):,

s::u

en
'?"

s::u
::3

):,

s::u

en
c;;
Comparison of As-Is and Scenario #3
Path Description As-Is Scenario #3
#
% Average Average Description
Elapsed Total
Duration Cost
1 Rejected: 15.5 1 day 57 $60.41 Rejected:
Traveller has minutes Traveller has
outstanding outstanding
settlement settlement
2 Rejected: 17.5 35 $18.75 Rejected:
Request not minutes Request not
approved by approved by
PL PL
3 Rejected: 1.0 1 hour $38.75 Rejected:
Request not 32 Request not
BM BM
4a Success: 45.5 1 day 1 $73.75 Success:
Non-urgent, hour16 <=$2K, local ,
local travel minutes non-urgent
request request
4b Success:
>$2k, local,
non-urgent
request
% Average Average
Elapsed Total
Duration Cost
20.5 1 minute $0.00
14.5 23 $18.75
minutes
1 53 $38.75
minutes
18 7 hours $32.08
49
minutes
13.5 11 hours $52.08
26
minutes
Comparisons
%
Improvement
over As-Is
(duration)
Near to 100%
34.3%
42.4%
69.1%
54.7%
%
Improvement
over As-Is
(cost)
100%
0%
0%
56.5%
29.4%
~
C')
Cb
(I)
(I)
:b.
~
~
~
(I)
~
~
~
~
::3
t=:;
:b.
~
~
~
(I)
Ci)
.j::>.
c.o
5a Success: 13.5 1 day 6 $90.41 Success:
Non-urgent, hours 44 <=$2k,
overseas minutes overseas.
request Non-urgent
5b Success:
>$2k,
overseas,
non-urgent
request
6a Success: 4.5 23 hours $80.75 Success:
Urgent, local 16 <=$2k, local ,
request minutes urgent
request
6b Success:
>$2k, local ,
urgent
?a Success: 2.5 1 day 52 $97.41 Success:
Urgent, minutes <=$2k,
overseas overseas,
request urgent
7b Success:
>$2k,
overseas,
urgent
3 8 hours
37
minutes
2.5 14 hours
8
minutes
1 2 hours
42
minutes
1 10 hours
35
minutes
0.5 1 hour
43
minutes
0.5 8 hour
16
minutes
$44.58 80.0% 50.7%
$64.58 54.0% 28.6%
$39.08 88.4% 51 .6%
$59.07 54.51% 26.8%
$51.58 93.1% 47.0%
$71.58 66.8% 26.5%
CJ1
0
\:)
C3
C")
Cb
en
en
):,

s::u

en
'?"

s::u
::3

):,

s::u

en
c;;
8a Success: N/A N/A N/A Success: 1 9 hours $59.58 There is no direct comparison
Overseas, e- >$2K, 53 between Scenario #3 and the
ticket overseas, e- minutes As-Is process. However, we
ticket notice that the performance
8b Success: 6.5 5 hours $39.58 for all the e-ticket paths
<=$2K, 8 certainly take less duration
overseas, e- minutes and cost compared to any of
ticket the success paths in the As-Is
9a Success: N/A N/A N/A Success: 8.5 10 hours $47.08 process. This is an obvious
Local, e-ticket >$2k, local, 8 improvement.
e-ticket minutes
9b Success: 8 9 hours $27.08
<=$2k, local , 40
e-ticket minutes
Table 6.17: Comparison of As-Is process and To-Be process scenario #3
From Table 6.17, we can see that the To-Be process Scenario #3 has significant improvements over the As-Is
process in terms of duration as well as cost.
There is improvement over every path of the process. The results for each path in Scenario #3 satisfy
the performance targets set out for improving efficiency and cost reduction.
In addition, the maximum elapsed time for Scenario #3 is only 11.5 hours, which means all travel
requests can be completed within a day or the next.
~
C")
Cb
(I)
(I)
:b.
~
~
~
(I)
~
~
~
~
::3
t=:;
:b.
~
~
~
(I)
Ci)
CJ1
....>.
Now we further analyse Scenario #3.
Most occurring path:
With reference to Table 6.17, the most occurring path is #4 (4a and 4b).
It has an improvement of 69.1% and 56.5% in duration and cost
respectively for travel requests less than or equal to US$2000 and 54.7%
and 29.4% in duration and cost respectively for travel requests amounting
to more than US$2000.
The next most occurring path is the travel requests resulting in the
use of e-tickets (total of 24% in distribution). The different variation of e-
tickets paths have significant improvement over any of the success cases
in the As-Is process. Although there is no direct comparison between this
path with the As-Is process, it is obvious from the figures that there is
significant improvement.
Rejected travel requests:
Table 6.18 shows the comparison of costs between the As-Is and To-Be
process Scenario #3 for the rejected travel application paths.
Path As-is process To-be process (scenario 3) Difference
No of Avg Total Cost No of Avg Total
occur- Cost occur- Cost Cost
rences rences
out of out of
200 200
request request
per day per day
Rejected 31 $60.41 $1872.71 41 $0.00 $0.00
due to
outstanding
settlement
Rejected 35 $18.75 $656.25 29 $18.75 $543.75
by PL
Rejected 2 $38.75 $77.5 2 $38.75 $77.50
by BM
Total Cost s 2606.46 s 621.25 s 1985.25
Table 6.18: Comparison of cost spent on rejected requests
From Table 6.18, if Scenario #3 is to be implemented, there is a potential
savings of $1985 everyday just based on the rejected requests alone.
Based on 20 working days a month, it is a savings of around half a million
in a year's time. In addition, as mentioned earlier, for the purpose of being
prudent, the resource time required by PL and BM to approve has not been
reduced for the simulation of Scenario #3. It is likely that they would have
taken a shorter time as paper-based problems such as illegible handwriting
would have been eliminated. It is also possible that the number of rejected
cases could reduce with an online system as checks can be made to
ensure that valid data (e.g. airport code) is input into the request form.
Bottleneck Analysis:
Table 6.19 shows the comparison of the activities which cause the
bottlenecks in As-Is process and improvements achieved in the To-Be
process Scenario #3.
Activity Name Average Average Resource Improvement
Delay Delay over As-is
Duration Duration process
(As-Is) (To-Be)
Assign request to 44 minutes 28 minutes Travel 36% improvement
Agents for processing Advisor
Check Settlement 37 minutes 0 seconds - Bottleneck totally
Status removed
Normal Dispatch ticket 3 hours 3 hours Dispatch Slight or no
12 minutes 9 minutes Personnel improvement
Generate Sanction 31 minutes 0 seconds - Bottleneck totally
Letter removed
Update travel request 48 minutes 27 minutes Travel 44% improvement
with ticket details Advisor
Verify Control Sheet 33 minutes 0 minutes Travel Bottleneck totally
Advisor removed
Visa Application 34 minutes 9 minutes Travel 74% improvement
Advisor
Table 6.19: Comparison of bottleneck activities
From Table 6.19, it is clear that many of the bottlenecks have been
improved or totally eliminated. Only one activity resulted in no
improvement, that is, 'Normal Dispatch Ticket'. As in the analysis for As-Is
process, it is understandable that the non-urgent dispatch of ticket may
have high delays because it is a batch activity. As such, we are not
concerned by the bad performance for this activity since the percentage of
request that requires dispatch of ticket would be considerably reduced
through the introduction of e-tickets.
With reference to Table 6.20, looking at the resource shortage, there
has been good improvement. The financial advisors are totally freed up
from the travel process and hence can be better utilized in their core
functions. The travel desk is still slightly short of resources. However, 10
minutes is probably an acceptable waiting period. If GSPL would like to
improve this further, it can consider adding one more resource in the travel
desk.
Resource Weighted Average Shortage Improvement over As-is
Duration Process
Finance-1 No longer required in the To-Be Resource totally freed up.
process
process
process
Travel-1 1 0 minutes 0. 77 4 second 58% improvement
Travel-2 10 minutes 12.852 seconds 67% improvement
Travel-3 10 minutes 55.512 seconds 60% improvement
Travel-4 9 minutes 22.463 seconds N.A. (Resource originally from
Visa Desk)
Table 6.20: Comparison of resources contributing to bottleneck activities
We feel that this is inline with the performance target on removing
bottlenecks. Most bottlenecks are either totally removed or significantly
reduced.
Evaluate cost tor outsourcing dispatch to Courier Company:
In this section, we evaluate the savings from outsourcing the dispatch to an
external Courier Company.
Cost of resource I No of resource No of hours of work Cost (US$)
hour (US$) per day
25 3 8 600
Table 6.21: Cost of hiring 3 resources in the dispatch department
Type of dispatch service No of Cost per Total Cost (US$)
used occurrences out request (US$)
of 200 request
per day
Normal dispatch 74 5 370
Urgent dispatch 6 12 72
Total 442
Table 6.22: Cost of using services from a courier company
Examining Tables 6.21 and 6.22, it is evident that there are cost savings
when using a Courier Company. Although it is only around $160 day, it
could amount near to $40,000 a year. We would recommend outsourcing
this activity as it is not part of the core business of GSPL. However, GSPL
should take into consideration moral issues regarding whether these
resources are to be redeployed or made redundant and reliability of the
Courier Company before taking a final decision on this matter.
Conclusion tor the To-Be Analysis
Based on the analysis, we conclude that Scenario #3 is the most efficient
and effective process to implement for GSPL. It helps to meet the
performance targets set in Phase 2 and addresses some of the issues
identified during the As-Is analysis.
Phase 3: Impact Analysis for To-Be
One of the decisions which would have an effect on all the stakeholders in
GSPL irrespective of the chosen scenario is the elimination of paper forms
with the aid of an online travel requisition system. All paper-based travel
forms will be in electronic format. This would enable (1) a shared view of
the travel request that is common to all departments and individuals, (2)
the creation of a self-service travel portal for employees, thereby
addressing the root causes of department coordination and manpower
shortages respectively, (3) reduction in errors in entering the travel
information and (4) automatic routing and processing of travel requests
within the organization and across to the business partners such as travel
agents.
GSPL Internal Organization
With implementation of the new process, there is certainly impact on the
organization. The impact could be organizational wide or specific to the
individual departments. Some of these impacts to GSPL are summarized
in Table 6.23
Organizational wide:
Description Impact
Retrain Medium
With the new process, there is a need to retrain the employees
of GSPL to use the online system to raise travel requests, to
approve them, to view and update status and to assign the
request to travel agents. There may be a need to retrain them
on the knowledge of using information technology.
Change of policy
The proposed To-Be process requires a slight change in
policy. Now, not all the requests require approval from
business manager. Instead, only the requests above US$2000
require approval from the business manager. This however,
still conforms to the binding management decision for the
redesign (Phase 1 ).
Potential change of IT architecture tor the organization
Implementation of new process and the information
technologies that support the new process may potentially
result in changes to the overall IT architecture for GSPL. This
is because there is a need to introduce new system (and
potentially new technologies) and change the existing systems
(e.g. the ERP system).
Departmental specific:
Description
Impact on IT department
In the case of GSPL, the departmental specific changes are
likely to be resource related. GSPL IT department maybe
required to acquire new skills or add in more resources in
order to carry out the change.
Impact on Accounts department and Forex desk
The account department and Forex desk gained positive
impact from the change as many manual activities are
eliminated and consequently their time is freed up to perform
core activities resulting in higher efficiently.
Impact on Travel desk
The travel desk gained positive impact from the change as well
due to elimination of manual activity.
Resource in Visa Desk is merged into Travel Desk. This
resource has to be retrained to perform work of Travel Desk
and vice versa.
Impact on Dispatch Department (it outsourcing is used)
Resources in dispatch department have to be redeployed to
other parts of the organization or made redundant. This may
affect the morale of the employees.
Low
High
Impact
Medium
Low
Medium
High
Table 6.23: Impact analysis for the internal organization (GSPL)
GSPL Business Partners
The two external parties that would be affected by changes in the travel
requisition process would probably be the travel agents and banks. Table
6.24 summarizes the impacts on the GSPL business partners.
Business Partner
Description Impact
Impact on Travel Agents Low
All travel agents who deal with GSPL must be informed of the
new form layout and that it can be received through automatic
email or fax. This is not real-time integration with the agents
and hence has a very low impact.
Impact on Banks Medium
The banks who deal with GSPL must be informed about the
new sanction letter to be able to accept the generated sanction
letter for foreign exchange issue.
Table 6.24: Impact analysis for GSPL's external partners
Phase 4: Selection of the To-Be process
From the impact analysis, it is clear that there is no real show stopper to
deter GSPL from implementing the new process. As such, we can safely
conclude that the To-Be process Scenario #3 (referred to as To-Be travel
process subsequently) is selected as the To-Be process. The following
steps describe the proposed To-Be process. The proposed system would
also be referred to as e-Travel System (ETS} in the subsequent case
study.
1. Traveller to raise a travel request through use of an online system, e-
Travel System (ETS}.
2. Upon submission of the travel request, ETS checks the settlement
status against the ERP system (i.e. Enterprise System).
3. If the traveller has outstanding settlement, the request is rejected.
Otherwise, ETS routes the request to relevant parties in the
workflow. Only requests that are > $2000 requires second level
approval.
4. Upon approval, request is routed to Travel Desk for review and to be
assigned to a Travel Agent.
5. ETS will email or auto-fax the request to the Travel Agent.
6. Next, ETS checks if the request involves overseas travel. If yes, it
generates a sanction letter which the Traveller can print out.
7. The process now awaits completion of ticket purchase by the Travel
Agent.
8. When the Travel Agent has completed the ticket purchase, the Travel
Agent
a. updates the Travel Desk with the ticket details and
b. dispatches the ticket either through email (if e-ticket is used) or
by handing to the courier company employed by GSPL
9. Upon receiving ticket details, the Travel Desk enters the ticket
information into ETS.
For a complete view of what the To-Be travel process would be, To-Be
business process models are developed. These models are as shown in
Figures 6.11, 6.12, 6.13, 6.14 and 6.15a, 6.15b and 6.15c show the
Organization, Location, Collaboration, Process Catalogue and Workflow
Model respectively. Table 6.25 shows an example of the Business Rules
Model for one activity.
~
GSPL
t
d ' ~
d ' ~
Travel Desk
All
(New)
Employees
t
t
d ' ~ ~ ~
~ ~ Q
Vi sa Desk Travel
Business PL Traveller
Desk Manager
~
External
Parties
t
d ' ~ ~ ~ d ' ~ ~ &
Embassies Bank Travel Courier
Agent Companies
Figure 6.11: To-Be Organization Model
World
All Travel Desk
Employees (New)
Figure 6.12: To-Be Location Model
l';m;'
I
External
I
I e-Tickets
Visa
II
...
Ti ckets
~
Request Form
~ ~
Traveler
Proposed
Ti cketing & billing
~
Ticketing & billing
Travel
details
System
. quJst
aeta11s
Agents
Request Farm
TraveiDesk
Travel r
Sanction Letter del ils
[IF
L
ickets
~
~
Business
~
Settl men! Status
Manager
Courier
~
Ti ckets
Companies
r--
Approval
ERP
I
I
Settlement ~
!.li sa Aoolication Form Q
verifi cation
I I Embassies
done by
Visa
system
~
F ore1gn c urrencies
I I
Bank
I
I
Sanction Letter
1'
I
Figure 6.13: To-Be Collaboration Model
rm"
External
L
e-Ti ckets I
Visa
I

I I
Tickets
..,
Request Form '.!i:!

Traveler
Ploposaa
Ticketing & billing

Ti c KeUng & billing
Travel
details
System ae a1 s
Agents
Request Form
Tra-.eiDesk
Travel request
Sanction Letter
Tic ket Rec uisitic Jn f'rbcess

l
ickets
r---r

Business
-----..
sen: memStaws
Manager
I
Courier
H

Tickets Companle
.._ Annm""l ERP
I I
I
I
\li.c.::a .R t:ln 1 (

''""m'"' l
i ..... Jl
verifi cabon
done by
Embassies
Visa
I
system
I
I
I
i
j
ore1gn c..;urrenc1es
Bank
r-. .r"'>.;
n, ,
f
- _,, '-'1-
.
Figure 6.14: To-Be Process Catalogue Model
Tr..,.eler
0
e-Travel
System
(ETS)
S2
PL
0
Business
Manager
_i_
Tr..,.eiOesk

Travel
Agents
0
'
f EnteriUpdate tr..,.el details In)
l the form and submit 1
_[
I
(Approve or rejecl
l rn proposed system
4
)
No
Yes
Roule lnformallon
to Travel Desk
'" ,J .
aM Approved
l
Approve or reject request
In proposed syslem 1-------------------'
5
Assign !ravel request
to tr..,.el agents
8
No
Collect tickets an
Visa or reqd) 17
ll
Obtain Forex u I
Subprocess
10
L-
Ye!

kf
Process travel
Email traveller to
col lectVisafTicket If
required
16
J No
Figure 6.15a: To-Be Workflow Model

C")
Cb
(I)
(I)
:b.

(I)

::3
t=:;
:b.

(I)
c;;
(j)
....>.
Bank
e-Travel
System
(ETS)
Traveler
Process and Issue Forex
1
.,
1
Generate Sanction
Letter 2
Bri ng sanction letter to bank
Figure 6.15b: To-Be Obtain Forex Workflow Model
raveiDesk
Visa Application
2
Embassies
Process & Issue Visa
Figure 6.15c: To-Be Obtain Visa Workflow Model
(j)
1\.)
\:)
C3
C")
Cb
en
en
):,

s::u

en
'?"

s::u
::3

):,

s::u

en
c;;
Name Check Settlement Status
Activity Using Check Settlement Status
this Rule Set
Description This rule set checks if the traveller has outstanding
settlement before allowing him or her to travel again.
Rule Set ETS to query ERP system IF ERP system return
for settlement status of 'false'
traveller. THEN settlement status is
bad
IF ERP system return 'true'
THEN settlement status is
good
Related Rule None
Set
Table 6.25: Example To-Be Business Rules Model
CHAPTER 7
IT SOLUTION REQUIREMENTS DEFINITION
Chapter Topic List
1. Overview
2. Functional Requirements Definition
3. Non-Functional Requirements Definition
4. Conclusion of the Business Modelling Phase
References
Case Study - IT Solution Requirements Definition for the GSPL Travel
Requisition Process
Learning Objectives
Map out solution functionality from To-Be Modelling and To-Be Process
Analysis activities
Define non-functional requirements for the IT Solution
IT Solution Requirements Definition 165
IT SOLUTION REQUIREMENTS DEFINITION
1. Overview
The IT Solution Requirements Definition activity helps in mapping and
detailing the functional and non-functional requirements of an IT solution.
Use Cases are used to represent the identified functional requirements
[Bittner200]. The Use Cases are the end output of the Business Modelling
phase and in turn, are input to the Concept Solution Blueprinting phase.
Output from
To-Be Modelling
And
To-Be Process Analysis
Functional
Requirements Definition
Non-Functional
Requirements Definition
Figure 7.1: IT Solution Requirements Definition Steps
The IT Solution Requirements Definition involves two steps as shown in
Figure 7.1, namely, Functional Requirements Definition and Non-
Functional Requirements Definition. The To-Be models such as Workflow
Model, Collaboration Model and the To-Be Dynamic Analysis reports may
provide the necessary input for the IT Solution Requirements Definition
activity. The following sections describe each step.
2. Functional Requirements Definition
Use Case
A Use Case is a task, performed by an Actor (human or IT system) that
has some useful outcome. It is used to specify the functionality of an IT
solution.
Figure 7.2 shows some example Use Cases represented
diagrammatically. In Industry, UML [Pilone2005] is used as a standard
166 IT Solution Requirements Definition
when documenting Use Cases. Each Use Case is denoted by an oval-
shaped bubble. In Figure 7.2, two Use Cases are shown. In the first Use
Case, the Actor is the Customer and the functional requirement is that the
Customer must be able to "Enter a New Order". Similarly, in the second
Use Case, the Actors are the Finance Clerk and Finance Manager and the
functional requirement is that both these Actors must be able to "Enter
Billing Information".
Customer
~
Finance Manager
Enter a New
Order
Enter Billing
Information
Figure 7.2: Example Use Cases
Defining Functions
The definition of the functions is achieved in two steps.
Step 1: Use Cases are identified from the Workflow Model
Step 2: Use Cases are grouped into functions
Step 1: Identifying Use Cases
In the context of a business process, the Use Cases can be identified from
the Workflow Model. Each activity in a Workflow Model is a potential
candidate for a Use Case if it adheres to the following rules:
The activity is either automated or interactive
The scope of the activity is such that, on its execution, it brings the
system back into a state when that activity can be performed again. For
example, if the Customer Service Representative (CSR) performs the
Use Case "Amend Order", after having amended one order, the system
must revert to the state so that the CSR can amend another order
Following these rules, the Use Cases can be identified from the Workflow
Model, as shown in Figure 7.3. The Roles from the Workflow Model map to
the Actors for the Use Case, the Activity maps to the functional
requirement.
--- --.---
1
I
I
I
I
I
I
I
[ ____ . ~
Actor A
Figure 7.3 Identifying Use Cases from the Workflow Model
It is possible that a single activity cannot be mapped directly to a Use
Case. In such instances, two or more activities can be combined into one
Use Case. Usually, an interactive activity and the following automated
activity that is triggered by it are mapped into a single Use Case.
It is also possible that an individual activity can be broken down into
further smaller activities that individually or in some combination adhere to
the rules presented earlier. In such instances, more than one Use Case
can be created for that activity.
If sub-processes are present in the Workflow Model, then these sub-
processes have to be further expanded into activities and Use Cases are
to be derived from these activities.
Additionally, it must be noted that in some instance there will be
some Use Cases that are not directly derived from the Workflow Model.
These Use Cases have to be added to those derived from the Workflow
Model.
Once all the Use Cases are identified, they are represented in the
Use Case Model. Figure 7.4, shows an example Use Case Model derived
from the Workflow Model shown in Figure 7.3. Note that additional Use
Cases (Use Case 5 and Use Case 6) have been added in the Use Case
Model that is not derived from the Workflow Model. Along with the Use
Case Model, a brief description of the various Use Cases is also provided.
"
6
Actor A
6
"
~ 6
Actor C
e
Figure 7.4 Use Case Model
Activity 7.1
For the example Workflow Model shown in Figure 7.5, identify the Use
Cases and draw the Use Case Model.
IT Solution Requirements Definition
Customer
I e-{ Enter Order J
Details
1
Q
Web Order
...
J Send email to Shipping J Management
System
vailable?
l Officer 7
talidate
.___j
I Jl .[Notify Customer No _____,..-

!iii!
Inventory
l
System
l Check Inventory}-
Reorder
---l
Update
Availability 3 Yes Product
5 Inventory 8
!iii!
Credit
[ Credit
Supervisor
Exception )

Q
Handlmg6
f
Credit

Information
[ Verify Credit Details )
System
4 J
0
!iii!
Payment
Processing
Credit Accounts J
System Receivable
9
!iii!
Figure 7.5: Example Workflow Model
Step 2: Grouping Use Cases in Functions
"l
10

169
Once the Use Cases are identified through the Use Case Model, they are
then grouped together according to the IT functions defined by those Use
Cases. This is referred to as the Use-Case-to-Function Model. For
example, as shown in Figure 7.6, Use Case 1, Use Case 2, Use Case 3
and Use Case 6 can be grouped into one function, namely, Function A and
Use Case 4 and Use Case 5 into Function B. There is no hard and fast rule
on how to group Use Cases. One has to apply common sense and
knowledge gained by experience. This grouping has to be carefully thought
through and will usually be the result of elaborate discussion within the
team doing the requirements definition. One approach that usually works is
to group Use Cases that manipulate the same work product such as an
Order.
6:)
6:)
c:B
6:) 6:)
c:B
Function A Function B
Figure 7.6 Use-Case-to-Function Model
Activity 7.2
Develop the Use-Case-to-Function Model for Use Cases identified in
Activity 7. 1
It is important to understand that the functional requirements elicited are
still at a conceptual level that is not sufficiently detailed for implementation.
The main purpose of the functional requirements at this stage is to help in
developing a high-level design of the IT Solution. Further refinement of the
requirements is necessary before detailed design and implementation of
the IT Solution.
3. Non-Functional Requirements Definition
Use Cases do not provide sufficient details regarding non-functional
requirements. Therefore, it is necessary to ask specific questions of the
users to derive associated non-functional requirements such as response
time, throughput and usability in the context of the current Use Case.
Some examples of these questions include:
Are the actors for this use case physically working at the same location?
How many locations are there? Where are the locations?
How many concurrent users will there be at any point of time?
What are the peak usage times (of the day) or season (of a month or
year)?
What type of knowledge or experience will the users require when
interacting with the system?
How familiar will they be with the tasks they need to perform?
What is the maximum acceptable time for getting responses from the
system during the course of this use case?
What are the particular security concerns?
The BPE team works with the IT Solution Architect team who provides
guidance on defining the non-functional requirements for the IT Solution.
These requirements are then captured for various categories such as
Capacity, Security, Reliability and Scalability. Table 7.1 shows some
example non-functional requirements.
No Category Non Functional Requirements
1 Capacity The solution shall support at least 50 requests in one
hour
2 Security The solution shall be available only for employees of
the organization over Intranet
3 Reliability The solution shall be available 24x7 with at most 5%
unplanned downtime
4 Scalability The solution can be scaled to support 10000 users
without major modifications
Table 7.1 Example Non-Functional Requirements
4. Conclusion of the Business Modelling Phase
The IT Solution Requirements Definition Activity marks the completion of
the Business Modelling Phase of the Business Process Engineering
Methodology. The various models developed help in providing a better
understanding of the current problem and the high-level requirements of
the proposed IT solution. The final deliverable at the end of Business
Modelling phase is a set of Business Modelling Documents that may
include the following:
Models for the As-Is Process such as Organization, Location,
Collaboration, Process Catalogue, Workflow and RCI, Root-Cause
Recommendation Model, Recommended Solution Summary, As-Is
Dynamic Analysis Report, Proposed Initiatives Summary, To-Be Dynamic
Analysis Report, Models for the To-Be Process such as Organization,
Location, Collaboration, Process Catalogue, Workflow, Use Case Model
and Use Cases Grouping into functions. In some instances, preliminary
User-Interfaces are also developed for discussion with the Stakeholders.
However, it is important to note that not every model and report will
be required for every business scenario. In fact, the BPE team are
promoting their solution ideas to the client. Therefore, BPE team must use
their judgement and consider the current business needs and client
requirements to select appropriate models and reports to be included in the
Business Modelling Documents to effectively market their proposed
solution.
Once the client accepts the proposed solution, the BPE team then
embark on to next phase, Concept Solution Blueprinting. This phase
comprises a step-by-step approach to specify the concept solution
architecture that will satisfy the requirements of the proposed IT solution.
The activities in this phase help the IT personnel to further understand and
analyse the requirements of the proposed IT solution and then develop
appropriate high level views to represent it.
References
[Bittner2002]
Kurt Bittner and lan Spencem 2002. Use Case Modeling. Addison Wesley
Professional.
[Pilone2005]
Dan Pilone and Neil Pitman 2005. UML 2.0 in a Nutsheii.O'Reilly Media
Inc.
Case Study
IT Solution Requirements Definition for the GSPL Travel
Requisition Process
173
Upon completion of Dynamic Analysis, the BPE Team put forth the
recommendations, which GSPL accepted. Based on the To-Be Business
Models, some of the IT Solution Requirements are derived using workflow
models. The IT Solution Requirements derived from To-Be workflow model
are documented in a Use Case Model as shown below.
J._ Approve or Reject
Mana/ Requests
L Project Leader

Create Travel Traveller
Request

/ e-Travel System (ETS)

Figure 7.7 Use Case Model for the To-Be Travel Requisition Process
The Use Case Model in Figure 7.7 shows the Use Cases that are derived
from the To-Be Workflow Model as presented in Chapter 6 Case Study. In
reality, when designing a new IT Solution to support the new business
process, one has to consider the other related processes (or sub-
processes) to make the IT System design complete. For example, the
Ticket Payment Process will have to be considered when designing the IT
Solution for the Travel Requisition Process. These related processes or
sub-processes may result in additional Use Cases, e.g. Issue Payment
Voucher.
To understand the requirements further, the BPE Team obtained additional
information about the current situation as listed below:
The travellers in GSPL record their expenses in the Enterprise System
(ES), a legacy ERP application, through a proprietary user interface
provided by ES. Travellers are required to do this upon return from the
trip and before the next travel.
When the expense is approved, the expense would be settled either by
reimbursing traveller or write-off against the foreign currency that has
been issued. This is referred to as the Settlement.
When the Accounts Department need to determine the settlement
status, they print the expense records from ES and reconcile against the
foreign currency issued. This is largely manual.
The payment to Travel Agents is handled through another legacy
system, Accounting System (AS). AS also handles other payments for
GSPL for other processes such as Procure-to-Pay process. Some of the
other existing GSPL applications handle payment by utilizing
functionality in AS to issue payment voucher to the relevant vendor.
Figure 7.8 shows some of the additional Use Cases that must be
considered for the IT Solution.
Accounting System
eTS
Enterprise System
Initiate Payment
Enter Expense
Details
Figure 7.8 Additional Use Cases for the To-Be Travel Requisition Process
From the Use Case Model, we can derive the logical functions by grouping
the closely related Use Cases. Figure 7.9 shows the grouping for Travel
Requisition Process.
Approval
Expense Management

Travel Request Mgmt Payment
Communication Mgmt
Figure 7.9 Use-Case-to-Function Model for Travel Requisition Process
While defining the functional requirements for the IT Solution, the BPE
Team also worked with an IT Solution Architect to elicit the non-functional
requirements from GSPL. Table 7.2 shows an example of the output from
the non-functional requirement study.
No Category Non Functional Requirements
1 Capacity The solution shall support at least 300 requests per
day.
2 Capacity The solution shall support up to 20 concurrent users
with average response time of no more than 3
seconds per click.
3 Security The solution shall support single-sign-on using the
existing LDAP system.
4 Security The solution shall be available only for internal GSPL
users.
5 Security The solution shall support configurable access control.
6 Reliability The solution shall be available 24x7 with at most 2%
unplanned downtime.
7 Reliability The solution shall support at least RAID 1 for data
backup
176
8
9
Scalability The solution shall make provisions to keep data for at
least 7 years.
Scalability The solution shall support up to 450 requests a day in
5 years time.
Table 7.2 Example Non-Functional Requirements for the Travel
Requisition Process
Conclusion
The completion of the IT Solution Requirements Definition leads to the
completion of the Business Modelling Phase of the Business Process
Engineering Methodology. It is important to understand that the
requirements elicited from IT Solution Requirements Definition are still at
conceptual level that is not sufficiently detailed for implementation. The
main purpose of the requirements defined at the end of the IT Solution
Requirements Definition is to help arrive at a high-level design of the IT
Solution.
GSPL management can now review the proposed business models
and the associated functional and non-requirements for the new Travel
Requisition Process. If proposal is accepted, the BPE Team is then ready
to proceed to next phase of the Business Process Engineering
Methodology, Concept Solution Blueprinting.
CHAPTER 8
SOLUTION BLUEPRINT
Chapter Topic List
1. Solution Blueprint
2. Concept Solution Blueprint vs. Detailed Solution Blueprint
References
Learning Objectives
Understand the term Solution Blueprint
Understand the practice of developing a Solution Blueprint concerning
who develops it, who uses it, why it is needed, what inputs are required
to develop it, etc.
Understand the differences between Concept and Detailed Solution
Blueprints
178 Solution Blueprint
CONCEPT SOLUTION BLUEPRINT
1. Solution Blueprint
A Solution Blueprint is a set of documents containing the specification of
the various aspects of an IT Solution. It may include business processes,
applications, entity (e.g. data, business entities), user interface designs,
technologies, cost, risk assessment and project plan. These different
aspects are usually represented using various models. Each model
emphasizes certain aspects of the solution meaningful to a certain class of
stakeholder, and a combination of these different models together form the
consistent whole of the Solution.
Activity 8.1
Read the poem "The Blind Men and the Elephant",
(http://www.wordinfo.infolwordslindex/infolview unit/1/?letter=B&spage=3), by American
poet John Godfrey Saxe (1816-1887) which is based on a fable that was
told in India many years ago. Discuss how teachings in the story relate to a
Solution Blueprint.
Purpose of Solution Blueprint
In the context of an IT Project, the Solution Blueprint serves the following
purposes:
Ensuring a common understanding among the various stakeholders
Since the Solution Blueprint comprises all the artefacts that describe the
solution, it acts as a common reference for the proposed solution. It is
often used for analyzing and comparing the solutions proposed by different
IT companies. Once the end user company awards an IT company the
contract to build the IT Solution, part of the Solution Blueprint becomes the
terms of the contract between the various stakeholders involved in the IT
Project. The Solution Blueprint has different views of the solution as
appropriate to each stakeholder. Therefore, it is a good vehicle for
communication between the various stakeholders.
Saving cost and reducing project cycle time
Once the various stakeholders agree upon the Solution Blueprint, it
reduces unnecessary misunderstanding between the project delivery team
Solution Blueprint 179
and the end user organization. This will directly contribute towards savings
in design and implementation costs as well as reduce implementation cycle
time.
Input required for developing the Solution Blueprint
The functional and non-functional requirements derived from the Business
Modelling Phase form the major portion of the input required to develop the
Solution Blueprint. However, in addition to this, inputs such as Business
Goals, IT Trends, Enterprise Architecture, IT Architecture Principles,
Industry Standards and Corporate IT Standards also play a significant role
in defining the Solution Blueprint (see Figure 8.1 ).
Outputs of
Business
Modelling
Phase
;;aZ
tD 0
.c::::ll
C I
=i' ~
tD :II
3 ~
tD -
:II 0
frii
;;a
m.,
.Cic
:.:II
" " ~
tD -
3 0
tD :II
:II!.
fir
Business Goals,
IT Trends,
Enterprise Architecture,
IT Architecture Principles,
Industry Standards,
Corporate Standards, etc.
j,.
ca.
-a.
;;;:;
3 a
t D ~
~ .
Gl'
Solution Blueprint
Figure 8.1: Inputs for Developing the Solution Blueprint
Business Goal is a statement of business intent that is measurable
objectively and will contribute towards a business strategy. For example,
for an insurance company, "Cut auto claims fraud by 80% within the next
two years" is a business goal that will contribute to the business strategy,
"Maintain tight cost controls".
IT Trends indicate general direction the technology is moving towards,
which will have a significant impact on people, business and the IT Industry
in terms of exploiting the new technology to deliver business value.
Usually, a number of IT analyst and research companies such as Gartner,
Forrester, Yankee Group, IDC and AMR publish IT Trends reports, which
can be generic technology trends that are applicable to many business
domains or specific to business domains such as insurance, banking, etc.
IT Trends are also published in IT Magazines such as CIO, CIO Insight,
DMReview and lnfoTech Trends. [CIOinsight2006] is an example
document that contains some of the trends for the year 2007. Since the
trends are very time specific, it is important for the senior IT professionals
to constantly update their knowledge on the latest trends. Figure 8.2 shows
an example set of IT Trends.
Advanced Analytics Becomes Significant
Advanced analytics will play a major role as a business differentiator in the years
ahead. Analytics will have a primary rather than supporting role in competitive
strategies. Businesses are more likely to "compete on analytics". This competition is
primarily based on business process optimization, doing business better than anybody
else does by having a better understanding of the business, the customer, the
competition and the forces that shape it all. This comes with advanced analysis of
detailed information
Improve Business Processes through IT
Business process owners will increasingly depend upon IT to optimize the process. The
general trend will be to automate the business process that will provide valuable data
for analytics applications to work on. Process owners will adopt event detection to
optimize a variety of business processes.
Figure 8.2: Example Set of IT Trends (adapted from [Scott2006])
Enterprise Architecture is a blueprint that describes how IT will be used
within the organization in order to provide business value and achieve the
mission of the organization [OpenGroup2007]. It addresses the following:
business processes, information elements, applications and technology for
the entire organization. A part of Enterprise Architecture is a roadmap that
addresses how the organization will migrate to the new targets over time.
Such a plan would provide a three to five year roadmap, detailing the way
in which technology solutions will be implemented incrementally over time
to help stakeholders realize their business targets. The Enterprise
Architecture is developed by a team that includes the Chief Information
Officer (CIO), Business Executives, IT Solution Architects and the
Infrastructure Architects of the organization. We may refer to this team as
the Enterprise Architecture (EA) Team. The Enterprise Architecture is a set
of living documents that are constantly updated as new projects are
completed and as the business evolves.
IT Architecture Principles are high-level statements that describe the
underlying general rules, guidelines and preferred practices followed for
the use and deployment of all IT resources and assets across the
enterprise. They reflect a level of consensus among the various elements
of the enterprise and form the basis for making future IT decisions. Usually,
the IT Architecture Principles form part of the Enterprise Architecture
documents. An example of two IT architecture principles along with the
rationale and implications of these principles is shown in Figure 8.3. The
rationale defines the underlying reason why this principle is important for
the enterprise and the implication defines the impacts and the various
actions to undertake because of the principle. Due to various constraints
brought about by these principles, it is possible that some IT Projects
cannot fully satisfy these principles. In such cases, the Enterprise
Architecture Team may approve these exceptions.
PRINCIPLE NAME:
Cost Effectiveness and Operational Efficiency
STATEMENT:
The minimization of total cost of ownership should
be a goal of an IT project. Both initial development
costs, and ongoing operational costs must be
considered in totality. Operational efficiency of the
architecture should be considered.
RATIONALE:
Some solutions which are cheap to deploy may
result in high operational costs, which are hidden
at the point of procurement
An IT solution that may be more expensive to buy
or build but easier to maintain can potentially
result in significant total s v i n ~ s compared to a
cheaper solution that is operationally cumbersome.
IMPLICATIONS:
Ease of use should be a a prime consideration.
Availability and cost of expertise should be also be
a consideration.
PRINCIPLE NAME:
Standard System-to-System Interface Protocols
STATEMENT:
Standard interface protocols should be used for all
systems, where standards are available
RATIONALE:
Standard interface protocols will facilitate
communication, and interoperability between
systems
Make it easier for introducing new applications or
functions which rely on existmg systems
Enable changes in data, network, system
interfaces and legacy systems without negatively
impacting applications
IMPLICATIONS :
Standard interfaces protocols covering data,
network and systems need to be selected or
defined
Standard interfaces to legacy systems should be
defined when and where necessary
Figure 8.3: Examples of IT Architecture Principles
Activity 8.2
Discuss how the Enterprise Architecture, that is also a blueprint, differs
from the Solution Blueprint.
Industry Standards refer to a set of specifications that define materials,
methods, processes or practices across an industry. Standards provide a
basis for determining consistent and acceptable minimum levels of quality,
performance, safety and reliability. Use of standards helps in doing things
in a consistent manner. For example, TCP Transmission Control Protocol
is an industry wide standard developed by IETEF, for applications on
networked hosts to create connections to one another. Usually, Standards
are developed by committees composed of representatives of
organisations interested in or affected by the subject matter. For example,
ACCORD is an organization that facilitates the development and use of
standards for the insurance, reinsurance and related financial services
industries.
Corporate Standards refer to a set of standards that an organization
adopts for its internal use. In some organizations, this may be part of the
Enterprise Architecture documents. Since there are many Industry
Standards, each organization must define the most appropriate ones for
use within the organization. For example, the Corporate Standards for an
insurance company may state that for all new applications, the ACCORD
XML shall be used as the standard for real-time exchange of data between
producers, insurers, rating bureaus and service providers.
Activity 8.3
Discuss the importance of why these inputs are required and what value
they add when developing the Solution Blueprint.
Who develops and uses the Solution Blueprint?
J.. -IT Solution Architects
- Business Analysts
Solution Blueprint
- Subject Matter Experts
J_ -Vendors (if any)
Use
I
J.. -IT Solution Architects
- Business Sponsor
- Designers
- lmplementers
J_ -EA Team
Figure 8.4: Stakeholders of the Solution Blueprint
The IT Solution Architects takes the lead role in developing the Solution
Blueprint with input from (see Figure 8.4)
Business Analysts
Subject Matter Experts
Vendors (if any)
Usually, a team comprising the above stakeholders develop the Solution
Blueprint. We may refer to this team as the Solution Team. The Business
Analyst provides inputs that are mainly the deliverables from the Business
Modelling Phase such as business goals, workflow model, collaboration
model, results of dynamic analysis, use-cases, etc. The Subject Matter
Experts provide domain specific information. For example, if the proposed
solution is in the insurance domain, the Subject Matter Experts will provide
inputs such as applicable insurance rules and regulations, insurance best
practices, insurance solution frameworks (packaged solutions for specific
insurance processes), etc. The IT Solution Architect will provide additional
inputs beyond the scope of the current solution in order that the current
solution is aligned with the Enterprise Architecture (Roadmap, IT
Architecture Principles, Corporate Standards, etc.). The Vendors will also
provide inputs such as IT Trends, Industry Standards, best practices, etc.
Once the Solution Blueprint is developed, a number of Stakeholders use it,
some of whom who were involved in developing it; these include (see
Figure 8.4 ):
IT Solution Architects
Business Sponsor
Designers
lmplementers
Enterprise Architecture (EA) Team
The IT Solution Architects use the Solution Blueprint as a contract for the
requirements that must be delivered by the solution. This document is then
used for discussion with the Business Sponsor on what the solution will
deliver, what can be modified, what the implications of these modifications
are, etc. The Designers use specific parts of the document to refine further
into detail designs that the lmplementers can implement. The
lmplementers, who implement the solution, use this document as a guide
to verify that the solution implemented conforms to the one that is
proposed. All further changes to the proposed solution are documented in
subsequent versions of the Solution Blueprint documents. The final version
of the blueprint must reflect the implemented solution. The Enterprise
Architecture (EA) team, then update the Enterprise Architecture documents
based on the final version of the Solution Blueprint.
2. Concept Solution Blueprint vs. Detailed Solution
Blueprint
One can develop the Solution Blueprint at various levels to include
increasing levels of details. In this book, we divide this into two levels,
namely Concept Solution Blueprint and Detailed Solution Blueprint. Figure
8.5, shows some of the models that apply to these two levels.
The Concept Solution Blueprint models are still at a higher level of
abstraction and their primary purpose is to help the various stakeholders
understand the proposed solution. The purpose is not to provide detailed
information for implementing the solution. These models encourage
discussions between the different stakeholders such as the end user
organization and the IT Company that will develop and implement the
solution. The end user organization may also use these models to
compare solutions proposed by different IT companies before deciding to
award the IT Project. Some example models for the Concept Solution
Blueprint include Solution Overview Model, Application Model, Information
Model, etc., which conceptually define the proposed IT solution.
The Concept Solution Blueprint is then further refined and analysed
to produce Detailed Solution Blueprint, which contains more detailed levels
of abstraction that are to be used during the design and implementation of
the proposed IT solution. These models are at a low level of abstraction
and provide the required information for the designers, developers and
operational personnel of the solution. Some example models for the
Detailed Solution Blueprint include Detailed Application Model,
Performance Model, Deployment Model, Layer Model, Detailed Cost
Model, etc.
Solution Blueprint
Concept Solution
To-Be Business Process Model
Solution Overview Model
Application Model
Information Model
Blueprint ~ ~
~ - - - - - - - - - - - - - - - - - - - - - - - - ~
Further refined
)
Detailed Solution I
Blueprint 1--r
~ - ~ ~ - ~ - ~ ~ - ~ ~ - - ~ - ~ ~ - ~ ~ - ~ ~ ______ !
Logical Model
Sub-Systems Model
User Interface Model
Detailed Application Model
Performance Model
Service Implementation Model
Product Mapping Model
Deployment Model
Detailed Data Model
Detailed Cost Model
185
Figure 8.5: Example Models for Concept and Detailed Solution Blueprint
For the remainder of the book, we will only focus on the Concept Solution
Blueprint and its models.
References
[CIOinsight2006]
"The 30 Most Important IT Trends for 2007", CIO Insight, November 17,
2006.
http://www.cioinsight.com/
[OpenGroup2007]
The Open Group Architecture Framework (TOGAF), is an industry
standard enterprise architecture framework
http://www.opengroup.org/architecture/togaf/
[Scott2006]
Scott Gnau and Ron Swift, "2006 Information Technology Trends for
CIOs", OM Direct Newsletter, February 17, 2006.
CHAPTER 9
CONCEPT SOLUTION BLUEPRINT ACTIVITIES
Chapter Topic List
1. Overview
2. Solution Modelling
3. Application Modelling
4. Domain Modelling
5. Service Modelling
6. Risk Modelling
7. Concept Cost Modelling
8. Summary of the Activities
References
Case Study - Concept Solution Blueprint for GSPL Travel Requisition
Process
Learning Objectives
Understand the various activities of the concept solution blueprinting
phase
Concept Solution Blueprint Activities 187
CONCEPT SOLUTION BLUEPRINT ACTIVITIES
1. Overview
Figure 9.1 shows the various activities of the Concept Solution Blueprinting
phase. The Concept Solution Blueprinting phase follows from the Business
Modelling Phase. With the completion of the Business Modelling phase,
where the business requirements and the corresponding IT functional and
non-functional requirements are clearly defined (see Chapter 7), the
Concept Solution Blueprinting phase then focuses on developing a high-
level design of the IT solution to satisfy these requirements. Depending on
the scenario, one or more activities can be performed. In this chapter, we
will discuss the various activities and the models developed during each
activity.
Outputs of Business Modelling Phase
(Organization Model, Location Model, Collaboration Model, Workflow Model, Use-Case Model, etc.)
Business Goals, IT Trends, Enterprise Architecture,
IT Architecture Principles, Industry Standards, CorporatE! Standards, etc.
l l 0 0 l l
Concept
..
Application
..
Domain
Modelling Modelling Modelling
Solution Overview Function Model Information Model
Model Application Model Information Access Model
..
Service ..
Modelling
~
Service Model
Service Description Model
Risk
Modelling
Risk Model
Concept Cost
Modelling
Concept Cost Model
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ~ ~ - ~ ~ ~ p ~ - ~ ~ ~ ~ - ~ ~ ~ ~ - - ~ ~ ~ - ~ p ~ ~ ~ ~ ~ : l - ~ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
l
Detailed
Solution Blueprinting
Figure 9.1 Concept Solution Blueprinting Activities
The activities refine the functional and non-functional requirements using
output of Business Modelling phase and other inputs such as Business
Goals, IT Trends, Enterprise Architecture, IT Architecture Principles,
Industry Standards and Corporate IT Standards to develop appropriate
models of the solution. The focus is now mainly on the proposed IT
solution that would enable the business process. The final output of this
phase is a document that describes the proposed IT solution.
188 Concept Solution Blueprint Activities
In Figure 9.1, the flow of these activities is laid out in a linear fashion.
In reality, it is always possible that one repeats these activities when
necessary while developing the Concept Solution Blueprint. This statement
is also true for the steps described for each activity. Additionally, it is also
possible that as a result of developing the Concept Solution Blueprint,
some of the outputs of the Business Modelling phase such as Workflow
Model and Use Case Model, may need to be modified.
2. Solution Modelling
Solution Modelling activity focuses on understanding the scope of the
proposed IT solution. In this activity, the Solution Overview Model that
defines the Actors and the Functions of the proposed solution is
developed. An Actor is a person, role, department, organization or an IT
system that interacts with the solution through one or more Functions. For
example, a "Customer" who is the Actor, may personalize his or her portal
through the "Customer Personalization" Function. A Function is a capability
that the solution provides to enable the Actor to carry out one or more
activities.
Examine the functions identified during the IT Solutions
Requirements Definition Activity
Identify any other functions
that are required
Group functions into new and existing
Determine actors required for the solution including those
identified during IT Solutions Requirements Definition
Draw a diagram appropriately linking Actors with
functions and functions with functions. Add other details
as required.
Describe the model through one or more scenarios
Figure 9.2 Steps for Developing the Solution Overview Model
Figure 9.2 shows the sequence of the steps to arrive at the Solution
Overview Model. The template for the Solution Overview Model is shown in
Figure 9.3.
J:- :?!
ro
Actor 1 o-
OJ
Dl
Ill
ro
a.
:-----i
-I Function sl ....____.j. .
I :,
I ,_ .
j Function 3
- L _ _ _ _ _ _ _ _ _ _ _ _ j ~ B
-1 '""'"006
System B
!
I I Non web-based I I
!
*
Actor2
System A ~ .. - .. - .. . ~
System C
J: Actor
c==J Existing Function
D New Function
i Existing System
I
r_-_-_-_-_-_-_-_-j Grouping of Functions
rr:::=:JJ Interface to Application
Figure 9.3 Solution Overview Model: Template
(adapted from [Adams2001])
The recommendations proposed at the end of the Dynamic Analysis
determine the solution that is to be developed. The functions that the
solution must support are identified during the IT Solutions Requirements
Definition activity, when the Use Cases are grouped into function blocks. In
some instances, new functions have to be identified that are not directly
derived from the previous activities. For example, general functions such
as "Personalization" may not be explicit in the earlier models.
Once functions are identified, they are to be grouped into new and
existing. This is important since new functions may require additional effort
to develop and will have to integrate with existing functions.
Most of the actors will have been identified during the IT Solutions
Requirements Definition activity. The actor can be a person, department,
organization or an IT system. Add any other actor who is relevant to the
solution.
The interactions between the actors-functions and the functions-
functions are determined and represented as single arrows and double
arrows to denote one-way and two-way communication respectively. An
actor may interact with many functions and vice versa. A function may
have multiple actors and may also interact with multiple functions.
The final step involves writing a description for the various functions
and actors shown in the Solution Overview Model using business
scenarios.
Activity 9.1
Discuss the purpose of the Solution Overview Model, i.e., who would use it
and how it can be useful?
Activity 9.2
Develop the Solution Overview Model for the Order-to-Cash process, using
the results of Activity 7.1 and 7.2 (see Chapter 7)
For the Workflow Model, assume the following are existing
functions:
Credit verification
Customer registration
Make any other reasonable assumptions required
3. Application Modelling
Application Modelling activity focuses on understanding the various
applications (systems) that are involved in the proposed solution. This
includes both existing and new applications. An Application is a software
that provides functions. One application can provide one or many
functions. For example, Function A and Function B may be provided by
Application A 1 and Function C by Application A2. For example, Customer
Relationship Management System is an application which provides
functions such as customer personalization and customer registration.
At the end of the Application Modelling activity, two models are
developed - the Function Model and Application Model. Figure 9.4 shows
the sequence of steps to arrive at the Function Model. The template for the
Function Model is shown in Table 9.1. Figure 9.5 shows the sequence of
the steps to arrive at the Application Model. The template for the
Application Model is shown in Figure 9.6.
Function
Function A
Function B
Refer to the Use-Case-to-Function Model and determine the Use
Cases that are satisfied by existing applications and those that are
new
Develop the Function Model by listing the function, Use Case, and
other information in a tabular form
Figure 9.4 Steps for Developing the Function Model
Use Case New/ Comments
Existing I To
be modified
Use Case 1 New This is currently done
manually
Use Case 2 New
Use Case 3 To be modified These two Use Cases
Use Case 6 To be modified are partially supported
by Application A but
will require
modifications
Use Case 4 Existing Fully supported by
Application B
Use Case 5 New This is a new
functionality that has
been introduced
Table 9.1 Function Model Template
When one function is mapped to many Use Cases, it is possible that some
Use Cases are fully supported by existing functionalities while others are
new or require changes to existing functionalities. The Function Model
helps to capture this information and provides a first cut understanding of
the effort (e.g. time and resources) required for developing the solution.
Refer to the Solution Overview Model and Function Model, group
functions into applications (systems) and appropriately label the
applications
Draw a diagram linking the different applications
Write a brief description to explain the model
Figure 9.5 Steps for Developing the Application Model
The Solution Overview Model and the Function Model provides the input
for developing the Application Model. In many instances, the grouping of
functions may not be straightforward and will require a few brainstorming
sessions to arrive at the final model. Once the Application Model is
completed, it will be worthwhile to verify with the Use Case Model, Use-
Case-to-Function Model and Workflow Model for completeness and
correctness. When developing the Application Model, it is necessary to
consider three types of applications. These include:
Existing application with no modification: The functions required are
fully supported by the existing application. Here, the consideration is how
the application is to be integrated with the solution in order that the
functions can be accessed by actors and other functions.
Existing application with modification: The functions required are not
fully supported by the existing application, but with some modification, the
existing application can support these functions.
New application: None of the existing applications support the functions
required and a new application has to be developed. This new application
can be:
A commercial off-the-shelf packaged application such as an ERP
package and Accounting package. These applications can be
purchased from a software vendor. Some of these packaged
applications will require customization to match with the specific
organization's process requirements
A custom-built application developed from scratch, where the
organization has to develop the application either through in-house
development team or outsource to an IT services vendor
However, at this stage one may not have all the information to make the
decision as to whether an application is packaged or custom-built. Hence,
the intention is to place a marker (as new application) and visit this at a
later stage during the Detailed Solution Blueprinting phase.
Application 1 (work product) Application 3
(Fl, F2) (F3, F4, FS)
Function
Symbol
F1
F2
(protocol)
Application 2 Application 5
(F6, F7,F8) (FlO, Fll)
Function Name
D Existing Application with no modification
Existing Application with modification
D New Application
FX Function
( ) Optional
Figure 9.6 Application Model: Template
As shown in the template, the Application Model shows the functions
supported by each application and the interaction between the different
applications involved in the solution. Optionally, it can also include:
The work product that is exchanged between the applications such as
"claims form", "insurance quote", "customer profile", etc.,
Interaction protocol between the applications such as HTTP, JMS,
SOAP, etc.
For existing and modified applications, it is not necessary to show all the
functions but only those functions that are relevant for the present solution.
Activity 9.3
Based on Activity 9.2, develop the Application Model for the Order-to-Cash
process.
4. Domain Modelling
Domain modelling activity focuses on understanding the various
information entities involved in the proposed solution. An Information Entity
is a data component that is created, used, deleted or updated when
performing an activity within the business process. For example, in the
Order-to-Cash Process, the activity "Enter Order Details" performed by the
"Customer", will lead to the creation of an entity "order details", which the
"Web Order Management System" will use in the activity "Validate Details".
An entity has a number of data elements or attributes or fields. For
example, "order details" may have elements such as "order-id", "customer-
id", "order-item-list", 'total-cost" and "order-date". At the concept solution
blueprint phase, we are not concerned with the details of these elements
such as the data type (whether it is text or numeric), field length and
validation rule for the element. However, one has to understand the
various information entities that will be used in the solution- who will create
it, who can read it, who can update it, where it is stored, etc. For example,
in the Order-to-Cash Process, only the "Credit Supervisor" role can update
the entity "credit details" while the "Inventory System" will not have access
to the entity "credit details".
At the end of this activity, two models are developed, namely,
Information Model and the Information Access Model. Figure 9.7 shows the
sequence of the steps to arrive at the Information Model. The template for
the Information Model is shown in Table 9.2.
Using the Solution Overview Model (including the scenario
description) and Application Model, identify the various
information entities that are created or used in the various
applications in the solution
Develop the Information Model, by listing the information
entities, along with a brief description, the most important
attributes, etc.
Figure 9.7 Steps for Developing the Information Model
The Solution Overview Model (including the scenario description) and
Application Model provide the input for developing the Information Model.
Walking through the scenario description facilitates elicitation of
information entities. When a function is performed in an application, it will
create or use (read or update or delete), one or more information entity. As
the business process progresses through a sequence of activities, the
information entity can undergo changes. For example, attribute values may
change, new attributes added or some attributes deleted. When developing
the Information Model, it is important to distinguish between existing and
new information entity. As far as possible, when developing a new solution,
one must try to reuse existing entities rather than duplicating them.
Here is an example list of questions that one may ask when developing the
Information Model and Information Access Model:
Who (department, organization) owns this entity?
Who creates the entity (applicable only to new entity)?
Where is this entity stored (within which system)?
How do the functions access the entity?
How is the entity used?
What changes would the entity undergo?
Are there any rules and regulations pertaining to using this entity? For
example, in a bank, the entity "account details" cannot be deleted for 7
years after it has been closed
Entity Entity Residing Key Attributes Existing/New Additional
Name Description
System of the Entity
Entity/TBD
Comments
TBD To-Be-Decided
Table 9.2 Information Model: Template
Due to lack of sufficient information at this stage, it may not be clear if the
entity is an existing one or a new one. In such cases, TBD can be used for
this column in the Information Model. However, it is good practice to use it
at the minimum and as a last resort.
Once the entities are identified, the next step is to determine the
relationship between the different roles (both humans and applications)
and the operations they can perform on the entity. This is captured in the
Information Access Model.
The basic operations that can be performed on an entity are as follows:
Create
Read
Update
Delete
Defining the operation for the entity helps to understand who has the
access to the entity and this information can be used for detailed design
and development phase to define access controls for the solution. These
access control rules can also be influenced by external organizations such
as governments, professional associations, etc.
Figure 9.8 shows the sequence of the steps to develop the
Information Access Model. The template for the Information Access Model
is shown in Table 9.3.
Using the Information Model, Application Model and the
Workflow Model, examine the different
roles/department/organization/application that access each
entity and determine their access rights with
regard to the entity
Develop the Information Access Model by listing the entities,
roles and access rights
Figure 9.8 Steps for Developing the Information Access Model
When developing the Information Access Model, here are some points to
note:
All entities must have at least one role/department/organization that
creates the entity
The role can be a human or an application
The following general rules may be applied when deciding who creates
the entity:
If an entity is created by an automated activity, the application
performing the activity creates the entity. For example, when a
logistics system automatically generates shipping details, the
logistics system creates the entity "shipping order".
If an entity is created by an interactive activity, the human
performing the activity on the application creates the entity. For
example, when a sales person enters new sales details using the
sales application, the sales person creates the entity "sales order".
For existing entity, the following must be considered:
As far as possible, try to reuse the entity from an existing
application. If for some reason, it is necessary to re-create the
entity within the current process, mechanisms must be in place to
ensure the entity in the new application and the entity in the
existing application is consistent. The access rights for the entity
must be verified with the owner of the original version of the entity.
When updating or deleting an existing entity, care must be taken
and the owner of the original version of the entity must be
consulted. It is most likely that the delete operation will not be
performed on an existing entity that has not been created within
the current process.
Information Entity 7 Entity 1 Entity 2 Entity 3 ...
Roles/Dept/Org J,
Role 1 RU R RU R
Dept 1 CRUD - - R
Role2 R - R -
C Create
R Read
U Update
D Delete
Table 9.3 Information Access Model: Template
5. Service Modelling
Conceptof"Servicen
A service is functionality that achieves a specific end goal for a requester.
Humans or machines can provide a service. For example, a travel agent
provides the Travel Booking Service. This service is used by the customers
of the travel agent. The requester is the traveller, the service provider is the
travel agent and the end goal is to book travel ticket and accommodation
for the traveller. A service has an input, output and a service level
agreement. In the travel agent example, the input is the travel details such
as date of travel, destination, number of days of stay, budget and name of
traveller; the output is the ticket and accommodation confirmation; the
service level agreement is for example, to book the cheapest air ticket and
hotel accommodation and send the confirmation to the customer within one
day.
However, in this scenario, the travel agent alone is not sufficient to
provide the Travel Booking Service. The travel agent uses the service
provided by the airline clerks and hotel booking clerks. As shown in Figure
9.9, the other services required are Airline Booking Service that is provided
by the airline clerks of the various airlines that have partnership with the
travel agent and the Hotel Booking Service provided by the hotel booking
clerks of the various hotels that have partnership with the travel agent.
rftor_ Travel Booking
m Service
Traveller , .
Hotel A
Booking Service
; / ~
,,
Hotel B
Booking Service
".f.
Airline A
Booking Service
Airline B
Booking Service
Figure 9.9 Example Services in the Manual Travel Booking Process
The travel booking process that controls the interaction between the
different services may be defined as comprising of the following steps:
1. The traveller gives the travel details to the travel agent
2. The travel agent then checks the details and then determines the
most suitable Airline(s) and Hotel(s). For example, based on travel
details (e.g. source and destination) and customer's preference (e.g.
frequent flying programme)
3. The travel agent sends request to each Airline and Hotel. Upon
receiving the reply, two airlines and two hotels with the cheapest
quotes are selected
4. The customer is then informed of these quotations and asked to
confirm the booking by selecting the most suitable airline and hotel
quotation
5. Upon receiving the customer's confirmation, the travel agent confirms
the booking with the Airline and Hotel
6. Upon receiving the customer's confirmation, the travel agent initiates
another business process- Invoicing
In Figure 9.9, the service interaction is between human-human through
face-to-face or telephone communication.
If we automate the manual travel booking process, the interaction between
the different services may be defined as comprising of the following steps
(see Figure 9.1 0):
1. The traveller logs into the online travel booking application provided
by the travel agent and enter the travel details
2. The travel booking application checks the travel details for errors and
then the most suitable Airline(s) and Hotel(s) are determined. For
example, based on travel details (e.g. source and destination) and
customer's preference (e.g. frequent flying programme)
3. A request is then sent to each airline booking application and hotel
booking application. Here, it is assumed that the airline booking
application and hotel booking application each provides a service
that allows other applications to send booking requests through
electronic means
4. Each airline and hotel booking application then sends an electronic
response to the travel booking application. Upon receiving the
responses from the different airline and hotel applications, two
airlines and two hotels with the cheapest quotations are selected
5. An email is then sent to the customer to inform the quotations and to
ask the customer to confirm the booking by selecting the most
suitable airline and hotel quotation
6. Upon receiving the customer confirmation, the online booking
application sends confirmation to the appropriate airline and hotel
booking applications
7. Finally, another business process, Invoicing, is initiated by the online
booking application.
In Figure 9.1 0, the interactions between the services include both human-
to-system and system-to-system.
Activity 9.4
In Figure 9.1 0, identify the human-system and system-system service
interactions.
Traveller
Travel Booking
Service
Hotel A
Booking Application Hotel A
Hotel B
Booking Application
Airline A
Booking Application
Booking Service
Hotel A
Quotation Service
Hotel B
Booking Service
Hotel B
Quotation Service
Airline A
Booking Service
Airline A
Quotation Service
Airline B
Booking Service
Airline B
Quotation Service
Figure 9.10 Example Services in the Automated Travel Booking Process
Definition of a Service
In the context of service modelling, we are only interested in identifying the
application-to-application services (system-to-system). An application-to-
application service may be defined as:
"Functionality in an application that can be invoked by other applications
over the network"
In essence, a service is a function or sub-function that is externalized for
other applications to access over the network. For example, in the travel
booking process, the airline application provides the booking service that
allows the online-booking application to invoke over the network (e.g.
Internet). The input to the airline booking service is the travel details such
as date of travel, destination and name of traveller; the output is the
booking confirmation reference number, flight schedule and the ticket
price; the service level agreement is for example, the airline booking
application returns the output to the online-booking application within 1
minute and it can simultaneously process 100 booking requests from the
online-booking application.
Developing the Service Models
Service Modelling activity focuses on understanding the services provided
by the different applications (systems) that are involved in the solution. As
mentioned earlier, we focus only on application-to-application interaction.
At the end of this activity, two models are developed, namely, Service
Model and the Service Description Model.
Figure 9.11 shows the sequence of the steps to arrive at the Service
Context Model. The template for the Service Model is shown in Figure
9.12.
Using the Application Model, determine the services an application
need to provide and which applications need to use these services
Draw a diagram showing the various applications, the services
provided and which applications use the services
Figure 9.11 Steps for Developing the Service Model
The Application Model provides the input for developing the Service Model.
Go through the Application Model and identify the various applications
involved in the solution. For each application, examine the functions and
sub-functions (Use Cases) that this application provides and those that can
be exposed as services. When deciding the function or sub-function to be
exposed as a service, two types of concerns must be addressed:
Which function or sub-function to expose as a service?
The granularity of a service; that is, should one sub-function, a group of
sub-functions, the whole function, or a group of functions, be exposed
as one service.
Following are some guidelines on exposing a function or sub-function as a
service:
Expose the function or sub-function as a service when it is going to be
used by at least one other application and there is potential use by other
applications in the future
Exposing a function or sub-function within an existing application may
be more complex when compared to that of a new application. This is
mainly due to the fact that existing applications may be developed many
years ago using legacy technologies
Try to avoid the temptation that all functions and sub-functions need to
be exposed as a service
If a function or sub-function is required by an application that belongs to
an external organization, it is better to expose it as a service
Exposing a function or sub-function always has an associated security
risk; hence, appropriate measures must be taken to ensure that security
is not compromised. The security risk is higher when the interaction
involves an application that belongs to an external organization
51 54
Application 1
Application 3
Application 4
55
I
1
51
52
Application 2
53
Application 5
Application A1 uses service 51
provided by application A2
Figure 9.12 Service Model Template
The Service Description Model provides a structured way to describe the
services. The template for the Service Description Model is shown in Table
9.4.
Application Name Application (s) Description Input Output Service
Providing the Using the Level
Service Service
Application 3 51 Application 1, ... ... ... ...
Application 2
Application 5 53 Application 2 ... ... ... ...
55 Application 4 ... ... ... ...
Table 9.4 Service Description Model Template
It is useful to give an appropriate name to a service that helps to identify
the functionality provided by just looking at the name. For example,
Currency Conversion Service, GST Calculation Service, etc. When
describing the service, keep the description short. For example, "This
service converts a given amount from one currency to another". The input
is usually a set of parameters that are required by the service, for example,
"Amount", "From Currency" and "To Currency". The output is usually a
result (set of parameters), for example, "Converted Amount". For every
service, there must be a set of service level agreements that must be
guaranteed by the application providing the service. This is similar to the
service levels one expects from a human service provider. Here are some
examples of service levels expectations for the "Currency Conversion
Service":
The service shall process up to a maximum of 500 simultaneous
requests
The service shall return the result within 3 milliseconds
The service shall be available 24 hours a day, 7 days a week
The result returned shall match with the current bank exchange rates
with an allowance of 0.05%
It is also possible to define varying service level agreements for different
applications that use the service. For example, for the "Currency
Conversion Service", the agreement regarding processing of simultaneous
requests can be different:
For Online Booking Application of Travel Agent A, the Hotel Booking
service will process up to a maximum of 500 simultaneous requests
For Online Booking Application of Travel Agent B, the Hotel Booking
service will process up to a maximum of 100 simultaneous requests
6. Risk Modelling
Risk Modelling activity focuses on evaluating the potential risk of the
proposed concept solution. Risk is a condition in which there exists a
quantifiable dispersion in the possible outcomes from any activity. The
problems that are going to be faced "tomorrow" are the risks that are
identified "today".
Risk is inherent in the implementation of complex solutions. The risk
model provides a guideline for identifying, quantifying risks and deriving
mitigation strategies before the risks become problems. The benefits of risk
management are hard to quantify and are not necessarily immediately
obvious. Preparing for risks is to prepare for a potential future activity and
accordingly, any benefits will only be received in the future. The potential
return on investment by preventing one major risk could possibly justify
and pay for all the risk management activities.
Risk can be classified into hard and soft risks. Hard risk relates to
exposure to potential damage of physical infrastructure, architecture or
monetary. Soft risk relates to potential impact on social, economic or
organization structure that requires more indirect action to create the
needed cooperation or alignment. One can also refer hard risk as tangible
risks and soft risk as intangible risks. Risk can also be classified into
Internal Risks and External Risks. Internal risks are risks that the project
team can influence or control, such as staff assignments, timelines and
cost estimates. External risks are risks that are outside of the control of the
project team. For example, technology changes, technology upgrades and
government decisions.
In the Business Process Engineering Methodology (BPEM), we have
already looked into the impact of the process change to the organization,
department and external business partners in the To-Be Analysis in the
Business Modelling phase (see Chapter 6). In concept solution blueprinting
phase, we will only focus on both internal and external hard risks that could
have an adverse effect on the technical aspects of the project. In other
words, the concept risk model will focus on risks associated with changes
to the existing applications or risks associated with implementation of new
technologies. The risk identified would also determine the final
Technologies proposed (hardware and software)
Costs
Schedule or Project Plan
Figure 9.13 shows the sequence of the steps to arrive at the Risk Model.
The template for the Risk Model is shown in Table 9.5.
Risk Description
Refer to Application Model and Function Model and select all
new applications/functions or applications/functions that
require modification
For each of the new I to-be-modified application/function,
estimate the difficulty level of implementing the
application/function. Identify the risk(s), the possibility of the
risk(s) occurring and the impact of the risk occurring
Assess each risk and use the Risk-rating Matrix to classify them
appropriately and identify a mitigation strategy
List the risks, corresponding ratings, mitigation strategy and
mitigation impact in the Risk Model
Figure 9.13 Steps for Developing the Risk Model
Impact Likelihood Rating Mitigation Mitigation
Strategy Type
Low/ Low/ A/B/ Risk
Medium I Medium I c Elimination/
High High Risk
Reduction
Low/ Low/ A/B/ Risk
Medium I Medium I c Elimination/
High High Risk
Reduction
Table 9.5 Risk Model Template
Impact of
Strategy
Risk Description
The risk description is textual information about the risk. It is important to
note that risks are some things that are potential causes of something bad
happening but not the result of the catastrophe. For example, "The project
will not be completed on time" is not a risk; it is an impact. The risk could
be "the project uses a new technology which requires staff training for up to
3 months".
Risk Impact, Likelihood of Occurrence and Rating
Risk Impact is a potential negative effect on the project schedule, cost
and/or delivery that may arise from a future event. Likelihood of
occurrence, as the name suggests, is the probability of an adverse
outcome. Risk rating is derived from the Risk Impact and the Likelihood of
Occurrence based on the Risk-Rating Matrix.
As Risk Impact is something that is highly subjective, Table 9.6
provides some guidelines that one may use when assessing the risk
impact.
The risk impact would likely to be of this nature (high, medium or low) if occurrence of
the risk results in
High Medium Low
Halt in project implementation or Some functionalities cannot be Minor change of
unacceptable by business sponsor implemented or requires manual requirements or functionality
A need to change major part of
work as workaround
A need to change a minor
the solution A need to change 30-50% of part of the solution
Delay of project for more than 6
the solution
Slight delay of project, < 1
months Delay of project for more than 3 month
Increase in cost by more than
months
Slight increase in cost, <
50% Increase in cost by more than 10%
etc ...
25%
etc ...
etc ...
Table 9.6 Risk Impact Guidelines
The Risk-Rating matrix helps to 'quantify' a risk. Certainly, 'quantifying' risk
contains some level of subjectivity based on the judgement and experience
of the risk analyst. The Risk-Rating Matrix is shown in Figure 9.14. The
risks are classified into three different ratings based on two indicators,
namely, the likelihood of the risk occurring and the impact of the risk if it
happens. Rating A is the highest rating and C is the lowest rating.
High
Rating B RitlngA
~
i
.....
3
Medium
"C
Dl
Rating C Rating B lla1mgA
!+
Low
Rating C Rating C Rating B
Low Medium High
Likelihood of Occurrence-
Figure 9.14 Risk-Rating Matrix
Mitigation Strategy and Types
Risk identification is only beneficial if actions are defined and executed to
mitigate the risk. Mitigation actions are proactive which help to prevent a
risk from occurring or reducing the impact of the risk. Risk mitigation
actions must be defined individually for each risk. One can either take
immediate action or plan for the future. Risks can either be mitigated by
eliminating the risk (risk elimination) or by reducing their degree of
occurrence and/or lessen the impact to the project (risk reduction).
Mitigation actions come with a cost. Table 9.7 shows an example
Risk Context Model with the two types of mitigation strategy (risk
elimination and risk reduction) and the impact of deploying the strategy.
Under the column Impact of Strategy, the impact of deploying the strategy
on the organization, cost and schedule are listed.
Risk Description Impact Likelihood Rating Mitigation Strategy Type Impact of Strategy
Lack of committed resources Medium High B Delegate specific Risk Increase in cost
as resources are required to resources to work Elimination for hiring or
spend time on BPE project as on the BPE project deploying
well as daily operations additional
resources
A new technology is
High High A
Plan for phase
Risk Schedule may
designed to be deployed. approach to the
Reduction lengthen by
The technologJ is new, lack implementation of
of stability an lack of the project.
additional 3
expertise to implement Conduct a months
prototype or
proof-of-concept
to ensure the
capability of the
technology
Table 9.7 Risk Model Example
7. Concept Cost Modelling
Concept Cost Modelling activity focuses on estimating the potential
qualitative cost level (high, medium or low) of designing, implementing and
maintaining (includes purchasing of software and hardware) for the
proposed concept solution.
Costs are to be estimated to cover project activities and computing
resources from proposal stage and throughout the lifetime for the solution.
The principal components of costs are:
Hardware costs
This covers the cost of computing equipment required for the proposed
solution. This includes the servers supporting the applications as well as
the peripherals such as scanners, readers, printers, point-of-sales, etc.
Software costs
This covers any commercial-off-the-shelf software licensing cost. It should
cover cost of software that is required in development, test and production
environment, e.g. licensing cost for development tool and multiple copies
of database licenses for development, test and production environment.
Process re-design and change management effort costs
BPE projects will change the way people are used to executing their work.
It is one thing to implement a new application which creates a new set of
processes and workflow, but it is quite another to get people to willingly
adopt these changes, to behave in accordance with the new procedures
and to embrace the new solution and the new processes. This cost covers
the effort not only to re-design the to-be process, but also the effort to
manage the changes, that is, help the employees to understand the
reasons for change, obtain their involvement and insight and create
commitment to the new processes and ways-of-working. The bigger the
changes in the process redesign, it is likely to have a bigger change
management effort. How change is managed will impact on how rapidly
and effectively the changes are adopted.
Design and implementation effort costs
This is also known as Development costs. This includes the cost to design
and implement the proposed IT solution, that is, the cost to pay to software
engineers for development of the solution. This is also usually the most
dominant cost and is the most difficult to estimate and control, yet has the
most significant effect on the overall cost. Effort costs are usually
estimated in man-days or man-months. However, in concept solution
blueprint, the exact scope and requirements for the project may not be
known as yet, hence making man-days estimation very challenging.
Deployment and training costs
This refers to the cost of training users on using the new IT solution and
cost of rolling out the solution. This cost would generally be higher if the
solution involves technologies that the users are not familiar with and/or
deployment to multiple locations or branches especially if it is cross-
country.
Maintenance costs
This is a cross-functional cost as it involves the costs of maintaining the
entire IT solution. In general, a matured and standardized solution for the
industry tends to have a lower maintenance cost. On the contrary, if the
solution involves new, emerging technologies, the maintenance cost may
potentially be high. Maintenance costs should include maintenance cost for
hardware, software, applications, process review and refinement, and
redeployment and training costs.
Developing the Concept Cost Model
During the concept blueprint phase, it is not possible to know the actual
requirements and details of the final deployment configuration for the
proposed IT solution, hence making detailed cost estimation very difficult.
Therefore, the approach to cost modelling at the concept solution blueprint
phase is such that we estimate the cost only in ranges but not the actual
dollar and cents. This may be referred to as the cost levels. Table 9.8
shows an example of the cost levels. For each solution, one may define
appropriate cost levels to suit the project needs.
If the cost is
High Medium Low
Cost>= $500,000 $100,000 <= Cost< $500,000 Cost< $100,000
* $ in Singapore Dollars
Table 9.8 Example of Cost Levels
Figure 9.15 shows the sequence of the steps to arrive at the Concept Cost
Model. The template along with an example for the Concept Cost Model is
shown in Table 9.9.
Design a set of cost levels suitable for the project
Referring to Solution Overview Model, Application Model and
Function Model, list the types of costs involved for each of the
functions based on the complexity and technologies used. All
To-be Business Models (e.g. Location Model, Workflow Model
and Collaboration Model) and preceding Concept Solution
Blueprint models may also be used
Estimate the cost level for each type of cost identified and the
corresponding maintenance costs
From each of the costs levels, determine the final cost level
and represent it in tabular form
Figure 9.15 Steps for Developing the Concept Cost Model
No Items
1 Hardware Total
1.1 Servers
1.2 Scanners
.. . ...
2 Software Total
2.1 Database
2.2 Portal
...
3 Process Redesign Total
3.1 Process study
3.2 Chanqe Management
4 DesiQn and Implementation
4.1 Applications A
4.1.1 Requirements
De sian
Construction
Test
Documentations
Project Management
4.2 Application B
4.2.1 Design
Modifications
...
5 Deployment and training
5.1 Application A
5.2 Application B
...
Fixed Costs Maintenance Total Cost Rating
Costs
Low Med Hiah Low Med High Low Med High
../
../ ../ ../
../ ../ ../
../
../ ../ ../
../ ../ ../
../
../ ../ ../
../ ../ ../
../
../ ./ ../
../ ../ ../
./ ../ ../
../ ../ ../
../ ../ ../
../ ../ ../
../
../ ../ ../
./ ../ ../
./
./ ../ ../
../ ../ ../
Table 9.9 Concept Cost Model Template with Example
Justification
C'":l
C)
:::::J
C")
Cb
~
....
Cl')
C)
i::
=::::!:
C)
:::::J
t:x::J
i::
Cb
~
~
....
):,
C")
=::::!:
~
tt;
(I)
1\.)
....>.
Price to Win
While the Concept Cost Model provides an indication of the cost of the
proposed solution, it is important to note that this may not necessarily
translate to the actual detailed cost model in the project. "Price to Win" is a
strategy that many IT services companies use to price the project to
strategically win the contract, even if it means eliminating or lowering the
profit margin. One must have comprehensive knowledge of the target
customer's needs and budget and the competitor's capabilities and prices
in order to be successful. Under such a circumstance, the Concept Context
Model should only be used internally and not be shared with the business
sponsor.
8. Summary of the Activities
Table 9.10 shows the various activities of the Concept Solution
Blueprinting Phase along with a brief description, the inputs and outputs for
each activity.
Activity Description Input Output
Solution Define the Use Case Solution
Modelling scope of the Model, Use- Overview Model
proposed Case-to-
solution Function Model
Application Define the Solution Application
Modelling various Overview Model, Model, Function
applications Use-Case-to- Model
involved in the Function Model
solution. For
each
application
identify the
functions
provided by the
application
Domain Identify and Solution Information
Modelling describe the Overview Model, Model,
various Application Information
information Model, Workflow Access Model
entities that are Model
used in the
solution. For
each entity
define the
access rights
Service Define and Application Service Model,
Modelling describe the Model Service
services that Description
are provided by Model
the applications
Risk Modelling Evaluate the Application Risk Model
risks Model, Function
associated with Model
the proposed
solution
Concept Cost Estimating the All To-Be Concept Cost
Modelling qualitative cost Business Model
of designing, Models and
implementing preceding
and Concept
maintaining the Solution
solution Blueprinting
Models
Table 9.10 Summary of the Concept Solution Blueprinting Activities
References
[Adams2001]
Jonathan Adams, Srinivas Koushik, Guru Vasudeva and George
Galambos, "Patterns for e-business: A Strategy for Reuse", IBM Press,
2001.
Case Study
Concept Solution Blueprint for GSPL Travel Requisition
Process
The Solution Team, comprising the original BPE team and a team of IT
Solution Architects, takes the outputs from Business Modelling phase to
develop a Concept Solution Blueprint to support the GSPL To-Be Travel
Requisition Process. The report in this section shows the proposed IT
Solution for the process studied.
"We", in this case study, refers to the Solution Team.
*
*
*
Solution Overview Modelling
We start with developing a Solution Overview Model based on the
recommendations from the Dynamic Analysis and Use Case Models. This
solution also takes into considerations the binding management decisions
of reusing the existing IT systems whenever possible (See Chapter 6 Case
Study). The Solution Overview Model is shown in Figure 9.16. We shall
refer to this solution as the Travel Requisition Solution.
Travel Desk
Traveller
::X: Actor
11 Existing Function (with
or without modification)
CJ New Function
r_-_-_-_-_-_-_-_-j Grouping of Functions
rr==Il Interface to Application
Figure 9.16 Solution Overview Model for Travel Requisition Solution
As per the recommendations from Dynamic Analysis, we are proposing
use of a web-based application for accessing the e-Travel functions.
Through the web-based interface, the Travellers interact with Travel
Request Management functions to raise a travel request, update and view
the request status. Travel Request Management uses the Approval
function to route the request to the relevant approvers. Approval function in
turn, interacts with Communications Management to send email alerts to
the approvers. The Project Leaders and Business Managers use the web-
based interface to view the requests and provide approvals as appropriate.
When approvals are completed, the requests await actions from Travel
Desk. The Travel Desk uses the Travel Request Management function
through the web-based interface to assign the travel requests to the Travel
Agents. The Travel Request Management uses the Communications
Management function to email or electronically fax to the Travel Agents for
ticket processing. Upon successful requisition of tickets, Travel Desk
updates the ticket details using the functions in Travel Request
Management. The update action, in turn, triggers an event to store the
payment information in the Payment function. If it is a foreign travel, the
Travel Request Management also triggers the Foreign Currency Sanction
function to generate the sanction letter for the traveller. When a sanction
letter is issued, the Foreign Currency Sanction stores the amount of foreign
currency issued and also inform the Expense Management function in
Enterprise System regarding the issuance.
When the traveller returns from the trip, the traveller must record the
expenses in the Expense Management in order to get reimbursements or
justify use of the foreign currencies. The traveller accesses the Expense
Management function through a proprietary non-web-based interface.
With the expense records, the Expense Management can compute the
settlement status for the traveller.
Application Modelling
Next, we need to identify the applications that would be involved in the
solution. In this case study, we use the words "Application" and "System"
interchangeably.
In order to determine if changes are required for an Application, we
examine the list of Use Cases in each function and map them to the
functionalities of existing systems. We use a Function Model to document
our analysis (Table 9.11 ). The following table (Table 9.11) shows the
Function Model for Travel Requisition Solution. This analysis also provides
an input to the Application Model as it reflects which applications require
modifications.
Function Use Case New/ Comments
Existing I To
be modified
Travel Request All New These functions are
Management designed to be a new
Approval All New Application, called E-
Communications All New
Travel System (ETS)
Management
Foreign Currency All New
Sanction
Payment Issue Payment Existing Other applications in
Voucher GSPL have been using
this function for
payment.
Expense Expense & Foreign New Currently done
Management Currency Issuance manually.
Reconciliation
Record Foreign New Currently only
Currency Issued recorded in the
sanction letter
Record Expense Existing Travellers have been
Details doing this currently
Enter Expense Existing
Details
Table 9.11 Function Model for Travel Requisition Solution
In our design, the new travel related functions are grouped in the same
application, that is, the e-Travel System {ETS} as proposed after Dynamic
Analysis. Since the E-Travel System (ETS} is a new proposed system, all
use cases within the ETS functions are new. The Expense Management
function partially exists in the Enterprise System (ES). This is because
some of the Use Cases such as "Enter Expense Details" and "Record
Expense Details" are existing functionalities and others such as "Expense
& Foreign Currency Issuance Reconciliation" and "Record Foreign
Currency Issued" are new functionalities. Payment function is an existing
function in Accounting System (AS) and we shall reuse the function to
generate payment voucher as per other applications in GSPL. The
Application Model in Figure 9.17 shows how the functions are grouped and
the work product exchanges between the applications.
Concept Solution Blueprint Activities
D Existing Application that requires no modification
Existing Application that requires modification
D New Application
Function
Symbol
F1
F2
F3
F4
F5
F6
Function Name
Travel Request Management
Approval
Foreign Currency Sanction
Communication Management
Payment
Expense Management
217
Accounting System
(AS)
Figure 9.17 Application Model for Travel Requisition Solution
From the Function Model and Solution Overview Model, we concluded that
ETS is an entirely new application while ES requires some modifications
and AS can be reused without modification. The interactions are only
between the ETS and ES to exchange settlement status and foreign
currency issued information and between ETS and AS to exchange
payment information.
Information Modelling
In this activity, we analyse what information needs to be stored, where they
are stored and the operations that can be performed on them by the
various actors. We document these in the Information Model and
Information Access Model as shown in Tables 9.12 and 9.13 respectively.
Entity Name Entity Description Residing
System
Travel Request This entity stores ETS
Details information about the
travel request including
the status
Expense This entity stores the ES
Details traveller's expense
information
Currency This entity stores the ETS I ES
Sanction information about the
Details amount of foreign
currency approved and
issued to the traveller
Payment This entity stores the ETS
Details payment amount due to
the travel agent when a
travel request is fulfilled
Key Attributes

Requestor

Name of passenger(s)

Place of origin

Destination

Date of travel

Date of return

Medium of travel

Request status

Ticket details

Expense date

Expense description

Actual amount

Claim amount

Purpose

Currency

Issued to (employee)

Issued date

Issued amount

Currency

Pay to (vendor)

Date

Payment amount

Payment currency
Existing Additional Comments
I New
New
Existing
New Master copy in ETS,
duplicated copy in ES
New This information must be
kept of minimum of 7 years
due to a government policy
1'\.)
--"
co
C'":l
C)

C")
tb

....
Cl')
C)
i::
=::::!:
C)

0::1
i::
tb

g .
....
):,
C")
=::::!:

(b
(/)
Settlement
Status
Approval
Routing Details
Ticket Details
This entity stores the ES

Employee New To be derived by ES
settlement status of the

Settlement status
through reconciliation of
traveller expense and settlement
amount for the foreign
currency issued
This entity stores the TBD

Employee TBD TBD- To Be Determined
approval routing

1st level manager Need to check with GSPL if
sequence for each

2"d level manager
there is any existing
employee organization directory (e.g.
LDAP)
This entity stores the ETS

Ticket type ( e-ticket, Each travel leg has a set of
booking and ticket details paper ticket) ticket details, i.e., if it is a
for the travel

Booking reference
return trip, there is at least 2

Carrier type
sets of ticket details for both

Carrier code
the departure and return

Departure date
trips

Departure time

Boarding location
Table 9.12 Information Model for Travel Requisition Solution
C":l
C)
:::::J
C')
Cb

....
Cl')
C)
i::
=::::!:
C)
:::::J
t:x::J
i::
Cb

....
):,
C')
=::::!:

tt;
(I)
1\.)
.......
c.o
Information n t i t y ~ Travel Expense Currency Payment Settlement Approval Ticket
Roles/DepUOrg J, Request Details Sanction Details Status Routing Details
Details Details Details*
Traveller CRUD CRU R R
Business Manager RU
Project Leader
I
RU
Travel Desk CRU CRUD
Enterprise System(ES) I R R CRU
Accounting System(AS) R
e-Travel System (ETS) I R CRU CRU RU R
Table 9.13 Information Access Model for Travel Requisition Solution
* How this entity is created or updated is unclear at this stage; further study is required. However, we are sure
that ETS needs to read this information to route the request to the appropriate person for approval.
1\.)
1\.)
0
C'")
c
~
(')
tb
"'tJ
.....
Cl)
c
t:
~
~
t:XJ
t:
tb
"'tJ
s
.....
):,.
(')
~
~
C'b'
~
Service Modelling
With better understanding of the interactions between the applications and
where each information entity is stored, we can now identify the services
that the applications need to expose in order to achieve the system-to-
system interactions.
By examining the Solution Overview Model and Application Model, we
derive the following information:
1. ES needs to expose functions to allow ETS
To check the employee's settlement status and
To inform ES the amount of foreign currency authorized and issued
to the employee
2. AS needs to expose functions to allow ETS
To trigger the function to issue payment voucher for a particular
Travel Agent
The Service Model and Service Description Model for GSPL Travel
Requisition Process are shown in Figure 9.18 and Table 9.14 respectively.
Enterprise
51,52
e-Travel
System (ES)
System (ETS)
53
Accounting
System (AS)
Table 9.18 Service Model for Travel Requisition Solution
Application Name Application(s) Description Input Output
Providing Using the
the Service Service
Enterprise S1: Check e-Travel System This service

Employee 10

Settlement
System Settlement checks the Status
Status settlement status
in ES and returns
the value
S2: Record e-Travel System This service

Employee 10

Success
Currency records the

Issued date Status
Issuance foreign currency

Issued
that has been
amount
issued to an

Currency
emr>loyee
Accounting S3: Issue e-Travel System This service

Vendor 10

Success
System Payment allows payment to

Date Status
vendor by

Payment
updating the
amount
payment details to

Payment
the Accounts
currency
PC!Y_able function
Table 9.14 Service Description Model for Travel Requisition Solution
Service Level

Round trip
duration less than
3 seconds.

Process up to 20
concurrent
requests

Process up to 1 0
concurrent
requests

Process up to 1 0
concurrent
requests
1'\.)
1'\.)
1'\.)
C':l
C)

C")
tb

....
Cl')
C)
i::
=::::!:
C)

0::1
i::
tb

g .
....
):,.
C")
=::::!:

(b
(/)
Risk Modelling
We next identify the risks associated with technical aspects of the proposed IT Solution. The soft risks on
organization and people have already been discussed when we proposed the To-Be Process. The Risk Model
is shown in Table 9.15.
Risk Description Impact Likelihood Rating Mitigation Strategy Mitigation Impact of Strategy
Type
Settlement status may Medium Medium B Before starting the Reduction Slight additional design
not be easily computed implementation, effort required
or retrievable since ES is conduct detailed
a legacy system technical study with
ES's Technology
Expert
Efforts to obtain, import High Medium A A detailed study of the Reduction Significant increase in
and maintenance of following is required: efforts and resources to
routing detail could be

structure of the conduct this study and it
enormous due to the entire organization may not be easy since
size of the organization

how the structure is
GSPL is a worldwide
currently stored
organization.

How rapid the
organizational
changes could be
Table 9.15 Risk Model for Travel Requisiti on Solution
C'":l
C)
:::::J
C")
Cb

....
Cl')
C)
i::
=::::!:
C)
:::::J
t:x::J
i::
Cb

....
):,
C")
=::::!:

tt;
(I)
1\.)
1\.)
w
Concept Cost Modelling
The cost can make or break the success of an IT Solution. In the Concept Cost Model , we assess the initial
cost components for the proposed IT Solution. More often than not, if the risk and cost are assessed to be too
high for an IT Solution, we should re-look at the proposed IT solution, the IT Solution Requirements and even
the recommended To-Be business process. Table 9.16 shows the Concept Cost Model. In our case for GSPL
Travel Requisition Process, the overall cost seems to be manageable. We would, as such, stay with the
solution developed so far.
Fixed Costs Maintenance Total Cost Rating Justification
No Items Costs
Low Med High Low Med High Low Med High
1 Hardware Total
./ ./
1.1 Servers
./ ./ ./ ./ ./ Only ETS requires new hardware and
based on the initial study of the
requirements (functional and non-
functional ), the hardware requirement
should be well within range of $50K -
$200K
1.2 Email, Fax, Printers - - -
./ ./
Re-using existing infrastructure
2 Software Total
./
2.1 Database
./ ./ ./
2.2 Portal ./ ./ ./
3 Process Redesign Total
./ ./
3.1 Process study
./ ./ ./
Relatively simple business process
involving few stakeholders
3.2 Change Management
./ ./ ./ ./ ./
Relatively manageable and convincible
since the travel process has been a pain
point for the longest time. However, as
there are few organization changes, e.g.
merging of visa dept and redeployment of
dispatch dept and forex desk, lay-off or
redeployment efforts could be significant
1'\.)
1'\.)
.j::>.
C'":l
C)

C")
tb

......
Cl')
C)
i::
=::::!:
C)

0::1
i::
tb

g.
......
):,
C")
=::::!:

(b
(/)
No
4
4.1
4.1.1
4.2
4.2.1
5
5.1
5.2
Fixed Costs Maintenance Total Cost Rating Justification
Items Costs
Low Med High Low Med High Low Med High
Design and Implementation
./ ./
ETS
./ ./
Requirements
./ ./ ./
Design
./ ./ ./ ./ ./
Depending on the functionality of the
portal deployed and the amount of
extensions required to satisfy
requirements, efforts could vary
Construction
./ ./ ./
Test
./ ./ ./
Documentations
./ ./
Project Management ./ ./
Enterprise Systems
./ ./
Design & Modifications
./ ./ ./ ./ ./ Depending on the complexity, the effort
could be medium or low. This is also
listed as one of the risks
Test
./ ./
Documentations
./ ./
Deployment and training ./
ETS
./ ./ ./
New system and organization wide
deployment. Training efforts would be
significant
ES ./ ./ ./ Changes to the system are made for
automated functions. Little end-user
training required
Table 9.16 Concept Cost Model for Travel Requisition Solution
C"")
c

C')
tb
"t::l
.....
Cl')
c
t:
g.

t:XJ
t:
tb
"t::l

.....
):,.
C')
:::t

ct;

1\.)
1\.)
01
Conclusion
The models we have developed so far provided insights to both business
aspects (Business Modelling models) and IT solution aspects (Concept
Solution Blueprint models). The models show the changes that need to be
made to the process, how technologies can be used to improve the
efficiency, what application needs to be built and the changes to the
existing IT Applications that must be made.
In the To-Be process that we have recommended for GSPL, we
could potentially improve the processing time by up to 70% and savings of
approximately half a million dollars in a year on human resources. We aim
to achieve this performance through automation and deployment of
technologies. The concept IT Solution involve use of an online Portal to
handle travel related functions. The solution involves 3 applications - 1
new application and reusing 2 other applications (1 of which to be
modified). Based on output from the concept solution blueprinting activities,
we feel that the complexity, risk and cost for the changes are manageable.
Beyond the Concept Solution Blueprint phase, the implementation
team should bring the solution into further detailed study of the
requirements and system design before implementation.
Summary
In this book, we have presented a Business Process Engineering
Methodology (BPEM) that brings formalization and repeatability to the
process of translating business objectives into IT solutions through a
collection of models, techniques and tools. The BPEM comprises of two
phases, namely, Business Modelling and Concept Solution Blueprinting.
The Business Modelling phase helps both the business and IT personnel
to:
Understand the current business process by capturing it through the As-
Is models
Identify the problems in the process by analysing the As-Is models
Design a new process and capture it through the To-Be models
Analyse and optimise the new process
Define the requirements for an IT based solution to support the new
process
The Concept Solution Blueprinting phase helps both the business and IT
personnel to:
Understand the proposed IT based solution at a high-level of abstraction
by designing and capturing it through various models
The Business Process Engineering Methodology presented in this book is
best suited to the pre-proposal stage of an IT project, where a feasibility
study is carried out or the proposal stage, where the aim is to come up with
a solution proposal. In the context of these stages, both consultancy
organizations that provide IT services to external clients and in-house IT
departments that provide IT services to internal clients can use it. The
methodology is best suited for IT projects that aim to automate a business
process.
Though the book presents a methodology, in practice, one should not
adopt a cookbook approach; rather, adapt the methodology to suit the
project and the organization. Not all steps and models will be required in
every project and details of steps and models may be adapted.

Aligning IT Solutions With Business Processes

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Aligning IT Solutions With Business Processes

Caricato da

Copyright:

Formati disponibili

This page is intentionally left blank.

14 Travel Desk 16) l to be complet ed before

Potrebbero piacerti anche