bsp

From h_lo Tue Dec 8 09:14:36 1998 Return-Path: Received: (from h_lo@localhost) by oz.plymouth.edu (8.9.1/8.9.0) id JAA24548 for harding; Tue, 8 Dec 1998 09:14:35 -0500 (EST) From: "Hon S. Lo" Message-Id: <199812081414.JAA24548@oz.plymouth.edu> Subject: no subject (file transmission) To: harding (Edward Harding) Date: Tue, 8 Dec 1998 09:14:35 -0500 (EST) X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oz.plymouth.edu id JAA24548 Status: O bsp Chapter 1. BSP Concepts

Business Systems Planning is most often thought of as a structured approach or methodology. This methodology, however, is based upon some fundamental concepts, a good understanding of which can give the BSP study team member:

1. A better appreciation of the "why's" of the methodology.

2. Improved confidence in applying variations to meet specific situations

3. A better background with which to communicate the objectives and eventual recommendations to senior management.

The premise for conducting a BSP study is that there exists within the organization a need for significantly improved computer-based information systems (I/S) and a need for an overall strategy to attain them. BSP is concerned with how these information systems should be structured, integrated, and implemented over the long term. The basic concepts of BSP can be related to the long-term objectives for I/S in an organization.

An I/S Must Support the Goals and Objectives of the Business

The most basic concept underlies the "top down" philosophy of the methodology as well as several of the specific steps, such as executive interviews and system priorities.

Since information systems can be an integral part of a business and be critical to its overall effectiveness, and because they will continue to represent major investments of time and money, it is essential that they support the organization's true business needs and directly influence its objectives. BSP, then, can be thought of as a vehicle or process to translate business strategy into I/S strategy (see Figure 1).

Obviously, it is important that an organization be willing and able to express its long-term goals and objectives. For some organizations, this can be done principally through the business plan. For others, where a business plan is not available or current, it can be done as a part of the BSP methodology. In either event, a recognition of this basic need by senior management is critical, for only with that recognition will their commitment and involvement be great enough to guarantee a meaningful BSP study.

An I/S Strategy Should Address the Needs of All Levels of Management Within the Business

This requirement has several implications relative to I/S structure. First, it is important to recognize the varying characteristics of information as needed by different activities and management levels. Typically, lower levels need considerable detail, volume, and frequency, higher levels need summaries, "exception" reporting, and inquiries, and still higher levels need cross-functional summaries, special requests, "what if" analyses, "external" requirements, etc. It would be impractical to construct a single system to accommodate all activities or management levels, and it would be erroneous to associate any one type of information requirement solely with one management level. Clearly, there is need to establish some reasonable framework upon which the I/S can be defined.

First, the emphasis in I/S should be in support of management decision making. This is in contrast to more traditional bookkeeping or recordkeeping functions. Business decisions are made for various purposes, but most can be associated with either planning or control. Planning, of course, is the establishment of various missions, objectives, and policies, and it occurs at all levels. Good information is vital to the establishment of good plans. Control decisions, on the other hand, are made in order to guide an activity toward some implicit or defined (by the plan) objective. The I/S can provide the measurements of the current or actual condition to the decision maker. We thus complete a planning, measurement and control cycle with I/S potentially an integral part. Since planning and control are the keys to decision making, a framework for I/S based upon these activities can be utilized. It has been proposed, *and well accepted today, that three distinct but concurrent planning and control levels exist in any organization:

Strategic planning, the process of deciding on objectives of the organization, on the resources used to attain these objectives, and on the policies that are to govern the acquisition, use, and disposition of resources.

Management control, the process by which managers assure that resources are obtained and used efficiently in the accomplishment of the organization's objectives.

Operational control, the process of assuring that specific tasks are carried out effectively and efficiently.

Further characteristics of these areas are outlined in Figure 2. An advantage of this framework is that it does not restrict planning and control activity to any particular industry, function, or management level. A conclusion at this point is that an I/S could conveniently address itself to any one of the above three planning and control levels.

Resource management is also key to this philosophy and represents a major vehicle for I/S definition. The specific resources to be managed vary in nature and relative importance from one organization to the next. Examples of traditional resources to be managed are people, facilities, materials and money. Their requirements are based upon the needs to support the prime mission area of the organization, e.g., its products or services. Because an organization's product or service area has all the attributes of a resource, i.e., a life cycle of activities and decision points, and yet drives the other resources, it is referred to as the "key resources". Each resource, including the key resource, is managed through planning and control decisions of the three levels previously discussed. Resource management has the desired characteristic of cutting across organizational boundaries---vertically across management levels and horizontally across functional lines. Thus a framework based on resources as well as planning and control levels can be established, and I/S architecture can be applied within this framework.

An I/S Should Provide Consistency of Information Throughout the Organization

The keyword in this objective is consistency. The implication is that information derived from more traditional data processing applications is not necessarily consistent, particularly when applied to new business problems (decision areas) of broader scope. The problems in data consistency normally arise as a result of a historical evolution of computer usage that traditionally occurs. Isolated and independent application areas are selected and mechanized, typically to reduce operational costs. The data files are defined as necessary to support the specific needs of each application without regard to one another or to future applications. The data itself is converted from manual files located and maintained by the using organization.

As computer applications are added, new data files are usually required since the data requirements for different applications are rarely the same. These are usually created from spinoffs of existing mechanized files plus any additional data that may be required from the using area. Summary-type reports for higher management levels are the result of sorting and merging various existing data files together to create new ones. Rarely is any existing data file of the form or content required to provide newly requested information of any magnitude. Thus new data files are born. Data redundancies and file update requirements multiply. The continual cry from management that "I know the data that I need is somewhere in data processing, but I can't get at it" may be basically true from their point of view. The data may be there, but not necessarily defined as needed, of adequate summary level or sequence, or of proper time period or currency.

Data, then, exists in most organizations in varying form, definition, and time. The form may be uncaptured raw data, mechanized data files, detailed DP reports, summarized DP reports, business documents, or knowledge in someone's head. The definition of any given data can have as many variations, and thus inconsistencies, as there are users of that data. For example, "salary" to the payroll department may mean an employee's actual figure monthly pay, to the project manager an annual figure plus burden to be charged to a customer, to the department manager a budget line item representing total expense for all reporting employees. In addition, a time inconsistency is very likely to exist between what may otherwise be comparable data. Data may be captured by such varying methods as the mail, telephone, data terminals, or satellites. It may be "batched" over varying lengths of time by the user or by DP before processing, or it may be entered "online" as each transaction occurs, directly from its source. Data may be processed daily, weekly, or monthly on a predetermined schedule, or it may be incapable of being processed until a series of prior computer runs are completed (e.g., the month-end closing). The output itself may be mailed or it could be immediately available as the result of an online inquiry. Finally, the report may be up to the second, as when reading from a terminal, or it may have lain in a desk for three weeks after last month's processing. The combinations of time deviations between data capture, data processing activity, and actual data usage are many.

With all these potential data inconsistencies, it is no wonder that reports frequently don't "match" between using departments and managers. This becomes a problem most often during interdepartmental decision making or at higher reporting levels where consolidation of multifunction activities is important. Attempts to provide better data consistency usually result in "resystematizing" or "consolidating" existing applications into larger ones with broader problem scope and data definitions. This may yield a satisfactory system within the defined scope, but again, as still broader problems are addressed, there will undoubtedly be data inconsistencies between the larger systems. Resystematizing at this scope may be extremely expensive and difficult to justify, let alone accomplish. Comments prevail such as "our systems cannot talk to one another".

What has been described is the classical "bottom up" evolution of data processing systems. In order to begin to address the data consistency problem, a different philosophy must be adopted relative to data management. This is commonly referred to as managing data as a resource. This concept suggests that data is of considerable overall value to an organization and should be managed accordingly. It should be potentially available to and shared by the total business unit on a consistent basis. It should not be controlled by a limited organizational segment but by a central coordinator, much like other corporate resources, such as cash and personnel. The management function would include formulating policies and procedures for consistent definition. sourcing, technical implementation, use, and security of the data.

An l/S Should be Able to Live Through Organizational and Management Change

Many data processing systems and applications are set up to provide the information needs of a specific department or other organizational entity. Others are built solely on the specific output report requirements of a particular manager. Both types can become immediately obsolete upon a reorganization or management change. A new manager may have his own ideas as to what information is needed to run the department. While this kind of change is inevitable, it can be expensive from a data processing standpoint. The data processing system, however, should in no way inhibit management flexibility in a dynamic enterprise. Thus, the l/S must anticipate and be capable of living through the long-term organizational and management changes of a business with minimum impact if the expected return on investments is to be realized.

This objective cannot be realized without the proper support vehicle for l/S, and this vehicle must be independent of the various components of the organizational structure. The BSP vehicle is the business process, that is, a basic activity and decision area irrespective of any reporting hierarchy or specific management responsibility. A logical set of these processes can be defined for any type of business and will undergo minimum change as long as the product or service area of the business remains basically the same.

One example of a business process is purchasing. A particular business might define this as "the process by which raw materials are acquired from vendors." There may or may not be a separate organizational unit to accomplish this process, or indeed there may be several. Inherent within this process are the various activities and decisions necessary to accomplish the process.

Defining the organization's business processes is one of the most important parts of the BSP methodology, and the method for doing so is tied directly to the previously discussed l/S framework, that is, one based on resources and planning and control levels. With this in mind it is convenient to define an organization's business processes in association with each of its defined resources. Emphasis in BSP is normally placed upon those processes necessary to manage the key resource. Each resource of a business can be thought of as having a "life cycle" made up of several stages. A product life cycle, for example, has four stages: requirements, acquisition, stewardship, and retirement. The time spread of the life cycle can vary greatly with the particular product area but is of no consequence in this approach. Business processes can be identified to describe the major activities performed and decisions made by the business in the course of managing the resource throughout its life cycle. These can normally be organized into a process hierarchy, and this is done without regard to organizational involvement or responsibility.

The above approach results in process definitions that encompass the three planning and control levels previously discussed--namely, strategic planning, management control, and operational control. Using a product resource as the example again, the decision to pursue a particular product area would be "strategic planning," the planning and control decisions relative to product volumes or advertising expenditures would be "management control," and the decisions in areas of engineering control, manufacturing efficiency, etc., would be "operational control." By using this approach for all the resources it is possible to define all the business processes that take place within any organizational segment. This may be tempered by practicality in the actual BSP as there may be little l/S support interest for some of the resources.

The l/S Strategy Should Be Implemented By Subsystem Within a Total Information Architecture

There are several implications and concepts associated with this statement. The first is that a total l/S to support the entire business unit's needs is too big to build in any single project. However, because of the many problems associated with a "bottom up" evolution of systems (data inconsistencies, non-integrated system designs, expensive resystematizing, priority difficulties, etc.), it is very important that long-range goals and objectives for l/S be established. The basic concept, then, is top-down l/S planning with bottom-up implementation (figure 3).

With this concept the long-range l/S goals and objectives are identified through a top-down planning process (the BSP approach). The identified systems are then implemented in a modular building-block fashion over time while remaining consistent with the organization's business priorities, available funds, and other shorten-term considerations. This philosophy can be likened to the detail design and construction of a large office building, which would be unthinkable without an architect's approved drawing of the finished product.

The BSP methodology, although consisting of considerably more steps and detail than shown in Figure 4, is consistent with this philosophy, Step 1 of Figure 4, defining the business objectives, is intended to ensure agreement among all executive levels as to where the business is going, so that the l/S strategy can be in direct support. Step 2, defining the business processes, establishes the prime long-term basis for l/S support in the business. Step 3, defining the data classes, can be done on the basis of the processes to be supported. A data class, as the name implies, is a major category of data needed to support one or more business processes. For example, customer information is a data class needed in several process areas, such as order entry, billing, and distribution. This step results in a definition of all the data to be managed as a resource across the business unit. Step 4, defining the information architecture, becomes a statement of the long-term l/S objective. This is normally in the form of a group of interrelated l/S areas and the associated data to be managed. From the information architecture the individual modules can be identified, prioritized, and built as scheduled by the l/S plan.

A significant piece of the BSP methodology is the formulation of a recommended information architecture. The intent is to develop an implementation strategy that can be built in modules and yet provide justifiable return to the business at each step. These modules or implementation pieces are generally referred to as information systems (l/S). Each could be thought of as the depository or management point for a particular set of the data classes. As the data classes are implemented (assumed through data base technology), it is possible to provide the information needs for various business processes. Each l/S then normally becomes associated with one or more business processes and one or more data classes (see Figure 5). The implementation strategy should obviously be in tune with the business needs. An identified l/S is responsible for the collection and maintenance of its data bases for the entire business. Other, or later implemented, systems can draw on these data bases as well as new ones that they will create and maintain.

Most of the identified l/S areas will normally be in support of processes that are operational in nature. That is, the decision area inherent in the processes will relate to the "operational control" level of planning and control. Thus these l/S's are sometimes referred to as operational control systems. The managed data is also at an operational level and is typified by much detail and quantity. A management control system, on the other hand (Figure 5), is in support of a "management control" category of processes. Its managed data would typically be summarizations of the internally generated operational data (dotted lines in the figure) plus any other data (competitive data, for example) as necessary to support the processes. By having "business plan" data in the date base, the executive could effect control decisions by comparing actual versus plan for his area of responsibility.

In summary, there are a number of basic concepts and philosophies relative to information systems upon which the BSP methodology is based. The methodology itself should be considered flexible in nature. That is, certain steps and techniques could be altered in order to adapt to specific situations without detriment to the final outcome. However, these basic concepts themselves should be considered inviolate. They, in effect, are BSP.