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
Business Process and IT
3
the customer and processing payment from the customer. Figure 1.1 shows a simplified example of an order-to-cash process along with the sequence of activities. Each activity is typically conducted by an individual or a system within a department. The Sales department receives an order that is handed off to the Finance department for a credit verification that is then handed off to Order Administration who enters the order into the ERP system and on and on until the order is finally shipped to the customer and the Accounting department sends an invoice and processes the payment. SALES
Receive Order
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
Business Process and IT
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
Business Process and IT
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
Business Process and IT
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.
Business Process and IT
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
Business Process and IT
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?
Business Process and IT
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
Business Process and IT
• 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
Business Process and IT
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.
Business Process and IT
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
Business Process and IT
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.
Business Process and IT
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.
Business Process and IT
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.
Business Process and IT
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)
Business Process and IT
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
Business Process and IT
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
Business Process and IT
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.
Business Process and IT
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)
Business Process and IT
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 MV
::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;;·
Process Analysis- Dynamic Analysis
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
Average Total Cost $0.00
%
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
Average Total Cost $0.00
2 hours 34 minutes
$38.75
12 hours 22 minutes
$52.80
Description
%
Average Elapsed Duration 1 minute
Average Total Cost $0.00
Rejected : Traveller has outstanding settlement Rejected : Request not approved by PL Rejected : Request not approved by BM 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 request Success: $2k, local , urgent Success: $2k, overseas, urgent Success: >$2K, overseas, eticket Success: .;
_,,
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;;·
Process Analysis- Dynamic Analysis
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
Chapter Topic List 1. 2. 3. 4.
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
IT Solution Requirements Definition
165
IT SOLUTION REQUIREMENTS DEFINITION
1. Overview The IT Solution Requirements Definition activity helps in mapping and detailing the functional and non-functional requirements of an IT solution. Use Cases are used to represent the identified functional requirements [Bittner200]. The Use Cases are the end output of the Business Modelling phase and in turn, are input to the Concept Solution Blueprinting phase.
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
IT Solution Requirements Definition
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
IT Solution Requirements Definition
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.
IT Solution Requirements Definition
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.
IT Solution Requirements Definition
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.
IT Solution Requirements Definition
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?
IT Solution Requirements Definition
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
IT Solution Requirements Definition
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.
IT Solution Requirements Definition
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
~~ " ~/
e-Travel System (ETS)
~
Figure 7.7 Use Case Model for the To-Be Travel Requisition Process The Use Case Model in Figure 7.7 shows the Use Cases that are derived from the To-Be Workflow Model as presented in Chapter 6 Case Study. In reality, when designing a new IT Solution to support the new business process, one has to consider the other related processes (or 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.
IT Solution Requirements Definition
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
IT Solution Requirements Definition
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
IT Solution Requirements Definition
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
Concept Solution Blueprint Activities
In Figure 9.1, the flow of these activities is laid out in a linear fashion. In reality, it is always possible that one repeats these activities when necessary while developing the Concept Solution Blueprint. This statement is also true for the steps described for each activity. Additionally, it is also possible that as a result of developing the Concept Solution Blueprint, some of the outputs of the Business Modelling phase such as Workflow Model and Use Case Model, may need to be modified.
2. Solution Modelling Solution Modelling activity focuses on understanding the scope of the proposed IT solution. In this activity, the Solution Overview Model that defines the Actors and the Functions of the proposed solution is developed. An Actor is a person, role, department, organization or an IT system that interacts with the solution through one or more Functions. For example, a "Customer" who is the Actor, may personalize his or her portal through the "Customer Personalization" Function. A Function is a capability that the solution provides to enable the Actor to carry out one or more activities. Examine the functions identified during the IT Solutions Requirements Definition Activity
Identify any other functions that are required
Group functions into new and existing
Determine actors required for the solution including those identified during IT Solutions Requirements Definition
Draw a diagram appropriately linking Actors with functions and functions with functions. Add other details as required.
Describe the model through one or more scenarios
Figure 9.2 Steps for Developing the Solution Overview Model
Concept Solution Blueprint Activities
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
Concept Solution Blueprint Activities
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.
Concept Solution Blueprint Activities
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
Concept Solution Blueprint Activities
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
Concept Solution Blueprint Activities
• 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
Concept Solution Blueprint Activities
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
Concept Solution Blueprint Activities
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
Concept Solution Blueprint Activities
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
Concept Solution Blueprint Activities
• 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
Concept Solution Blueprint Activities
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
Concept Solution Blueprint Activities
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
Concept Solution Blueprint Activities
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
Concept Solution Blueprint Activities
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
Concept Solution Blueprint Activities
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
Concept Solution Blueprint Activities
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
Concept Solution Blueprint Activities
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
Concept Solution Blueprint Activities
• 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
Concept Solution Blueprint Activities
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
Concept Solution Blueprint Activities
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
Concept Solution Blueprint Activities
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
Concept Solution Blueprint Activities
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
Concept Solution Blueprint Activities
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 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
-
Maintenance Costs Low 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
Maintenance Costs 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
Concept Solution Blueprint Activities
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.
