Business function-task analysis

By -

Business function-task analysis

40.1 Purpose

Business function-task analysis was developed by IBM in the 1960s to establish the relationships between an organization’s data, processes, and organizational units.

40.2 Strengths, weaknesses, and limitations

Business function-task analysis is particularly valuable when an application or a system development project starts from scratch (no existing system), when a company is faced with a massive reorganization, or when a company’s data resources change substantially. Because so many users are involved, it is relatively easy to obtain user buy-in. Once a business function-task analysis is completed, the results can be used to support further system development and/or expansion.

Although the underlying idea is easy to understand, considerable time and effort are required to perform a business function-task analysis. The relevancy of the data collected is not always clear, and no information is collected from the operational level. Finally, this approach is quantitative, and it fails to account for qualitative factors.

40.3 Inputs and related ideas

The results of a business function-task analysis can be used to prioritize information system development projects or as a structure for defining information system strategy.

40.4 Concepts

Business function-task analysis was developed by IBM in the 1960s to establish the relationships between an organization’s data, processes, and organizational units. It is also known as the enterprise analysis approach and the business systems planning approach. The basic idea is to analyze the entire organization in terms of organizational units, functions, processes, and data elements.

40.4.1 The focus group

Business function-task analysis is performed by a focus group composed of managers from all the functional units in the entire company. Depending on the scope of an information system project, some functional units might be grouped to form meta-units (e.g., an accounting unit might represent the accounts payable, accounts receivable, and customer credit departments) or divided into smaller subunits.

40.4.2 The 5W analysis

The first step in the process is to survey the focus group by asking the members to answer five key questions (how, where, what, who, and when) about relevant functions, processes, and data elements. This task is sometimes called 5W analysis. Some examples of the kinds of questions that might be asked are listed in Table 40.1.

40.4.3 The organizational unit-process matrix

After the 5W analysis survey is completed, an organizational unit-process matrix is constructed (Figure 40.1). The matrix shows the various organizational units along the horizontal axis and the processes the focus group members perform along the vertical axis. Each cell in the matrix is marked with an M (to indicate major involvement) or an S (to indicate some involvement); blank cells indicate no involvement.

The purpose of the organizational unit-process matrix is to identify the relationships between the organizational units and the processes and to determine the degree of involvement of the various units in specific processes. Subsequently, when information systems are developed to perform a given process, the central focus should be placed on those organizational units with major involvement in the process, while organization units with some involvement should receive less attention until adequate resources are available.

40.4.4 The process-data element matrix

The process-data element matrix (Figure 40.2) lists the data elements along the horizontal axis and the processes the focus group members perform along the vertical axis. Each cell in the matrix is marked with a U (to indicate a user of the data) or a C (to indicate a creator of the data); once again blank cells indicate no involvement. Some organizations further clarify the type of use by coding an M (for modify) or an R (for retrieve or read only). Clusters of letters clearly identify the data required to support related processes.

40-01
Figure 40.1  An organizational unit-process matrix.

40.4.5 Data analysis.

Analyzing the wealth of information summarized in the unit-process matrix and the process-data element matrix often reveals indirect relationship between the organizational units, the functions, the processes, and the data elements. Additional cross-checks and walk-throughs can help reduce redundancies and resolve conflicts. The final step in the process is to document the specific information requirements of all the functional units and their related processes.

40.5 Key terms
5W analysis —
The first step in the business function-task analysis process during which the focus group is asked to answer five key questions (how, where, what, who, and when) about relevant functions, processes, and data elements.
Business function-task analysis —
A methodology developed by IBM in the 1960s to establish the relationships between an organization’s data, processes, and organizational units.
Focus group —
A group composed of managers from all the functional units in the entire company that conducts a business function-task analysis.
Organizational unit-process matrix —
A table that identifies the relationships between the organizational units and the processes and shows the degree of involvement of the various units in specific processes.
Process-data element matrix —
A table that shows the relationships between the data elements and the processes.

40-02
Figure 40.2  A process-data element matrix.

40.6 Software

Although no software is specifically designed to support business function-task analysis, spreadsheet software can be used to create and maintain the organizational unit-process matrix and the process-data element matrix. The matrixes in this chapter were created using Excel.

40.7 References
1.  Doll, W. J., Avenues for top management involvement in successful MIS development,MIS Q., 1985.
2.  Laudon, K. C. and Laudon, J. P., Management Information Systems: A Contemporary Perspective, 2nd ed., Macmillan, New York, 1991.
3.  Zachman, J. A., Business systems planning and business information control study: a comparison, IBM Syst. J., 21, 1982.

Comments

Post a Comment

Popular posts from this blog

The Conversion Cycle:The Traditional Manufacturing Environment

By -
Image
The Traditional Manufacturing Environment The conversion cycle consists of both physical and information activities related to manufacturing products for sale. The context-level data flow diagram (DFD) in Figure 7-1 illustrates the central role of the conversion cycle and its interactions with other business cycles. Production is triggered by customer orders from the revenue cycle and/or by sales forecasts from marketing. These inputs are used to set a production target and prepare a production plan, which drives production activities. Purchase requisitions for the raw materials needed to meet production objectives are sent to the purchases procedures (expenditure cycle), which prepares purchase orders for vendors. Labor used in production is transmitted to the payroll system (expenditure cycle) for payroll processing. Manufacturing costs associated with intermediate work-in-process and finished goods (FG) are sent to the general ledger (GL) and financial reporting system. Dependin...
Read more

The Revenue Cycle:Manual Systems

By -
Image
Manual Systems The purpose of this section is to support the system concepts presented in the previous section with models depicting people, organizational units, and physical documents and files. This section should help you envision the segregation of duties and independent verifications, which are essential to effective internal control regardless of the technology in place. In addition, we highlight inefficiencies intrinsic to manual systems, which gave rise to modern systems using improved technologies. SALES ORDER PROCESSING The system flowchart in Figure 4-12 shows the procedures and the documents typical to a manual sales order system. In manual systems, maintaining physical files of source documents is critical to the audit trail. As we walk through the flowchart, notice that in each department, after completion of the assigned task, one or more documents are filed as evidence that the task was completed. Sales Department The sales process begins with a customer cont...
Read more

HIPO (hierarchy plus input-process-output)

By -
Image
HIPO (hierarchy plus input-process-output) 64.1 Purpose The HIPO (Hierarchy plus Input-Process-Output) technique is a tool for planning and/or documenting a computer program. A HIPO model consists of a hierarchy chart that graphically represents the program’s control structure and a set of IPO (Input-Process-Output) charts that describe the inputs to, the outputs from, and the functions (or processes) performed by each module on the hierarchy chart. 64.2 Strengths, weaknesses, and limitations Using the HIPO technique, designers can evaluate and refine a program’s design, and correct flaws prior to implementation. Given the graphic nature of HIPO, users and managers can easily follow a program’s structure. The hierarchy chart serves as a useful planning and visualization document for managing the program development process. The IPO charts define for the programmer each module’s inputs, outputs, and algorithms. In theory, HIPO provides valuable long-term documentation. However...
Read more