Since the subject of "Information Resource Management" (IRM) first emerged in the late 1970's, there have been volumes written to describe the concept and underlying theories supporting it. Unfortunately, most explanations have been academic and/or cryptic in nature. Consequently, few companies have adopted a clear IRM policy and capitalized on this powerful management concept. There are probably as many interpretations of IRM as there are people who tout its virtues. And wherever inconsistencies occur, confusion is sure to follow. There are those who see IRM as nothing more than records management, others simply regard it as managing data resources, or merely managing information related technologies (e.g., computers, networks, office automation, etc.). What is needed is a common-sense approach to IRM that executives can readily understand and embrace; one that is not couched in esoteric theories of information management. Whereas some companies have treated IRM as an art form, there have been others who have been able to use common management concepts to turn IRM into a legitimate science. There are significant differences between an "art" and a "science." An "art" depends on an individual's intuitive instincts about a particular subject. Such intuition is difficult to teach and apply in a consistent manner. An art-form, by definition, implies non-conformity and represents an expression of personal style and taste. In contrast, a "science" is based on proven principles and, as such, can be taught and applied in a uniform manner by many people. In order for IRM to progress from an art to science, a body of knowledge has to be defined in terms of proven concepts and standard terminology. Unfortunately, this is where the industry has been wallowing for the last fifteen years. Whereas computer vendors and consultants have been arguing over the semantics of IRM, a group of Japanese companies have been able to establish a practical science and put it into practice. Their example reveals that it is not necessary to invent any new theories of management, but rather to re-use existing management principles that have already been proven over time. By doing so, they have been able to successfully move IRM from an art to a science.
DEFINING INFORMATION RESOURCE MANAGEMENT (IRM)
The concept of IRM has been evolving in Japan over the last
fifteen years. Today, it is primarily regarded as the design,
development and control of ALL of the resources required to
produce information. This includes three classes of information
resources:
Control over these resources permits their manipulation to produce
different forms of information to serve business.
 A BILL OF MATERIALS PROCESSOR (BOMP) Click 'Back' to return.
In many ways, the IRM concept is analogous to the discipline of
Materials Resource Planning (MRP) as found in manufacturing. MRP
is the process where all materials, raw or manufactured, are
specified, cataloged and cross-referenced to products, assemblies,
sub-assemblies and other parts. Consequently, different products
can be easily assembled and inventories effectively controlled. This
is precisely the same objective of IRM. But instead of products and
parts, IRM is concerned with information and the resources needed to
produce it.
 Click 'Back' to return. The mission of IRM and MRP, therefore, is the same: to standardize, control, share and re-use components needed to produce products. Whereas MRP is geared towards managing the parts needed to produce products, IRM is concerned with managing the resources needed to produce information. A single product may consist of hundreds or thousands of components. Conversely, a single information system will consist of hundreds or thousands of resources. Trying to manage these resources without some form of standardized and consistent approach will only produce disjointed results and the opportunity to share and re-use resources will be lost. One of the prime functions of MRP is to coordinate the use of parts on assembly lines. The same is true in IRM where resources are shared and re-used between development projects. Sharing and re-using resources in this manner offers many benefits:
This IRM/MRP analogy is significant. Not only does it establish a palatable rationale for IRM, but it paves the way for creating a mass production environment for engineering and manufacturing information resources. There are five basic elements within any mass production environment: Mass Demand, Assembly Lines, Division of Labor, Standardization of Parts, and Precision Tooling. Several Japanese companies have been able to adapt to the MRP analogy and implement mass production environments for building information resources.
 Click 'Back' to return.
MASS DEMAND
Mass Demand represents the impetus for any type of mass
production. Customer demand results in the production of new
products and services. The demand for accurate and timely
information is no different.
Kansai Electric Power Company, Inc.
Kansai Electric is a major power utility serving over 11
million customer accounts in the six prefectures of the Kansai
district of Japan (Osaka area). In 1964 the company developed
its first major computer application, automation of the Customer
System. As one of the company's core systems, the Customer
System was used to monitor energy consumption and issue customer
billings. Like any information system, Kansai's Customer System
underwent extensive changes over the next twenty years. Modifications
were required to implement changes to tariff structures and computer
technology; e.g., the addition of interactive screens, the
introduction of new data base management techniques, and migration
from one computer platform to another (Burroughs to IBM). After 20
years of sporadic surgery, the Customer System was difficult to
manage and maintain. So much so, that by 1987 an executive level
decision was made to completely re-design the whole system.
Kansai's information requirements were fueled by the need
to service a growing customer base and changes in government
regulations. The technical implementation of the system simply
could not keep pace with the burgeoning demands for
information. Studying the problem in detail, Kansai identified
3,139 information requirements to be implemented by the
system. Recognizing that building a system of this magnitude
would be no small endeavor, Kansai decided to re-evaluate their
development environment prior to undertaking such a mammoth
development project.
The BEST Project
By the late 1980's Japanese banking systems seriously lagged
behind those in the west. So much so, Japan's Ministry of Finance
helped orchestrate a strategic project to leap-frog the west in terms
of banking systems. Entitled the BEST Project, the Ministry brought
together four of the top trust banks in Japan: Yasuda Trust & Banking,
Mitsubishi Trust & Banking, Nippon Trust & Banking, and Chuo Trust
& Banking. The intent of the project was to revolutionize Japanese
banking systems by creating a cooperative systems environment between
the four banks. The premise was to design and share information
resources, thereby creating integrated information systems and
provide customers with extraordinary service.
Although the premise of the project was simple, the scope
was inordinately large. Realizing the project would require the
implementation of voluminous information requirements and probably
dozens of systems, the consortium decided to appraise their development
environment. Compounding the problem was the fact that each company
participating in the project used different and conflicting methods
for developing systems. Consequently, it was essential to redefine
the project's development environment prior to embarking on a project
of this magnitude.
In both examples, Kansai Electric and the BEST Project,
voluminous information requirements were the impetus for challenging
traditional development methods and creating a mass production
environment.
The second element of mass production is the Assembly Line
defining the progression and synchronization of work. This concept
has been successfully applied to everything from automobiles and
consumer goods to shipbuilding and construction.
Perhaps the most obvious advantage of the Assembly Line is that
it breaks large projects into smaller, easier to manage, units of
work. As products are designed and assembled, they can be inspected
after each stage of work to assure the work product conforms to the
level of work effort. If not, it can either be corrected or rejected,
thereby inconsistencies and oversights are detected and corrected
prior to progressing to the next phase of work. The Assembly Line,
therefore, promotes quality and consistency of workmanship.
Because of the magnitude of their Customer System, Kansai
Electric felt uncomfortable with using traditional methods for
implementing the project; e.g., superficial requirements definition
and "trial and error" programming. Instead of relying on the
intuition of programmers, as they had done in the past, they devised
a scientific method. Historically, programmers had been allowed
free-reign in terms of their approach to design and solve
problems. This led to inconsistent and incompatible results, and
ultimately the disarray of the existing Customer System.
As Kansai redefined its development environment, it
specified the concepts and principles it would adhere to during
development. This included a definition of terms. With this
conceptual foundation in place, they were then able to define
an assembly line process to develop the new Customer System.
Kansai's assembly line specified the sequence by which resources
were defined and related to form products. For example, in Phase 1
information requirements were defined and related to the data elements
needed to support them (both new and existing). In Phase 2, the
requirements were related to the business processes (sub-systems) and
outputs (screens and reports) implementing the information; further,
the sub-systems were defined and related to the inputs, outputs and
files associated with each business process. In Phase 3, the
procedural work flow of a business process was defined and related to
inputs, outputs and files. Ensuing phases were used to decompose the
system into finite detail with pertinent resource relationships. When
it came time to write software for the programs, everything was
explicitly defined and documented, thereby taking the guesswork out
of programming.
Such a disciplined development environment is useful as a means
for improving communications. Because the methodology is precisely
defined, an effective dialog can be established between developers to
distinguish Who is to perform What work, When, Where, and Why. This
was vital for a project as massive as the BEST Project.
The BEST Project brought together a team of more than 200 analysts
and programmers from the four banks. Recognizing project assignments
would require a mix of personnel on the various stages of work, Project
Management defined an assembly line process which defined the
activities and work products for each stage of work. As a result,
each member of the project understood their duties and responsibilities
and the type of results expected from each stage of work.
Each phase was also defined in terms of the skills and proficiencies
required to perform the activities. Consequently, the BEST Project
Managers found they could plug people in and out of the development
process without having an adverse effect on the project schedule. On
most occasions, an analyst or programmer was assigned a specific phase
of work to carry through to completion. However, in order to balance
the workload of the staff, it was common for Project Management to
reassign a worker from one phase to another. For example, an analyst
or programmer would suspend activity at one point of the project,
transfer to another phase of work, and allow another person to
complete the phase without losing a significant amount of time. Further,
because the specifications for the work products were well defined, it
was easy to suspend work in one phase and resume it at a later date.
An assembly line process, such as the methodologies used by
Kansai Electric and the BEST Project, is an effective means for
managing human resources to maximum effect. Such personnel mobility
is unheard of under traditional methods for systems development. Traditionally,
if a phase is suspended, all design specifications must be recreated
before proceeding with the phase.
The methodologies used by Kansai and BEST exhibit the following
assembly line characteristics:
Bottom-line, the assembly line process can turn a heterogeneous
development environment into one that is homogeneous. By demystifying
the development process, the project teams within Kansai Electric and
the BEST Project were able to communicate at a common level, both
internally within the staff and externally with end users. This, in
turn, promoted cooperation and teamwork from all parties involved.
Coupled closely with the Assembly Line concept is the Division
of Labor, the purpose of which is to break the production process
into separate tasks performed by specialists. Defining the
relationship between work steps and the development function
delineates the duties and responsibilities within a project. For
example, a Systems Analyst is responsible for performing the
System Engineering phases, and a Programmer is responsible for
performing the Software Engineering phases.
Each phase of work can also be defined in terms of the required
skills needed to perform the work along with the required
proficiency. This is useful for determining staffing and training
requirements for a project.
Historically, programming has represented the lion's share of
work effort in a systems development project. Unfortunately, this
leads to the "trial and error" method of development as mentioned
earlier. In this type of environment it is not uncommon to find
three programmers for every systems analyst (4:1 or 5:1 is also
quite common). Because the orientation of IRM is on engineering
total systems and not just on programming, this trend should be
reversed.
Ajinomoto Company, Ltd.
Ajinomoto is the world's leading manufacturer of amino acids
and a diversified food producer with total sales of $5 billion.
In the early 1980's the company found its systems development
organization in disarray. There were no formal methodologies
in place, standards were rare, and organizationally the department
was in chaos. Like so many other development organizations, Ajinomoto
had a 3:1 ratio of programmers to systems analysts and found they were
spending considerable time in programming (approximately 80% of a
project). Instead of specifying information requirements and
engineering an overall system architecture, Ajinomoto's development
staff was spending most of their time writing computer software. Because
the software rarely satisfied user requirements, the staff spent
considerable time re-writing programs. As a result, the company
found itself in a constant "firefighting" mode and little progress
was made towards achieving the company's major goals.
During the mid-1980's, the company re-configured their development
organization by introducing a mass production environment similar to
the ones created by Kansai Electric and the BEST Project. Emphasis in
the new environment was on design correctness (producing systems that
accurately satisfy user information requirements) and building
enterprise-wide systems. In addition to implementing a regimented
assembly line process, the company realized it would be necessary to
retrain the development staff to learn the methodology and develop
the types of skills needed to implement major systems. As the shift
in orientation from software to total systems gradually took effect,
Ajinomoto began to experience project teams consisting of only 31%
programmers. Because of the emphasis on up-front planning and design,
the programming phases of Ajinomoto's methodology have dwindled to
only 21% of the overall development process (with less than 5% of the
time spent on coding). Kansai Electric and the BEST Project have
reported similar experiences.
The "trial and error" approach to systems development is based
on the belief that programming represents the most significant work
effort in the development process. Users and developers alike do
not believe they are being productive until they begin software
engineering. Consequently, an insignificant amount of time is spent
analyzing the business, defining information requirements, determining
business processes, and specifying software requirements. This
approach results in an inordinate amount of time in programming with
questionable results (e.g., systems and software that do not meet
user needs; elegant technology addressing the wrong business problems).
A true IRM environment represents the antithesis of the "trial
and error" approach. Considerable time is spent up-front studying
problems, specifying requirements, and developing the overall system
architecture. As a result, software engineering is de-emphasized and
represents only a fraction of the overall development process. In the
IRM environment, software specifications are defined with a high degree
of precision, thereby eliminating misinterpretations and a lot of
re-programming.
 Click 'Back' to return.
STANDARDIZATION OF PARTS
The Standardization of Parts is required in Mass Production for
interchangeability and assembly by unskilled or semiskilled workers.
As simple as it may sound, concepts such as sharing and re-using
resources can offer a company considerable leverage, as demonstrated by
the MRP analogy. It is difficult to imagine a company designing and
manufacturing a line of automobiles without standard parts. Under this
scenario, each model would be designed with a distinctively separate set
of parts. Because of the lack of conformity and standardization, it
would not be possible to share and re-use parts between models. Further,
inventories would increase exponentially to accommodate the increase in
total parts. Obviously this is not a practical way of operating. Standardization
of parts is an inherent part of engineering and manufacturing and is a
requirement for Information Resource Management.
There is more to an information system than program source code. Much
more. An information system consists of many processes, inputs, outputs,
files, records, data elements, etc. We recently conducted a research study
of the number of information resources and design decisions in several of
our customers' information systems. The purpose of the study was to
determine the scope of systems being developed today. Many diverse systems
were analyzed from a cross-section of industries and applications,
everything from small programming assignments to major systems such as
those developed by Kansai Electric and the BEST Project.
One of the key observations made in the study was that there is a
finite number of design decisions associated with each type of information
resource. As an example, for an output, decisions have to be made as to
its physical media (screen or report), size (number of characters), messages
associated with it, etc. For a data element, its logical and physical
characteristics must be specified (definition, type, size, class, length,
etc.). For a program, the language to be used, software logic, required
file structures, etc. These design decisions can be simple or complex;
regardless, they are all required in order to design a system. When we
multiply the number of design decisions by the number of information
resources in a system, we get an idea of the magnitude of the average
information systems development project:
|
