Process Analysis
CHAPTER SYNOPSIS
The business process and activity analysis step is a more in depth analysis of the information and business functions identified and developed in the preceding steps. A business function is an end-to-end role or reason for existence. These individual functions, however, are composed of a series of processes or individual activities which individually and in combination perform the work of that function. A function is thus a group of related processes or activities all performed to achieve a predetermined goal. Those discrete processes or activities are in turn composed of discrete tasks.
This chapter discusses the concept of a business process and provides some insight into their identification and documentation. It includes extensive lists of questions for the analyst to ask when interviewing at the process and activity level.
What Is a Business Process?
A definition
A process is a sequence of related activities, or may be a sequence of related tasks which make up an activity. These activities or tasks are usually interdependent, and there is a well-defined flow from one activity to another or from one task to another.
A definition
An activity is a set of tasks which are organized and proceduralized to accomplish a specific goal. The distinction between a subfunction and an activity is as much a matter of interpretation as it is a matter of scope.
Generally, an activity is discrete and part of an overall function. It is highly structured and task oriented as opposed to control or management oriented. Generally functions are managed and activities are performed, although this distinction is far from definitive.
Activities are data driven in that they are triggered by transactions or requests for data. Activities are the active portion of functions and tend to be repetitive and formalized.
Business Process Analysis
The business process and activity analysis step is a more in depth analysis of the information and business functions identified and developed in the preceding steps.
A business function is an end-to-end role or reason for existence. These individual functions, however, are composed of a series of processes or individual activities which individually and in combination perform the work of that function. A function is thus a group of related processes or activities all performed to achieve a predetermined goal. Those discrete processes or activities are in turn composed of discrete tasks.
A business process is a set of activities or tasks which are performed in sequence or in parallel to accomplish a specific goal. The process may be manual or automated and may comprise one or more activities or tasks.
For each function identified at the preceding step, the analyst must identify those processes or activities which are performed to support that function. They may be performed by one or more persons in one or more areas of the firm.
A major portion of the effort in the analysis phase is devoted to this analysis of user processes and activities. This analysis describes and defines each user process and activity to determine if, and under what conditions, they may be automated. As with the functional analysis these descriptions in and of themselves do not provide adequate insight into the flow, complexity, or interdependence of the user processing activities. All too often each user process is treated as if it stood alone and was complete in and of itself. This individual treatment of processes does not capture the processing flow, nor does it necessarily detect related processes which are external to the immediate user's function.
The task of the analyst is to identify and describe in detail
Each process or activity must be identified, described, and the following information gathered and documented.
Some Questions to Be Asked during Process Analysis
The business process description document developed as a result of the process analysis should, at a minimum, answer the following questions.
Where possible, the documentation should answer the following questions.
Business Process Analysis Documentation
For each input document handled by the user while performing the process or activity, the analyst should describe in business terms
For each document generated by the processing area user, the analyst should describe in business terms
User Specific Interview Questions
For each user within the processing area that has a personal computer or workstation the analyst should describe the following in business terms
(Note: Remember that each process or activity area is a part of a functional area, and that the following questions may have already been asked of the user in the context of the functional area analysis. If the same users are interviewed as part of both functional and process analysis, care should be take to ensure that the questions asked in this set of interviews are relevant to the use of personal computers or workstations in conjunction with the user’s processing responsibilities and activities.):
Workstation:
Printers and plotters
Scanners:
Fax machines:
File storage and data access
If the processing area has a Local Area Network (LAN) or connectivity to a WAN Wide Area Network, are all (or any) processing area user workstations connected to a LAN or WAN?
For each user connected to the LAN or Wan, the analyst should describe the following in business terms:
The documentation produced should also contain, at a minimum,
User Applications
One basic set of questions that must be asked of the users within a processing or activity concerns the automated support available to them to perform that processing or activity:
Mainframe support
Departmental Computing Support
Network Server and Personal Computers
Additional Documentation To Be Included, If Available
In addition the business process analysis should contain detailed information about
The Need for Business Process Models
Just as the business functional analysis benefits from the development of a business function model, so too the business process analysis benefits from the development of business process models, one for each major, or significant, business process. These models depict the interactions of the various user tasks and activities during the performance of the processing and the interaction of the user's processing with other processing areas of the firm.
Without this graphic representation of user processing within the overall framework of the function, and perhaps within the organization as well, and without an understanding of the relationship of the user process with the other processes of the firm, it is difficult for analysts to assess the accuracy of their business knowledge and their understanding of the information gathered from the user during the interview process and from their own observations.
Many processing flows interact in ways which transcend and cross the hierarchic boundaries which are implicit in the table of organization. The process models, both individually and in composite form, help the analyst understand the overall flow of processing and of data and information within the firm.
The process description documentation and the process-to-process relationships developed in this phase will be used to develop a process map, process flow diagram, or process entity-relationship model.
These business process models place each of the business processes into perspective with every other business process and map the flow from one business process to another to accomplish the business area function.
As with the business function model, the process model of the function can depict these interrelationships and interactions in a much clearer and more meaningful way than can the narrative alone.
Business process models may be produced in a variety of ways and for a variety of reasons. They may model the flow of material or information into and out of processing stations, or they may model the flow of a particular item of material or information through the entire firm, showing its various uses and transformations. The models may attempt to show the sequence of processes without regard for the inputs and outputs. Some models indicate conditional flows and others ignore conditional logic.
For this reason, as with the functional models, it may be necessary not only to develop multiple models but to use many different modeling techniques to portray all the relevant information. Entity-relationship models may be drawn, for example, to depict the sequence of processes relevant to a particular input document or type of material.
Data flow diagrams, on the other hand, might be used to depict all of the inputs and outputs of a series of related processes and the ways in which all the inputs and outputs affect each other.
A hierarchic process diagram would depict the processing dependencies and sequence without regard to the particular data or materials which drive, or result from, the processes themselves.
Flowchart diagrams may be used to depict not only the processes but also the types of data storage or transfer media involved and the logical decision points which govern the various processing legs.
Business Process Entities versus Processes
Business processes are the activities performed by a business functional unit. Because the processing units and the processes performed by those units usually bear the same designation, any model produced should clearly indicate whether the processing stations or the processing activities themselves are being modeled. The need for this distinction becomes apparent when one looks at the differences between the two. The concept of a processing station or a processing entity is derived by combining the definitions of a process and an entity.
A definition
A process entity is defined as the conceptual unit which is designated to perform one or more specific processing tasks upon a business transaction or upon business materials. That conceptual entity performs all the activities and tasks required by a single processing step. Each process entity exists to handle some discrete aspect of a business transaction and thus relates to the other process entities, each of which handles some other discrete aspect of that transaction.
In many businesses the same discrete set of process activities may be performed in many different physical units (a logical flow). By the same token, a physical unit may perform a number of different discrete processes (a physical flow). These processes may or may not be related to each other through a particular transaction or thread.
It thus becomes necessary to state clearly whether we are modeling the flow of processes logically between units or physically within a unit itself, or whether we are modeling the processing actions themselves. The logical flow follows the transaction through the firm; here the transaction remains constant and the processing areas change. The physical flow models the inputs and outputs of a particular unit; here the unit remains constant and the flows change. The logical flow is the more difficult of these models, since, as stated previously, process entities interact in ways which transcend and cross the hierarchic boundaries which are implicit in the table of organization. A process model can depict these inter-process relationships and interactions in a much clearer and more meaningful way than can a straight narrative.
When we dealt with functions, we dealt with their roles or, in other words, what function was performed and when. When we examine process entities we are again dealing with the roles or activities of the process entities within the functions. These process entities are of necessity subservient to the functional entities and the functional relationships which have been previously defined. A functional entity should not employ a process entity which is not related to the functional role itself; however, it is possible to find process entities which perform work for multiple functional entities. In this case, the processes should be consistent with each of those functions. Personnel record keeping activities would be an example of such a cross-functional process.
In the functional model we took care to ensure that each functional entity represented a single functional role. Within a process model we must take care to ensure that each process entity represents a single process. Each unique process should be triggered or initiated by a single transaction type or class of transaction. Each process may require other material or data to complete its tasks, but there should be a primary trigger transaction.
Process Entity-Relationship Models
A process entity-relationship model is not concerned with the data that flows between the process entities but rather with the direction of the flow, source, and destination of the flow and the sequence of the stations along the flow. Here we are not concerned with the processing that is performed or even how it is performed, but rather who performs the processing and when.
These are not necessarily transaction flows in that they follow a particular transaction through the firm, but rather they depict the sequence of actions which result from a particular transaction. Just as there may be many functional threads through the firm, so too there may be many separate processing threads; however, no transaction should generate multiple threads, although a single thread may have multiple legs (see Figures 13.1, 13.2, and 13.3).
While these multiple threads may cross, join, or run parallel, each is distinct and thus each should be modeled separately. The usual method for producing process models is to select each distinct primary document, in turn, and note the sequence of processing steps which are initiated by it.
The sequence will end with a final report being produced, the information contained in the transaction being stored in the files of the firm, or the information being of no further interest to the firm.
Where the sequence ends in a filing step, it should be noted whether this is an intermediate file, waiting further triggers (such as an invoice awaiting payment or a purchase request awaiting material receipt) or a final or archive file (such as paid invoices, filled orders, or shipped material).
Guidelines for Developing a Process Model
The following are some guidelines to be used in developing a process model.
It should be understood here that we are looking at a sequence of steps, not necessarily at the flow of the transaction. The transaction is only the trigger for the first step.
A Professional's Guide to Systems Analysis, Second Edition
Written by Martin E. Modell
Copyright © 2007 Martin E. Modell
All rights reserved. Printed in the United States of America. Except as permitted under United States Copyright Act of 1976, no part of this publication may be reproduced or distributed in any form or by any means, or stored in a data base or retrieval system, without the prior written permission of the author.