Functional Analysis

Contact Martin Modell   Table of Contents

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

  1. Identifiable and definable, but may or may not be measurabl
  2. Definable in terms of activity, responsibility, and accountability

A function may

  1. Be a major area of control or a major activity of the firm<
  2. Be composed of one or more subfunctions
  3. Be performed in one area or in multiple areas
  4. Be performed by an individual, a group of individuals, groups of individuals, areas of the firm, or the firm itself
  5. Involve one or more distinct, dependent or independent activities<
  6. Be identified and defined without being performed

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.

  1. Who are the users? How many people are in the user functional 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 personnel head count increase 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 function, or functions, that the user is supposed to perform?
  9. What are the users' 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?

Business Function Analysis Documentation

For each input document handled by the user, the analyst should describe the following 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 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? Are there any other document dependencies?
  8. Are the documents received continuously, or is their arrival cyclic? Are there peaks and valleys?
  9. How long are the documents kept?
  10. What criteria are used to determine when a document should be disposed of?
  11. Are there any document priorities? Are there any significant variations within the general document types?

For each document generated by the user, the analyst should describe the following 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 document?
  8. Are there any significant variations within the general document type?

User Personal Computer/workstations

If the user has a personal computer or workstation the analyst should describe the following in business terms

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. If so, 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?
  1. Does the user have any personal products on his machine?
  2. Does the user have a home machine?
    1. If so, how does the userís home machine compare to the office machine?
    2. Are the products on the user's home machine the same or different products on their home machine?
  3. Does the user have access to an on-line service provider?
    1. At home?
    2. In the office?
  4. If so what use is made of the facilities of that provider?
  5. Are there formal standards for product use, document preparation and file storage?
  6. Does the user have the most current versions of the products used?
  7. Does the user have product manuals for each product that is used?
  8. Are the manuals up-to-date?
  9. 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?
  6. And if selected ones:
    1. Which ones?
    2. Why were they selected?
  7. What media is used for file back-up?
  8. Where are the back-up copies stored.
  9. Is there a log or record kept of when files were backed-up and when?

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:

  1. What products and files can be accessed form the LAN?
  2. Can the user connect to his or her business machine from their home machine?
  3. 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 organizational chart
  2. The placement of the user and his or her organization within the overall organization
  3. The nature of the user's business
  4. The user's function or job description
  5. The user's specific function, or functions
  6. The nature of the user's problems, if any<
  7. The impact of those problems on the user, the user's function, and, if necessary, on the firm
  8. Any functional constraints which apply. These constraints should cover resources, time frames, personnel, business exposure, loss of management control, cost impact, and the costs and benefits of resolving the problem, etc.

Additional Documentation to Include, If Available

In addition the business functional analysis should contain detailed information about

  1. The user's charter or functional description and user comments as to how accurate that charter or functional description is
  2. Any user-perceived problems with the current functional responsibilities or relationships<
  3. Any user perceived problems with any of the currently received documents
  4. Any user dependencies on functions performed in any other user area
  5. Any user management or financial controls

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.

  1. Functions are not properly placed within the organization.
  2. Functions are not properly named in an organization.
  3. Functions either do not appear on the chart of organization or are not identified by the user.
  4. Functions are not readily identifiable, except in a graphic model.
  5. Some functions are in reality multiple functions combined under one name.
  6. The interaction of the various functions cannot be appreciated except when placed in the overall context of the firm.

Since functions are managerial concepts, the relationships between functional entities are by definition either managerial, consultative, or simply transfer-of-control relationships.

  1. Managerial relationships are those where one entity performs in a planning, controlling, monitoring, organizing, coordinating, or reviewing capacity over another.
  2. Consultative relationships are those where two independent functions work together to perform an activity or achieve a common result. A consultative relationship may also be one of information transfer (informative) or advisory.
  3. Transfer-of-control relationships are those where responsibility for the completion or continuation of a particular task passes to a new function, or where a task has been completed and that completion triggers the beginning of new tasks by new functions. A transfer-of-control relationship may be implemented by the passing of some physical object, such as a file, document, person, or thing from one functional area to another, or it may be implemented by simple notification, where one function notifies another that a state or condition has changed and that the second function may now initiate its activities.

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.

  1. Working from a corporate table of organization, the user interviews, and the functional area descriptions, the analyst is able to identify the individual functions of the firm, develop detailed descriptions of each function, the role of those functions within the firm, and the functions which interact with the subject function. Since each function plays a unique role, it must interact with other functions which play other roles.
  2. Determine those interactions by examining those functions to which the subject function has a direct or immediate relationship.
  3. Make each functional box in the table of organization into a functional entity. Care must be exercised at this point to ensure that each of these functional entities represents a single, unique function, not a combination of functions. All subfunctions should be broken out into separate boxes for clarity of presentation.
  4. Arrange these functional boxes with the names of the functions within each box in a rough sequence corresponding to the business life cycle being depicted.
  5. Draw the relationships between each set of functions as they relate to each other during the particular life cycle being depicted.
  6. Add the name of each relationship to each relationship symbol, and note the flow of the lines connecting the relationship symbols to the functional entities. Unlike the typical entity-relationship models, the relationships will not normally be bi-directional. That is, the flow will normally pass from function 1 to function 2, but not necessarily from 2 back to 1.

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.

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.