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 nonfunctional 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 [email protected].

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. 2. 3. 4. 5. 6.

What is a Business Process? Example Business Processes Business Strategies and Goals Business Process Management Process Architecture 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

Business Process and IT

2

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-tocash process. These include receiving the order, checking the customer credit, entering the order, fulfilling the order (production/shipping), invoicing


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

FINANCE

Check Credit

ORDER ADMIN

Enter Order

SHIPPING

Ship Item

ACCOUNTS

Process Payment

Figure 1.1: An example order-to-cash process

Activity 1.1 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


4

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 subprocesses. 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.

1

Process Billing Process

Explanation This process encompasses provisioning of billing to customers, supporting the billing and assuring accurate invoicing and collection of all revenues due to the


2

Assurance Process

3

Billing and Collections Management Process

4

Fulfilment Process

5

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. 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. This process encompasses the 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. 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


6

5

Human Resource Management

6

Financial and Asset Management

order, ensuring timely completion as well as customer satisfaction. This process encompasses the 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. This process encompasses accounts 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.


7

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 claims processing insurance business 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 Define business strategy

l Establish goals to achieve strategy

l Convert goals into functional /department goals

l Convert functional goals into job objectives

l Establish measures to track performance against job objectives

1990s- Present Define business strategy

l Establish goals to achieve strategy

l Convert goals into objectives for cross-functional processes

l Convert process objectives into activity objectives

+ Relate activity objectives to 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.

8


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?


9

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?

10


• 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.

At this level the concerns may be: • 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


11

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. At this level the concerns may be: • 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.


12

Define business

__.

strategy

Establish goalfs to achieve strategy

I

Initiate~

Process change

c----------------------------------------------------------------~~~~~~---------------------------------------------------------------, : BPM

Enterprise

i

• Develop process architecture • Define process strategy matrix

Process • Develop concept solution blueprint • Design and implementation of solution • Design and implement event monitoring and processing solution

• 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?

~pacts • 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

Imp~

Process

• If we remove the number of Impacts

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


13

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.


14

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

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

5. Process Architecture 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.


15

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.


16

Business Unit 1

Business Unit 2

Core Processes Group 1

Business Unit 3

Business Unit 4

I

Process 1

I

Sub-Process

I

I

Sub-Process

I

I

Process 1

I

Sub- Process

1

Core Processes Group 2 Process 1

I

I

I

Sub-Process

Process 2

I

Sub-Process

I

Sub-Process

I

I

Sub-Process

I

I

Sub- Process

I

I

Sub-Process

I

Supporting Processes Grou~ 1

I

Sub- Process

I

I

Sub-Process

I

I

I

Sub-Process

Figure 1.6a Executive View: Example Template I Sales and Marketing

Finance

Warehouse

I

Resource Management and Operations

I

Transportation

II

\

/ (ogistics Processes Collection and Delivery Process

I

Order Handling

I

I I I

Dispatch and Delivery Package Collection

Shipment Process

I

Packaging

I

I

I Warehouse Management Process

"----

I I

I I Customs Clearance I Fleet and Package Assignment I Shipment Route Planning

Inventory Management Supply Chain Management

I I /

I

\

/strategic Planning Processes Strategic Sourcing Management

I

I I I

Collection Route Planning

I I

Strategic Warehouse Selection

I

Resource Data Collection and Analysis

I I

Performance Measure and Review

I

3PL Vendor Management

Strategic Management Control Process

I I

I

Policy Development and Administration /

Operations Support Processes

I

Audit and Readiness Process Fleet Management Process

I

Fleet Maintenance

I Fleet Procurement I

Manpower Allocation

I

I I

Figure 1.6b Executive View: Example for a Logistics Company (partially complete)


17

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

Sub-Process

Sub-Process

Sub-Process

(L2)

(L2)

(L2)

H

Sub-Process

(L3)

-

-

H

Sub-Process

(L3)

Sub-Process

(L4)

-

Sub-Process

-

Sub-Process

Sub-Process

(L4)

H

I

...

Sub-Process

r--

(L3)

I

4

...

I

Sub-Process

(L4)

(L3)

(L3)

~

Sub-Process

(L4)

Lx- Leve lx Sub-Process '----

(L3)

-

Sub-Process

I

(L3)

Figure 1.7a Process Hierarchy View: Example Template


18

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 Event

The event that initiates the process

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 Sequence

A diagram describing the sequence of the process showing the various sub-processes and 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 Measures

Metrics that will be used to determine the effectiveness of the process

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 Event

One of the following event: new account/new order/account renewal/update pervious 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 Sequence

See Credit Authorization Process Flow View

Responsibility

Credit Assessment Manager

Roles

Finance Clerk, Credit Assessment Supervisor, External Agency

Performance Measures

Credit Authorization is completed within 1 working day Amount of bad debt due to inability to pay by the customers Number of inappropriate credit authorization

19

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 subprocesses and activities and the sub processes contain activities and subprocesses. An instantiation of this template for the Credit Authorization sub-process of a Logistics company is shown in Figure 1.8b.


20

Note

Process A

8

0

·I Sub-P~ocess I

D Sub-Process A

Sub-Process B

= Decision box

Activity

D

Sub-Process B

~---l.___A_ct_iv_ity------'1-G

Figure 1.8a Process Flow View: Example Template

Obtain Appropriate Approvals

j Yes Advice Credit Terms

Credit Investigation Credit Authorization Process

~

).o

Receive Credit Check Request

Obtain the Necessary Information

Calculate and Assign Credit Score

Credit Investigation Sub-Process

Figure 1.8b Process Flow View: Example for Credit Authorization Process (partially complete)


21

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, lrtra slro..clt.re & Prcd.Jd l::tntegy & Can nit

Operatims

ll Lifecycle lrtra~~Lre

Operatims

r Lifecycle rro.cl M
S~rt&

MarkEii n;J & Offer Management II

II

II

r~llin;J

I

II

I

I

Resa.rce Managemert & cper:ti ms (jpplic;;rtion, Cofllluting and N
II

I

O..in De11elcpment & M
II

Assuan::e

l

II

II

I

Sero.i ce Managerrert & Operatims

Resoo..rce De vel cpmert & Managerrert (JlprJicaicn, CofllJUirg <11d ~ crk)

SU~y

Ft.Jfill rrert

D..!stcmer Rel:ti mstip Management

Seroj ce Develcprrert & Management

I

II

Read ness

I

SLWiier/Partner Relatimship Managerrert

II

I

II

Erterprise Managerrert l

strat~glc &. Bl~ rpH a A am lng

I

l l

~rpr1 1a

Financial &A ue t 1,\lna ~ma nt

Ill

l.tmagem ant

•~

II

~ ~ 1,\lnagem ~rpr1 1aant El'f;chrane •1 l lo\lnagem !Qlowlad~ant&. ~oaarc 11 1

sta~e l~)ld&r & E1 ~rm 1 1 1 Hllll an Re tcu rce 1 Re l a ~ o n t 1,\ln agem~nt

M an agem~nt

I

Figure 1.9 The Enhanced Telecom Operations Map® [eTOM]

22


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-toend 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].


23

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.


24

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.


25

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 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.


26

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


27

• 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.

28


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 stretchwrap 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. 2. 3. 4.

Business and IT Alignment Need for a Methodology Requirements Business Process Engineering Methodology (BPEM): An Overview

References

Learning Objectives On completion of this chapter, you will be able to: • 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 nonfunctional requirements • Understand the various phases of a Business Process Engineering Methodology (BPEM)

Business Process Engineering Methodology

30

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.

Business Process IT capabilities and challenges shape the Business Process

Business Process change impacts IT

Figure 2.1 Business and IT alignment 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


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.

32


• 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


33

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.

34


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


35

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.


36

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 nonfunctional 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


37

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.

$100X

ti

$50X

0

()

$3X 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 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

Functional/Non· Functional


38

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-STANDARD-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


39

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.

40


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. 135137. [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/wsbdd/index.html , December 2005.

CHAPTER 3 BUSINESS MODELLING ACTIVITIES

Chapter Topic List 1. 2. 3. 4. 5. 6. .

Overview As-Is Modelling As-Is Process Analysis To-Be Modelling To-Be Process Analysis IT Solution Requirements Definition Summary of the Activities

References

Learning Objectives On completion of this chapter, you will be able to: • Understand the various activities of the business modelling phase

Business Modelling Activities

42

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

.

Define Solution Space (Business to System)

.-------------------------------------!

:

To-Be Modelling

~

~~

Issues and l_----------------------Recommendations

To-Be Proc~

-~~~~~~~~---

..

To-Be Models

IT Solution Requirements Definition

l IT Solution Functional and Non-Functional Requirements

Figure 3.1 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 Business Analyst

Expertise • 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.

44


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. As·ls 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


45

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.

46


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 nonfunctional 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


47

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 As-Is Modelling

As-Is Process Analysis

Purpose Elicit and document key business process and related information required to assess the business need of an IT solution Analyse the As-Is models to elicit and understand the issues or pain points. Based on the results of the analysis create a set of recommendations to address these issues by leveraging IT enabled solution ideas

Input Business goals, change intent

Output As-Is Models which identify and describe the current problem scope

As-Is Models and industry reference models

As-Is Process Static and Dynamic analysis document which discuss the issues and propose recommendations


48

To-Be Modelling

To-Be Process Analysis


Translate recommendations into specific To-Be business models

As-Is Models, AsIs process analysis document, proposed recommendations

To-Be models which documents the future business and high-level system behaviour that would be required to implement the recommendations Analyse the To-Be Models, Dynamic 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 Map and detail To-Be Models Document the functional and describing the 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] InFlux™ Materials, lnfosys Technologies Limited, 2004. Please see the acknowledgement for more details.

CHAPTER4 BUSINESS PROCESS MODEL

Chapter Topic List 1. 2. 3. 4. 5. 6. . 8. 9.

Overview Organization Model Location Model Collaboration Model Process Catalogue Model Workflow Model Business Rules Model Modelling Notations Use of Tools

References Case Study- GSPL Travel Requisition Process

Learning Objectives On completion of this chapter, you will be able to: • 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

Business Process Model

50

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. Business Rules Model o

Organization Model o

Captures the rules that must be applied when performing an activity

Collaboration Model o

Captures the roles and the reporting structures o

Location Model o

o

Maps geographic location of the business Provides deployment view for the solution

Captures interaction of various entities within and outside the organization Gives a high level view of interaction and work product exchange

Workflow Model o

Process Catalogue Model o

o

Captures sequence of activities Provides the process flow view

Captures the subprocesses within a process

Figure 4.1 Views of a 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§ Retai l Company

~

Organization

t

I

j

do

0

~~

Sales

Regional Manager

Ware house

i

0

0

Sales Manager

T

I

Store Manager

i j

0

Q

Sales Agent

Store Kee per

Role

Figure 4.2 Example Organization Model

J

52


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.

lOrganization Contains

1

1..*

Contains

[ Department ..... Contains Contains

1..*

.r

l

I ll.. *

Role

I

Superio 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?


53

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

54


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.


55

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 fulfilment process for a catalogue sale retail organization.

~

us

New York Office

Atlanta Offi ce

Dallas Office

Sales

do

~

Warehous ~

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


56

• 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 In the context of understanding the business and developing an IT solution, 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


57

stakeholder departments in these entities are stationed in various physical locations and their location specific needs or solution deployment have to be addressed

Sample Elicitation Questions 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


58

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 fulfilment process for a catalogue sale retail organization.

f'-

~ ,

I

Interaction

~'"r---.-----,

0

Valldate

Q

Customer

esponr

Sales

I

ll

I

1

I

Billing

System

I

Agent

difi~d

.___--.--'NeworM OrderO tall

Sales

N,ew o~ Modilied Order Details

1

Order Detail

System

Invoice

Figure 4.6 Example Collaboration Model 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


59

Figure 4. 7 Meta-Model for the Collaboration Model

Activity 4.5 In the context of understanding the business and developing an IT solution, 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

Sample Elicitation Questions • • • •

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?


60

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. 3. 4. 5.

61

Select the start of interaction from this participant to trigger the need and identify all interactions that are necessary to fulfil the need Name the process (sub-process) for this need fulfilment Eliminate the transactions that have been identified under this process from the collaboration model 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 fulfilment process for a catalogue sale retail organization.

Figure 4.8 Example Workflow Model


62

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


63

Activity 4. 7 In the context of understanding the business and developing an IT solution, 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


64

Sample Elicitation Questions • • • • • •

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.


Sa les

l

65

Enter Ord~r

l

J

Reject Orde:

00 Finance (

o.t..mioe Dis co unt

2

f

·l

~

D•t.,mioe~

Credit Worthiness 3

Bad

Good

•

Accountant

l

~

Calculate Price 4

l r

Delivery

j

I

De liver 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 Claimant is an employee AND injury occurred on premise AND there is medical necessity

IF a customer has a gold account

AND procedure is covered

THEN issue a gold credit card

THEN adjust amount billed

ELSE issue a standard credit card If Claimant is an employee IF total miles earned is > 10,000

AND injury occurred off-premise

THEN change status from blue to silver

THEN reject claim

IF loan type is first mortgage

If Claimant is not an employee THEN reject claim

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

Figure 4.11 Example Business Rules


66

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 Rule Set

Determine Credit Worthiness

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 Then credit worthiness is good

And external rating is bad 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.


67

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.



68

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.


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

70


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 1Okm 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


72

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


74

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


76

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.


77

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 ~~

d~

d~

I

J ~~

Visa Desk

Travel Desk

Dispatch Dept

Fo rex Desk

Accounts Dept

All Employees

I

iI

d~

~. External Parties

Bank

E~ernal parties

-

who have a stake in the travel process

Embassies

I

~

--

Virtual dept to denote all em ployees from allloc ations & depts. Any e mployee can be Travel er/PUBM .

I

Q

Q

Q

Business Manager

PL

Traveller

Travel Agent

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 Emp loyees -- 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.


79

Collaboration Model

;

J~

Q"~

Request form

Trave ll er

I

External

I

Internal

Trave l Desk

Request form

Ti ckets Tickets

Q"~

Travel Agents

Reque !form

Di spatch Dept

~I

I Ti ckr ts

Clarifications

li

Approval

PL

;

Approval

Bu sine ss Mana ger

Q"~ Reque st Form Approval Visa Request, Trave l Do cument

Visa and Trave l Do cument Forex Request Foreign Curren cies

Accounts Dept

Vis~~esk Q"~ Forex Desk

Visa Reque st, Tr vel Document

I

!

Visa and Travel Do cument

I

~~

I

Forex Request Foreign Currencie s

Figure 4.14 As-Is Collaboration Model

·1 Embassies

I

£~

I

Bank


80

Process Catalogue Model

Through a close examination of the Collaboration Model of the Travel Requisition Process, the following processes (sub-processes) are identified. ,-------

Internal

Exlernal

1

0

((~

Request form

Trave ller

Travel De sk

Request

form~

Tickets Tickets

· Dispatch cl Dept

~

I

I

Reque~t

Travel Agents

torm

I

L__

Tickets

Clarifi cabons

[;]

Approval

0

Approval

Business Manage r

o"O

Request Form

Accounts Dept

Approval Visa Request, Travel Document

Visa and Travel Docume nt ForexRequest Foreign

r:um>nt.ie~

Ticket Requisition Process Visa Request, Travel Document

o"o I

VIsa De sk

I

I

I Visa and Trave l

O:o

cI Embassies

J

oacume\fiS? Requisition Process

o"o ForexDesk

Forex Request

"'~~~~rex

cl

-a"o Bank

n. Req 1uisit.v,

Figure 4.15 As-Is Process Catalogue Model

IV\.."-ss

0::1

Workflow Model: Travel Requisition Process and Ticket Requisition Sub-Process Traveller

'

If ll

!~-----------------~

Flll thetravel requestrormt

Submltto8114~

Submlt toPLI:iilj (

2 )

4

l~::.:f} ~ ~ ~... '"

: (

VosaDeptit requlred 8

J

[

Collect tickets fro~ TraveiDesk , ,f-----.-1 18/ --.

l

l

Dept

._._ti~

lr

J-;m

-l

ll I

~

~ertty~ ok? N e

l

Verify settlement )

'-

[tj]

(

~ Receive forms from Travel Desk

Dispatch rorrns Travel Agents

13

Travel

j

•:J 14

'

17

Fork to para llel actM1ies

,

~-Collect tickets fro~~ ents and send back to Travel Desk

Sub-process

~

coltec~~~~cket If

If overseas trave l

ManuaiActMly

a::=:D

( Email traveller to

I

J.

~

Legend

request to travel agents 10

do Dispatch Dept

-~ - r~------ 1 ------~lj·-----------------------

Assign trave~

details Verifytravet

'---___:9_,.,

~

C)

c.

-ye!es-rr • - - - - - - - -1- - - - statu s 7

l

Travetoesk

(/) (/)

" ( Requests traveller to ~_ submltcorrect rorm 6

5

Atcounts

\:)

(3 Cb

orreje~cAppr - oved

Apprave request

_ f.:\

C")

_No

0

Cb

(/) (/)

~

1

'!:':~~~~~

0

( Desk_ Sub requesttoTrave8 Also to Forex and

c::: ::5"

(/)

~

16)

l

'

_ Jo10 -Activity 1 & 2 needs to be complet ed before starting Acti';ity 3

j_

Agents

Purchas~ [

"

V

Forex Desk

®

Visa Desk

tf_~

Tickets 15) f - - - - - _ J

If overseas

travel

l-l

J

~

1

~~~~~:0~~:

ln

11[)r - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - _ j

VIsa Appllcallon Subprocess

12

llJ

t------------------------------------

Figure 4.16a As-Is Workflow Model CX) --"

co

"'

Forex Requisition Sub-Process iTNMIIer --..[

0 ForexOesk

Vertt,' travel detail and assign requests to agents 1

o"o

Pnl¥ide sanctlo 1ener to Bank

SubmHForex~

sanction IaUer 10 Bank 3

2

Bank ( Verifyandlalj Issue For,)

•

.(i) ~

Figure 4.16b As-Is Workflow Model Visa Requisition Sub-Process ~sa Desk

o-o Embassies

I

..-

.rlandverifyassign travel datal~~ req uests to agents

llssue Travel related documents

1

J · ~

d'o

j_ 3)

•

ProcessVJsa ~

2)

Figure 4.16c As-Is Workflow Model

0::1

c::: (I) :::i'

Cb

(I) (I)

\:)

(3 C')

Cb

(I) (I)

~

C)

t:::l..

~


83

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


Overview Issue Elicitation Issue Analysis Recommendations Formulation

References Case Study- Static Analysis for the GSPL Travel Requisition Process Appendix A- Catalogue of Horizontal Process Patterns

Learning Objectives On completion of this chapter, you will be able to: • 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]. Problem Space

Interview Scripts As-Is Models

l

Solution Space

Patterns/ Best Practices

l

Issue Elicitation

Issue Analysis

Recommendations Formulation

Figure 5.1 Static Analysis Methodology When the necessary information on As-Is process is gathered and the AsIs 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


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


87

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?

88


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 Description

Category

Cause Description

Root Cause

Impact

Impact Level

Table 5.1 RCI Model Template

Business Measure Impacted

Business Factor Impacted


89

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


90

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

Issue #

Issue Description

Category

Cause Description

Root Cause

Impact

Impact Level

1

Enrolment info is captured, validated and input at different stages by different participants in the processthus leading to errors

Process

Paper based collection of info gives participants liberty to capture incorrect or incomplete info

2

...

...

...


Govt Regulation to capture info on paper

More resources are needed to perform these non-value adding tasks of error verification

High (4)

No of enrolments

Productivity

...

...

...

...

...

Table 5.2 RCI Model Example: Process Category



91

Process Name: Order-to-Cash

Issue #

1

2

Issue Description

Category

Cause Description

Root Cause

Customer information needs to be re-keyed into multiple systems

System

Systems do not talk with each other and thus the same information is entered multiple times

Lack of system integration

...

...

...

...

Impact

Impact Level


Contribute to a high elapsed time. Also it results in data inconsistency across different systems

High (4)

Measure 1: Total Process Time

...

.. .

Measure 2: No of inconsistent data points between systems with regard to customer record

...


Factor 1: Efficiency Factor 2: Quality

...

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

1

Recommendation

Recommendation Impact Score

Complexity of Implementing Recommendation

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.

92


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


93

Table 5.5 shows an example of the Root Cause Recommendation Model. Root Cause

Recommendation

Govt. Regulation to capture info on paper

1.

...

...

Form cooperation with other insurance companies to propose change to the Govt.


Complexity of implementing recommendation

4

Highly Complex

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 AsIs 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

94


Figure 5.2 Example Use of the As-Is Workflow Model



95

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 highlevel recommendation model which addresses the problems with the current process. In this report, "we" represents the BPE team.

(0 (j)

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 lmp~act Level uses the following scale: Very High - 5, High - 4, Medium - 3, Low - 2, and Very Low -1.

Process Name: Travel Requisition Process Issue

# 1

Issue Description

Category

Cause Description

Root Cause

Impact

Impact Level

Traveller has to manually go to many departments to verify and process forms. This takes too much time.

Process

Non-automated paper-based collection of info gives participants liberty to capture incorrect or incomplete info

Paper-Based System

Wasted time in non valueadding tasks causing frustration and reduce employee productivity

High (4)

Business Measure Impacted Cycle time

Business Factor Impacted Productivity

~ C")

tb

en en )::::. ~

s:u

~

en

'?" Cr)

~

~ )::::. ~

s:u

~

en

c;;·

Issue #

Issue Description

Category

2

The business manager's role is trivial. All he does is check the project code.

Policy

3

Particular people must be in the office in order for the process to flow. Otherwise the process is halted.

Process

Cause Description

Root Cause

Verification of the project code is required before travel desk would proceed with the bookings

Separate roles/depart ments with redundant functions

Employee has to do all the legwork himself, since he cannot be in 2 places at the same time. The process becomes sequential even if there are parts that can run concurrently

Paper-Based System

Impact

Business Manager's time is wasted and employee has to seek additional approval Employee's time is wasted and the process cycle time becomes very long

Impact Level Low (2)


Business Factor Impacted Productivity

~

C")

Cb (I) (I)

:b. ~

~

~ (I)

~Ci')

~

~ :b. ~

~

~ (I) Ci;•

Medium Cycle (3) time

Productivity

tO ""-!

Category Cause Description

Root Cause

Impact

Settlement details are not easily retrievable from the ERP system, hence relied on paper verification

Business-IT misalignment in existing system

Medium (3)

Policy

Bureaucracy within the department delays travel approval process

Separate roles/depart ments with redundant functions

Delays in processing travel approval result in decreased worker productivity Delays in processing travel approval result in decreased worker productivity


Medium (3)

Cycle time

Productivity

Process

The process is paper-based, so the readabi lity of each form is dependent on the employee's handwriting.

Paper-Based System

Inaccurate results or increased processing time due to the need for clarification

High (4)

Accuracy of forms, Cycle time

Accuracy, Cycle Time, and Cost

Issue #

Issue Description

4

System Checking of settlement details is inefficient, time-· consuming and prone to human error

5

Too many levels of sequential approvals (project leader, business manager, accounts dept, etc) required, resulting in long cycle time Illegible writing makes forms unreadable and error-prone

6

Business Factor Impacted Productivity, Accuracy (of data)

Impact Level

(0 (X)

~ C")

tb

en en )::::. ~

s:u

~

en

'?" Cl')

~

~ )::::. ~

s:u

~

en

c;;·

Issue

# 7

8

Issue Description

Category

Any mistakes made in the process would require the entire process to restart

Process

Urgent request cannot be processed promptly

Process

Cause Description

Root Cause

The process has been designed not to allow error exception. In the case of an exception, the entire scenario will have to start from the beginning As dispatches are done only once or twice per day, urgent requests that are submitted between these times have to wait for the next dispatch which resulted in long processing time

Paper-Based System

Paper-Based System

Impact

Impact Level

Time is wasted on restarting the process and inefficiencie s occur.

High (4)

Traveler is not able to travel on schedule as required by the business

Very High (5)


Business Factor Impacted Accuracy, Cycle Time, and Cost

~

C")

Cb (I) (I)

:b. ~

~

~ (I)

~Ci')

~

~ :b. ~

~

~ (I) Ci;•

Cycle time

Productivity

tO tO

Issue #

Issue Description

Category Cause Description

Root Cause

Impact

Impact Level

9

Employees are unable to check request status or update travel details

Process

Overdependence on phone calls

Employee's time is wasted on making several calls; changes in travel plans might not be updated in time

Medium (3)

Employees may take a long time to get request status and have difficulties to update the Travel Desk of changes in their travel plans as the phone is always engaged when they call

Business Measure Impacted No. of travel status checks supported per day

Business Factor Impacted Productivity, Accuracy

0 0

Table 5.6 RCI Model for GSPL Travel Requisition Process

~ C")

tb

en en )::::. ~

s:u

~

en

'?" Cl')

~

~ )::::. ~

s:u

~

en

c;;·


101

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.

102

Root Cause

Overdependence on phone calls

Paper-Based System

Business-IT misalignment in existing system


Recommendation (based on horizontal process patterns) 1. Use an automated telephone system 2. Use an online system to provide process-based experience such that it allows employees to update or check the status of their travel arrangements 1. Use an employee selfservice online system to handle travel related matters 2. Share electronic information with external partners such as auto-fax or email electronic travel request forms to travel agents 1. Develop interface to retrieve relevant data to facilitate settlement checks 2. Integrate new online system (if any) withES to perform settlement checks automatically



2

Moderate

4

Highly Complex

5

Highly Complex

5

Moderate

5

Moderate

4

Highly Complex


Root Cause

Separate roles/ departments with redundant functions

Recommendation (based on horizontal process patterns) 1. Merge Visa Desk with Travel Desk 2. Cut down the need to work with so many departments through automation. E.g. automate settlement status checks and generation of sanction letter 3. Streamline approval process by cutting down approval requirements such as getting supervisor to check project code instead of business manager 4. Streamline some activities to allow some functions to be done in parallel , e.g. approval

103



3

Complex

4

Complex

4

Moderate

2

Easy

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

104


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 L __

Travel Desk

_ J ,___

Business Manager

.,_

___,

:

PL

Traveller

-

1- ---- -- -------------J ----------1

-- : changes

.. ~ External Parties

--- -

External patti es who have as take in the travel pro cess

I

I

: I

'----------~

t

~~

~~

~~

Bank

Embassies

Travel Agent

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, inability to do parallel processing). The online system provides a onestop-solution for employees to apply for travel.


105

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.

106


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.


107

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) Impact: Improves efficiency. 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. Impact: Improves efficiency.

108


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 when the order is placed. Hence, customer is not able her order. For example, if a Travel Booking Request customer is unable to verify the status of the request or

service ends to track his or is placed, the 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.


109

Solution: Look at the workflow to see if the information or document required can be shared. Impact: Better maintainability and traceability. 10.

Outsourcing

Context: Some non-core business functions have high cost-ofownership 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 Hand·Offs

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.

110


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.


111

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


Overview Tools for Dynamic Analysis A Methodology for Dynamic Analysis Limitations of Dynamic Analysis

References Case Study- Dynamic Analysis for the GSPL Travel Requisition Process

Learning Objectives On completion of this chapter, you will be able to: • 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. costoverrun, 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-oninvestment) of streamlined business processes before retraining and retooling • Enables organizations to quickly redesign processes or plan future processes as business needs change

114


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 exceptionhandling 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)


115

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

~·······························~

•

Modelling Activities & Simulations

,--------------------

Establishment of Process Performance Targets

1

I

i~

Simulate & Analyse As-Is process

I

I I I I I I I I I I I

Start

1

Identify Simulation Parameters Modelling Preparation Activities

Simulate & Analyse To-Be Process Alternatives 1

L ---------------------~

Revision if impact is not acceptable

4 1---- - - ------, Final Selection of To-Be Process for Implementation

Impact Analysis of the To-Be Alternatives

End

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


116

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. To-Be process

Baseline As- Is process Redesign based on process performance targets

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 and their priorities

~

Step 2: Identify any binding organization policies 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


117

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.


118

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.


119

Activity

Fill the travel request form

Time taken to complete activity

Normally distributed between 18-22 minutes, average of 20 minutes

Simulation Parameter using Tooll

Distribution: Normal Time unit: minutes Mean: 20 Standard Deviation: 2

...

~~

1 I

Activity

General P
l/isualzaloo

SirnJiotlo<1

Du' otio<1 OistrWoo:

I:lliiila

rmelri:

r==

Maxilun Delay SLA:

De
~E

[20

MeM:

Stondord Devlaloo: [2

Est mated mean cost ol actlvly Is: 100

Simulation Parameters using Tool2

Distribution: Normal Time: 18-20 Time unit: minutes

. , ..

)(

ActMtvTwe

GUde

3

IActivtv Modefng

l ine;

Input•

l o~trWed

Resoo
Task

IN<>mal

D ~•

3 3

ra--

to

~

IMm..

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.

120


Capacity Analysis

This involves measurement of the maximum capacity of the process based on a set of defined operational conditions.

Process Cycle Time/Cost Analysis

This involves understanding of the duration (time) and cost of the process cycle. E.g. The order fulfillment process takes average of 20 minutes with standard deviation of 2.4 minutes.

Resource Utilization/Cost Analysis

This involves understanding how the resources (human or machinery) are utilized in the process and how much cost it adds to the process. E.g. Order entry clerk is over-utilized at 127%.

Activities Time/Cost Analysis

This involves understanding of the duration (time) and cost of each individual activity in the process. 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 ana lysis, 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) Analysis

This involves analysis of the various paths that constitute the whole process. Paths are usually results of decision points. Some Dynamic Analysis tools refer to this as a 'case'.

Unusual Event Analysis

This involves analysis of events that may have a huge impact on the process but it does not occur 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?

E.g. The order management process can handle up to 1000 transaction a day over a period of 8 hours.

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


121

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). Issue packaging instructions to warehouse /

~

/ /

Impacts / / /

/ /

¥

/

Issue shipping instructions to Fed Ex

Send shipping info to customer

t I I 1 Impacts

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.

122


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.


123

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.

1. 2.

3. 4.

Priority Process Redesign Goals Achieve a more efficient Travel Requisition Process for High all travellers Reduce the manual activities involved in the Travel High Requisition Process so as to reduce the time wasted and errors made To reduce the overhead of approval for the project High leaders and business managers Medium To lighten the load of the various GSPL departments (e.g. Travel Desk, Financial Department) Table 6.3: Process re-design goals for the To-Be process


124

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.

1.

2.

Process Performance Targets Increase overall efficiency by reducing the processing duration for a travel request by at least 25% Reduce the overall cost for a travel request by at least 10%

3.

Remove the bottlenecks that have been identified

4.

Reduce manual activity

Metrics Average Duration of travel requests for each individual path Average Cost of travel requests for each individual path Number of bottlenecks and the delays caused by each of them 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.


125

Key Data Number of travel request per day

200

Value

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 process

$2

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 Unlimited

Traveller

Not modelled

830-1730hrs MonFri (lunch 12001300)

Finance Advisor

US$65 /hr


3 (Finance-1, Finance2, Finance-3)

Travel Advisor

US$50 /hr


3 (Travel-1, Travel -2, Travel -3)

Project Leader

US$75/hr


50 (PL-1

PL-50)

Business Manager

US$120/hr


5 (BM-1

BM-5)


126

Role

Cost

Available Time

Number and name of resources in the Role 1 (Visa-1)

Visa Advisor

US$50/hr 830-1730hrs ManFri (lunch 12001300)

Travel Agents

N/A

Distribution Personnel (Urgent)

US$25/hr 830-1730hrs Man Sat

Distribution Personnel (Urgent)

US$25/hr 930-1130hrs

Bank

N/A

830-1730hrs Man Fri (lunch 12001300)

Unlimited

Embassy

N/A

0900-1700hrs

Unlimited

0900-1900hrs

4 (Agent-1

Agent-4)

3 (Distribution-1 Distribution-3)

1630-1830 Man Sat

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

Bring Form to Project Leader (PL)

PL Approval

Bring Form to Business Manager (BM) BM Approval

Duration (minutes)

Normal distribution Mean= 15 Std D = 2 Normal distribution Mean= 18 Std D = 3 Normal distribution Mean= 15 Std D = 2 Normal distribution Mean= 12 Std D = 2

Role Resource Traveller

Project Leader Traveller

Business Manager


Activity name Take Travel Request To Travel Desk Check Settlement Status

Assign Request to Agents

Ticket Purchase

Update Travel Request with Ticket Details Dispatch Ticket (Urgent)

Dispatch Ticket (Normal)

Dispatch Form (Urgent)

Dispatch Form (Normal)

Update Travel Request with Reject Details Verify Control Sheet

Visa Application Process & Issue Visa

127

Duration (minutes) Normal distribution Mean= 15 Std D = 2 Normal distribution Mean= 10 Std D = 2 Normal distribution Mean= 10 Std D = 2 Normal distribution Mean= 30 Std D = 10 Normal distribution Mean= 5 Std D = 2 Normal distribution Mean= 20 Std D = 5 Normal distribution Mean= 20 Std D = 5 Normal distribution Mean= 20 Std D = 5 Normal distribution Mean= 20 Std D = 5 Normal distribution Mean= 5 Std D = 1 Normal distribution Mean= 5 Std D = 1 15mins Random 0, 3hrs, 6hrs, 1day, 2days 3days,4days, ?days,

Role Resource Traveller

Finance Advisor Travel Advisor Agents

Travel Advisor Distribution PersonnelUrgent Distribution PersonnelNormal Distribution PersonnelUrgent Distribution PersonnelNormal Travel Advisor Travel Advisor Travel Advisor

Embassy (external)


128

Provide Sanction letter to Bank Verify & Issue Forex

Collect Forex

Collect Visa & Travel

10days 10 mins Random 30mins, 1hr, 1.5hrs, 2hrs 2.5hrs, 3hrs, 3.5hrs, 4hrs Normal distribution Mean= 15 Std D = 2 Normal distribution Mean= 15 Std D = 2

Forex Desk Bank

Traveller

Traveller

Table 6.8: Activity related parameters

Decision Points Does PL approve the request

Yes (0/o) 80

No (0/o) 20

Does BM approve the request

98

2

Does traveller has outstanding

20

80

Is it an overseas travel

20

80

Is it an urgent travel request

10

90

settlement

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.

~

C")

Cb (I) (I)

:b. ~

~

~ (I)

Having a

~-

completed travel

~ ~

request form

~

::3

@

t=:;·

G)

:b. ~

BM Approval

~

~ (I)

c;;·

G) Check Settlement Status

,,,No

L

.~

.~

Figure 6.7a: As-is Travel Requisition Process modelled using the WBIM- Part A

"'c.o

VJ

0

~@

~

G) Is ll'gent ) request

l :~ ticket

G "'

Normal

~

~ Vet:'fy

control sheet

Dispatch

ticket

\:)

C3 C") Cb

en en ):, ~

s::u

~

en

'?" Figure 6. 7b: As-is Travel Requisition Process modelled using the WBIM - Part B

~s::u ::3

~ ):, ~

s::u

~

en

c;;·


131

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


132

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 # 1

2 3 4 5 6 7

Distribution

Rejected: Request not approved by Finance. Traveller has outstanding settlement Rejected: Request not approved by PL Rejected: Request not approved by BM Success: Non-urgent, local travel request Success: Non-urgent, overseas request Success: Urgent, local request Success: Urgent, overseas request Weighted

15.5%

17.5%

Average Elapsed Duration 1 day 57 minutes

Average Total Cost $60.41

35 minutes

$18.75

1.0%

1 hour 32 minutes 45.5% 1 day 1 hour 16 minutes 13.5% 1 day 6 hours 44 minutes 4.5% 23 hours 16 minutes 2.5% 1 day 52 minutes Averages 21 hours 18 minutes 19.567 seconds

$38.75 $73.75 $90.41 $80.75 $97.41

s64.86

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


133

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

Rejected due to outstanding settlement Rejected by PL Rejected by BM

No of occurrences out of 200 request per day 31

35 2

Average Cost

Total Cost

$60.41

$1872.71

$18.75 $38.75 Total Cost

$656.25 $77.50 2606.46

s

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.

Average Delay Duration Assign request to Agents for processing 44 minutes Check Settlement Status 37 minutes Activity Name

Normal Dispatch ticket Provide Sanction Letter to Bank

3 hours 12 minutes 31 minutes

Update travel request with ticket details

48 minutes

Resource Required Travel Advisor Financial Advisor Dispatch Personnel Financial Advisor Travel Advisor


134

Verify Control Sheet Visa Application

33 minutes 34 minutes

Travel Advisor 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 Finance-1 Finance-2 Finance-3 Travel-1 Travel-2 Travel-3

Weighted Average Shortage Duration 9 minutes 59.693 seconds 10 minutes 12.014 seconds 10 minutes 12.142 seconds 24 minutes 53.895 seconds 30 minutes 38.651 seconds 25 minutes 35.283 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 AsIs 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 ToBe process.


135

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)

136


• 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, unproductive and unable to handle urgent requests.

making it

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.


137

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 1 Begin the travel process with checking of settlement status, followed by PL's and BM's approvals (sequentially)

Rationale Comparing the three probabilities, it is noted that the outstanding settlement check activity has a 20°/o chance of rejection; while the PL and BM approval activity has 20% and 2% rejection rate respectively (see Table 6.9). With the new initiative, checking of outstanding settlement would no longer be resourceintensive.


138

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

This would attempt to test whether combining rearrangement of activities together with concurrency would reap benefits by having a balance between time gains from concurrency and cost savings from sequential processing. To determine whether the implementation of such a policy would yield time and cost benefits.

3

Check settlement status then concurrently send to PL and BM for approval Check settlement status then check if the request is > $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.

~

C")

Cb (I) (I)

Scenario #1

:b. ~

~

~ (I)

~-

~ ~ ~

::3

t=:;· :b. ~

@-=-.- . !

Receiv

Check

completed

Settlement status

request f orm

~

~

l>-D-

~ (I)

c;;·

Figure 6.8a: To-Be Travel Requisition Process Scenario 1 modelled using the WBIM - Part A VJ

c.o

.j::>.

0

Ao.tanotk

l.l)datereject

vo--1

detals

[>-D---@

!

ROLte r~to

travel desk

~

G l.\ldatetravel ·~\\ttl

ticbt detois

\:)

C3 C") Cb

en en ):, ~

s::u

~

en

'?" Figure 6.8b: To-Be Travel Requisition Process Scenario 1 modelled using the WBIM - Part B

~s::u ::3

~ ):, ~

s::u

~

en

c;;·

~

C")

Cb (I) (I)

Scenario #2

:b. ~

~

~

~ (I)

~-

~ ~ ~

~

@ -~

Receive completed request form

Check Settlement status

~

l>V

::3

t=:;· :b. ~

~

~ (I)

c;;·

76.4% PL approve, BM approve

Figure 6.9a: To-Be Travel Requ isition Process Scenario 2 modelled using the WBIM - Part A

.j::>. ....>.

.j::>. 1\.)

t>

[>-D--@

~

Jprove

i ·eject

app-ove ~etravel

\:)

requestwlh licketdet41s

C3 C") Cb

en en ):, ~

s::u

~

en

Figure 6.9b: To-Be Travel Requisition Process Scenario 2 modelled using the WBIM - Part B

'?"

~s::u ::3

~ ):, ~

s::u

~

en

c;;·

~

C")

Cb

Scenario #3

(I) (I)

:b. ~

~

~ (I)

~~

~-

~

~ ~ ~

{i}

@ _~

Receive completed request form

~

::3

{$

t=:;·

Check Settlement Status

:b. ~

~

~

~

~ (I)

c;;·

50.0% No

G) PL Approval

~ ~

~~

Figure 6.1 Oa: To-Be Travel Requisition Process Scenario 3 modelled using the WBIM- Part A .j::>.

w

.j::>. .j::>.

{i Automatic update reject

detais

[)-D---8

»

RDW r~to

travel desk \:)

C3 C") Cb

en en ):, ~

s::u

~

en

'?" Figure 6.1 Ob: To-Be Travel Requisition Process Scenario 3 modelled using the WBIM - Part B

~s::u ::3

~ ):, ~

s::u

~

en

c;;·


145

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 not specified) Check Settlement Normal distribution Status Mean= 0.5 Std D = 0.2 Route Request to Normal distribution Travel Desk Mean= 0.5 Std D = 0.2 Assign Request to Normal distribution Agents Mean= 6 Std D = 1 Update Travel Request Normal distribution with Reject Details Mean= 0.25 Std D = 0.08 Generate Sanction 30 seconds letter Email e-tickets 30 seconds Dispatch Ticket Normal distribution (Urgent) Mean= 20 Std D = 5 Dispatch Ticket Normal distribution (Normal) Mean= 20 Std D = 5

Role Resource Not Applicable

Cost

Not Applicable Travel Advisor Travel Advisor Not Applicable Agent Not Applicable (outsource) Not Applicable (outsource)

US$12 per request US$5 per request

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

.j::>. (j)

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 Average Elapsed Duration 1 minute


%

14.5

22 minutes

$18.75

15

1

1 hour 34 minutes

$38.75

%

1

2

3

4

5

Rejected : Traveller has outstanding settlement Rejected: Request not approved by PL Rejected: Request not approved by BM Success: Nonurgent, local travel request

Scenario #2

20

31

9 hours 18 minutes

$52 .80

20.5

31

Scenario #3

Average Elapsed Duration 1 minute


2 hours 34 minutes

$38.75

12 hours 22 minutes

$52.80

Description

%

Average Elapsed Duration 1 minute


Rejected : Traveller has outstanding settlement Rejected : Request not approved by PL Rejected : Request not approved by BM Success: <=$2K, local , non-urgent request Success: >$2k, local , non-urgent request

20.5

14.5

23 minutes

$18.75

1

53 minutes

$38.75 \:)

C3 C")

18

7 hours 49 minutes

$32 .08

Cb

en en ):, ~

s::u

~

13.5

11 hours 26 minutes

$52.08

en

'?"

~s::u ::3

~· ):, ~

s::u

~

en

c;;·

6

Success: Nonurgent, overseas request

5.5

10 hour 44 minutes

$56.25

5

17 hour 26 minutes

$56.25

7

8

Success: Urgent, local request

2

6 hours 59 minutes

$59.08

2.5

10 hours 36 minutes

$59.08

9

10

Success: Urgent, overseas request

1.5

10 hours 27 minutes

$68.75

1

18 hours 23 minutes

$68.75

11

12

13

Success: Overseas, eticket

7.5

11 hours 23 minutes

$59.58

8.5

15 hours 6 minutes

$59.58

Success: <=$2k, overseas. Nonurgent Success: >$2k, overseas, nonurgent request Success: <=$2k, local , urgent request Success: >$2k, local , urgent Success: <=$2k, overseas, urgent Success: >$2k, overseas, urgent Success: >$2K, overseas, eticket Success: <=$2K, overseas, eticket

3

8 hours 37 minutes

$44.58

~

C")

Cb (I) (I)

:b. ~

2.5

1

1

0.5

14 hours 8 minutes

$64.58

2 hours 42 minutes 10 hours 35 minutes 1 hour 43 minutes

$39.08

~

~ (I)

~-

~ ~ ~

::3

t=:;· :b. ~

~

$59.07

~ (I)

c;;·

$51.58

0.5

8 hour 16 minutes

$71.58

1

9 hours 53 minutes

$59.58

6.5

5 hours 8 minutes

$39.58

.j::>.

"'-I

14

15

Success: Local , e-ticket

17

12 hours 8 minutes

$47.08

16.5

13 hours 33 minutes

$47.08

Success: >$2k, local , eticket Success: <=$2k, local , e-ticket

8.5

8

10 hours 8 minutes 9 hours 40 minutes

$47 .08

.j::>.

co

$27.08

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.

\:)

C3 C") Cb

en en ):, ~

s::u

~

en

'?"

~s::u ::3

~· ):, ~

s::u

~

en

c;;·

~

Comparison of As-Is and Scenario #3

C')

Cb

Path Description #

1

2

3

4a

4b

Rejected : Traveller has outstanding settlement Rejected: Request not approved by PL Rejected: Request not approved by BM Success: Non-urgent, local travel request

As-Is %

15.5

Scenario #3 Average Average Elapsed Total Duration Cost

Description

1 day 57 minutes

Rejected: Traveller has outstanding settlement Rejected: Request not approved by PL Rejected: Request not approved by BM Success: <=$2K, local, non-urgent request Success: >$2k, local, non-urgent request

$60.41

17 .5 35 minutes

$18.75

1.0

1 hour 32 minutes

$38.75

45.5

1 day 1 hour16 minutes

$73.75

(I) (I)

Comparisons %

Average Average Elapsed Total Duration Cost

20.5 1 minute

$0.00

% Improvement over As-Is (duration) Near to 100%

:b.

% Improvement over As-Is (cost) 100%

~

~

~ (I)

~-

~ ~ ~

::3

t=:;· :b. ~

~

14.5 23 minutes

$18.75

34.3%

0%

1

53 minutes

$38.75

42.4%

0%

18

7 hours 49 minutes

$32.08

69.1%

56.5%

$52.08

54.7%

29.4%

13.5 11 hours 26 minutes

~ (I) Ci)•

.j::>.

c.o

5a

Success: Non-urgent, overseas request

13.5

1 day 6 hours 44 minutes

$90.41

5b

6a

Success: Urgent, local request

4.5

23 hours 16 minutes

$80.75

6b

?a

7b

Success: Urgent, overseas request

2.5

1 day 52 minutes

$97.41

Success: <=$2k, overseas . Non-urgent Success : >$2k, overseas, non-urgent request Success: <=$2k, local , urgent request Success : >$2k, local , urgent Success: <=$2k, overseas , urgent

3

8 hours 37 minutes

$44.58

80.0%

50.7%

2.5

14 hours 8 minutes

$64.58

54.0%

28.6%

1

2 hours 42 minutes

$39.08

88.4%

51 .6%

1

10 hours 35 minutes 1 hour 43 minutes

$59 .07

54 .51%

26.8%

$51.58

93.1%

47.0%

Success : >$2k, overseas, urgent

0.5

$71.58

66 .8%

26.5%

0.5

8 hour 16 minutes

CJ1

0

\:)

C3 C") Cb

en en ):, ~

s::u

~

en

'?"

~s::u ::3

~ ):, ~

s::u

~

en

c;;·

8a

Success: Overseas, eticket

N/A

N/A

N/A

8b

9a

9b

Success: Local, e-ticket

N/A

N/A

N/A

Success: >$2K, overseas, eticket Success: <=$2K, overseas, eticket Success: >$2k, local, e-ticket Success: <=$2k, local, e-ticket

1

6.5

8.5

8

9 hours 53 minutes

$59.58

5 hours 8 minutes

$39.58

10 hours 8 minutes 9 hours 40 minutes

$47.08

There is no direct comparison between Scenario #3 and the As-Is process. However, we notice that the performance for all the e-ticket paths certainly take less duration and cost compared to any of the success paths in the As-Is process. This is an obvious improvement.

~

C")

Cb (I) (I)

:b. ~

~

~ (I)

~-

~ ~ ~

::3

t=:;· :b. ~

~

$27.08

~ (I) Ci)•

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.

CJ1 ....>.

152


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 etickets 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 Avg No of occurCost rences out of 200 request per day 31 $60.41

Rejected due to outstanding settlement Rejected 35 by PL Rejected 2 by BM Total Cost

$1872.71

To-be process (scenario 3) No of Avg Total occurCost Cost rences out of 200 request per day 41 $0.00 $0.00

$18.75

$656.25

29

$18.75

$543.75

$38.75

$77.5

2

$38.75

$77.50

Total Cost

s2606.46

Difference

s621.25 s1985.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


153

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

Resource

Improvement over As-is process

Travel Advisor

36% improvement

0 seconds

-

3 hours 9 minutes 0 seconds

Dispatch Personnel

Generate Sanction Letter Update travel request with ticket details Verify Control Sheet

3 hours 12 minutes 31 minutes 48 minutes

27 minutes

Bottleneck totally removed Slight or no improvement Bottleneck totally removed 44% improvement

33 minutes

0 minutes

Visa Application

34 minutes

9 minutes

Assign request to Agents for processing Check Settlement Status Normal Dispatch ticket

Average Delay Duration (As-Is) 44 minutes

Average Delay Duration (To-Be) 28 minutes

37 minutes

Travel Advisor Travel Advisor Travel Advisor

Bottleneck totally removed 74% improvement

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


154

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 Finance-1 Finance-2 Finance-3 Travel-1 Travel-2 Travel-3 Travel-4

Weighted Average Shortage Duration No longer required in the To-Be process No longer required in the To-Be process No longer required in the To-Be process 10 minutes 0. 77 4 second 10 minutes 12.852 seconds 10 minutes 55.512 seconds 9 minutes 22.463 seconds

Improvement over As-is Process Resource totally freed up. Resource totally freed up. Resource totally freed up. 58% improvement 67% improvement 60% improvement 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 hour (US$) 25

No of resource

No of hours of work per day 3

Cost (US$) 8

600

Table 6.21: Cost of hiring 3 resources in the dispatch department

Type of dispatch service used

Normal dispatch Urgent dispatch

No of Cost per Total Cost (US$) occurrences out request (US$) of 200 request per day 74 5 370 12 72 6 Total 442

Table 6.22: Cost of using services from a courier company


155

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

Retrain 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.

Impact Medium

156


Low 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). High 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.

Impact Medium

Low

Medium

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) High 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. Table 6.23: Impact analysis for the internal organization (GSPL)


157

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 on Travel Agents

Impact 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, eTravel 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.


158

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 De sk (New)

All Employees

t

t

d'~

~~

~

~

Q

Vi sa De sk

Travel De sk

Business Manager

PL

Traveller

~ External Parties

t d'~

~~

d'~

~!&

Embassie s

Bank

Travel Agent

Courier Companie s

Figure 6.11: To-Be Organization Model


159

World

Travel De sk (New)

All Employe es

Figure 6.12: To-Be Location Model

l';m;' ~

I

External

I

I

e-Tickets Visa

...

Ti ckets

II

~

Request Form

Travele r

Ti cketing & billing details

Proposed System

Request Farm

$~

TraveiDesk

Sanction Letter

~ Ticketing & billing aeta11s Trave l r. qu Jst del ils

Trave l Agents

[IF L

ickets

~ Bu siness Manager

~ Approva l

$~

Settl men! Status

~

r--

Courier Com panie s

Ti ckets

ERP

I I

Settlement ve rifi cation done by system

~

!.li sa Aoolication Form

I I Visa

~

Fore 1gn c urrencies

I

I

Q Embass ies

Sanction Letter

Bank

I I

I

Figure 6.13: To-Be Collaboration Model

1'


160

r·m"

~ ..,

~

e-Tickets Vis a

Tickets Reque st Form

Trave ler

'.!i:! Ploposaa System

Request Form Sanction Letter

II @"~

Ticketing & billing details

Tra-.eiDesk

External

L

I

I

~

TicKeUng & billing ae a1s Travel request

Travel Agents

Tic ket Rec uisitic Jn f'rbcess

~ l

r---r -----.. Business

ickets

sen:

Manager

~

H

. . _ Ann m""l

~$

memStaws Tickets

I

ERP

I I

I I

verifi cabon done by system

''""m'"'

l

~.

\li.ic.::a .R t:ln 1( .....~" •

r-.

Visa

.r"'>.;

_,,

Jl

~r01~ess Embassies

ore1gn c..;urrenc1es

-·

Courier Companle

'-'1-

I

I

I

I

i Ba nk

~'".

. n, ,

f

Figure 6.14: To-Be Process Catalogue Model

j

~

C")

Cb (I) (I)

:b. ~

Tr..,.eler

~

0

'

e-Travel System

the form and submit 1

or

Roule lnformallon to Travel Desk

ll

'" ,J .

Obtain Forex Subprocess

u

~

::3

t=:;·

10

:b. ~

L-

~

~ (I)

c;;·

Ye!

_[

S2

~ ~

I

·aM Approved

PL

~-

No

1---~

(ETS)

~ (I)

Collect tickets an Visa reqd) 17

fEnteriUpdate tr..,.el details In)

l

+-----1-----1-----~

(Approve or rejecl reques~ rn proposed system ) 4 I

l

0 Business Manager

_i_

l

Ap prove or reject request Yes In proposed syslem 1 - - - - - - - - - - - - - - - - - - - '

5

Tr..,.eiOesk Email traveller to colle ctVisafTicket If required 16 J No

No

~0_ Travel Agents

Assign !ravel request to tr..,.el agents 8

kf

Process travel

0

Figure 6.15a: To-Be Workflow Model

(j) ....>.

(j) 1\.)

Bank

Process and Issue Forex

e-Travel System (ETS)

1

.,

Generate Sanction Letter 2

1

Traveler Bring sanction letter to bank

Figure 6.15b: To-Be Obtain Forex Workflow Model rave iDesk Visa Application

\:)

C3 C")

2

Cb

en en ):,

Embassies

~

Process & Issue Visa

s::u

~

en

'?"

~s::u ::3

~

Figure 6.15c: To-Be Obtain Visa Workflow Model

):, ~

s::u

~

en

c;;·


Name Activity Using this Rule Set Description Rule Set

Related Rule Set

163

Check Settlement Status Check Settlement Status This rule set checks if the traveller has outstanding settlement before allowing him or her to travel again. ETS to query ERP system IF ERP system return 'false' for settlement status of traveller. THEN settlement status is bad IF ERP system return 'true' THEN settlement status is good None

Table 6.25: Example To-Be Business Rules Model

CHAPTER 7 IT SOLUTION REQUIREMENTS DEFINITION


Overview Functional Requirements Definition Non-Functional Requirements Definition Conclusion of the Business Modelling Phase

References Case Study - IT Solution Requirements Definition for the GSPL Travel Requisition Process

Learning Objectives On completion of this chapter, you will be able to: • Map out solution functionality from To-Be Modelling and To-Be Process Analysis activities • Define non-functional requirements for the IT Solution


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.

Functional Requirements Definition Output from To-Be Modelling And To-Be Process Analysis 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 NonFunctional 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

when documenting Use Cases. Each Use Case is denoted by an ovalshaped 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". Enter a New Order Customer

"~

Enter Billing Information

Finance Manager

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


167

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 subprocesses have to be further expanded into activities and Use Cases are to be derived from these activities.


168

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.

" "

Actor A

6 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.


Customer I

e-{

Enter Order Details 1

169

J

Q Web Order Management System

... ta lidate

J Send email to Shipping J

Det~lsJ

!iii! !iii!

l

Check Inventory}Availability 3

l

Yes

Credit Supervisor

•

!iii! Payment Processing System

.[Notify Customer

·~ "l

Re·order Product 5

---l [

7

Jl

I

Credit ~ Exception ) Handlmg6

Q Credit Information System

Officer

_____,..-

No

Inventory System

l

.___j

vailable?

10

~

Update Inventory 8

•

f [ Verify Credit Details )

4

J

~ 0

Credit Accounts Receivable 9

J

!iii!

Figure 7.5: Example Workflow Model

Step 2: Grouping Use Cases in Functions 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.


170

6:) 6:) 6:)

c:B 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?


171

• 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. Category No 1 Capacity

2

Security

3

Reliability

4

Scalability

Non Functional Requirements The solution shall support at least 50 requests in one hour The solution shall be available only for employees of the organization over Intranet The solution shall be available 24x7 with at most 5% unplanned downtime 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

172


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.


173

Case Study IT Solution Requirements Definition for the GSPL Travel Requisition Process 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._

L

~ Mana/

Bu~n;

Requests

Approve or Reject

Project Leader

~T~v~esk~ Create Travel Request

~ "

Traveller

~~ " ~/


~

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 subprocesses) 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.


174

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 Initiate Payment

eTS

Enterprise System

Enter Expense Details

Figure 7.8 Additional Use Cases for the To-Be Travel Requisition Process


175

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 1 Capacity 2

Capacity

3

Security

4

Security

5 6

Security Reliability

7

Reliability

Non Functional Requirements The solution shall support at least 300 requests per day. The solution shall support up to 20 concurrent users with average response time of no more than 3 seconds per click. The solution shall support single-sign-on using the existing LDAP system. The solution shall be available only for internal GSPL users. The solution shall support configurable access control. The solution shall be available 24x7 with at most 2% unplanned downtime. The solution shall support at least RAID 1 for data backup


176

8

Scalability

9

Scalability

The solution shall make provisions to keep data for at least 7 years. 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 On completion of this chapter, you will be able to: • 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",

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. (http://www.wordinfo.infolwordslindex/infolview unit/1/?letter=B&spage=3),

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

179

Solution Blueprint

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 ).

Business Goals, IT Trends, Enterprise Architecture, IT Architecture Principles, Industry Standards, Corporate Standards, etc.

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

j,. ca. -·a. ;;;:; 3 a· tD~ ~!!.

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.

180

Solution Blueprint

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

Solution Blueprint

181

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:

PRINCIPLE NAME:

• Cost Effectiveness and Operational Efficiency

• Standard System-to-System Interface Protocols

STATEMENT:

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 .

• Standard interface protocols should be used for all systems, where standards are available

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 savin~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.

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.

182

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? Solution Blueprint

Use

I J.. - IT Solution Architects

J.. -IT Solution Architects

~ - Business Analysts

~ - Business Sponsor

~ - Subject Matter Experts

~ - Designers

J_ - Vendors (if any)

~ - lmplementers

J_ - EA Team Figure 8.4: Stakeholders of the Solution Blueprint

Solution Blueprint

183

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

184

Solution Blueprint

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

Blueprint

vs.

Detailed

Solution

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.

185

Solution Blueprint

Concept Solution Blueprint

~~

To-Be Business Process Model Solution Overview Model Application Model Information Model

~------------------------~

)

Further refined

Detailed Solution Blueprint

I

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

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. 2. 3. 4. 5. 6. 7. 8.

Overview Solution Modelling Application Modelling Domain Modelling Service Modelling Risk Modelling Concept Cost Modelling Summary of the Activities

References Case Study - Concept Solution Blueprint for GSPL Travel Requisition Process

Learning Objectives On completion of this chapter, you will be able to: • Understand the various activities of the concept solution blueprinting phase

187

Concept Solution Blueprint Activities

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 highlevel 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 Concept Modelling

l

..

Solution Overview Model

0

Application Modelling Function Model Application Model

0

.

Domain Modelling

..

Information Model Information Access Model

l Service Modelling

l

.. ~

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


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


189

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

J:Actor 1

:?! ro

o-

-

L____________j~

Function 3

B

-I sl Function

:-----i ....____.j.I

: ,.

I

,_

.

~ · · - ·· - .. - .. - .. - . ~ System C

System A

OJ

Dl

Ill

ro a.

J:

-1

'""'"006

System B

I I

! Non web-based

I I

c==J D

Existing Function New Function

i

!

*

Actor

Existing System

I

r_-_-_-_-_-_-_-_-j Grouping of Functions

Actor2

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 functionsfunctions are determined and represented as single arrows and double arrows to denote one-way and two-way communication respectively. An

190


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.


191

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

Function

Use Case

New/ Existing I To be modified

Comments

Function A

Use Case 1

New

This is currently done manually

Use Case 2 Use Case 3 Use Case 6

New To be modified To be modified

Use Case 4

Existing

Use Case 5

New

Function B

These two Use Cases are partially supported by Application A but will require modifications Fully supported by Application B 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.

192


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, UseCase-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

193


• 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 (Fl, F2)

(work product)

Application 3 (F3, F4, FS)

(protocol)

Application 2 (F6, F7,F8)

Application 5 (FlO, Fll)

D

Existing Application with no modification

F1

~~

Existing Application with modification

F2

D

New Application

Function Symbol

Function Name

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.

194


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", "customerid", "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

195


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 Name

Entity Description

Residing System

Key Attributes of the Entity

Existing/New Entity/TBD

TBD

Additional Comments

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

196


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

197


• 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. Entity 1

Entity 2

Entity 3

...

Role 1

RU

R

RU

R

Dept 1

CRUD

-

R

Role2

R

-

R

-

Information Entity 7 Roles/Dept/Org J,

C

Create

R

Read

U

Update

D

Delete

Table 9.3 Information Access Model: Template

198


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. Hotel A Booking Service ;/. ~

,, Hotel B Booking Service ".f. •

rftor_

m

Traveller

Travel Booking Service ,. Airline A Booking Service

Airline B Booking Service

Figure 9.9 Example Services in the Manual Travel Booking Process


199

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

200


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 humanto-system and system-to-system.

Activity 9.4 In Figure 9.1 0, identify the human-system and system-system service interactions.

Hotel A Booking Application

Hotel A Booking Service Hotel A Quotation Service

Hotel B Booking Application

Hotel B Booking Service

Travel Booking Service

Traveller

Hotel B Quotation Service

Airline A Booking Application

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


201

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-toapplication 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

202


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

Application 3

Application 1

54 Application 4 55

1 51 52

Application 2

53

Application 5

~ Application A1 uses service 51 ~ provided by application A2

Figure 9.12 Service Model Template

I

203


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 Providing the Service

Name

Application (s) Using the Service

Description

Input

Output

Service Level

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:

204

• For Online service will • For Online service will


Booking Application of Travel Agent A, the Hotel Booking process up to a maximum of 500 simultaneous requests Booking Application of Travel Agent B, the Hotel Booking 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

205


• 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. 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 Risk Description

Impact

Likelihood

Rating

Mitigation Strategy

Low/ Medium I High

Low/ Medium I High

A/B/

Risk Elimination/ Risk Reduction

Low/ Medium I High

Low/ Medium I High

A/B/

Risk Elimination/ Risk Reduction

c

c

Table 9.5 Risk Model Template

Mitigation Type

Impact of Strategy

206


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 unacceptable by business sponsor • A need to change major part of the solution

• Some functionalities cannot be implemented or requires manual work as workaround • A need to change 30-50% of the solution

• Minor change of requirements or functionality • A need to change a minor part of the solution

• Delay of project for more than 6 months • Increase in cost by more than 50% • etc ...

• Delay of project for more than 3 months • Increase in cost by more than 25% • etc ...

• Slight delay of project, < 1 month • Slight increase in cost, < 10% • 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.

207


High

Rating B

RitlngA

~A

Rating C

Rating B

lla1mgA

Rating C

Rating C

Rating B

Low

Medium

i

..... 3 Medium "C Dl

!+ Low

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.

208


Risk Description

Impact

Likelihood

Rating

Mitigation Strategy

Type

Impact of Strategy

Lack of committed resources as resources are required to spend time on BPE project as well as daily operations

Medium

High

B

Delegate specific resources to work on the BPE project

Risk Elimination

Increase in cost for hiring or deploying additional resources

A new technology is designed to be deployed . The technologJ is new, lack of stability an lack of expertise to implement

High

High

A

Plan for phase approach to the implementation of the project. Conduct a prototype or proof-of-concept to ensure the capability of the technology

Risk Reduction

Schedule may lengthen by additional 3 months

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


209

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 crosscountry. 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

210


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

Fixed Costs No

Items Low

1 1.1 1.2 .. .

Hardware Total Servers Scanners

2 2.1 2.2

Software Total Database Portal

Med

Hiah

Maintenance Costs Low Med High

Total Cost Rating

../

../ ../

C'":l

C)

:::::J C")

Low

Med

High

../ ../

Justification

Cb ~

....

Cl')

../

C)

i::

../

=::::!:

C)

...

:::::J

t:x::J

i::

../ ../

../ ../

Cb ~

../ ../

~....

../

):,

...

C")

=::::!:

3 3.1 3.2

Process Redesign Total Process study Chanqe Management

DesiQn and Implementation 4 4.1 Applications A 4.1.1 Requirements De sian Construction Test Documentations Project Management 4.2 Application B Design 4 .2.1 Modifications ... 5 5.1 5.2

Deployment and training Application A Application B

../ ../

../

../ ../

../

../

../ ../

./ ../

../ ../

~ tt;· (I)

../

./

../ ../

../ ../

../

../

../

../

../

../

./

../

./ ../

../ ../

../ ../ ../ ../

./ ../

../ ../

../

...

Table 9.9 Concept Cost Model Template with Example 1\.) ....>.

212


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 Solution Modelling

Application Modelling

Domain Modelling

Description Define the scope of the proposed solution Define the various applications involved in the solution. For each application identify the functions provided by the application Identify and describe the various information entities that are used in the

Input Output Solution Use Case Model, UseOverview Model Case-toFunction Model Solution Application Overview Model, Model, Function Use-Case-toModel Function Model

Solution Information Overview Model, Model, Application Information Model, Workflow Access Model Model

213


Service Modelling

Risk Modelling

Concept Cost Modelling

solution. For each entity define the access rights Define and describe the services that are provided by the applications Evaluate the risks associated with the proposed solution Estimating the qualitative cost of designing, implementing and maintaining the solution

Application Model

Service Model, Service Description Model

Application Model, Function Model

Risk Model

All To-Be Business Models and preceding Concept Solution Blueprinting Models

Concept Cost Model

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.

214


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.

::X:

Travel Desk

Actor

1 1 Existing Function

(with

~ or without modification)

CJ New Function r_-_-_-_-_-_-_-_-j Grouping of Functions

Traveller

rr==Il

Interface to Application

Figure 9.16 Solution Overview Model for Travel Requisition Solution


215

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 webbased 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.

216


Function

Use Case

New/ Existing I To be modified

Comments

Travel Request Management Approval Communications Management Foreign Currency Sanction Payment

All

New

All All

New New

These functions are designed to be a new Application , called ETravel System (ETS)

All

New

Issue Payment Voucher

Existing

Expense & Foreign Currency Issuance Reconciliation Record Foreign Currency Issued

New

Expense Management

Record Expense Details Enter Expense Details

New

Existing

Other applications in GSPL have been using this function for payment. Currently done manually. Currently only recorded in the sanction letter Travellers have been doing this currently

Existing

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.

217


D

Existing Application that requires no modification Accounting System Existing Application that requires modification

D

(AS)

New Application

Function Symbol

Function Name

F1

Travel Request Management

F2

Approval

F3

Foreign Currency Sanction

F4

Communication Management

F5

Payment

F6

Expense Management

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.

1'\.)

--"

co

Entity Name

Entity Description

Residing System

Key Attributes

Existing I New

Trave l Request Details

This entity stores information about the travel request including the status

ETS

• •

New

•

• • • • • •

Expense Details

This entity stores the traveller's expense information

ES

• •

• • • •

Currency Sanction Details

Payment Details

This entity stores the information about the amount of foreign currency approved and issued to the traveller This entity stores the payment amount due to the travel agent when a travel request is fulfilled

ETS I ES

ETS

• • • • • •

• •

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

Additional Comments

Existing

New

Master copy in ETS, duplicated copy in ES

C'":l

C)

~ C")

tb

....

~

Cl') C)

i::

Pay to (vendor) Date Payment amount Payment currency

New

This information must be kept of minimum of 7 years due to a government policy

=::::!:

C)

~

0::1

i:: tb

~

g. .... ):,

C")

=::::!:

~

(b• (/)

C":l C)

:::::J C')

Cb ~

....

Cl') C)

i:: =::::!:

C)

:::::J

Settlement Status

This entity stores the settlement status of the traveller

ES

•

•

Employee Settlement status

Approval Routing Details

This entity stores the approval routing sequence for each employee

TBD

• • •

Employee 1st level manager 2"d level manager

Ticket Details

This entity stores the booking and ticket details for the travel

ETS

•

Ticket type (e-ticket, paper ticket) Booking reference Carrier type Carrier code Departure date Departure time Boarding location

• •

• • • •

New

TBD

To be derived by ES through reconciliation of expense and settlement amount for the foreign currency issued TBD- To Be Determined Need to check with GSPL if there is any existing organization directory (e.g. LDAP) Each travel leg has a set of ticket details, i.e., if it is a return trip, there is at least 2 sets of ticket details for both the departure and return trips

t:x::J

i::

Cb ~

~· .... ):,

C')

=::::!:

~ tt;· (I)

Table 9.12 Information Model for Travel Requisition Solution

1\.)

.......

c.o

1\.) 1\.)

0

Information Entity~ Roles/DepUOrg J,

Travel Request Details

Traveller Business Manager Project Leader Travel Desk Enterprise System(ES) Accounting System(AS) e-Travel System (ETS)

CRUD RU RU CRU

I

I

I

R

Expense Details

Currency Sanction Details

CRU

R

R

R

Payment Details

Settlement Approval Routing Status Details*

Ticket Details R

CRUD

CRU

CRU R CRU

RU

R

Table 9.13 Information Access Model for Travel Requisition Solution C'")

c

~

(')

tb

* 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.

"'tJ ..... Cl)

c

t: ~ ~

t:XJ

t: tb

"'tJ

s·

.....

):,. (')

~

~

C'b' ~

221


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-tosystem 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 System (ES)

51,52


53

Accounting System (AS)

Table 9.18 Service Model for Travel Requisition Solution

1'\.) 1'\.) 1'\.)

Application Name Providing the Service

Application(s) Using the Service

Description

Input

Output

Service Level

Enterprise System

e-Travel System

This service checks the settlement status in ES and returns the value

•

•

•

This service records the foreign currency that has been issued to an emr>loyee This service allows payment to vendor by updating the payment details to the Accounts PC!Y_able function

•

S1: Check Settlement Status

S2: Record Currency Issuance

Accounting System

S3: Issue Payment

e-Travel System

e-Travel System

Employee 10

Settlement Status

•

• • • •

• • •

Employee 10 Issued date Issued amount Currency

•

Success Status

•

Vendor 10 Date Payment amount Payment currency

•

Success Status

•

Round trip duration less than 3 seconds. Process up to 20 concurrent requests Process up to 10 concurrent requests

Process up to 10 concurrent requests

C':l

C)

~ C")

tb ~

....

Cl') C)

i:: =::::!:

C)

~

0::1

Table 9.14 Service Description Model for Travel Requisition Solution

i::

tb ~

g. .... ):,.

C")

=::::!:

~

(b• (/)

C'":l

Risk Modelling

C)

:::::J C")

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.

Cb ~

....

Cl') C)

i:: =::::!:

C)

:::::J

t:x::J

Risk Description

Impact

Likelihood

Settlement status may not be easily computed or retrievable since ES is a legacy system

Medium

Medium

Efforts to obtain, import and maintenance of routing detail could be enormous due to the size of the organization

High

Medium

Rating

Mitigation Strategy

Mitigation Type

Impact of Strategy

B

Before starting the implementation, conduct detailed technical study with ES's Technology Expert A detailed study of the following is required: • structure of the entire organization • how the structure is currently stored • How rapid the organizational changes could be

Reduction

Slight additional design effort required

A

i::

Cb ~

~· .... ):,

C")

=::::!:

~ tt;· (I)

Reduction

Significant increase in efforts and resources to conduct this study and it may not be easy since GSPL is a worldwide organization.

Table 9.15 Risk Model for Travel Requisition Solution

1\.) 1\.)

w

1'\.) 1'\.) .j::>.

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 Items

No

Low

1 1.1

1.2 2 2.1 2.2

Hardware Total Servers

Email, Fax, Printers Software Total Database Portal

Med

./

./

-

-

High

-


Total Cost Rating Low

Med

./

./ ./

./ ./

./

./

./ ./

./

Justification

High Only ETS requires new hardware and based on the initial study of the requirements (functional and nonfunctional ), the hardware requirement should be well within range of $50K $200K Re-using existing infrastructure

./ ./

./

C'":l

./

C)

~ C")

3 3.1 3.2

Process Redesign Total Process study

Change Management

./ ./

./ ./

./

./ ./ ./

tb

./

./

~

Relatively simple business process involving few stakeholders 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

......

Cl') C)

i:: =::::!:

C)

~

0::1

i:: tb

~

g.

......

):, C")

=::::!:

~

(b• (/)

Fixed Costs No

Items Low

Med

High


Total Cost Rating Low

Justification

C"")

c

~ C')

tb

Med

High

"t::l .....

./ ./ ./ ./

./ ./

c

Cl')

Design and Implementation 4 4.1 ETS Requirements 4.1.1

./ ./

Design

4.2 4.2.1

Construction Test Documentations Project Management Enterprise Systems Design & Modifications

Test Documentations

5 5.1 5.2

./ ./ ./

./

./

~

./

Depending on the functionality of the portal deployed and the amount of extensions required to satisfy requirements , efforts cou ld vary

./

./

./ ./

./

./

./

~· .....

:::t

./ ./

./ ./

./

t: tb

"t::l

):,.

~ ct;·

./ ./ ./

t:XJ

C')

./ ./

./

./

t:

g.

./

./ ./

./

Deployment and training ETS

ES

./

./ ./

~

Depending on the complexity, the effort could be medium or low. This is also listed as one of the risks

New system and organization wide deployment. Training efforts would be significant Changes to the system are made for automated functions. Little end-user training required

Table 9.16 Concept Cost Model for Travel Requisition Solution

1\.) 1\.)

01

226


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 AsIs 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

Recommend Documents