by Milt Bryce, Tim Bryce and Kazuya Matsudaira

TRANSLATE THIS PAGE TO... Chinese (simple)   Japanese       Dutch   French     German     Italian    
Free Translation courtesy of ALS      Chinese (traditional)   Korean       Portuguese       Russian       Spanish         


    Even though western companies have become proficient in developing computer software, building major enterprise-wide systems is an embarrassingly difficult task for most companies to perform. The press is riddled with stories of major systems development projects that have gone awry. Project "runaways" (projects that overrun budgets and schedules) have become common-place in corporate America. Further, patching programs, commonly referred to as "firefighting," has become the normal mode of operation for most IS organizations. Consequently, little progress can be made towards the major development projects required for the business.

    In contrast, numerous Japanese companies have successfully been able to design and build major systems on time and within budget. Is it because they used some magical software engineering tool? No. They have simply been able to apply sound management principles to the design and development of their information resources. The results have been overwhelming. Not only have they delivered on time, the Japanese have produced quality systems with high user satisfaction. These systems have been applied to all types of industries; banking, manufacturing, construction, utilities, etc., and they are beginning to have a profound impact on how the Japanese conduct business; e.g., zero defects in production, cost reductions, accelerations in product delivery, cash flow improvements, reduced inventory overhead, improved customer service, etc.

    As the Japanese have demonstrated, developing information resources need not be a cryptic art form. Rather, a scientific method can be applied based on common-sense and time honored management techniques. This paper is based on the authors' observations of several Japanese clients. The authors conclude that the methods used by their clients are not necessarily unique to the Japanese culture and can be universally applied to just about any business, East or West.


    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.


    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:

    1. BUSINESS RESOURCES - representing the parts of the business requiring information or involved in the processing of data. These resources include enterprises, business functions, jobs/positions, human/machine resources, skills, business objectives (specifying motivation), and projects (implementation of objectives).

    2. SYSTEM RESOURCES - representing the necessary processing components. This includes information systems, sub-systems (business processes), administrative procedures (for manual processing and office automation), operational steps, computer procedures, programs, and modules (separate "building blocks" of software).

    3. DATA RESOURCES - representing the data needed to produce information. Included are data elements, storage records, computer files, manual files, input transactions, screen panels (including windows), print maps, inputs, outputs, logical files (objects), logical records (views), and data bases.

    Control over these resources permits their manipulation to produce different forms of information to serve business.


    Click on graphic to enlarge.  Click 'Back' to return.

    NOTE: Click on graphic to enlarge.
    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 on graphic to enlarge.  Click 'Back' to return.

    NOTE: Click on graphic to enlarge.
    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:

    • Resources can be re-used in other projects, thereby expediting future application development projects. To illustrate, if a data element is properly defined in one application, it should not have to be re-defined in other applications; it should be re-used, which results in time and costs saved. Historically, the trend has been to define data on an application by application basis. This leads to inconsistent definitions and complicates system maintenance, particularly when dealing with complicated calculations that have been defined differently for each application.

    • Sharing resources promotes systems integration, where multiple systems share data, which improves the integrity of data. A file in one system should be used in other systems, provided it contains the necessary data and can be accessed in the required time frame. This eliminates redundancies and produces consistent facts. For example, it is not uncommon to find such redundancies in corporations. As a result, executives must work with incompatible results (e.g., one executive perceives "gross sales" differently from other executives).

    • Controlling resources provides the ability to effectively study the impact of change of one resource on others, thereby improving change control (implementing changes and corrections). For example, if an information resource such as a module or data element is properly defined and related to other resources, it becomes a relatively simple matter to study the effect of change on all resources. Such analysis is invaluable for planning and implementing changes. Without such analysis, changes are implemented without any forethought. Subsequently, seemingly harmless changes produce catastrophic repercussions and "firefighting" (correcting "bugs") becomes the normal mode of operation.

    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 on graphic to enlarge.  Click 'Back' to return.

    NOTE: Click on graphic to enlarge.
    Click 'Back' to return.


    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:

    • Standard and re-usable Work Breakdown Structures (WBS) and precedent relationships. The WBS represents various levels of work effort, from general to specific. Such a breakdown is needed to decompose project work into manageable pieces. Re-usable structures provides for uniform work effort and work products. Consequently, workers do not have to be re-trained when asked to execute the same type of work step in another project. For example, someone well versed in performing a "System Design" phase need not be re-trained when asked to perform a "System Design" phase in another project.

    • Precedent relationships specify the dependencies between steps in the WBS (preceding/succeeding work steps in a project). This is required to specify the direction of the work flow in a project. Without it, projects cannot proceed from one step to another. Such dependencies must allow for both parallel and sequential execution of projects.

    • Re-usable Work Breakdown Structures provide a logical consistency between projects. As such, it provides a means for establishing metrics between projects and allows management to make a comparative analysis between projects and workers.

    • Defined work products (deliverables) for each work step in the WBS. Deliverables substantiate completion of work and adherence to the methodology. The work product is either produced or it is not. The phase of work remains open until the work product has been produced.

    • Defined review points and acceptance criteria for design reviews. This provides the means to evaluate the quality of work and either approve the work product, request revisions, or reject the work product outright.

    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 on graphic to enlarge.  Click 'Back' to return.

    NOTE: Click on graphic to enlarge.
    Click 'Back' to return.


    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:


Info ResourcesNumber in Avg Size SystemNumber of Design Decisions per Resource Decisions in Avg System Design Project
(business processes)
(both computer & administrative)
(manual steps)
(interactive or batch)
(screens & reports)
(logical and physical files, computer and manual)
(includes files structures, print maps, panels, input transactions, etc.)
TOTAL NUMBER2,006 49,850

NOTE: Decisions are design oriented only; they do not include Project Management related decisions (such as those associated with planning, estimating and scheduling).


    You cannot share and re-use a resource if it is not documented. Having a tool to track the location of information resources may be useful for inventory control purposes, but it does little to detect redundancies. In order to share and re-use resources, the basic building blocks have to conform to a prescribed criteria, thereby assuring their completeness and conformity to standards. Knowing this, Kansai Electric used a sophisticated tool to catalog and classify resources. Again, borrowing a lesson from engineering/manufacturing, Kansai made use of a "Bill of Material Processor" (BOMP) specially adapted for managing information resources.

    In manufacturing, a BOMP is a tool to classify and track the parts of a product and how they interrelate. A similar tool can be used to inventory and standardize information resources.


    Click on graphic to enlarge.  Click 'Back' to return.


    NOTE: Click on graphic to enlarge.
    Click 'Back' to return.

    As part of their re-evaluation of the development process, Kansai Electric made BOMP the cornerstone of their development efforts. As analysts and programmers progress through a development project, information resources are cataloged and cross-referenced to other resources in Kansai's BOMP. In addition to identifying each resource by number and name, the characteristics of each resource is described. For example, an information requirement is defined in terms of its required timing (Frequency, Offset, and Response Time), the type of information it represents (Policy, Control, or Operational), and a text description. Data elements are defined in terms of their logical and physical attributes (type, class, size, length, source, precision, scale, program labels, etc.). These attributes become the basis for detecting and eliminating resources with redundant characteristics.

    A project as large and encompassing as the BEST Project would not be possible without a BOMP-like tool to catalog and control the thousands of resources and design decisions associated with it.

    Another top Japanese bank, Norin Chuo Kinko, was able to revitalize an aging banking system by implementing a mass production environment using a BOMP tool to catalog and control its information resources. This one application supported branch offices in 36 cities throughout Japan and involved 3,740 programs (over 2.8 million lines of code) supported by a Data Base Management System. Integration of the business, systems and data resources would not have been possible without a BOMP tool to record the components and their relationships.

    Although the principal purpose of BOMP is to control and classify resources, it has the added capability of performing an "impact analysis" on resources, which is an analysis of resource relationships; for example, if one resource is changed, "impact analysis" will list the chain of resources that are either directly or indirectly affected. Such capability provides the ability to study and control changes.


    Click on graphic to enlarge.  Click 'Back' to return.

    NOTE: Click on graphic to enlarge.
    Click 'Back' to return.

    As the BOMP is populated with information resources, other development aids (such as software engineering tools) can tap into the BOMP and download vital design intelligence for producing software and data base structures.

    This leads to the final element of Mass Production...


    The purpose of Precision Tooling is to provide mechanical leverage for performing tasks routinely with a high degree of accuracy and uniformity. Whereas an Assembly Line process specifies the 5-W's (Who, What, When, Where, Why), tools implement specific techniques which dictate "How" various tasks are to be performed.

    In a Mass Production environment it is important to understand when to use the right tool to perform the right task. Failure to understand this will result in the wrong tool being used under the wrong circumstance which, obviously, will be counter-productive. To illustrate, industrial robots offer an efficient means to implement mundane tasks such as welding. However, if a weld is performed at the wrong time and in the wrong place, efficiency becomes an irrelevant issue.

    Defining the Assembly Line is a precursor to the selection and deployment of tools. If the development environment is not defined properly, supporting tools will inevitably be misapplied and misused. To illustrate, consider the misapplication of Computer Aided Software Engineering (CASE) tools in the United States. Studies have shown that as little as 25% of all CASE tools purchased to date have been effectively implemented. As a result, the advertised benefits of these tools are seldom realized due to their misapplication.

    In contrast, several Japanese companies have been able to effectively capitalize on CASE technology, simply because they knew where the tools are to be used in their defined development environments. For example, Kansai Electric maximized the use of Software AG's NATURAL fourth generation language (program generator) and ADABAS data base management system (DBMS) in the new Customer System.

    There have been other similar examples:

    • Kibun Company, Ltd. is a large manufacturer/processor of seafood, including today's popular artificial crab meat. The company has also developed a reputation for building perhaps the best "JIT" (Just In Time) system in Japan. Like Kansai Electric and the BEST Project, Kibun has implemented a disciplined development environment featuring defined phases of work. During the software engineering phases, Kibun makes active use of the TELON program generator from Computer Associates.

    • JGC Corporation is a major engineering/construction firm headquartered in Tokyo. JGC has been using program generators for nearly a decade. This has significantly changed the focus of the development staff away from writing software, and towards engineering total systems.

    • Yokogawa Electric Corporation is a prominent manufacturer of electronic components and instruments. Their development environment includes the use of a UNIX toolkit during the software engineering phases.

    • Kyowa Hakko Kogyo Co., Ltd. is a manufacturer of solvents spirits, and yeast. Their environment makes use of the POWERHOUSE fourth generation language from Cognos Corporation.

    All of these companies were able to realize the full potential of the tools simply because their development environments were well defined and they knew precisely when and where to use the various tools. As a result, they can plug tools in and out of the development environment as required.

    Today, there are so many application development aids available that it is not uncommon to find a single development organization using a multitude of CASE tools. Further, there is no single vendor with a complete "womb to the tomb" application development aid for some rather obvious reasons: companies use different programming languages, design techniques (structured programming versus object oriented programming), input/output techniques (graphical user interfaces versus full screen menus versus command languages, etc.), and file management techniques (including various DBMS architectures), and operating systems. Computer technology is simply evolving too rapidly for a single vendor to offer a single comprehensive product that does everything. Instead, companies must orchestrate a variety of tools to work in a concerted manner. Unfortunately, the various tools were not designed to be compatible. Different CASE vendors implement different techniques using different concepts and terminology. For example, a "file" in one product may be called a "data store" in another product, and a "table" in another. Such anomalies inevitably create confusion. Even when the same terminology is used, they often express different meanings.

    Fortunately, tool integration is made possible through Standardization of Parts as implemented using a Bill Of Materials Processor. When implementing a new tool, a company must translate the vocabulary of the tool to the standard parts as maintained by the BOMP. Consequently, the tool can access the intelligence regarding the various information resources maintained in the BOMP. CASE tools can either export design intelligence from the BOMP or be used as a vehicle to import information resources to the BOMP.

    Interfacing tools is not as difficult as it may seem. All of the companies mentioned above have interfaced their various CASE tools to their in-house BOMP. As a result, the tools are synchronized and work in harmony.


    Implementation of the five elements of mass production for designing and managing information resources is no small task. Ultimately, it represents implementing an "Information Factory" environment complete with assembly lines, production control (to monitor project status) and materials management. Fortunately, there is a discipline oriented to this task, again, derived from engineering and manufacturing: Industrial Engineering (IE).

    The purpose of the IE function is to define the mass production environment in terms of:

    • Defining the stages of work effort as per the Assembly Line.

    • Defining the necessary skills and proficiencies required to perform the work.

    • Preparation of job descriptions detailing the duties and responsibilities for the various work functions.

    • Evaluation and selection of pertinent tools and techniques to be used on the Assembly Line.

    This in not a one-time endeavor. In fact, Industrial Engineering is an on-going process which monitors the environment and constantly seeks new ways to improve production. The Industrial Engineer uses work sampling and work measurement techniques in gauging performance. In many instances, IE fulfills the role of inspector to evaluate the quality of work products.

    All of the Japanese companies mentioned in this article have gone through this type of IE process in order to implement their new development process. This represented a considerable re-orientation, re-training, and re-tooling effort by the various companies. The work place had to be re-configured, attitudes towards systems development had to be modified, and new skills had to be learned.

    On the surface, it would appear such an environment would be more suited towards engineering/manufacturing related companies, who could easily assimilate such concepts, as opposed to service related industries (e.g., banking, insurance, etc.). However, the fact that companies such as those involved in the BEST Project, and the Norin Chuo Kinko bank indicates that mass production is adaptable to the service sector as well.


    Kansai Electric

    After implementing their new environment, a project was initiated to replace the aging Customer System. Three years later, the first stage of the project was delivered on time and within costs. Stage one primarily represented the base operational needs of the Customer System, and included 858 programs (with over 829K lines of source code) in an integrated data base environment. The system now processes over 300K transactions per day and supports over 2,410 end users, such as the Customer Service department, Billing, and Accounting.

    Since its initial implementation, the Customer System has progressed into additional stages of development to integrate with other corporate systems and incorporate additional features without replicating or supplanting existing information resources. The ensuing stages will interface the Customer System with Banking Systems, Energy Load Projections/Balancing, and Strategic Planning.

    The BEST Project

    From inception to completion, the BEST Project lasted three years. In that time, the project produced over 70 major integrated systems. Upon completion, the project members dispersed and the systems were implemented by the four banks. Although it was originally planned that a group of 50 analysts and programmers would remain to correct bugs, after six months it became apparent such a large group would not be necessary due to how well the systems were performing. Subsequently, the group was reduced to 25 and eventually phased out completely.

    Ajinomoto Company, Ltd.

    Since 1989, when the company re-configured its development organization, it has produced four major systems for sales, accounting, research and production. These systems run on multiple computer platforms and consist of more than 2,650 programs. The systems have greatly reduced inventory overhead, led to "Zero Defects" in operations, and cost reductions of 400 million yen per year ($3.4 million).

    As part of their on-going analysis of the environment, the company discovered a direct correlation between user participation in the early development phases to the quality of the system and user satisfaction with the finished product. This would not have been possible if the environment was not defined and the duties and responsibilities of both developers and end-users alike were not specified and understood by the participants.


    As the Japanese have demonstrated, moving IRM from an art to a science can make a significant contribution to the overall productivity of a company. What is interesting in the Japanese case studies is that defining an IRM environment did not require any new theories of management, but rather, the use of basic common-sense techniques that have existed for years. Instead of arguing over the semantics of IRM, the Japanese have been able to adopt a pragmatic solution.

    Moving IRM from an art to a science has its advantages. It demystifies and simplifies the development process. As a consequence, it can be easily taught and managed in a consistent manner which provides a means to produce more systems in a uniform manner. Critics might argue a "science" inhibits individual creativity. Nothing could be further from the truth. Disciplines such as engineering, architecture, even music, are all regarded as sciences, yet have some of the most creative people in the world. A "science" simply establishes the governing rules. Any company still hand-crafting each system is doomed to extinction. The demand for information in today's business world mandates the use of a scientific method using mass production concepts.

    The Japanese case studies also highlight how they perceive the concept of productivity. Whereas most western companies are obsessed with "efficiency," the Japanese are equally concerned with "effectiveness." Whereas efficiency addresses how fast a task is performed, effectiveness addresses the necessity of the task itself. Again, using the industrial robot example mentioned under "Precision Tooling," the Japanese feel there is nothing more unproductive than to perform something efficiently that should never have been performed in the first place. Productivity, therefore, is viewed as:


    Although a program generator offers efficiency in writing software, if the program is not needed or doesn't serve a business purpose, it is useless. 100% efficiency multiplied by 0% effectiveness equals 0% productivity.

    Because the Japanese were able to communicate the IRM concept in practical business terms, such as the MRP example, they were able to successfully recruit support from upper management. If presented as a cryptic concept, management would have simply regarded it as another form of computer chicanery. Instead, the Japanese believe information resources can be developed and managed like any other corporate resource (e.g., materials, human, equipment, financial resources). The only difference is that IRM deals with a much less tangible resource.

    Although there are some short-term benefits associated with IRM, the real benefits are long-term in nature. Sharing and re-using resources is an evolutionary process. Resources must be carefully designed and standardized before they can be re-used. Consequently, IRM requires executive visionaries with an eye on the future. There is an old saying in Japan that perhaps sums up the IRM concept best, "You must plant the seed before you can harvest the crop." END


    Milt Bryce & Tim Bryce are with the Tampa Bay consulting firm of M. Bryce & Associates (MBA) and specialize in the area of Information Resource Management (IRM). Kazuya Matsudaira is President of PRIDE Japan, Inc., MBA's partner in Tokyo. MBA has been working with Japanese clients since 1976. Click HERE to visit MBA's corporate web page.


    1. Fujimoto, Yasushi - "Designing a Major Customer System," Management Visions (1991).

    2. Okada, H - "Construction of Strategic Information Systems," the Nikkan Kogyo Shinbun, Ltd. (1990)

    3. Bryce & Bryce - "IRM - the Engineering of Information Resources," Nikkei Business Publications, Inc. (1990)

    4. Iwamoto, S., Echigo, K. - "The Development of an Integrated Customer Information System at Kansai Electric Power," Computer & Management, Vol. 28, No. 2 (1989)

    5. Bryce & Bryce - "The IRM Revolution: Blueprint for the 21st Century," MBA Press (1988), ISBN 0-9621189-0-7

    6. Deagon, B. - "Achilles' Heel of Many Projects is Poor Management, Not Technology" (two parts), Investor's Business Daily (December 6 & 7, 1992).

    7. Munezawa, T. - "The Quality of Customer Satisfaction in the Development of Information Systems," ICIS Conference Proceedings (March 1993).

    8. Bryce, T. - "An INFORMATION FACTORY Development Environment," Managing System Development (newsletter), Applied Computer Research (April 1993).



Copyright © M&JB 1993-2016 All rights reserved.