Process Analysis

Contact Martin Modell   Table of Contents

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

  1. All the areas where those related processes or activities are accomplished
  2. What those processes or activities are
  3. How they are performed
  4. Why they are performed
  5. How each process or activity relates to the other processes and activities of the function and to other processes and activities within other functions

Each process or activity must be identified, described, and the following information gathered and documented.

  1. The business transactions which trigger this process or activity.
  2. For each transaction, a description of its source document, its timing, frequency, and volume, any variants, all exception conditions, and any editing which is performed.
  3. If only part of the data resident on the transaction source document is necessary, a statement as to why the remainder is unused. Any additional sources of the same data should be identified, as well as the rules for validation and verification.
  4. For each transaction, describe in detail the processing which is initiated as a result of that transaction's arrival. Document whether that processing is immediate, deferred, or conditional. If the processing of that transaction is dependent upon prior processing or prior data availability, it should also be indicated.
  5. Any applicable manual procedures which apply to the processing should be identified, described, and, where applicable, included.
  6. Any data saved or filed between processing steps should be identified and the method of saving or filing the data described. Data saved on the originating transaction document should be included in this description.
  7. Any reports generated as a result of the processing should be documented, and samples of each unique page of each report should be included in the documentation. Any controls should be documented, and any auditing procedures should be described.
  8. Any control checks, control points, and decision points should be clearly identified and described.
  9. All procedures for error detection and correction should be clearly documented, and the actions taken as a result of error detection should be included.

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.

  1. Who are the users? How many people are in the user processing area?
  2. What is the average length of employment within the user area?
  3. What is the average length of experience in the user area?
  4. What is the average rate of increase in personnel head count in the user area?
  5. What is the average turnover rate in the user area?
  6. What do the users do?
  7. Whom do the users work for, and what do the users' superiors do?
  8. What is the business process or activity, that the user is supposed to perform?
  9. What are the user's problems, and why are they problems?
  10. Why do the users do what they do?
  11. Whom do the users do what they do for?
  12. When do the users do what they do?
  13. Where do the users do what they do?

Where possible, the documentation should answer the following questions.

  1. Who performs the processes or activities?
  2. What are the actions performed by that person or persons?
  3. When are these actions performed?
  4. Why are these actions performed?
  5. Why are these actions being performed at this time?
  6. What is the impact on the firm if these actions are not performed?
  7. What is the impact if these actions are performed incorrectly?
  8. What is the frequency of these transactions?
  9. What is their rate of arrival?
  10. Are there peak periods?
  11. What is the average number of transactions processed per day, week, or other applicable time frame?
  12. What is the maximum expected number of transactions?
  13. Are there any problems which consistently arise with the present transaction documents?
  14. Are there any data which could be added to the document which would ease the processing burden?

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

  1. Where do these documents come from?
  2. What is their frequency of arrival?
  3. What is the average document waiting time and the average processing time?
  4. What is the average backlog of documents waiting to be handled?
  5. What is the document's level of accuracy or completeness?
  6. Are there any document processing dependencies?
  7. What other information is needed to process the document?
  8. Are there any other document dependencies?
  9. Are the documents received on a continuous even basis, or is their arrival cyclic? Are there peaks and valleys?
  10. How long are the documents kept?
  11. What criteria determine when a document is disposed of?
  12. Are there any document priorities? Are there any significant variations within the general document types?

For each document generated by the processing area user, the analyst should describe in business terms

  1. Where do these documents go?
  2. What is their frequency of departure?
  3. How long does it take to generate the document?
  4. What is the average backlog of documents waiting to be generated?
  5. What is the document's level of accuracy or completeness?
  6. Are there any document dependencies?
  7. What is the average length of the documents?
  8. Are there any significant variations within the general document type?

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:

  1. How would the user rate his knowledge of the personal computer (his level of computer literacy)?
  2. What portion of the normal dayís work is performed using the computer?
  3. What packages or products does the user use?
    1. Word processor?
    2. Spreadsheet?
    3. Graphics or presentation preparation?
    4. Database or file management product?
    5. Project Management?
    6. Personal time management?
  4. Does the user have any add-in or supplementary product such as conversion tools, dictionaries, add-in assistants?
  5. What does the user use each product for?
  6. Does the user consider any of the products to be critical for his or her work?
    1. Which ones?
    2. Why?
  7. How often is each product used?
  8. What is the userís evaluation of their level of proficiency with each product?

Printers and plotters

  1. Does the user have a personal printer?
  2. Does the user share a printer with other users?
    1. Dot Matrix?
    2. Inkjet?
    3. Laser?
    4. Color?
  3. How much use is made of each?
  4. Does the user have a personal plotter?
  5. Does the user share a plotter with other users?
  6. How often is the plotter used and for what purposes?

Scanners:

  1. Does the user have a scanner?
  2. Does the user share a scanner with others?
  3. How often is the scanner used and for what purposes?

Fax machines:

  1. Does the user have fax capability in his machine?
  2. Does the user share a fax machine with others?
  3. How often is the fax machine used and for what purposes?
  4. Does the user have any personal products on his machine?
  5. Does the user have a home machine?
  6. How does the userís home machine compare to the office machine?
  7. Does the user have the same or different products on their home machine?
  8. Does the user have access to an on-line service provider
    1. At home?
    2. In the office?
  9. If so what use is made of the facilities of that provider?
  10. Are there formal standards for product use, document preparation and file storage?
  11. Does the user have the most current versions of the products used?
  12. Does the user have product manuals for each product that is used?
  13. Are the manuals up-to-date?
  14. How often does the user refer to product manuals?

File storage and data access

  1. Describe the kind and amount of data storage devices (floppy disk, hard disk, CD-ROM) associated with the userís machine?
  2. What does the user store on each of the above?
  3. Does the user back up the data files on the personal computer?
  4. How often does the user back up the data files on the personal computer?
  5. Are all data files backed up, or only selected ones?
    1. And if selected ones:
    2. which ones?
    3. Why were they selected?
  6. What media is used for file back-up?
  7. Where are the back-up copies stored.
  8. Is there a log or record kept of when files were backed-up and when?

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:

  1. What products and files can be accessed form the LAN?
  2. If the user has a home machine, can the user connect to his or her business machine from their home machine?
  3. If the user has a home machine, can the user connect to the business network from his or her home machine?
  4. Where (on what server) are the userís files stored?
  5. If the files are stored on multiple machines is there a scheme for which files are stored in what location?
  6. Does the user have access to E-mail?
  7. How frequently does the user use the E-mail system?
  8. If there is a scheduling function for meetings and personal tasks is this facility used?<
  9. Does the user also have access to the Internet?
  10. What use does the user make of the Internet facilities?
  11. Does the use transfer files to and from his machine?

The documentation produced should also contain, at a minimum,

  1. The user's job description.
  2. The nature of the user's problems, if any.
  3. The impact of those problems on the user, the user's processing, and, if necessary, on the firm.
  4. Processing constraints which apply. These constraints should cover resources, time frames, personnel, business exposure, loss of management control, cost impact, and the cost versus benefits of having the problem resolved, etc.
  5. User-perceived problems with the current processing responsibilities or relationships.
  6. User-perceived problems with any of the currently received documents.
  7. User dependencies on processes performed in any other user area.
  8. User management or financial controls should also be well documented.

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

  1. What applications do they use?
  2. Who designed and developed each application?
  3. Did the user have a role in developing the requirements for any of the applications?
  4. Did the use have a role in testing any of the applications?
  5. Did the user have a role in approving the use of any of the applications?
  6. What functions, facilities, screens or reports do they use?
  7. How frequently do they use each of the above?
  8. What are each used for?
  9. Are those facilities, screens, reports or functions sufficient for their needs?
  10. Are there any deficiencies with the available screens, reports facilities or functions? And what are they?
  11. How current are the data files associated with each application?
  12. How meaningful is the information in the data files?
  13. Does the user have the ability to query the data files on his own or must he use canned queries?
  14. Does the user have personal files on the mainframe?
  15. When was each of these applications last modified?
  16. What outstanding requests for modification, change or enhancement have been submitted for the application?
  17. When were those change request submitted?
  18. What are the status of those change requests

Departmental Computing Support

  1. What applications do they use?
  2. Who designed and developed each application?
  3. Did the user have a role in developing the requirements for any of the applications?
  4. Did the use have a role in testing any of the applications?
  5. Did the user have a role in approving the use of any of the applications?
  6. What functions, facilities, screens or reports do they use?
  7. How frequently do they use each of the above?
  8. What are each used for?
  9. Are those facilities, screens, reports or functions sufficient for their needs?
  10. Are there any deficiencies with the available screens, reports facilities or functions? And what are they?
  11. How current are the data files associated with each application?
  12. How meaningful is the information in the data files?
  13. Does the user have the ability to query the data files on his own or must he use canned queries?
  14. Does the user have personal files on the departmental computer?
  15. When was each of these applications last modified?
  16. What outstanding requests for modification, change or enhancement have been submitted for the application?
  17. When were those change request submitted?
  18. What are the status of those change requests

Network Server and Personal Computers

  1. What applications do they use?
  2. Who designed and developed each application?
  3. Did the user have a role in developing the requirements for any of the applications?
  4. Did the use have a role in testing any of the applications?
  5. Did the user have a role in approving the use of any of the applications?
  6. Who designed and developed the application?
  7. What functions, facilities, screens or reports do they use?
  8. How frequently do they use each of the above?
  9. What are each used for?
  10. Are those facilities, screens, reports or functions sufficient for their needs?
  11. Are there any deficiencies with the available screens, reports facilities or functions? And what are they?
  12. How current are the data files associated with each application?
  13. How meaningful is the information in the data files?
  14. Does the user have the ability to query the data files on his own or must he use canned queries?
  15. When was each of these applications last modified?
  16. What products and files can be accessed form the LAN?
  17. What products does the user have on his personal machine?
  18. What applications has the user written using each of those products?
  19. Does anyone else use an application written by the user?
  20. Does anyone else use the data in the userís data files?
  21. Does anyone share the userís machine?
  22. Where are the userís files stored?
  23. If the files are stored on multiple machines is there a scheme for which files are stored in what location?
  24. Does the user have business related files on the server? On his personal machine?
  25. Does the user have personal files on the Server? On his personal machine?
  26. Does the user back up any data files on a regular basis? Which ones? How often?
  27. Does the user produce reports for use by others from data maintained in personal files?
  28. Does the user produce data files for use by others from data maintained in personal files?

Additional Documentation To Be Included, If Available

In addition the business process analysis should contain detailed information about

  1. The user's charter or job description
  2. User comments on the accuracy of the charter or job description.
  3. Any standards, policies, or procedures which govern or apply to the user's processing activities.
  4. Any user manuals which have been produced by the user or for the user by others.
  5. Samples of all documents handled by the user area. These samples should include both blank and completed documents and should include as many exception cases as possible.
  6. Samples of all reports, charts, graphs, and other output produced by the user area. These reports should be accompanied, where possible, by a complete description of each section or entry on the document, report, graph, chart, etc.

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.

  1. Clearly identify the subject of the particular model.
  2. Clearly identify the start and end points.
  3. Clearly identify the name of each process or process entity in the model.
  4. Identify the direction of the flow, any relationships between processes, and of any material or information entering or leaving each process step or entity.
  5. Identify the time sequences or time frames involved.
  6. Identify the source of any off-model inputs, and the destination of any off-model outputs.
  7. Clearly identify the thread of the model and any points where the activities of this thread may initiate other threads.

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.

Contact Martin Modell   Table of Contents

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.