> >
Functional Analysis
CHAPTER SYNOPSIS
A function is a series of related activities, involving one or more entities, performed for the direct, or indirect, purpose of fulfilling one or more missions or objectives of the firm, generating revenue for the firm, servicing the customers of the firm, producing the products and services of the firm, or managing, administering, monitoring, recording, or reporting on the activities, states, or conditions of the entities of the firm.
This chapter discusses the concept of business functions and provides some insight into their identification and documentation. It includes extensive lists of questions for the analyst to ask when interviewing or gathering data at the functional level.
What Is a Function?
A definition
A function is a series of related activities, involving one or more entities, performed for the direct, or indirect, purpose of fulfilling one or more missions or objectives of the firm, generating revenue for the firm, servicing the customers of the firm, producing the products and services of the firm, or managing, administering, monitoring, recording, or reporting on the activities, states, or conditions of the entities of the firm.
A function should be
A function may
If a function is performed in multiple areas, those areas may or may not be related in either an organizational or reporting sense. A function is normally chartered to perform one or more related activities. These activities are usually related because they work on common data entities or because the activities are sequential or parallel and perform related work to a common end.
Generally, firms are organized along function lines, in that each vertical organizational grouping performs the same or related set of activities and is responsible to a single control point. Functions may be grouped into superfunctions which come together at very high organizational levels.
Two Categories of Business Functions
The functions of any firm, whether it is a manufacturing, finance, or service firm, can be segmented into two broad categories (Figure 12.1). Each of the various functions of the firm can be assigned to one or the other of these categories, and in some cases, a function may be assigned in both categories.
Business category
Functions in this category consist of those activities which are directly involved in producing the products, providing the services, generating the revenues and the profits of the firm, or managing those areas. This category has been termed the operational area of the firm. The functions in this category have also been termed line functions.
Administrative, support or overhead category
This category contains those functions which service the firm as a legal entity and provide for its day-today well being. The administrative category usually contains functions such as personnel, buildings and maintenance, executive management, general accounting, etc. These functions have been termed staff functions.
Business Function Analysis
Each user function description should be accompanied by an overview of the business documents or transactions which are input to the user function and which in turn drive that function. Samples of each input form should include form data element descriptions of the information on the form that is currently used by the firm; information that might be of potential use to the firm at a later date should also be included, along with the input descriptions.
The analyst should prepare a functional description for each function addressed. This functional description should be written in user, i.e., business, terms, and should not include any data processing jargon or terminology.
The goal of this phase is to place the user sponsor in perspective within his or her specific business area and within the overall corporate business functional framework.
Again it should be stressed that the language of the document should be in user, and thus in business, terms. The scope of the problem, the length of time the problem has existed, and any attempts which have been made to rectify the problem should also be documented.
Some Questions to Be Asked during Functional Analysis
The business function description document developed as a result of the functional analysis should, at a minimum, answer the following questions.
Business Function Analysis Documentation
For each input document handled by the user, the analyst should describe the following in business terms.
For each document generated by the user, the analyst should describe the following in business terms.
User Personal Computer/workstations
If the user has a personal computer or workstation the analyst should describe the following in business terms
Workstation:
Printers and plotters
Scanners:
Fax machines:
File storage and data access
If the user’s workstation is connected to a Local (LAN) or Wide Area Network (WAN) or the analyst should describe the following in business terms:
The documentation produced should also contain, at a minimum,
Additional Documentation to Include, If Available
In addition the business functional analysis should contain detailed information about
The Need for a Business Function Model
Typically, the business function analysis document alone does not provide a true picture of the scope of the business functions; at best, it provides a limited insight into the interactions of the user's function with the other functional areas of the firm.
Without this insight into the place of the user function within the overall framework of the organization and without an understanding of the relationship of the user function to the other functions of the firm, it is difficult for analysts to assess the accuracy of their business knowledge.
In reality, the various functions of the firm interact in ways which transcend and cross the hierarchic boundaries which are implicit in the table of organization. In many organizations, the table of organization is either restricted to certain title or organizational levels, or is so fragmented as to be meaningless, or worse, hopelessly out of date. (See Figure 12.2 for a manufacturing chart of organization.)
The functional description documentation and the function-to-function relationships developed in this phase should be used to develop a function map, function flow diagram, or functional entity-relationship model.
This business function model (Figure 12.3) places each of the business functions into perspective with every other business function and maps the flow from one business function to another to accomplish the business area function. This function flow diagram, or function map, is also called the business function model or enterprise model.
The functional model of the firm, or of a specific functional area of the firm, can depict these cross-functional interrelationships and interactions in a much clearer and more meaningful way than can the narrative documentation alone.
The functional model should depict the flow of control, or the flow of materials or information through the corporation, rather than the hierarchic chain of command. In reality corporate functions act and react with one another in much the same way as the components of any complex structure. That is, there is not so much a hierarchic flow as there is a complex set of relationships between quasi-independent units, each of which is responsible for its own functioning, and for receiving and processing material and information and passing it on to others. Sometimes this processing is independent; sometimes it is in concert with other functions. The processing may be linear, or it may be recursive or iterative.
Since functions are concepts, the modeling of functions consists of modeling conceptual things and thus conceptual relationships. One can use the entity-relationship diagrams to depict a functional model. The concept of a functional entity can be derived by combining the definitions of function and entity.
A definition
A functional entity is defined as the conceptual unit which is designed to perform a specific role within the business life of the firm. That conceptual entity performs all the activities and handles all the processing described within the functional description. Each functional entity exists to handle some discrete aspect of the firm's business and thus relates to other functional entities, each of which handles some other discrete aspect of the business. Functional entities normally have the authority to draft, publish, and monitor corporate policies, standards, and procedures related to their specific sphere of responsibilities.
Although the logical starting point of a functional model is the corporate organizational chart, there are some problems when it is used to identify the business functions.
Since functions are managerial concepts, the relationships between functional entities are by definition either managerial, consultative, or simply transfer-of-control relationships.
In the case of support functions, there may be an additional relationship of a request for service. That is, one function may request the services of another and that request itself initiates a sequence of activities. In some cases more than two functions may participate in a relationship or may contribute the results of their activities to still another function.
The relationship between two functions should be expressible in terms of simple sentences. Each sentence should have a subject (function one), a verb (the relationship), and an object (function two). To illustrate: Purchasing notifies receiving to expect an incoming shipment from a vendor (Figure 12.4).
The Business Life Cycle Matrix
A business life cycle represents the flow of control and interaction through the business. The relative positioning of each functional box is determined by its activity during the life of a single product of the firm, or other unifying aspect or thread.
The determination of this thread is one of the more difficult aspects of functional analysis. One primary source in determining this thread might be the corporate mission statement or charter. Another might be statements by senior management in the annual report as to the firm's main business, or lines of business.
Where the firm has multiple lines of business, the analysts should expect multiple threads to appear, unless the lines of business represent a vertical or horizontal integration of the overall business. Some functions are active only once during the life of a product, or on a thread, while others are active on a continual basis. For the purpose of the model, one should assume that each function is active for the duration but has a specific activation point.
Developing the Functional Model
Developing a functional model requires the following steps.
When completed, the functional model should depict the flow of control, material, or information, or all three, along the life cycle. Because the firm may have many products, services, information, controls, or other logical threads, it may be necessary to produce multiple models, each depicting a particular thread or flow. For instance, the accounting thread will probably be different from the material management thread. The various lines of business threads may themselves be different from the administrative thread. In decentralized organizations there might even be multiple versions of each of the basic threads, each corresponding to the management techniques in use by each decentralized unit. These decentralized threads might in turn be different from the parent company threads.
For these reasons it may be necessary to produce multiple models, or to clearly state at the outset which part of the firm is being modeled. If multiple models are produced, they may intersect or overlap at various points or they may be completely discrete. Overlap and intersection points, if they exist, should be examined carefully to determine if both models agree at those points.
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.