"You must first plant the seeds in order to harvest the crop. Unfortunately, most companies tend to eat the seed and then there is no crop to harvest." - Bryce's Law
INTRODUCTION
When we introduced the original version of the "PRIDE" methodology in 1971 (which is now referred to as "PRIDE"-ISEM), we were primarily concerned with developing enterprise-wide systems. Over time, it became clear to us that we needed to enhance our approach for developing the corporate data base, hence "PRIDE"-DBEM (Data Base Engineering Methodology) was born. Shortly thereafter, we introduced "PRIDE"-EEM (Enterprise Engineering Methodology) as a means to model the business and formulate an enterprise information strategy. When this was done, the last piece of the puzzle of our philosophy for Information Resource Management (IRM) fell into place. This was completed by the early 1980's.
At the time, most companies were concerned with only controlling the data resources pertaining to their Data Base Management Systems. This was a nice first step, but as it became necessary to share and re-use other resources such as software, it started to become obvious a more global perspective on managing information resources was needed, which is where IRM comes in.
DEFINITION
Information Resource Management is the design, development, implementation, and control over all of the resources needed to produce information. Its intent is to share and re-use resources where appropriate. Sharing represents the interchangeability of resources, thereby promoting the standardization and integration of parts in products. By doing so, development time and costs are reduced by simply re-using parts.
To those of you in manufacturing, this will all sound very familiar as this is the same objective of Materials Resource Planning (MRP) and, as such, IRM can trace its roots to MRP. The intent of both IRM and MRP are the same, the only difference is the types of resources being managed. Whereas MRP is concerned with tangible parts and products, IRM is concerned with resources that are more intangible. Nonetheless, both IRM and MRP are concerned with the collection, storage, and delivery of resources in the most cost effective means possible.
TYPES OF INFORMATION RESOURCES
To understand the resources needed to produce information, we must first understand the fundamental nature of information itself. We define it as "the intelligence or insight required to support the actions and decisions of the business." Further, we provide a simple formula for it:
Information = Data + Processing
This means there are two equal variables for producing information: data (representing the facts and events of the business) and, processing (representing how and when data is to be collected, stored, and retrieved). If the data is correct, but the processing is wrong, the information will be wrong. Conversely, if the data is wrong, but the processing is correct, the information will also be wrong. From this, we can deduce three classes of information resources:
DATA RESOURCES - representing the facts and events of the business, along with how they are stored.
SYSTEM RESOURCES - representing how data is to be processed.
BUSINESS RESOURCES - representing both the consumer of the information as well as the human and machine resources participating in the production of information.
DATA RESOURCES
Data Elements - individual facts and events regarding an enterprise (the basic building block of all data resources). Used to identify, describe and quantify the objects of the business; includes both primary and generated values (e.g., Net-Pay, Percent Completed, etc.).
Records - a collection of one or more data elements. Represents logical and physical storage areas within a file, input transactions, print maps and screen panels (incl. messages), and call arguments between programming modules.
Files - a collection of one or more records. Represents logical and physical storage, both computer and manual.
Data Base - all of the files either within a single application or a given enterprise, both logically and physically.
Inputs - a collection of one of more records used to collect data. Can be implemented by screens, paper, verbal, optical, etc.
Outputs - a collection of one or more records to transmit information
SYSTEM RESOURCES
Systems - a collection of one or more sub-systems. Systems can be implemented manually, in part or in full, or with mechanical support (computers).
Sub-Systems - a collection of one or more procedures within a system. A sub-system is a business process representing a flow of work within a specific time-frame.
Procedures - a collection of one or more operational steps (Administrative) or one or more programs (Computer).
Operational Step - an individual task.
Programs - a set of computer-executable instructions performing a step within a computer procedure. A program may be subdivided into modules if so desired.
Modules - compilable program source code consisting of one or more subroutines written in the same programming language. It is not executable by itself. Modules can call other modules.
BUSINESS RESOURCES
Enterprises - a defined business entity with a specific mission, whether profitable or non-profitable in intent. Enterprises take many forms, such as the conventional commercial venture, whether private or public, a government agency, etc. Enterprises consist of business functions and are implemented by Positions.
Functions - a scope of responsibilities for carrying out a specific portion of the mission of the enterprise, e.g., Marketing, Sales, Manufacturing, etc. Functions are implemented by Positions.
Positions - a prescribed set of duties and responsibilities; another name is "job." Positions implement business functions either in part or in full. Positions are implemented by Human/Machine Resources.
Human/Machine Resources - employees, part-time workers, consultants, computers, equipment, etc. Such resources possess...
Skills - specific knowledge or talent as developed by education and/or experience. Proficiency denotes level of skill.
Information Requirements - specific needs for information in order to perform actions and decisions related to the business of the enterprise
Objectives - a goal for the enterprise to achieve whether strategic, tactical, or mandatory in nature. An objective can be used to call for new development, modify or improve an existing condition (mod/imp), or to maintain or correct something. One or more objectives can be grouped into a project. An objective may relate to one or more information requirements.
Projects - a scope of work consisting of one or more phases. A project is an application of the material and human resources to a specific objective through the execution of a prescribed sequence of events. A project implements one or more objectives.
Many of the relationships between the resources are hierarchical in nature, such as Systems Resources that subscribe to a "Standard System Structure" as specified by "PRIDE." Some also have recursive relationships, such as files-within-files or modules-calling-modules. Yet, others are represented by a network of relationships (too extensive to go into here). All of these relationships ultimately represents a model of the business and provides the ability to perform an "Impact Analysis" whereby we can study the effect the change of one resource may have on another. For example, should we decide to change the length of a data element, we should be able to determine, with great accuracy, all of the other resources affected by the change, thereby providing a "roadmap" for a maintenance project.
The mapping and maintenance of these extensive relationships between information resources is the forte of an "IRM Repository" which acts as a "Bill of Materials" processor (see "Managing Design Complexity" - "PRIDE" Special Subject Bulletin #10) at: http://www.phmainstreet.com/mba/ss050207.pdf
In order to promote sharing and re-usability, resources should be uniquely identified by number and name, along with its prescribed characteristics. Such resource definition ultimately represents the rules of the business and allows us to differentiate resources. Using an automated IRM Repository, tests can be performed to check for redundancy in characteristics and, as such, the use of redundant resources can be avoided.
Also see "Establishing an IRM Repository" at: http://www.phmainstreet.com/mba/pride/spir.htm
DIFFERENT METHODOLOGIES
The three classes of resources also hints at three different methodologies for developing them:
Enterprise Engineering Methodology (EEM) - primarily concerned with developing business resources and is performed by Enterprise Engineers (Business Analysts)
Information Systems Engineering Methodology (ISEM) - primarily concerned with system resources (Software Engineering is considered a subset of ISEM), Such resources are developed by Systems Engineers and Software Engineers (analysts and programmers).
Data Base Engineering Methodology (DBEM) - primarily concerned with data resources and is performed by Data Engineers and Data Base Administrators.
Although the methodologies will define "who" is primarily responsible for their development, it is quite common for information resources to cross methodology boundaries. For example, during EEM systems and "objects" (logical files) are identified which are later implemented by ISEM and DBEM respectively. During ISEM, application logical files are identified and detailed later in DBEM. In DBEM, physical files for a specific application are designed and delivered to ISEM in Software Engineering. This means resources are initially identified and then refined in ensuing phases of the various methodologies. In this regards, an IRM Repository is used as a "scratchpad" by developers to record the specifications of information resources.
Project Management and Quality Assurance will also find information resource definition helpful in their assignments. The phases of the methodologies dictate which resources must be used and their degree of definition. For example, in ISEM, the need for specific data elements must be identified in Phase 1 (to support an information requirement), either new or established data elements to be re-used. At this time, for new data elements, only its logical definition must be supplied. The physical attributes of the data elements (e.g., length, picture, precision, scale, etc.) do not have to be defined until Phase 3 (prior to Software Engineering). By taking this approach to development, Project Management and Quality Assurance can substantiate completion of the resource definition and the phase of work (it either has been done or it has not). Such analysis of the completion of work is commonly referred to as performing a "status check."
IMPLEMENTATION
As we mentioned in our earlier article, "Managing Design Complexity," sharing and re-using resources doesn't happen by accident. It takes a premeditated effort to do so. This means we have to uniquely identify, describe, and cross-reference each resource.
Is such definition work endless? Hardly. There is a finite number of information resources in an organization. For example, there is probably no more than 500 - 1,000 unique data elements in an enterprise. Once they are documented, they can be shared and re-used over and over again. This is the real payoff of IRM, thus expediting development and simplifying change control.
Year ago there was a problem in India where people were starving to death. To help out, the United States sent seed grain to India for the local populace to plant and harvest. This was a viable long-term strategy to take. Unfortunately, when the sacks of seed were delivered to the docks, the people opened them and ate the seed as opposed to planting it. This remedied their immediate hunger problem, but ruined their long term needs. You cannot harvest a crop if you do not sew the seeds. The same is true in IRM and MRP. To harvest the crop, we must first document our resources. Only then can we realize the benefits of sharing and re-using them.
For more information on our philosophies of Information Resource Management (IRM), please see the "Introduction" section of "PRIDE" at:
http://www.phmainstreet.com/mba/pride/intro.htm#irm
Tim Bryce is the Managing Director of M. Bryce & Associates (MBA) of Palm Harbor, Florida and has 30 years of experience in the field. He is available for training and consulting on an international basis. He can be contacted at: timb001@phmainstreet.com Copyright © 2006 MBA. All rights reserved. |
No comments:
Post a Comment