OS/2 Shareware BBS: 14 Text/14-Text.zip/bestmba.zip/BESTMBA.INF

OS/2 Help File | 1995-05-26 | 293KB | 4,219 lines

ΓòÉΓòÉΓòÉ 1. Title & Publisher ΓòÉΓòÉΓòÉ

                                 THE BEST OF MBA
                WRITINGS ON INFORMATION RESOURCE MANAGEMENT (IRM)

                                  Published by:

                                    MBA Press

                           M. BRYCE & ASSOCIATES, INC.
                                777 Alderman Road
                             Palm Harbor, FL  34683
                                  United States
                               Tel:  [phone]
                               Fax:  [phone]
                               BBS:  813/786-4864
                             CompuServe:  76235,2364
                            E-Mail:  [e-mail]
                                IBM Link: DEV2643

                               Tim Bryce - Editor

                              Published - June 1995

           Since 1971:  "Software for the finest computer - the Mind"

This file may be freely copied and distributed; however, the contents (text and
graphics) are the property of M. Bryce & Associates, Inc. (MBA).  Any
reproduction of the contents without the expressed written permission of MBA is
strictly prohibited.  "PRIDE" is an acronym for PRofitable Information by
DEsign - through phased planning and control.  "PRIDE" and "INFORMATION
FACTORY" are the registered trademarks of MBA.  Copyright (C) M. Bryce &
Associates, Inc. (MBA) 1995.  All rights reserved.

Trademarks:

     IBM and OS/2 are the registered trademarks of the International Business
      Machines Corporation.

     Windows is the trademark of Microsoft Corporation.

     "PostScript" is a trademark of Adobe Systems Incorporated.

 All other trademarks both marked and unmarked belong to their respective
 companies.

 END


ΓòÉΓòÉΓòÉ 2. Introduction ΓòÉΓòÉΓòÉ

                                  INTRODUCTION

Ever since we began MBA in 1971 we have been asked to comment and write on a
variety of subjects related to Information Resource Management (IRM).  Our
articles have appeared in some of the most prominent trade journals in the
world.  These writings culminated in 1988 with the publication of our book,
"THE IRM REVOLUTION:  BLUEPRINT FOR THE 21ST CENTURY."  Reaction to the book
has been gratifying, particularly in Japan where it became a best seller.

In producing this publication, we selected those articles from our collection
that garnered the most interest and response from our readers.  This is not to
suggest that our readers always agreed with us; some of our comments inevitably
would create controversy.  But bottom-line, we want our readers to think about
what they are doing as opposed to blindly following the latest fad or trend.

This collage of articles is primarily aimed at MANAGEMENT.  We do not believe
another technical journal would provide any assistance in addressing the
problems of planning, design, and development.  Rather, this publication is
oriented to providing insight into the management problems in this area and how
to address them.  "THE BEST OF MBA," therefore, is intended for an audience of
I.S. and executive managers.  Application developers will also find it of
interest as will end-users.

Although some of the articles were written in the mid-1980's they remain as
relevant today as they were when they were first published.  We hope you enjoy
them.

To make this publication easy to distribute and read, we are providing the
articles in three file formats:

   1. BESTMBA.TXT - This is a version of the publication in ASCII text format
      suitable for use with your favorite text editor/word processor.  Please
      note this version does not include the graphics as used in the other two
      versions.

   2. BESTMBA.INF - For use with the standard "View" utility (VIEW.EXE)
      accompanying IBM's OS/2 (version 2.x or higher).

   3. BESTMBA.HLP - For use with the standard "Help" utility (WINHELP.EXE)
      accompanying Microsoft's Windows (version 3.x or higher).

 Both the INF and HLP file formats include graphics and text suitable for
 on-line viewing.  These facilities also provide a convenient means to quickly
 search through the documentation as desired.

 This electronic publication can be obtained from a variety of network
 providers (file name BESTMBA.ZIP):

     America Online
     CompuServe
     FTP sites
     Bulletin Boards (including MBA's own BBS at 813/786-4864)

 Address questions and comments to:

                           M. Bryce & Associates, Inc.
                                777 Alderman Road
                              Palm Harbor, FL  34683
                                  United States
                                Tel:  [phone]
                                Fax:  [phone]
                                BBS:  813/786-4864
                            E-Mail:  [e-mail]
                             CompuServe:  76235,2364
                                IBM Link:  DEV2643

 ABOUT THE AUTHORS

 Unless otherwise noted, the articles represent a collaborative effort between
 Milt Bryce and Tim Bryce.

 Milt Bryce

 Mr. Bryce is the President & C.E.O. of MBA.  Having begun his career in 1954
 with the Univac I, Mr. Bryce was one of the first few programmers in the
 United States.  Over the last four decades, Milt pioneered many concepts and
 innovations, including:  structured design, data resource management, layered
 systems documentation, methodologies, and data dictionaries, to name but a
 few.  In 1971 he founded MBA and is regarded as the father of the company's
 "PRIDE" family of products.  Mr. Bryce is a frequent lecturer and has spoken
 extensively to computer and management related societies worldwide.  In 1982
 he was recognized in Tokyo for improving the productivity of systems
 development in Japan.  Mr. Bryce is a charter member of the Association for
 Computing Machinery (ACM) and the American Association for Artificial
 Intelligence.  He earned a Bachelor of Arts (BA) degree in Industrial
 Psychology from the University of Buffalo (now the State University of New
 York at Buffalo).

 Tim Bryce

 As the Director of Marketing & Customer Service for MBA, his responsibilities
 include training and installing "PRIDE" products at customer locations
 worldwide.  In addition, he is the company's chief product architect and was
 responsible for developing the company's Enterprise Engineering Methodology
 (EEM), Computer Aided Planning (CAP) aids, automated systems design tool, and
 the "PRIDE" INFORMATION FACTORY.  In addition to his regular duties, he has
 been active in the Association for Systems Management (ASM), Founder and
 Past-President of the Tampa Bay OS/2 Users' Group (TBOUG), and Editor of
 various newsletters including OS/2 CONNECT, PROS/2, and Management Visions.
 Mr. Bryce holds a Bachelor of Science degree in Communications from Ohio
 University, and is a Certified Systems Professional (CSP).

 Also mentioned in this publication:

 Kazuya Matsudaira

 As President of PRIDE Japan, Inc. (PJI) in Tokyo, Mr. Matsudaira represents
 MBA in Japan and the Asian market.  As MBA's representative since 1976, he has
 provided consulting and training services to some of Japan's largest
 companies.  Mr. Matsudaira is frequently quoted in the Japanese trade press
 and often lectures on IRM related subjects, both at home and abroad.  He is a
 member of the Association for Computing Machinery (ACM), and the Japanese
 Management Association (JMA).  His company is also actively involved with
 Japan's Ministry of International Trade & Industry (MITI), the Japanese
 Software Industry Association (JSIA), and the International Standards
 Organization (ISO).  Mr. Matsudaira holds a Master's of Business
 Administration degree from Keio University.

 END

 COPYRIGHT (C) MBA 1995


ΓòÉΓòÉΓòÉ 3. Some Common Sense About Improving Productivity ΓòÉΓòÉΓòÉ

                 SOME COMMON SENSE ABOUT IMPROVING PRODUCTIVITY
                                  June 1, 1995

                                  by Tim Bryce

I have been in the systems industry for twenty years now, which to my way of
thinking is not a very long time.  However, it has offered me the opportunity
to witness several technological changes in the area of systems development.
In this short period of time I have seen several fads come and go:

      Data Dictionaries
      Structured Programming
      CPA written Methodologies
      Project Management Systems
      Fourth Generation Languages
      Data Flow Diagrams
      CASE tools
      Function Point Analysis
      Information Engineering
      Encyclopedias/Repositories
      Joint Application Development (JAD)
      Rapid Application Development (RAD)
      Total Quality Management (TQM)
      Business Process Re-Engineering (yes, BPR was a "fad")

 The current craze is Object Oriented Programming (OOP), the Data Warehouse,
 and Client/Server Computing.  Despite this wide array of tools and techniques
 I am still amazed that the problems are no different today then when I entered
 the field in the early 1970's:  projects are still late and over budget,
 documentation is virtually non-existent, data redundancy is still the norm (as
 opposed to sharing and re-using data in integrated systems), users are
 unhappy, systems are built that do not adequately serve business needs, even
 worse, system priorities are not synchronized with business priorities, etc.
 The development problems of the 1990's are no different than those of the
 1970's (or earlier).

 Management is bewildered by the return on their technological investment.
 Even though they have paid millions for the latest computer gizmo, they're at
 a loss as to why their systems are not running like a fine watch.

 Before we start pointing fingers let's consider our perspective on
 productivity.  For years companies have been operating under the premise that
 the best way to improve productivity is through task efficiency.  In other
 words, if you want to improve the task of welding, you may want to use
 robotics to perform it; If you want to improve the speed of software
 development, you buy a better programming tool.

 This philosophy is fine for a single task, but what is necessary is the
 ability to orchestrate all of the tasks in a development project in a
 concerted manner.  Otherwise, tasks are performed at the wrong time in a
 disjointed, uncooperative manner.  As projects fail, the tools are inevitably
 blamed, purged, new ones purchased, and the vicious circle starts all over
 again.

 There is more to productivity than just efficiency, there is also the concept
 of effectiveness:

                    PRODUCTIVITY = EFFICIENCY X EFFECTIVENESS

 The differences between efficiency and effectiveness is subtle yet
 significant.  Whereas the former addresses task performance, the latter is
 concerned with the necessity of the task itself.  There is nothing more
 unproductive than to build something efficiently that should never have been
 built at all.  To illustrate, robotics is an efficient means for performing
 tasks such as welding, but if a weld is performed at the wrong time or place,
 it is counterproductive regardless of how efficiently it was performed.  The
 same is true in programming; if a program is written prematurely or outside
 the boundaries of an overall systems architecture, then it will be
 counterproductive, regardless of the tool used to produce it.

 In a manufacturing facility, the Industrial Engineer is responsible for the
 organization and layout of the assembly lines and what tools will be deployed
 throughout them.  The engineer focuses on the organization and synchronization
 of the development tasks (effectiveness).  When this is accomplished, the
 engineer concentrates on the tools and techniques to be used (efficiency).

 Unfortunately, most systems development organizations do not have a support
 function like the Industrial Engineer to layout and monitor the development
 environment.  This is because it is erroneously assumed that everyone
 understands Who is to perform What tasks, When, Where, and Why (the 5-W's) in
 a uniform manner.  Typically, each project is executed according to the whims
 and discretion of the individual Project Manager or lead programmer.
 Uniformity between development projects is avoided, leading to inconsistent
 and incompatible results between projects.  Consequently, the opportunity to
 share and re-use resources is lost.

 In order to move the development of systems from an art to a science in an
 organization, it is necessary to define and standardize the terminology and
 establish a consistent development environment.  This is complicated by
 industrial gurus and academics who perpetually try to re-invent the industry
 by changing the terminology and concepts.  As I listen to some of these
 pundits at trade shows or read their articles, I am reminded of the
 expression, "re-arranging the deck chairs on the Titanic."

 A little common sense will go a lot farther in this business than the latest
 technological fad.  Developing enterprise-wide systems need not be cryptic or
 an arduous task.  What is necessary is someone to define the ground rules for
 development, and layout the roadmap for how to get from one point to another
 in an organized manner.

 Implementing a defined development environment is perhaps a bigger challenge
 than introducing a new tool since it represents a change to the corporate
 culture.  Instead of hacking away at program code over and over again, we're
 now asking people to plan and organize their activities, and impose certain
 disciplines.

 Some people believe that building systems requires an artistic type of person,
 and that organization, discipline and accountability only serves to stifle the
 creativity of the individual.  This appears to be the mind set at companies
 such as Microsoft who also consistently manages to slip product delivery
 dates.  However, nothing could be farther from the truth.  Even in creative
 fields such as music, art, and architecture there are certain governing rules
 and regulations to be observed in development; why should the development of
 systems and software be any different?  Surprisingly, most people are more
 comfortable working in a defined development environment as opposed to one
 that is chaotic.

 Years ago, when I took my first programming class from IBM, I was put on a
 team with two other programmers from other companies who had more "on the job"
 experience than I had.  As part of our training, we were given small
 programming assignments to implement.  With each assignment, I would take out
 my template and draw a block diagram of the processing logic for the program,
 code it, then compile and debug it.  While I was doing this, my two cohorts
 would simply start coding, compiling and debugging.  Whereas it would take
 them several compiles for them to get it right, I would get it right on either
 the first or second compile and in much less time.  Curious, I asked my
 teammates why they developed programs the way they did, and why not think the
 problem through first like I had done.  They explained their management didn't
 want them to waste time planning and flowcharting, that the real work was in
 coding.  This baffled me since I was performing the task quicker in a more
 disciplined and consistent manner.  Later on, I bumped into the IBM rep who
 signed me up for the class.  The rep asked me what I thought about the course.
 I replied, "I'm learning more about programmers, than about programming."

 Twenty years later, I'm still learning about programmers.  Even though the
 development technology has changed, the fundamental philosophy has not.  I
 believe the secret to improved productivity does not lie in efficient
 programming aids, but rather in managing programmers to perform their jobs
 more effectively.  A little common sense is all that is needed.  However,
 there's only one problem with common sense in this industry; it's not very
 common.

 END

 COPYRIGHT (C) MBA 1995


ΓòÉΓòÉΓòÉ 4. Moving IRM from an Art to a Science ΓòÉΓòÉΓòÉ

NOTE:  This article first appeared in the August 1993 issue of MBA's Management
Visions newsletter.

                       MOVING IRM FROM AN ART TO A SCIENCE

                 by Milt Bryce, Tim Bryce and Kazuya Matsudaira

Foreword

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.

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:

   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.

 THE MRP ANALOGY

 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.

 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.

 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.

 ASSEMBLY LINES

 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.

 DIVISION OF LABOR

 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.

 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:

                        AVERAGE NO.    NUMBER OF     DECISIONS
                        RESOURCES      DESIGN        IN AVERAGE
                        IN AVERAGE     DECISIONS     SYSTEM
                        SIZE SYSTEM                  DESIGN
                        ___________    __________    __________

  SYSTEMS                     1            25            25

  SUB-SYSTEMS                15            25           375
  (business processes)

  PROCEDURES                 40            30         1,200
  (both computer &
   administrative)

  PROGRAMS                   75            30         2,250

  OPERATIONS                125            10         1,250
  (manual steps)

  INPUTS                     50            15           750
  (interactive or
   batch)

  OUTPUTS                   200            15         3,000
  (screens & reports)

  FILES                     100            30         3,000
  (logical and physical
   files, computer and
   manual)

  RECORDS                 1,000            30        30,000
  (includes file
   structures, print
   maps, panels, input
   transactions, etc.)

  DATA ELEMENTS             400            20         8,000

  TOTAL NUMBER:           2,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).

 RESOURCE CHARACTERISTICS

 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.

 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.

 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...

 PRECISION TOOLING

 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.

 THE NEED FOR INDUSTRIAL ENGINEERING

 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.

 THE RESULTS

 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.

 CONCLUSIONS

 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:

                    PRODUCTIVITY = EFFECTIVENESS X EFFICIENCY

 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

 COPYRIGHT (C) MBA 1995


ΓòÉΓòÉΓòÉ 5. The Four Stages of IRM Growth ΓòÉΓòÉΓòÉ

NOTE:  This article first appeared in the May 1987 issue of MBA's Management
Visions newsletter.  A modified version of the article appeared in the October
1987 issue of INFOSYSTEMS.

                          THE FOUR STAGES OF IRM GROWTH

It seems that everyone is aspiring to perform Information Resource Management
(IRM), managing the resources by which information is produced; but is anyone
actually doing it?  Most people don't even understand the problem, let alone
how to build an effective IRM environment.

How does a company grow into an IRM environment?  Does it happen overnight?
Hardly.  It evolves slowly over time as companies become aware of the role of
information in their organization.  For most companies, it is a costly and
painful learning process.  The following is a description of the four stages of
maturity that companies typically follow:  Birth, Childhood, Adolescence and
Adulthood.

BIRTH

The day a company goes into business is the day when its information systems
are born.  When a new company or organization is established, there are some
very primal information requirements to accommodate the operation of the
enterprise.  For example, basic bookkeeping (billing, payroll, government
reporting, etc), minutes of meetings, recording of policy decisions,
correspondence, etc.

To implement these basic administrative requirements, simple office equipment
is all that is required, such as typewriters, dictation equipment, calculators,
photocopiers, telephones, etc. An Office Manager with a clerical staff (e.g.,
secretaries, book-keepers) normally implements these processes and operates the
equipment.  During this stage, their concern is for implementing basic manual
procedures with an eye for work simplification to minimize overhead.

As the business expands and becomes more complicated, whether from an increase
in employees and/or business, there is a growing demand for more information
which leads to the next stage of growth...

CHILDHOOD

This stage is entered either by an emerging company or an established firm that
is pressured to investigate the potential of new technology, namely the
computer, to give leverage to their business needs.  This is a stage which most
of the "FORTUNE 500" companies and major government institutions went through
in the 1950's, 60's and 70's.

In the childhood stage, the intent is to investigate the potential of the
computer.  This is an age of experimentation where a highly complicated and
technical device is introduced to a company.  This new technology, of course,
requires a technically oriented individual to operate it.  Someone who is more
in tune with the equipment, as opposed to the problems and objectives of the
enterprise.

The computer is typically centralized in one location until someone can
determine an appropriate way to apply it to the business.

This stage results in the executive's "black box" image of the computer.  As a
consequence, they divorce themselves from the machine, and appoint a "Data
Processing Manager" who is given free reign over the new technology.  Like the
staff that supports him, the D.P. Manager is technically inclined (probably
just one step ahead of a programmer).

The "Data Processing Department" tackles simple problems aimed at automating
some of the basic administrative routines of the company.  There is not
considerable pressure to satisfy business problems, only a "see what you can
do" type of attitude.  As a result, the D.P. staff takes an ad hoc, "quick and
dirty" programming approach to problem solving.  This type of philosophy sows
the seeds for problems to come in the years ahead.  For example, applications
are not integrated, data is not shared (data redundancy is commonplace) and
documentation is non-existent, applications are not easy to maintain or modify.
As a result, they are constantly being discarded and rewritten, further
compounding the problem.

One of the most significant aspects of this stage is that it fosters the "tool
oriented approach" for solving problems.  The attitude of the staff is that the
only legitimate problems worth solving are those that can be addressed by the
computer.  All others are immaterial.  This is a frame of mind that will take
considerable time to overcome.  The indifferent attitude of the D.P. Department
irritates and alienates end users who have increasing demands for information.

Impatient for results, management begins to apply pressure on the D.P. Manager
for more applications to satisfy user demands.  This forces the next stage ...

ADOLESCENCE

This is the age of awakening for most companies, an era when the D.P.
Department begins to manage itself in order to accommodate growing business
demands.  The D.P. Manager is supplanted by an "MIS Director," someone who is a
little more adept at management politics. In fact, the "MIS" (Management
Information Systems) designation is indicative of the company's growing
awareness of the need for information.

In this stage, the MIS Director implements rudimentary management controls,
particularly in the areas of project management and documentation.  Using the
"tool oriented approach" to improve staff productivity, the MIS Director
implements several software tools and techniques, such as:  Data Base
Management Systems (DBMS), Data Dictionaries, Program Generators, Report
Writers, Fourth Generation Languages (4GL), Test Data Generators, Computer
Aided Software Engineering (CASE) workstations, Structured Programming, etc.

Dazzled by sophisticated software and in fear of "falling behind" in the
technology race, the MIS Director authorizes the purchase of tools that
implement esoteric (some prefer to call it "Voodoo") management principles.

Unfortunately, the MIS Director is seduced and abandoned by the technology; the
results are still the same:  Applications do not satisfy user needs,
applications are not integrated, data redundancy is still pervasive,
applications are still difficult to modify and maintain, and the staff remains
a free-spirited group of technicians.

The "tool oriented approach" is very costly to the company, but the results are
still the same.  The MIS Director is still supported by a technical staff that
believes that the "real work" is in the production of software, where their
programming skills excel.  The "Analyst/Programmer" is really nothing more than
a senior programmer.

Superficial standards and pseudo-scientific management techniques are applied
to the development process.  An application project typically consists of the
classical approach for developing systems: A primitive Feasibility Study,
General Design (sometimes referred to as "External Design"), Detail Design
("Internal Design"), Programming (usually following a Structured Programming
Guru's technique), Testing, Installation, and Review.  In this situation,
programming remains 85% of the entire project.  This approach is usually well
packaged in voluminous standards manuals (which no one but the DP Auditors
read).

The computer is decentralized with terminals, minis and micros being
distributed throughout the company.

The end User, who is frustrated by the lack of support from the MIS Department,
turns to the Personal Computer (PC) for help. Unfortunately, the User is no
more adept at using the computer as the MIS people are in using the mainframe
and the problems are compounded even further (particularly in the area of
redundant data).

Despite the substantial investment in computer hardware and software thus far,
management finally recognizes that conditions are intolerable and that the
company is not getting a satisfactory return on investment.  This becomes the
catalyst for change.  Without it, the company stagnates and the situation
worsens.  Adolescence must eventually give way to ...

ADULTHOOD

This stage represents a radical departure from the past mode of operation.
Very few companies, if any, have reached this stage of growth yet.  It
represents a mature environment where the information systems staff is in tune
with the mission of the company, and information is viewed as a corporate asset
used for strategic purposes.  This is the age of Information Resource
Management (IRM).  This philosophy gives rise to the Chief Information Officer
( CIO), a legal officer of the company, not just a job title.

No longer is the "tool oriented approach" pervasive in the company.  It was
tried, and it failed.  The latest "state of the art" technology is a worthless
status symbol if it doesn't contribute to the profitability of the company.

Now, the CIO turns to tried and proven approaches to management. Information
Systems design is no longer viewed as an art, but a science.  The CIO organizes
the systems development environment into an Engineering/Manufacturing company,
complete with Assembly Lines, Production Control and Materials Management.  As
a result, the systems staff is transformed from free spirited programming
"hackers" to a group of disciplined and quality conscious business
professionals.  In some respects, the staff will resemble the "Methods &
Procedures" staff of yesteryear who had a business orientation.

The computer is viewed as just another piece of office equipment; they are not
discernible.  Users and management no longer fear technology because the CIO
implements it effectively into the business.  In the adult stage, the emphasis
is on complete and integrated information systems, not just software.
Programming is less than 15% of the entire development process, with the bulk
of the work being expended on business analysis.  Data is managed as a resource
and redundancy is eliminated.  All of the problems experienced earlier
disappear.

As enticing as adulthood may sound, very few companies have the management
skill or fortitude to make it happen, particularly in the United States.  Most
companies don't even understand the problem. Adulthood represents a substantial
and long-term corporate commitment, not just departmental commitment, which
most American companies strongly resist.  Instead, they are content with
short-term "quick and dirty" solutions.  On the other hand, Japanese companies,
who are much more far-sighted, have a greater chance for success and are
rapidly moving into the adulthood stage.  This will make them increasingly more
competitive in the years ahead.

SUMMARY

Over the last ten years alone, computer technology has changed radically, job
titles and terminology have changed, and salaries have risen sharply, but
little else has changed.  The information problems of today are no different
than 10, 20 or 30 years ago.  Despite today's technology, companies still
experience:

     Project cost overruns and slipped schedules.

     Poor communications and relations with the User community.

     Redundant data and lack of application integration.

     Applications are difficult to modify and maintain.

     Lack of adequate documentation.

     Design inconsistencies.

     Applications still do not satisfy User needs.

     Hardware/Software dependencies.

     Employee dependencies to maintain systems.

 The tools and characters have changed, but the tune remains the same.
 Regardless of the titles and technology used, most companies in North America
 are stuck in either the "Childhood" or "Adolescent" stages of growth.
 Indicative of this are the journals, trade groups, universities, and trade
 shows that still promote the "tool oriented approach" as opposed to promoting
 management.  Systems Development is still viewed by many people as an art, not
 a science.  Whereas, it is a science in reality.  It has established and
 proven concepts and can be taught as a science.

 No amount of elegant technology will solve our problems, only strong
 management will.

                                  THE FOUR STAGES OF IRM GROWTH
                   ---------------------------------------------------------------
  CHARACTERISTICS  |     BIRTH    |  CHILDHOOD   | ADOLESCENCE  |   ADULTHOOD
  -----------------+--------------+--------------+--------------+---------------
    INFORMATION    |Concern for   |Experimentatn.|Awakening.    |Age of IRM.
    ENVIRONMENT    | manual       |'Quick &      | Applying     | Strong Mgmt.
                   | processing;  | dirty pro-   | rudimentary  | Science vs
                   |Work simplifi-| gramming.    | management   |  Art.
                   | cation       |Beginning of  | techniques & | Discipline,
                   |              | the "tool    | tools. Pro-  |  Organization
                   |              | oriented"    | gramming is  |  & quality
                   |              | approach.    | 85% of effort|  conscious.
  -----------------+--------------+--------------+--------------+---------------
    APPLICATIONS   |Basic book-   |Program basic |Major systems,|Information as
                   | keeping and  |administrative| but lacks    | asset and
                   | clerical     |routines      | integration. | strategic
                   | tasks.       |              |              | weapon
  -----------------+--------------+--------------+--------------+---------------
    EQUIPMENT      |Basic office  |Centralized   |Decentralized |Computers blend
                   | equipment    | computer     | computing    | in with office
                   |              |              |              | equipment.
                   |              |              |              |
  -----------------+--------------+--------------+--------------+---------------
    PERSONNEL      |Office Manager|D.P. Manager  |MIS Director  |C.I.O.reporting
                   | and clerical | reporting to | & Programmer/| to C.E.O. with
                   | staff        | administra-  | Analysts     | business
                   |              | tive area.   |              | oriented staff
  ------------------------------------------------------------------------------

 END

 COPYRIGHT (C) MBA 1995


ΓòÉΓòÉΓòÉ 6. Corporate Culture ΓòÉΓòÉΓòÉ

NOTE:  This article first appeared in the May 1987 issue of MBA's Management
Visions newsletter.

                                CORPORATE CULTURE

The subject of "corporate culture" seems to be on everyone's mind these days;
from the college graduate entering the job market, to the IRM executive who is
trying to improve management and productivity in his organization.  It is the
topic of interest at social as well as professional gatherings.

The perceptive manager understands the importance of establishing and
controlling the work environment, including both logical and physical
considerations.  Unfortunately, many managers don't appreciate the concept of
corporate culture and how to use it to their advantage.

Corporate culture pertains to the identity and personality of the company we
work with, either in the private or public sectors.  All companies have a
culture; a way they behave and operate.  They may be organized and disciplined
or chaotic and unstructured.  Either way, this is the culture which the company
has elected to adopt.  What is important is that in order for an employee to
function and succeed, they must be able to recognize, accept and adapt to the
culture.

MEMBER VS. ALIEN

Have you ever noticed how people react to foreign visitors; whether an exchange
student or a visiting professional?  The stranger may be welcomed, but may
never be accepted unless that person can adapt to the norms of their new
environment.  If they don't, the members will shun the stranger and reject the
alien from their culture.  The same is true in business.  If the new employee,
consultant or visitor cannot adapt to the corporate culture, their chances for
success are slight.  The members of the culture will reject the person outright
and will work against them.

The reason for this phenomenon is that people tend to prefer conformity in
their culture.  Conformity represents a harmonious environment where the
behavior and actions are predictable.  Most people have a deeply rooted desire
for a sense of order and stability in their lives, which is what conformity
provides.  A stable environment promotes self-confidence in the members of the
culture and allows them to concentrate on their work.

HUMAN PERSPECTIVE

Corporate culture deals with how we see ourselves and others.  We act on our
perceptions, not necessarily what occurs in reality.  The culture greatly
influences our perspectives and behavior.  For example, our values and beliefs
may distort what happens in fact.  Gossip, propaganda, and a sensational press,
deals with what people want to hear, not necessarily what happens in fact.

DEFINING CULTURE

Before we can alter the culture, we must first understand it.  Culture is
defined as the characteristics of the members of a civilization.  Ultimately,
culture defines the quality of life for a group of people.

Culture doesn't appear suddenly, it evolves over time as people grow and learn.
The older the heritage, the more ingrained the culture is in its members.

There are essentially three parts to any culture:  Customs, Religion and
Society.  Each influences the others.

   1. CUSTOMS - Webster defines custom as a "long-established practice
      considered as unwritten law."  Custom dictates the expected manner of
      conduct for the culture.  It prescribes the etiquette to be observed in
      dress, speech, courtesy and politics (gamesmanship).  Several companies,
      most notably IBM, have long understood the power of customs.  These norms
      are established to project a particular image the company wishes to
      convey.

   2. RELIGION - Religion is the philosophy of life and the basis for our
      values.  It influences our judgement in terms of what is ethical and what
      is not.  Although uniform morality sounds attractive to executives, it
      can be quite dangerous if unethical practices are allowed to creep into
      the moral fiber of the company.

   3. SOCIETY - Society defines our interpersonal relationships.  This includes
      how we elect to govern and live our lives.  Society defines the class
      structure in an organization, from Chairman of the Board to the hourly
      worker.  It defines government, laws and institutions which must be
      observed by its members.  More often than not, the society is "dictated"
      by management as opposed to "democratically" selected by the workers.

 INFLUENTIAL FACTORS

 Obviously, it is people, first and foremost, that influence any culture.  In
 terms of corporate culture, the only external factor that influences the
 enterprise is the "resident culture," which is the culture at any particular
 geographical location.  The resident culture refers to the local customs,
 religion and society observed in our personal lives, outside of the workplace.
 The resident culture and corporate culture may differ considerably in some
 areas but are normally compatible.

 Anthropologists have long known that the physical surroundings, such as
 geography and climate, greatly influence the resident culture.  The resident
 culture, in turn, influences the corporate culture.  The corporate culture,
 which affects the behavior of its members, will greatly influence the resident
 culture.

 SUB-CULTURES

 Within any culture there are those people exhibiting special characteristics
 that distinguish them from others within an embracing culture; this is what is
 called "sub-cultures." In a corporate culture, sub-cultures take the form of
 cliques, special interest groups, even whole departments within a company.
 This is acceptable as long as the sub-culture doesn't violate the norms of the
 parent culture.  When the characteristics of the sub-culture differ
 significantly from the main culture, it becomes a culture in its own right.
 This situation can be counterproductive in a corporate culture, a company
 within a company.  For example, we have seen several IS organizations who view
 themselves as independent of the companies they serve.  They "march to their
 own drummer" doing what is best for the IS Department, not necessarily what is
 best for their company. Conversely, we have seen management regulate the IS
 department as a separate, independent group as opposed to a vital part of the
 business.

 CHANGING THE CORPORATE CULTURE

 Changing the corporate culture involves influencing the three elements of the
 culture:  Customs, Religion and Society.  This is not a simple task.  It must
 be remembered that culture is learned.  As such, it can be taught and
 enforced.  However, the greater the change, the longer it will take to
 implement.  It should evolve naturally over time.  A cultural revolution, such
 as the one experienced in communist China, is too disruptive for people to
 understand and accept.  As a result, they will resist and rebel.

 A smaller company can change its culture much more rapidly than a larger
 company, simply because of communication considerations.  In addition, an
 organization in the private sector can change faster than one in the public
 sector (such as a government agency), only because a commercial company isn't
 encumbered with government regulations.  This is an instance where a
 "dictatorship" works more effectively than a "democracy."

 To change the corporate culture, one must begin by defining the current
 corporate and resident cultures, including the customs, religion and society
 that is observed.  There are several indicators for measuring the pulse of the
 culture:  Absenteeism, Tardiness, Turnover, Infractions of Rules, Employee
 Attitudes, Productivity, etc.  All of these can be used to gauge how people
 behave within the corporate culture.

 This is followed by a set of requirements for the culture and a plan to
 implement them.  In a corporate culture, a policy and procedures manual can
 usually stipulate the customs and society to be observed.  Developing a
 corporate consciousness is far more difficult to implement and involves
 considerable training and demonstration.  Great care must be taken to avoid
 the "do as I say, not as I do" situation.

 It is one thing to enact legislation, quite another to enforce it.  Without an
 effective means to monitor and control the culture, it is quite futile to
 establish any formal policies or guidelines.

 SUMMARY

 Management is much more than just meeting deadlines.  It is a people-oriented
 function.  If we lived in a perfect world, there wouldn't be a need for
 managers.  People would build things correctly the first time and on schedule,
 on costs.  The fact of the matter is that we live in an imperfect world.
 People do make mistakes; people do have different perspectives, etc.
 Management is getting people to do what you want them to do, when you want
 them to do it.  The corporate culture is a vital part of the art of
 management.  Failure to recognize this has led to the demise of several
 managers.  But for those managers who take it into consideration, the
 corporate culture can greatly influence the productivity of any organization.

 END

 COPYRIGHT (C) MBA 1995


ΓòÉΓòÉΓòÉ 7. Today's CIOs:  the Untouchables ΓòÉΓòÉΓòÉ

NOTE:  A modified version of this article appeared in COMPUTERWORLD (August 3,
1992; "CIOs, Get Out of Your Cocoons").

              TODAY'S CHIEF INFORMATION OFFICERS:  THE UNTOUCHABLES

It has often been said that there should be two Presidents for the United
States; one to deal with politics, and another to tend to the true affairs of
government.  The same can be said for today's Chief Information Officers (CIO).
Although they should be tending to matters of state, they are all too often
preoccupied with politics and gamesmanship.

Ideally, the CIO is the information keystone for a company.  As chief architect
and information broker, the CIO represents the catalyst between understanding
business information needs, and the development organization who must satisfy
them.  Although the position often comes with much pomp and circumstance, it is
all for naught if the CIO cannot effectively tend to this pivotal role.

As the focal point for a company's information resources, the CIO must deal
with a wide spectrum of people:  end-users concerned with the status of their
development projects, as well as reporting problems to existing systems;
technicians who argue over tactics of implementation; vendors marketing the
latest technical panacea; and CPA's who scrutinize every penny spent by the
CIO.  Sound hectic?  It is.  Feeling harassed, the CIO tries to insulate
himself, and herein lies the problem.

THE ELECTRONIC COCOON

The CIO begins his tenure as an "ambassador" between his department and the
rest of the organization.  But as demands close in, he builds a buffer around
himself, an electronic cocoon of voice mail and E-mail.  Though voice mail is
designed to record messages while a person is away from the office, it is
primarily used to screen out unwanted callers (both internal and external).
Consequently, calls are not returned.  E-mail is touted as a convenient way to
enhance organizational communications, but the CIO finds himself besieged by a
ton of memos and notes (most of which go unanswered).  By coordinating these
two technologies, it is possible to avoid human contact altogether.  However,
this would negate the need for the organizational cocoon.

THE ORGANIZATIONAL COCOON

After the electronic cocoon is in place, the CIO develops an "infrastructure"
featuring several layers of management.  This allows the managers to
concentrate on the day-to-day operations of the department, while the CIO
concentrates on hobnobbing with the corporate brass.  As problems rise through
the organization (as they invariably will), the CIO simply adds another layer
of management to deal with the problem.  In departmental issues, the CIO is
more concerned with who gets to deal with the problem than what the true
solution might be.

The CIO's final and crucial sentry is his secretary.  Used properly,
secretaries play vital roles as expediters for their managers.  For the CIO,
the secretary has more of a "pit bull" role, with explicit orders to redirect
phone calls and mail, and to tell anyone foolhardy enough to try for a
face-to-face encounter that the boss is "in a meeting" and cannot be disturbed.

POLITICALLY CORRECT

The CIO often speaks in a forked-tongue.  On the one hand he is conversant in
the latest catch phrase (e.g., "global," "infrastructure," "re-engineering,"
etc.), but on the other he must be politically correct when talking with his
peers.  Although he balks at technical discussions with his own staff, he loves
to overwhelm executive management with his technical verbosity.  Conversely, he
dazzles the technical staff with management jargon, discussing the "global
impact" and "bottom line strategies."  As a consequence, the CIO fails
miserably as translator between management and the technicians.  He plays a
different part for each group, making sure neither group can understand (or
attack) his grandiose ideas.

LOSING TOUCH

Surrounded by the false security of e-mail and voice mail, protected by
platoons of managers and his diligent secretary, the CIO can finally relax.
However, due to poor communications with the CIO, executives and users do not
know how their business information requirements are being satisfied.  And
since you cannot communicate with someone who is not there, they become
frustrated with the elusive executive.  Technicians, awaiting their marching
orders, are following a leader who has lost touch with the real world.
Impossible to communicate with, he cannot properly manage his department.

Without proper management, chaos will reign, and the CIO's tenure will be
brief.  Perhaps this is why the average life expectancy for a CIO position is
between 6 and 24 months.  How can an IS department plan for the future if there
is a revolving door at the top?  CIO's must shed their insular layers and
become accessible to their own people and executives.  Only then will
information systems be synchronized with the goals of the business.

SOME RECOMMENDATIONS

The CIO is the pivotal player for satisfying the information requirements of an
enterprise.  The CIO, therefore, must recognize interpersonal communications as
an inherent part of the job.  Instead of avoiding it, he must master it.  Some
suggestions:

   1. RESTRICT THE USE OF ELECTRONIC MAIL - there are some merits to passing
      documents electronically throughout the company.  However, legislate the
      distribution of "junk" mail as a felonious crime.

   2. DUMP THE VOICE MAIL - its dehumanizing effect is perhaps the biggest
      irritant around.  Instead...

   3. HIRE AN EFFECTIVE SECRETARY - not just a clerk to chase people away on
      the phone.  A real secretary can expedite problems when the boss is busy
      or away.  The CIO's secretary can be one of the most powerful people in
      the IS organization.

   4. FLATTEN THE ORGANIZATION - building an empire with layer upon layer of
      management only causes confusion in terms of responsibilities and slows
      the decision making process.  Even worse, important decisions tend to
      fall through the cracks.

   5. TALK IN PLAIN BUSINESS TERMS - using the latest catch phrases (technical
      or otherwise) may be trendy but they may also be misleading.  Find out
      what you're talking about, and express it in simple terms.  If your
      executives or technicians cannot follow what you are saying, you are not
      communicating.  If they truly understand what you and your department are
      doing, you will have real backing and support, instead of a sign-off for
      the latest superficial offering.

   6. Last but not least, ANSWER THE DAMN PHONE!  People like to know there is
      a real person out there, not someone who is obscure and runs around the
      world answering messages by E-mail or voice mail.

 END

 COPYRIGHT (C) MBA 1995


ΓòÉΓòÉΓòÉ 8. In Japan - "Maybe Yes" means "No" ΓòÉΓòÉΓòÉ

NOTE:  This article first appeared in the ICP Business Software Review,
December 1987.

                        IN JAPAN - "MAYBE YES" MEANS "NO"

                                  by Milt Bryce

In 1976, I made my first trip to Japan.  Needless to say, this trip was quite a
cultural shock.  Here was an environment that was totally alien to me in every
way, from food, to language, to social customs.  I had been invited to give a
presentation (with translator, of course) to a large group of Japanese
businessmen on the occasion of my first client's Tenth Anniversary.  This
company has since become one of the largest providers of programming services
in Japan.  As in similar situations in the U.S., I decided to begin my
presentation with a bit of humor.  After being introduced, I walked to the
podium, gave the usual greetings to my host and guests and stated, "I feel very
much at home here in Tokyo.  You have the same cars, television sets, cameras
and watches we have in America."  I waited for a reaction.  Not one of the over
350 businessmen in the audience even chuckled.  In fact, there wasn't even a
change in expression.

LESSON:  "Don't tell jokes in Japan."

The Japanese are very literal people.  What I had said was simply a statement
of fact to them and certainly not humorous.

LESSON:  "Find out as much as you can about the Japanese and their culture or
you will not succeed in their country."

I entitled this article, "In Japan - 'Maybe Yes' Means 'No'" to illustrate the
fact that the Japanese are very polite people.  They will avoid being negative,
such as saying "No", at all costs.  This is an important part of their culture.
If you are not aware of this aspect of their culture, you can perceive the
wrong messages.  For example, many American businessmen have felt they were
making effective sales presentations in Japan.  Since the Japanese audience
nodded their heads up and down during their pitches, they believed the Japanese
were buying what they had to sell.  When the sales didn't materialize, the
Americans were shocked, dismayed and baffled.  What they didn't realize was the
only thing the Japanese were indicating by their nodding was that they
understood what was being said.  It did not mean they were ready to buy their
products.  Making a sale is a completely different process in Japan whether you
are selling a product or ideas.  They have a procedure called "Ringi" which is
very time consuming.  It involves everyone having consensus or "Wa."  They will
not make the buy decision until everyone is in agreement.  This process begins
at the lowest level in the organization and proceeds upward until it ends with
the President.  At this point, he asks, "Is everyone in agreement?"  If the
answer is yes, he applies his stamp or "Ringi" and the decision is made.

I could enumerate ad infinitum the many differences between the Japanese
culture and ours.  This is not the intent of this article.  Rather, I will
discuss the Information Systems development environment in Japan and how it
differs from our approach in the U.S.

During my first trip to Japan in the mid 70's, I visited several major Japanese
companies and toured their systems development departments.  It was clear to me
they were, at this point in time, considerably behind U.S. companies in the
application of computer technology both in hardware and software.  In fact,
their systems development efforts reminded me of the way we did things in the
early fifties in the U.S. when the computer was first introduced.  Our systems
were mostly batch processes.  We programmed in machine code or assembly
language.  The applications we worked on were conversions from existing
tabulating processes or emulations of parts of manual systems.  We did very
little, if any, real systems work (it also could be said facetiously that we
haven't improved much in this respect over time.)  The U.S. hardware
manufacturers provided the little software that was available as a "freebie."
Software packages were virtually unknown and not generally available.  This was
exactly the same situation I found in Japan.  They knew they were behind and
were anxious to catch up.  As a result, they spent as much time as possible
talking with "Giajin" (foreigners), particularly Americans, in their search for
the latest technology.

This brings to mind a popular myth perpetuated about the Japanese, particularly
by Americans.  You know the one about how they lack "creativity"; "The Japanese
are great copiers, but creative - definitely not!"  Strangely, the Japanese
don't mind perpetuating this myth either.  The fact of the matter is that the
Japanese are very creative and are becoming more so every day.  What adds to
this misunderstanding is the fact that the Japanese are not "Wheel
Reinventors."  They consider this a waste of time and money.  Something we
apparently pride ourselves in doing since we spend a great deal of our time
re-inventing based on our "Not Invented Here" syndrome.  The Japanese  will
seek out the best technology available and apply it.  In fact, they have
institutionalized this process by what they call "Tour Groups."  This is where
groups of Japanese companies tour America to review what we are doing.  For
many, this is an annual ritual.  This does not seem to affect their egos one
bit since they do not suffer from the N.I.H. factor.

LESSON:  "Don't underestimate the Japanese."

Our Automotive, Steel and Electronics Industries did and we are all aware of
what happened to them.

In the ten years since my first visit, I have seen the Japanese progress
rapidly.  They have followed our developments closely and learned from our
mistakes and successes.  Added to their successes and failures, they have
developed formidable know-how.

You have probably read about the so-called "Software Factories" in Japan,
usually written by people who have not been there.  These do not exist as such
unless you call what the Japanese computer manufacturers do when they are
building operating system software, a "Software Factory." What you will find,
however, are "Systems Factories."  This is what the Japanese companies have
labeled their Information Systems departments.  The Japanese, as we all know,
are engineering and manufacturing oriented.  They organize their Information
Systems departments based on engineering and manufacturing principles.  They
view Information Systems as products that can be built as products using
manufacturing/engineering techniques.  For example, the methodologies such as
Information Systems Engineering, Data Base Engineering, and Software
Engineering are considered the engineering and manufacturing processes.
Project Control is equivalent to production control.  Information Resource
Management is the same as the parts department with a Bill of Materials
Processor.  All of this is intended to produce a quality product (see Figure
1).

FIGURE 1
                           JAPANESE SYSTEMS FACTORIES

                 -----------------------------------------------
                 |      INFORMATION RESOURCE MANAGER  (2)      |
                 -----------------------------------------------
                       A       A        A       A        A
                       |       |        |       |        |
                       V       |        V       |        V
-------------    ------------- |  ------------- |  -------------    -------------
|STRATEGIC &|    |ENTERPRISE | |  |INFORMATION| |  |SOFTWARE   |    |INFORMATION|
| TACTICAL  |--->|ENGINEERING|--->|SYSTEMS ENG|--->|ENGINEERING|--->|  SYSTEMS  |
|OBJTVS. (5)|    |METHOD. (1)| |  |METHOD. (1)| |  |METHOD. (1)|    |    (4)    |
-------------    ------------- |  ------------- |  -------------    -------------
                       A       |        A       |        A
                       |       |        |       |        |
                       V       V        V       V        V
                 -----------------------------------------------
                 |   DATA BASE ENGINEERING METHODOLOGY  (1)    |
                 -----------------------------------------------

<------------------PROJECT MANAGEMENT (3) & QUALITY ASSURANCE------------------->

(1)  Engineering and Manufacturing Process
(2)  Materials control and Bill of Material Processing (BOMP)
(3)  Production Control and Management
(4)  Product
(5)  Enterprise mission and objectives

You will not hear Japanese professionals talking about "Computer Systems" or
"Software Systems."  They do not believe such things exist.  For the same
reason they would not call a manufacturing process a "Robot Process."  They
instead discuss Information, Information Systems and business needs.  They
realize that the computer and its associated software are only implementation
tools for developing parts of systems.  They also realize that developing
Information Systems is a much larger and more involved process than merely
writing computer programs.  In manufacturing, robots can perform important
tasks but to the Japanese, the manufacturing process is a much more important
issue than merely the tools that are used at points in the process.  Before
they implement a new product, they ask such questions as, "Are we building the
correct products?"  "Will we build them in the proper sequence?"  "Do they meet
market needs?", etc.  They do the same thing when building Information Systems.
Because of this type of thinking and perspective, the Japanese companies
recruit new college graduates who have a general academic background as opposed
to Computer Science or other such specialties and train them technically at
their companies as needed.  They want to assure that their people are business
oriented as opposed to technically oriented.  They believe that systems should
serve the information needs of business, and technical needs, although
important, are secondary.

The Japanese also have a highly developed sense of order, discipline and
planning.  This is an integral part of their culture.  As opposed to our "ad
hoc" and "quick and dirty" inclination to problem solving, the Japanese will
develop goals and plans covering long periods of time.  Ten years is not
considered too long.  In the area of "Information Resource Management," they
realize it will take a significant period of time to control and document all
of their information resources, such as data, systems and people.  They,
however, are willing to pursue this objective and make the investment since
they see the long range benefits.  Few American companies will do this or for
that matter, see the need.  Remember, it is part of our culture to say, "If you
are not coding, you're not being productive."  Long Range planning in the U.S.,
may be as long as a year or as short as the end of the day.  What I am
highlighting in effect is that we tend to respond to the problems of the moment
and choose those that give immediate returns, preferably if shown on the Bottom
Line in the next Quarterly Stockholders' Report.  We are always looking for
panaceas and don't recognize there are no "free lunches," only hard work.  A
current example of this attitude is our fascination with the so-called "CASE"
tools.  This term is a misnomer in the first place since these tools and
techniques do not implement "Software Engineering" in the correct meaning of
the term.  The looseness of this definition, however, is immaterial but it does
illustrate the U.S. approach to systems development and our eternal optimism.
We are always looking for magic where none exists.  This leaves us wide open
for exploitation and inhibits progress.  The Japanese on the other hand
consider Information Systems development a complex process (hard work) that has
to be addressed conscientiously in a thorough and methodical way with a great
deal of up-front effort when determining business information needs and
requirements.

Another thing you will notice in Japanese "Systems Factories," is a lack of
Project Control as we know it.  In the U.S. as soon as projects start
over-running costs and schedules, the "knee jerk" reaction by M.I.S. management
is to install Project Management or more administrative control.  They actually
believe that this additional overhead will solve the problem.  Usually, just
the reverse happens and the situation worsens.  The real problem is two-fold.
One, the department personnel are not trained and do not know what they are
doing or how to do it.  Secondly, systems personnel are not motivated
personally or otherwise.  They really don't care whether the job gets done or
not.  At best, they are mildly interested.  This is not a problem in Japan.  We
chuckle about the idea of "losing face" but this is a real factor with the
Japanese.  Whenever a project is undertaken in Japan, everyone is involved in
the decision.  They arrive at a consensus as to "What" will be done, "How" it's
done and "When."  When the project is started, all members will do whatever is
necessary to see that its objectives are met, even if this means working day
and night, seven days a week.  They don't want to let anyone down or "lose
face."  In this environment, you don't need Project Control.  We lack this
motivation and dedication in the U.S.  You will see exceptions, of course, but
this is rare.

In terms of know-how, amazingly the methodologies being used in Japan for
Systems Engineering, Data Base Engineering and Information Resource Management
(IRM) are American.  This is analogous to the situation with Quality Control.
Messrs. Demming and Juran could not sell their ideas to American Industry but
found an open mind in Japan.  The same with U.S. methodologies.  These
methodologies are based on engineering and manufacturing and fit the Japanese
environment like a glove.  The Japanese view tools, aids and techniques such as
4GLs, Structured Programming, Prototyping, etc., as being helpful at the task
level, the same as as where a robot performs tasks such as welding, painting,
etc. in the factory.  For real productivity, an overall framework and structure
that formal methodologies provide is required.  This is the production line of
Systems Development.  American Information Systems departments are more tool
oriented and lack an appreciation for this broader view.  We seem to advocate
an "ad hoc" or free form type approach to systems development.  As a matter of
fact, in my conversations with many American M.I.S. Directors, I am told that
to apply a formal methodology would require a cultural change in their
organization that they are either unwilling to undertake or find too difficult
from a management point of view to implement since it will "stifle creativity".
(Another phrase for wheel reinvention).

Language brings a special problem to the Information Systems environment in
Japan.  Unlike the U.S., where we are concerned fundamentally with only one
language or alphabet, the Japanese are concerned with four, Kanji, Katakana,
Hiragana, and English.  Of the four, Kanji is the most challenging.  Kanji
consists of at least 40,000 distinct characters and each are unique.  What kind
of a keyboard do you use to enter them and how do you store them inside the
computer or on mass storage devices?  Talk about creativity!  The Japanese have
solved this problem.  You now see Kanji word processors, computer printouts,
etc.  As stated previously, don't underestimate them!  I won't bore you with
the details of their solution to this problem but I will tell you it takes two
bytes to store one Kanji character in computer memory.

On my first visit to Japan, my wife, who is also my business associate, and I
visited the main offices of one of Japan's major electronic producers (TV,
Stereos, VCR's).  During our walk through the offices to the visitor's lounge,
where we were to meet with the President and M.I.S. Director for tea and
discussion, my wife commented that even though everything seemed similar to a
typical large corporation, the ambience was strange.  We looked around and lo
and behold, there were no typewriters and of course, no noise associated with
this standard office machine.  This was our first contact with the significance
of Kanji in the Information Systems environment.  I asked our host about this
and he told us that Japanese secretaries take dictation and write all letters
in Kanji by hand.  These are given to their bosses who in turn sign them with a
stamp.  They only use a typewriter for letters to foreign clients.  This now
has changed with the advent of Kanji word processors.  It is still quiet,
however, since all the machines are electronic.

Lastly, let's discuss that worrisome U.S. problem called "management
involvement."  If there is anything I have heard over the past thirty years,
it's that the U.S. users and management plainly don't want to become involved
in Information Systems development.  This, however, seems to be changing
somewhat, since computer age managers are rising in the U.S. to positions of
influence.  As far as the Japanese are concerned, this has never been a
problem.  Japanese executives have a keen appreciation of the value of
information.  Their superior information allowed them to make significant
in-roads in the U.S. and around the world.  They realized the need for quality
and fuel efficiency a long time before the auto executives in Detroit realized
they had a problem.  When you attend computer oriented conferences in the U.S.,
you are inundated "ad nauseum" with propaganda about the latest hardware
gimmick or software tools, as if this technology was the only key to our
future.  In addition, who attends these conferences?  You see mostly vendors
trying to sell their wares and technicians being rewarded by their bosses with
a little R & R.  On the other hand, in Japan, just the reverse happens.  The
conferences in Japan are attended by senior management from Vice Presidents to
the Chairman of the Board.  The subject matter discussed at these conferences
deals with the real substance of the Information Systems field, such as, "How
can Information Technology be used to improve the competitiveness of a
corporation?"  "What is Strategic Systems Planning (SSP)?" "The Role of
Information Resource Management in the future", etc.  Japanese management is
information oriented and they leave the details of technology to the
technicians after they have specified the What, Why, and When of the problem
and given direction.  They are firmly in control and consider information
systems the "life blood" of their companies.

In the foregoing, I have outlined some of the major differences between the
U.S. and the Japanese Information Systems environments.  In answer to the
question "Are we ahead or behind?", it depends on what areas you are talking
about.  In the area of Information Systems development and management, we are
falling rapidly behind.  In the area of computer technology and software, we
are still ahead but only barely.  As Pogo said, "We have met the enemy and it
is us."  We are so imbued with the way we view things and so arrogant about the
righteousness of our ways, we never seem to find the time or the initiative to
search out obviously effective ways of accomplishing goals that come from a
different culture.  We must have the open-mindedness to entertain the
possibility that other cultures may have a wisdom or an insight that our own
narrow viewpoint obscures.  This may be the ultimate lesson we learn from
Japan.

Are the Japanese behind?  "Maybe Yes."

END

COPYRIGHT (C) MBA 1995


ΓòÉΓòÉΓòÉ 9. The Lady or the Tiger? ΓòÉΓòÉΓòÉ

NOTE:  This article first appeared in the October 1991 issue of MBA's
Management Visions newsletter.

                             THE LADY OR THE TIGER?

In the short story, 'The Lady or the Tiger?,' a young man is forced to make a
difficult decision.  Behind one door is the maiden he hopes to wed, behind
another door is a ferocious tiger and certain doom.  The problem lies in the
fact that both doors look alike and there is no way to differentiate between
the two.  The lesson of the story is simple:  during our lives we are forced to
make some very difficult decisions based on insufficient information.

This same scenario is being played out in countless IS organizations around the
world.  Under pressure to produce information systems, IS management is
searching desperately for a panacea for their woes.  A variety of vendors and
consultants have responded with a diverse set of remedies, not all of which are
compatible or consistent.  Even though the jargon of these products sounds the
same, they have entirely different meanings and objectives.  Such
inconsistencies make it difficult for consumers to differentiate between
products and integrate them into their development practices.  For example, ask
two CASE vendors (Computer Aided Software Engineering) to define their terms
and you will probably come up with two distinctly separate lists.

Such inconsistencies are indicative of the state of the industry.  It would be
safe to assume that we have not yet attained 'profession' status in the area of
managing information resources.  Computer technology is one thing; Information
Resource Management is another.  While the 'experts' argue over information
theory, the western world is rapidly losing its edge; we refer to this as the
'rearranging the deck chairs on the Titanic' phenomenon.

The design, development and management of information resources does not have
to be based on cryptic concepts and terminology.  In fact, it is a teachable
science with simple governing principles and rules.  It has always been our
contention that the best solutions have been those that were simple and based
on common sense.

MANAGEMENT ISSUES

It is almost unanimous among authorities in the field that the best way to
implement application development aids such as CASE tools is to first establish
a strong management framework by which these tools can be orchestrated.  In
manufacturing, this type of activity is referred to as 'Industrial
Engineering,' a discipline aimed at establishing the assembly lines of the
business.  As workstations are established and the flow of work is defined, the
Industrial Engineer considers where various techniques and tools are deployed
and synchronized with the assembly lines.  The Industrial Engineer constantly
monitors the assembly line and introduces new and improved techniques and tools
to replace old ones.  What this highlights is simple:  without defined assembly
lines, tools and techniques will be misapplied to the point of being
counter-productive.

This concept of Industrial Engineering is implemented in MBA's "PRIDE"
INFORMATION FACTORY, a product that simulates a factory-like environment for
Information Resource Management.  The product defines three complementary
assembly lines (methodologies) for designing and manufacturing information
resources:

     Enterprise Engineering Methodology (EEM) - a phased approach for defining
      the enterprise and formulating an enterprise information strategy
      synchronized with business objectives.

     Information Systems Engineering Methodology (ISEM) - a phased approach
      for designing and manufacturing total information systems, not just the
      software portions.  Software Engineering is considered a subset of ISEM.

     Data Base Engineering Methodology (DBEM) - a phased approach for
      designing and developing the corporate data base.  The intent is to build
      data base synchronized with the information systems of the enterprise.

 The INFORMATION FACTORY offers many of its own tools and techniques to be used
 along the assembly lines, but they are not all inclusive.  Because of this,
 MBA recognizes that customers will want to use a variety of additional
 techniques and tools, particularly in the area of software engineering and
 physical data base design.  Consequently, the INFORMATION FACTORY offers an
 open architecture thus allowing additional tools to plug in and out of the
 environment, thereby integrating the development process.

 A totally integrated development environment does not happen by chance. It
 requires considerable planning and hard work (e.g., the Industrial Engineering
 analogy).  But the real catch is IT REQUIRES MANAGEMENT.

 A defined and integrated development environment, as described by 'PRIDE,'
 represents organization, discipline, cooperation, and accountability.  This
 goes totally against the grain in most data processing organizations.
 Consequently, the adoption of a management methodology is avoided in favor of
 CASE tools that do not require management commitment (the tool either works or
 it does not; another one can be easily substituted).

 All of this represents an interesting dichotomy:  people are beginning to
 understand that CASE alone is not the answer for solving their development
 problems (that strong management is actually the right answer), yet, they are
 unwilling to do what is necessary to make it work.  Instead, IS management
 opts for a 'quick and dirty' solution that will seemingly solve the problem on
 a short-term basis (until they can move on to their next job).

 Unfortunately, companies are finding out the hard way that these short-term
 solutions present some long-term headaches; e.g., lack of integration between
 tools, redundancy of effort, applications do not share data, no continuity
 between development projects, longer development cycles, etc.  By ignoring the
 problem, most IS executives hope that it will simply go away.  However, it
 will inevitably return with a vengeance.

 Even when forced into acquiring a methodology, IS management will typically
 take the most non-committal and superficial approach possible, thereby
 becoming nothing more than 'window dressing' to impress an auditor.  It is
 rather ironic that companies are willing to spend millions of dollars on
 computer technology, yet balk at acquiring management technology; a sort of
 'penny-wise, pound-foolish' behavior.

 Ignoring such serious management problems is tantamount to corporate
 negligence.  It will only delay or encumber the company's ability to respond
 effectively to competition.

 WHAT CAN BE DONE?

 The "PRIDE" INFORMATION FACTORY alone is not the answer.  Unless a change of
 corporate culture is effected, even "PRIDE" is destined for failure.  It is
 time for corporations to do some soul searching and reflect on their corporate
 policies and attitudes towards managing information resources.  There are many
 things that can be done to alter the corporate culture.  The following list
 represents the basics:

 1.  CHANGE INCENTIVE PROGRAMS

 Most western companies compensate employees individually on a week-to-week or
 month-to-month basis, regardless if anything is produced or not. Consequently:

     The individual thinks no further than the next paycheck.

     The emphasis is on time spent as opposed to accomplishments achieved.

     Individualism is promoted as opposed to teamwork and cooperation.
      Competitive politics emerge ('one-upmanship').

 Instead, incentive programs should be changed to manipulate personal
 attitudes.  Compensation should take into account:

     Goals attained over a long period of time (e.g., one year, five years,
      ten years).  This promotes employee longevity and raises the
      consciousness of corporate long-term goals.

     Reward based on group effort, not individual effort.  This will force
      people to work together toward common goals and promote cooperation.  It
      could even create an esprit de corps.

     Compensate based on deliverables produced, not hours worked.  This will
      force employees to concentrate less on watching the clock and more on
      producing products.  The only problem here is that if deliverables are
      not precisely defined, it would be impossible to measure how well they
      were prepared.  Consequently, sloppy work could be produced.  This gives
      rise to the next point...

 2.  CHANGE THE PERSPECTIVE IN DEVELOPMENT FROM AN ART TO A SCIENCE

 If development is regarded as nothing more than an elegant art form, where
 developers are treated as 'free-spirits' who cannot be encumbered by
 organization and discipline, than chaos will reign.  Just as the Berlin Wall
 inevitably was broken down, the 'black box' mystique to systems development
 must be taken apart brick-by-brick.

 To make this happen, several things have to occur:

     A Chief Information Officer (CIO) or Information Resource Manager (IRM)
      has to be appointed who will act as the principal information architect
      or information broker for the enterprise.  It is essential that this
      person be a businessman as opposed to a technician (ideally, this person
      should NOT come from computing).

     Define the governing concepts and philosophies for design and management.
      This should address resource management, project management, quality
      assurance, engineering and manufacturing.  Avoid cryptic and unproven
      theories; keep it simple.  Use common sense principles that work.  These
      will be easier to communicate and uphold over time.  Also, define your
      terms, thereby establishing the vocabulary for design and management.

     Formally define the work environment for implementing the governing
      concepts and philosophies.  This is the area of methodologies which
      defines WHO, is to perform WHAT, WHEN, WHERE, and WHY (the 5-W's).
      Ideally, the environment should focus on design correctness (proof that a
      design satisfies specifications), and the production of a quality
      product.  It should also specify the duties and responsibilities of the
      people in the work environment, benchmarks and deliverables, and review
      points.  The intent is to define an environment where results can be
      monitored and measured.

     Define the tools and techniques to be deployed throughout the workplace.
      Such tools and techniques should not run contrary to the governing
      principles and defined work environment.  They must be able to integrate
      within the methodologies with little or no difficulty.

     Move away from job titles such as 'programmer' and 'analyst,' and embrace
      titles such as 'engineer' and 'architect' instead.  Although such a
      change is actually cosmetic in nature, it tends to change the mind-set of
      people to think and act more as professionals.  (Even the initials 'MIS'
      or 'DP' should be dropped in favor of a more credible organization; such
      as 'IRM').

 This is the category where the "PRIDE" INFORMATION FACTORY can offer the most
 support.  As a management philosophy, it is used to define the work
 environment along with the duties and responsibilities of the people in the
 workplace.  Its approach to management and design is based on common sense
 principles that are universally applicable.

 3.  WEAVE IRM INTO THE MANAGEMENT FABRIC OF THE ENTERPRISE

 The lack of credibility has perhaps been the biggest stigma associated with IS
 organizations.  This is primarily because of the technical mumbo-jumbo and
 poor performance normally associated with data processing.  Consequently, IS
 executives are not included in the mainstream of business planning at the
 executive level.  To overcome this problem the IS organization must
 demonstrate that it has reformed its mode of operation.  This means educating
 executives in the governing principles of information resource management and
 the revised methods of operation.

 Assuming IS has proven its credibility, the CIO/IRM must become an integral
 part of executive management.  Such participation will put the IS organization
 in tune with corporate direction, thereby becoming more effective in terms of
 serving the information needs of the enterprise.

 Executive management must also participate in the development of a corporate-
 wide information strategy.  Such a strategy is not so much concerned with
 information related technology, as it is towards establishing the direction of
 development projects in support of business needs.  Such an Enterprise
 Information Strategy (EIS) establishes the priorities of the business, thereby
 moving the company as a whole towards common objectives.

 4.  LAST, BUT NOT LEAST - MANAGE!

 This is perhaps the biggest weakness in the whole formula for change.  All of
 the available management tools on the marketplace will not make anyone a
 better manager.  The tools can provide some important information, but unless
 the human being can effectively follow through on the information, they are
 for naught.  This highlights the fact that management is a people-related
 issue, not an administrative issue.  Management means leadership,
 communications, organization, motivation, delegating responsibilities,
 discipline, and holding people accountable for their actions.  Management
 represents the 'Achilles' Heel' of most IS/DP organizations.  Just because
 someone is proficient in a certain technology does not qualify them in
 management practices.  These are skills that have to be taught and practiced.
 People are not born with management skills.  They must be groomed in the
 science of management instead.  It is hard work requiring specific talents.

 As one indicator of the problems in IS management, consider the trend towards
 "outsourcing," where an internal IS department is replaced by a contracting
 company to run IS.  "Outsourcing" is an admission that companies do not know
 how to manage IS.  What they do not realize is that the outside contractor is
 probably just as inept as the internal employees they are replacing.

 CORPORATE CULTURE

 Changing the status quo is not a simple task.  People have a natural aversion
 to change (particularly in IS/DP).  Platitudinous statements will not suffice.
 Visible changes must occur to demonstrate the corporation's commitment to
 change.  After all, it is one thing to legislate a law, quite another to
 enforce it.

 It must be remembered that culture is learned.  As such, it can be taught and
 enforced.  Changing the culture involves influencing the company's customs,
 philosophy, and society.  Therefore, the impetus must come from executive
 management.  If they do not realize the severity of the problem, they will
 never commit to such cultural change.

 This is the edge the Japanese have over the western world.  They have a keen
 awareness of the role of corporate culture and go to great lengths to
 manipulate it.  Being a homogeneous society to begin with, they are not
 plagued by the heterogeneous people problems presented to their western
 counterparts.  Consequently, their incentive programs, work environments, and
 management philosophies are more in tune with those mentioned in this article.
 Are the Japanese smarter?  Not necessarily.  Many of the management concepts
 used in Japan were actually introduced by Americans (a la Deming, Juran,
 Kepner-Tregoe, etc.).

 To deny that such problems exist in the IS/DP world, is to deny reality.  A
 'wait and see' attitude will only postpone the inevitable.  This was the
 attitude American automotive manufacturers took in the 1970's.  They are still
 feeling the consequences from a delayed decision to change.

 The problems in IS/DP are real.  The patient is sick.  And the problems will
 not go away with superficial remedies.  In fact, the cure will be quite
 painful.  Hard decisions have to be made:  Do we delay the inevitable and
 continue to conduct business as usual?  Or do we address the problem head-on?
 The question is simple:  The Lady or The Tiger?

 END

 COPYRIGHT (C) MBA 1995


ΓòÉΓòÉΓòÉ 10. Back to the Future:  Re-Inventing Re-Engineering ΓòÉΓòÉΓòÉ

                BACK TO THE FUTURE:  RE-INVENTING RE-ENGINEERING
                                  July 13, 1992

          "The word "re-engineering" implies something was "engineered"
                 in the first place, which is rarely the case."

                                  - Milt Bryce

          "The common retort is, "Why replace these applications?  They
           may be old, but they're running!"  The answer is:  They are
                    costing companies more than they think."

                      - Ralph Sprague, Barbara McNurlin (1)

Controlling the elements of an information system along with the process by
which they are assembled are critical to success in development.  Companies are
now beginning to realize it is no longer a matter of how fast software is
written; instead, building the "right" software is far more important.  This is
what has led to the "Re-Engineering" movement in the IS industry.  The
lackluster results produced by Computer Aided Software Engineering (CASE) tools
have caused many companies to challenge not only what software is produced, but
the business processes to be supported. Re-engineering could be a viable
solution, if the industry can ever define it.

Unfortunately, re-engineering suffers from the same Madison Avenue hype as
other panaceas (e.g., CASE).  It promises to increase customer satisfaction,
improve quality, reduce turn-around time, increase staff morale and slash
costs, all at the same time.  At least that's what the seminars and
advertisements promise.  Of course, the "placebo of choice" of the 80's, CASE,
made similar promises.  And in spite of the nifty diagramming techniques,
rhombuses and 4th generation languages, the tools could not live up to the
hype.  However, CASE tools DO work - but their forte is limited to software
engineering, not systems engineering or business planning, which are sorely
needed if you want to develop the right software.

So what is re-engineering?  There are different types addressing different
things.  "Software Re-Engineering" focuses on maintaining computer software
only.  But what is the point of maintaining a program if it no longer serves a
business purpose?  Herein lies the problem and the need for what is today
called "Business Re-Engineering."  It is this latter form of re-engineering
that is in vogue today.  But without a clear delineation between the two, both
efforts will produce incompatible results.

There are four basic objectives to "Business Re-Engineering":

   1. DEFINE THE BUSINESS - an identification of the business functions
      implemented by the enterprise.  This establishes the mission of the
      business and the scope of its operations.

   2. DEFINE INFORMATION REQUIREMENTS - an identification of the intelligence
      required to manage/operate the business.  Information requirements
      support the actions and decisions of the business as specified by the
      business functions.

   3. DEFINE BUSINESS PROCESSES - a design of the overall processing components
      required to support the information requirements of the business.

   4. IDENTIFY THE NEED FOR SOFTWARE - a determination of the computer programs
      needed to support the business processes.

 There are, of course, other matters for consideration in "Business
 Re-Engineering," but these represent the primary concerns.

 EFFECTIVENESS VERSUS EFFICIENCY

 All of this, of course, relates to productivity; but to truly appreciate the
 need for "Business Re-Engineering," we must first understand the differences
 between efficiency and effectiveness, and how they relate to productivity.
 Bryce maintains that the concepts of effectiveness and efficiency are
 erroneously viewed as synonymous.(2)  In reality, they are separate and unique
 entities.  Efficiency addresses HOW an operation is performed (e.g., speed of
 development); Effectiveness addresses WHAT is to be performed.  In other
 words, are we doing the "right" things (effectiveness), and are we doing
 things "right" (efficiency)?  This leads to the Bryce formula:

                    PRODUCTIVITY = EFFECTIVENESS X EFFICIENCY

 Bryce argues, "There is nothing more unproductive than to build something
 efficiently that should never have been built in the first place."
 Application development aids, such as CASE tools, address the efficiency
 issue.  "Business Re-Engineering" addresses the effectiveness issue.

 RE-ENGINEERING VERSUS "METHODS & PROCEDURES"

  "To start our consideration (of the management system)
  and how to improve it, let us ask three questions:

  1.  Does anyone know exactly what information each man and
    each woman in the organization needs to carry on work?

  2.  How much of the effort now expended on computerization
    makes a direct contribution to essential systems actions?
    And, conversely, how much work in the computer room is
    necessary just because you're using a computer?

  3.  If you can examine a system, how can you judge if it
    is a poor system or a good one?"

                                                        - Leslie H. Matthies (3)

 True re-engineering isn't new; we've been asking these questions for years.
 In fact, Matthies was assisting companies in defining business procedures and
 their requirements long before the common business processes became automated
 (see chart).  However, when these processes became automated, people falsely
 assumed computers would naturally organize the procedures.  True "business
 analysts" were traded in for technicians who specialized in software design
 and development.  Regrettably, "Methods & Procedures" departments became a
 thing of the past.

 What did the "Methods and Procedures" departments actually do?  They would
 analyze the operations of a company; this included basic systems work, forms
 design, work simplification, and work measurement to determine what the
 company and its people were doing.  They determined which procedures were
 efficient, which were effective, and which ones needed to be changed.  In
 addition, they also evaluated the use of office equipment (e.g., tabulating
 equipment, etc.).  Sound familiar?  The "new" discipline of "Business
 Re-Engineering" covers the same concerns.

 Systems Analysts too often concentrate solely on the complexity of software.
 The computer has not solved the problem of process organization, nor has the
 software.  So now, with multiple systems, hardware, software and backlogs, we
 are re-examining what the company is doing.  This is one of the key reasons
 why re-engineering is popular today.  Re-examination is good, but it is not
 the equivalent to re-engineering.

 TIME FRAMES

 Evaluating the use of software will not help in the formulation of a corporate
 information strategy.  To illustrate, it will not provide any insight into the
 organization and operation of a business.  The processes themselves and their
 specifications must be examined.  When software is examined, process timing
 information is not defined; for example, there should be specifications for
 when a process occurs and how long it takes to perform it.

 Specifications must originate from information requirements.  Information
 supports the actions and decisions of the business; as these actions and
 decisions exist within a unique time frame, information is time dependent.
 Therefore, the business process responsible for delivering the information
 must also exist within a unique time frame.

 In the discipline of systems process management, time and motion studies are a
 key part of any systems study.  Such studies help determine the "best" way to
 accomplish a task (motion study), and "how much time" it takes to accomplish
 the task (time study).  This helps to determine the proper tasks for the
 process, and eliminates errors.

 Bryce clarifies information timing: "Information is a perishable commodity.
 It only has value within a specific point in time.  It is not sufficient to
 merely determine what data is necessary; it is also necessary to define the
 timing of the information.  This timing will ultimately dictate how data will
 be collected, stored, and retrieved to produce information."  Bryce says all
 business processes operate within time frames, such as instantaneous, daily,
 weekly, monthly, quarterly, etc.  And suggests making use of time
 considerations during design, rather than correcting the system later.

 Timing can be a good measure of how the current system is working; what works,
 what doesn't, and what can be re-used.  Timing is an important determinant for
 effective business process re-engineering.

 ACROSS-THE-BOARD ANALYSIS

 Information and business processes cross organizational and departmental
 boundaries.  To effectively implement re-engineering, we need to examine our
 business and its practices as a whole, not one department.  We must be able to
 accurately define:

     The scope of the business.

     How various business functions interrelate/communicate through common
      systems and data.

     How the business is physically organized.  This includes an
      organizational analysis to denote overlaps in responsibilities and
      omissions in fulfilling business functions.

     How well existing systems support the information requirements of the
      business.  This includes a description of where the company is well
      supported, and where it is weak.

 A true analysis will answer the questions WHO/WHAT/WHERE/WHEN and WHY (the
 five-W's).

 When performing such analysis, some companies are sidetracked by concentrating
 solely on the data aspects of the business.  Although this is helpful, it
 doesn't answer the more important question regarding information utilization;
 for example, "When the information is delivered, what will the user do with
 it?"  In other words, what business actions and decisions are supported?
 Considering a company's data requirements is important, but should fall
 outside the realm of "Business Re-Engineering."  Too often companies become
 immersed in data base studies that have lost sight of the main objective.
 Consequently, the enormous data models created by such effort lack
 applicability to the company's information requirements.  At most, business
 analysis should consider the major facts and events (objects) affecting the
 business.  There is a time and place for everything.  Creating detailed data
 models during a business study is not one.

 ENTERPRISE ENGINEERING

 Perhaps a more appropriate name for "Business Re-Engineering" is Enterprise
 Engineering; however, it also has different definitions.  Bryce views
 Enterprise Engineering as the discipline of defining business (organizational)
 resources and the development of an Enterprise Information Strategy
 synchronized with the business.  Sometimes, Enterprise Engineering is confused
 with the activities associated with Data Base Engineering.  Data Base
 Engineering is more appropriate for data base engineers as opposed to business
 analysts.

 The objective of true Enterprise Engineering is to:

     Define/model the business (both the logically business functions and
      physically organization).

     Make recommendations for changing the physical organization to more
      effectively implement the logical.

     Develop an Enterprise Information Strategy based the goals of the
      business (e.g., strategic and tactical).

 Enterprise Engineering is a precursor to all other efforts, such as
 Information Systems Engineering and Data Base Engineering.  It determines the
 essential requirements necessary to run the business.  The end result is an
 Enterprise Information Strategy; a "road map" for the company, defining the
 information priorities of the business.  Such insight is necessary in order to
 effectively deploy development resources; after all, you should never embark
 on a journey if you do not know your final destination.

 The Enterprise Information Strategy will not be a static plan; it will be
 dynamic, changing with the business.  A static plan cannot adapt to constantly
 changing business conditions (e.g., economics, politics, competition,
 government regulations, etc.).  Therefore, the strategy must be organized to
 accommodate change.

 WHO SHOULD PERFORM "BUSINESS RE-ENGINEERING"?

 Ideally, a Business Analyst or someone from the user community should be
 charged with this responsibility.  Unfortunately, "Business Re-Engineering"
 defaults to programmers who are not necessarily the best suited to perform the
 role.  Such activity requires someone who is more in tune with the business as
 opposed to technology.  After all, "Business Re-Engineering" addresses
 management issues, not computer issues.

 Implementing "Business Re-Engineering" often requires a change in the
 organization of development resources (see chart).  Instead of the
 proliferation of programmers, it is necessary to delineate the duties and
 responsibilities of separate development functions; e.g., Enterprise
 Engineers, System Engineers, Software Engineers, Data Engineers, DBA's, etc.
 Each is charged with developing different types of information resources.  For
 example,

     Enterprise Engineers develop organizational resources (business
      functions, organizational entities, information requirements, business
      objectives, projects, etc.).

     Systems Engineers develop the logical system resources (systems and
      business processes).

     Software Engineers develop physical system resources (programs, modules,
      subroutines).

     Data Engineers develop logical data structures.

     DBA's develop physical data structures.

 Although each development function is concerned with different types of
 information resources, they can all be integrated and shared, thereby
 improving communications between developers.  An organized and managed
 development environment offers control and the confidence that you are moving
 in the right direction.  And that's what "Business Re-Engineering" is all
 about - helping your organization better manage its information resources,
 today and tomorrow.

 REFERENCES:

   1. "INFORMATION SYSTEMS MANAGEMENT IN PRACTICE" - Ralph H. Sprague Jr.,
      Barbara McNurlin, 1986, Prentice-Hall, ISBN 0-13-464934-6

   2. "THE IRM REVOLUTION:  BLUEPRINT FOR THE 21ST CENTURY" - Milt & Tim Bryce,
      1988, MBA Press, ISBN 0-9621189-0-7

   3. "THE MANAGEMENT SYSTEM, SYSTEMS ARE FOR PEOPLE" - Leslie H. Matthies,
      1976, John Wiley & Sons, ISBN 0-471-57697-2

 END

 COPYRIGHT (C) MBA 1995


ΓòÉΓòÉΓòÉ 11. An Interview with Milt Bryce ΓòÉΓòÉΓòÉ

NOTE:  This article first appeared in the April 1991 issue of MBA's Management
Visions newsletter.

                          AN INTERVIEW WITH MILT BRYCE

Twenty years ago this month, Milt Bryce decided to go for broke.  Reflecting on
his future he did not believe he wanted to spend his time correcting,
rebuilding and staffing IS organizations.  He believed he could package his
know-how and help organizations prepare for the future.  With this goal in
mind, he resigned from his position, bought some basic office equipment, and
along with his wife Jean, set up an office in the back room of his house in
Cincinnati.  One of his first steps in starting his company was to take out a
large sheet of butcher-block paper and using a template drew out the phases,
decision points, deliverables and processing flow of what was to become the
world's first commercial system design methodology, "PRIDE" (PRofitable
Information by DEsign).  The rest, as they say, is history.  Since it was
introduced in 1971, "PRIDE" has grown and evolved into a robust product line
with customers all over the world.

To celebrate our twentieth anniversary we decided to interview the creator of
"PRIDE", Milt Bryce, MBA's President & C.E.O.  His outspoken comments and
observations about the industry are just as insightful today as they were back
in 1971.

Q:  WHEN YOU WERE ORIGINALLY SETTING UP THE COMPANY, WHAT DID YOU HOPE TO
ACCOMPLISH?

BRYCE:  Based on my experience as an MIS Director, I felt that it was
absolutely essential that I establish a company that would assist other
companies in the development of systems.  In other words, developing the
standards, procedures and methods for managing an information systems
organization.  As a director, it became blatantly obvious to me that such a
service did not exist.  People were operating on an 'ad hoc' basis.  I felt
that I could become the standards organization for companies and the industry
in general.  This has happened with many companies.  We are looked upon as
their standards department.  This makes a lot of sense because most companies
are not in this business and cannot afford to spend the time to develop their
methodologies and their management approaches.  So, they use us in this
capacity.

Q:  SO YOU SEE THE COMPANY MORE AS A MANAGEMENT CONSULTING FIRM AS OPPOSED TO A
SOFTWARE VENDOR?

BRYCE:  We only produce software to implement our concepts and philosophies. We
do not consider ourselves a software vendor as such.  We consider ourselves
management consultants specializing in the area of Information Resource
Management.  By the way, one of the areas we are moving strongly into is
providing methods, techniques and tools for the Systems Integration business.
We see this as a large marketplace in the future.  One of the things wrong with
Systems Integration today is that these companies lack the concepts and tools
needed to drive this type of business.  We think of the "PRIDE" Information
Factory as providing the 'engine' for the Systems Integration field.  Some
people in this area have already recognized this and we're developing
partnerships with them.  We'll provide the 'engine' and they'll provide the
manpower to build the applications.

Q:  WHAT WERE THE EVENTS THAT LED TO THE ADVENT OF "PRIDE" BACK IN 1971? IN
OTHER WORDS, WHY "PRIDE"?

BRYCE:  The creation of "PRIDE" was based on my experience as an MIS Director
for two major corporations.  After my tour of duty at UNIVAC, I went to work
for the Quaker Oats Company and, subsequently, with the U.S. Shoe Corporation.
At both of these companies I found the MIS function totally disorganized.  They
had no methods, procedures or anything.  It occurred to me that this was
probably true for many companies in the United States.  Therefore, I decided to
leave my job as MIS Director for U.S. Shoe and created the "PRIDE" methodology.
By the way, this was the first commercial 'methodology'.  There were already
many approaches for project management but I wanted to address the problem from
a DESIGN point of view, with project management and documentation as
by-products.

Q:  WAS "PRIDE" HARD TO EXPLAIN AND SELL IN THE EARLY DAYS?

BRYCE:  It still is.  Back in the early days when I was 'cold calling' on the
telephone I had a difficult time trying to describe the product.  MIS Directors
would say, 'Well what exactly are you trying to sell?'  I had trouble finding
the words at first but then said 'methods'.  They would ask, 'Methods for doing
what?'  'Methods for designing systems; a Systems Design Methodology,' I
replied.  And that's where the term 'SDM' came from.  But it was extremely
difficult since it was such a new concept.  People understood the need for
standards for documentation and project management but they did not understand
the concept of a formal methodology for designing systems.

Q:  HOW HAS "PRIDE" EVOLVED SINCE ITS INTRODUCTION?

BRYCE:  When we introduced "PRIDE" in 1971, it set many precedents for the
industry.  Unfortunately, many of these precedents were not understood.  For
example, it was the first methodology aimed at the design of information
systems.  But at the time we introduced it, people were only interested in
project management and documentation.  What MIS Directors didn't realize was
that you can't manage projects unless you have an organized methodology in
place first.  If the methodology is design driven, documentation is a natural
by-product.

"PRIDE" also introduced the concept of Data Management and the Data Dictionary.
Even though the dictionary was implemented manually, it still set the precedent
of providing a vehicle for controlling data and its relationship to process
components.

Data Management is very important.  This is a concept I introduced in 1965 at
the Quaker Oats Company, along with a primitive data dictionary.  This was a
necessity since we were trying to produce a complete MIS system.  You cannot
possibly design integrated systems unless you manage the data.  People at the
time didn't realize this.  Back then, the industry was mostly developing batch
systems, using flat files.  The concept of Data Management, at that time,
didn't seem important.  But data is the glue that holds systems together.  In
order to produce information, you must first control your data and processes.
The concept is really quite simple:  INFORMATION = DATA + PROCESSING.  In other
words, you have to control both data resources and your processing resources.
This is the rationale for an Information Resource Manager (IRM) as opposed to a
simplistic data dictionary.

One of the senseless arguments in our industry is whether you design systems
based on a 'data-driven' or 'process-driven' approach.  The answer, of course,
is both.  But that's not the point.  You shouldn't be only thinking of data or
processing; you should be thinking 'information'.

"PRIDE" went on to automate the Data Management concept in 1974 and we were
copied by many people, including IBM and others.  But none of them truly
understood the concept.  Due to their DBMS orientation, they were only
concerned with data resources, and not the other resources, such as processing
and business resources.  This is why we switched the name of our LOGIK
Dictionary to the Information Resource Manager (IRM) in 1981, to distance our
product from the other dictionaries on the market.  In 1979 we were also able
to interface the IRM to various Data Base Management Systems (DBMS) and program
generators, particularly those that were specification driven.  This is a big
deal now, but keep in mind, we were doing this in 1979.  Most people didn't
realize what we were doing.  It was simply a too advanced concept for most
people to understand.  Here we are in 1991 and the CASE people are just
starting to try to do what we did in 1979.

Our product evolved into three complementary methodologies, one for Enterprise
Engineering, one for Information Systems Engineering, and another for Data Base
Engineering.  By the way, one of the most ridiculous concepts I have ever heard
is 'Information Engineering'.  How do you engineer information?  All you can
really engineer are the components used to produce information, such as data
and processing.  I also believe that the gurus that talk about 'Information
Engineering' know nothing about 'information' or 'engineering'. Bear in mind,
in this industry, you don't have to be logical or intellectually correct to
sell an idea, just use a lot of marketing hype.  Shoot the baloney and people
will buy it.  Unfortunately, this is what's behind a lot of the CASE tools;
they're based on very shallow thinking.

At present, we have created the concept of the 'Information Factory' and I'm
waiting to see what the copy-cats will do now; whether they'll write books from
our sales brochures or whatever.

Other innovations I am particularly proud of is the introduction of the
Information Requirement component - a complete specification for information.
We're the only ones that I know of who have produced a tangible specification
for information; everyone else dances around the issue.  Also, our Data Base
Engineering Methodology (DBEM) introduced the concept of 'objects', a major
advancement over the entity-relationship model.  As it turns out, our 'object'
concept happens to be compatible with others in the field called 'object
oriented programming' and 'object oriented DBMS'.

Q:  LET'S FOLLOW THROUGH ON SOMETHING YOU JUST MENTIONED IN TERMS OF DATA
MANAGEMENT.  WHAT IS WRONG WITH THE INDUSTRY'S PERCEPTION OF THE DATA
DICTIONARY?

BRYCE:  The Data Dictionary as perceived by the industry today is nothing more
than a programmer's tool.  It's a cryptic approach for defining data resources,
nothing more.  The whole idea of defining the business and system resources is
foreign to the technicians.  Their interest is simply not there for obvious
reasons.  However, we see the data dictionary as a 'Bill Of Material Processor'
(BOMP) as used in manufacturing, which, although is a simple concept, is too
sophisticated for the software people to assimilate.  This is why we renamed
our dictionary to the IRM, a much more global perspective to the resource
management issue.

Q:  HAS STAYING THAT FAR AHEAD PRESENTED A MARKETING PROBLEM TO YOU?

BRYCE:  Being ahead in a field such as ours does present a problem.  People are
not focusing on the solutions you are thinking of.  They're only thinking of
current solutions.  Finding 'forward thinking' people is difficult.  In fact, I
have heard it said many times that our products do not fit what our competition
offers.  Thank God for that.  We're way ahead.  Things like CASE tools offer
some razzle-dazzle for developing programs, but they cannot help in an overall
Information Resource Management strategy.  This is where we're concentrating.

Q:  HAS THE CLIMATE FOR "PRIDE" CHANGED SINCE 1971?

BRYCE:  I don't think the climate has really changed.  It's still pretty much
the same.  People are still way behind.  The concepts embedded in "PRIDE" and
our Information Factory are still ten to fifteen years ahead of the industry.

In the United States most managers are doing nothing more than attacking
symptoms, which is no different than they were doing twenty years ago.  The
industry is still programming oriented.  It's kind of ridiculous.  It's like on
an assembly line in a manufacturing plant; we've got welding robotics on the
line, but nobody's challenging whether the product we're welding is any good or
not.  This is the same thing in the information systems field; we have all of
these technical tools and cute programming aids but fundamentally we're not
addressing the real problems of defining information and building the right
systems to produce it.  And that hasn't changed in the last twenty years.

Now I do see a lot of this changing rapidly over in Japan.  Everybody thinks
the Japanese are technically way behind us.  I'm sure there is a certain amount
of truth to that in the area of software but I tend to believe that they will
let the U.S. attack the software engineering problem while they attack the
systems engineering problem, which is a much more encompassing problem.  You
know, even if the system is physically implemented somewhat poorly, yet solves
the business problem correctly, then you will be successful.  But an elegantly
programmed system that solves the wrong problem accomplishes nothing.

Q:  "PRIDE" IS SOMETIMES REFERRED TO AS 'THE BEST KEPT SECRET IN THE WORLD';
WHY DO YOU THINK THAT IS?

BRYCE:  I'm not sure.  I guess, it's like comparing gold with lead.  If you
don't know the difference between the two, lead will function just as good as
gold.  I think you will find that's true in our industry.  People do not want
to think in an engineering/manufacturing way.  They're more concerned with
technical elegance and facade as opposed to substance.  They've forgotten the
purpose of our field:  to solve business problems.  But they're still worrying
about the technology as opposed to anything else.  In this type of situation,
"PRIDE" will always be a secret since it addresses business issues as opposed
to technical detail.

Up to now, we've kept a low profile as we were developing the Information
Factory.  But you're going to see this change when the product comes out.

Q:  HOW HAS THE COMPETITION CHANGED OVER THE YEARS?

BRYCE:  This is kind of interesting.  Initially, our competitors were companies
that stressed documentation or project management.  For instance, SDM/70 was
originally called 'Segmented Documentation Methodology' which was a very apt
name for the product.  From the accounting firms, came numerous paper driven
methodologies aimed at managing projects using the classical 'waterfall'
project management approach.

You have to be careful with the expression 'SDM'.  There's a big difference
between a Systems DESIGN Methodology, such as "PRIDE", and a Systems
DEVELOPMENT Methodology.  The intent of a design methodology is to do just
that, design.  How you manage the design effort is independent. It's just like
in architecture where there are phases by which a product, such as a building
or a house, is decomposed into levels of detail, from the abstract to the
specific.  Project Management can be added to monitor and control this effort,
but this should not be confused as a part of the design issues.  On the other
hand, Systems DEVELOPMENT is a clever way of saying that you wish to manage the
development process.  This means a project management orientation; not design.
It doesn't give you the governing rules and procedures for design.

A methodology should address the five W's (WHO is to do WHAT, WHEN, WHERE, and
WHY).  This is important since it defines your working environment.  Other
people concentrate on techniques and tools, which address HOW in the
methodology.  Most people are sloppy when discussing this subject.

Q:  SO NOT ALL METHODOLOGIES ARE CREATED EQUALLY?

BRYCE:  No they're not.  As a matter of fact, most of the methodologies that
people are talking about, such as 'Structured Analysis' and 'Information
Engineering' are not really methodologies at all.  They're techniques.  And
they're limited techniques.  Most of the CASE products are nothing more than
tools that implement these techniques.  I've heard many of these things being
called 'shelfware' because people do not know how to put them in a methodology
environment.  By the way, don't get me wrong, there are many CASE tools out
there that are effective in doing certain activities, within a methodology.
But if they don't have a framework from which to operate they'll become useless
and end up on the shelf.  I think we have to first have an overall framework
under which to build systems.

Q:  SO THEN YOU SEE METHODOLOGIES FROM A MANUFACTURING PERSPECTIVE IN TERMS OF
DEFINING THE ENVIRONMENT?

BRYCE:  Yes, in the sense that it resembles an assembly line.  However, it
encompasses both engineering and manufacturing.  For example, the engineering
aspect is when you are defining the specifications and doing the design.  Then
the manufacturing aspect is converting the engineering spec into something
physical, such as a program.  Really, you have to think of systems in terms of
products that can be engineered and manufactured like any other product.
'Double-entry bookkeeping' was a system that was first introduced by the
merchants of Venice in 1200 A.D.  They created the logical system for
bookkeeping, but it's been physically implemented many different ways over
time:  manually, bookkeeping machines, tabulating equipment, and now the
computer.  But fundamentally, the logical processing is no different than it
was hundreds of years ago.  So, we have to learn to make that distinction
between logical and physical.  But you should remember that the technicians are
more concerned with the physical then they are with the logical, and that's a
serious problem.  Logical design must precede physical design.  The tail should
not wag the dog.

Q:  WHAT DOES THE TERM 'INFORMATION FACTORY' MEAN?

BRYCE:  It means setting up an environment analogous to the environment you
would have in any manufacturing company.  You would have an engineering
department for determining your specifications and designs for the products you
want to produce.  Then setting up a manufacturing environment to build the
products accordingly.  Of course, you also need a production control department
to monitor the assembly lines and a materials management department to
standardize and control resources.  That's what we have done with the "PRIDE"
Information Factory.  And just like in manufacturing, we have the ability to
change tools and techniques when we want to.  This is a function analogous to
Industrial Engineering in the engineering/manufacturing environment.

You know, as simple as these engineering/manufacturing concepts are,
organizations such as government, banks, insurance firms and other financial
institutions have a real problem assimilating them.  It is simply not in their
nature to think in terms of products, parts, and so on.  Engineering/
manufacturing firms understand these things.  But if you've never been trained
or educated in this regard, you will be lost in the Information Factory.

Q:  HOW HAS THE INDUSTRY CHANGED?

BRYCE:  Well, the industry is still obsessed with the physical aspects of
systems.  And physically, we've gone from mainframes to minis to PC's.  But so
what?  Even though the physical has changed, the logical hasn't, yet we still
ignore it.  Again, this is an area where the Japanese excel.  They concentrate
more on the logical side than the Westerners do and it's starting to show some
substantial results, particularly in the types of applications they're
producing.

The industry still doesn't know the difference between systems engineering and
software engineering.  We still call everything software engineering and it's
not.  Software engineering is writing computer programs.  But a system is a
logical structure that sits over the physical implementation.  A system can be
implemented physically many different ways; a computer is but one.  By the way,
has anyone stopped to think what the word 'application' means?  It is the
'application' of the computer to a problem; not the solving of a problem from a
systems sense.

I heard that the Department of Defense a few years ago abolished the position
of business systems analyst in favor of a software engineering position.  This
is sad.  Instead of having global thinking people, they were content with just
techies.  I also understand that they're now paying a price for this decision.

Q:  HOW WOULD YOU DESCRIBE THE DIFFERENCES BETWEEN A SYSTEMS ENGINEER AND A
SOFTWARE ENGINEER?

BRYCE:  A systems engineer is someone who can analyze business problems and
design a systematic approach to produce information to satisfy the need.
You'll notice that the words 'computer' and 'software' were not mentioned.  In
the old days, a systems engineer was called a 'systems and procedures analyst'.
A software engineer is someone who creates a computer solution to a specified
process.  In manual systems, there is no such thing as a software engineer,
since no computer is involved.  The computer brings mechanical leverage to the
system processes.  Software engineers are fundamentally programmers, and
subordinate to systems engineers.  Using the term 'engineer' is an attempt at
making people think more in terms of a science as opposed to an art.

Q:  WHAT DO YOU THINK OF THE 'REVOLVING DOOR' POLICY COMPANIES HAVE TOWARDS
CHIEF INFORMATION OFFICERS (CIO)?

BRYCE:  The CIO function as advertised in the press is typically staffed using
people who have more facade than substance.  Have you noticed how many CIO's
mentioned in the press have been axed recently?  I counted at least five in the
last 60 days.  The CIO is an excellent concept but should not be staffed by
people who spend their time in self-promotion.  Maybe this is what irritated
their companies.

Q:  "PRIDE" IS NOW CELEBRATING ITS 20TH ANNIVERSARY.  QUITE AN ACCOMPLISHMENT.
WHAT DOES THAT MEAN TO YOU PERSONALLY?

BRYCE:  Well, it means to me that we have found enough people who believe in
these advanced concepts to keep us in business for the last twenty years.  And
I think we're going to stay in business for twenty more years.  People ask me
why do we spend most of our time overseas and not in the U.S.?  Well we do
spend a lot of time in the U.S., but we've found the people over here are too
software oriented and difficult to train in basic information systems theory.
We didn't experience this problem overseas.  So, you go where you can best
market your product, and this turns out to be places like Japan, Korea, and
other places outside the United States.

The English speaking world tends to be somewhat like the United States; whereas
the Orient, and particularly Japan, are more oriented to this
engineering/manufacturing approach.  I jokingly tell people that I will sell
outside the U.S. for the next ten to twenty years, and finally it will become
obvious to the United States and then I'll spend my waning years selling it
here.  This is similar to what Deming did with quality assurance.

Q:  IT ALSO MEANS THAT "PRIDE" HAS STOOD THE TEST OF TIME.

BRYCE:  Absolutely.  I've had people jokingly tell me, who are not technical in
the field, that all we're really selling is common sense.  They're absolutely
correct.  It's common sense and it relates to some simple governing principles.
But as I've always said, common sense is not very common in this field.
Getting caught up in technical aspects tends to blur your perspective.  If it's
not technically elegant, you lose interest.  For example, take the Data Flow
Diagram, which is an old technique that actually came out of the 1930's called
'Work Simplification.'  All people did was take an old concept and rename it.
We've tried to avoid that in our product.  But in our field, many who can't
invent any new technology just rename old stuff.

Something else; I contend that the Data Flow Diagram doesn't show the flow of
data.  All it shows is how groups of data are processed as inputs, outputs and
files in a particular instance.  This is what the old 'Work Simplification'
diagrams showed too.  But I guess the term 'Work Simplification' wasn't
technically elegant enough for some people and the expression 'Data Flow
Diagram' sold like hotcakes.  To this day I cannot see how it helps you do
anything.  It isn't even a good way to explain processes to users.

Q:  WHAT HAVE BEEN THE MOST GRATIFYING ASPECTS TO MBA AND "PRIDE"'

BRYCE:  The most gratifying aspect has been our success.  Okay, not 100%
success, but we sure have converted a lot of people.  Over the years people
have told us that "PRIDE" has carried over into their personal lives as well.
In Japan, "PRIDE" has become synonymous with climbing the corporate ladder.
There have been many Japanese MIS managers who have been bumped upstairs due to
"PRIDE".  And it's nice to see this when it happens.  Another reason why
"PRIDE" is successful over there is because it is culturally compatible with
their way of thinking and religion.  But the fact that we've been active, while
others have come and gone, means that we're doing something right.

Q:  AND WHAT HAS BEEN THE MOST FRUSTRATING ASPECTS?

BRYCE:  The most frustrating aspect is that MIS managers will purchase the
product and not have the self-discipline to learn it and make it work.  I don't
know why managers think that just by definition of title, they automatically
have this knowledge; they don't.  Just because you are an MIS Director doesn't
mean that you know everything.  That's a false sense of arrogance.  You should
know inside and out the approach you have chosen to manage your organization.
If you don't, you're going to go down the drain.  It always amazes me when MIS
Directors delegate the responsibility for purchasing a management methodology
to the techies.  Talk about irresponsible behavior.

The other frustrating thing I see is when an MIS Director moves or gets
promoted, his or her successor comes in and feels that anything associated with
the predecessor is no longer valid and has to be changed.  This does not
follow.  For example, I can recall an insurance company in Canada who used
"PRIDE" to document their systems, which was no small job, considering they
started out with absolutely nothing.  But over a few years the company was able
to completely inventory all of their information resources, including data and
processing components.  Systems were functioning well, projects were coming in
on time, and morale was high among the staff.  This was the crowning
achievement of the MIS Director who eventually retired.  Unfortunately, his
replacement was a young hot shot who didn't understand the virtue of
controlling information resources and saw the company's future rested on the
capabilities of Fourth Generation Languages.  Consequently, he ordered a purge
of "PRIDE" and in a matter of minutes had deleted the company's documented
resources off of the computer.  Imagine, having all of your company's
documented data elements, records, files, inputs, outputs, programs, modules,
procedures, systems, etc. all being flushed down the drain.  This type of
behavior is common in the U.S. and is based on the erroneous belief that
anything your predecessor did must be wrong.  By the way, you see this type of
behavior more in the Western world, than you do in Japan.  In Japan, the
incoming manager usually adapts to the existing culture, not the other way
around.

Q:  WHY HAS "PRIDE" DONE SO WELL IN JAPAN?

BRYCE:  This is not surprising.  Deming had the same experience with Quality
Assurance.  He had moderate success in the United States, went to Japan,
enjoyed great success, and now you see the results:  quality products, quality
service, etc.  Deming is a hero in Japan, and now only twenty to thirty years
later are U.S. companies starting to understand what he was talking about.
Well, the same is happening in the field of IRM with us.  "PRIDE" has had the
same kind of reaction in Japan.  Whereas Japanese companies see systems
development as a science, their American counterparts see it as an art.  And
don't kid yourself, the Japanese have every intention of dominating the systems
and software market in the same manner as they have taken over in other
markets, such as automobiles, steel, electronics, banking and so on.

Q:  WHAT PROGRESS HAS BEEN MADE OVER THE LAST 20 YEARS IN SYSTEMS DEVELOPMENT?
ARE WE MOVING FROM AN ART TO A SCIENCE?

BRYCE:  Well, you are moving towards a science if you've been using "PRIDE".
This alone means that you believe that there are some governing principles for
building systems.  Unfortunately, we do not corner the market with our
approach.  There are other approaches that are based on art.  So, I believe
overall that the industry in the U.S. sees systems development as an art, not
as a science.  This is one of the major problems we want to overcome with the
"PRIDE" Information Factory.  We're going to attack with a religious fervor.
We're going to try to demonstrate to the field that a science does, in fact,
exist and that it can be taught using common engineering/manufacturing
principles.

Recently, I was reading about the so-called 'Software Factories' in Japan.
Obviously, they believe as we do that you can design and build quality software
like any other product.  They're going to master this and then raise havoc in
the Western world.

Q:  HOW IS THE INDUSTRY IN TERMS OF STANDARDS?

BRYCE:  Our industry is a disaster.  Back in 1970 I gave a talk on standards to
DPMA in Seattle.  I created a bit of a controversy by challenging the
association to get more involved with instituting industry standards.  But you
know something?  The industry has not made one inch of progress since then.
The industry has no standards.  Even academics in the field do not define their
terms well.  For instance, one of the things that really bothers me is when
people talk about information like they know really what it is.  They don't!
Try looking in 'Information Engineering' related books and brochures.  You're
not going to find it.  The terminology and thinking in our industry is just
plain sloppy.

People still believe that systems and software are synonymous.  They most
definitely are not.  Some think IBM's AD/Cycle is a way of developing systems.
It's not.  It's only a way of developing programs using their tools.  It's a
programming environment.  It doesn't help you with systems engineering.  IBM
knows this.  IBM sells computers and programming tools.  They don't sell
systems design and development tools. AD/Cycle is nothing more than the old
five step 'waterfall approach' for managing software projects.

Q:  IN THIS AREA, IS GOVERNMENT A CATALYST OR IMPEDIMENT TO PROGRESS?

BRYCE:  Well, I used to be on some government sponsored programs, such as Data
Base Directions, and on some of the standards committees.  The results of these
were so minuscule and primitive that I abandoned trying to work on these
committees.  I don't think government enhances anything from that perspective.
The government may try, but not with any vigor.  The government should develop
more standards, particularly since they're the world's greatest user, but you
don't find any consistency within the government at all.

Q:  HOW DO YOU FEEL ABOUT INDUSTRY CERTIFICATION PROGRAMS?  ARE THEY WORTH THE
PAPER THEY ARE WRITTEN ON?

BRYCE:  I think we can come up with some certification for people such as
programmers or someone like that since we're talking about techniques.  But I
have trouble with certification in the systems area.  Most of these
certification programs are from a programming point of view and not the
business systems engineering view.  We've hired people who have been CDP's and
had Computer Science degrees and we've had mixed results.  A lot more
development is required in this area.

Q:  HOW ABOUT CERTIFYING UNIVERSITY CURRICULUM?

BRYCE:  I have trouble with universities.  You have courses designed by people
who attended school, graduated, then went on to graduate school and became
teachers without any real-world experience whatsoever.  I feel that when
academics talk to other academics and quote each other, it's like multiplying
zero times zero, you still end up with nothing.  I'm not terribly impressed
with what comes out of universities.  I think we have a lot of academic
hullabaloo.  For example, I was in this business way before the academics even
knew there was such a business.  We were developing things in industry way
before the academics.  Remember, necessity is the mother of invention.  I think
the universities have a long way to go in the area of Information Resource
Management.  The universities should staff with practicing professionals like
they do in Law and Medicine.

You know, when you hire someone with a college degree in this area you have to
first debrief them and re-educate them in the ways of the real systems world.
This would be a lot easier on business if the universities had their act
together.

Q:  BACK IN 1979 MBA WON A LANDMARK COURT RULING INVOLVING THE MISAPPROPRIATION
OF TRADE SECRETS.  HOW WOULD YOU DESCRIBE THE ETHICS IN THE INDUSTRY?

BRYCE:  I don't think our industry has anywhere near the ethics that it should
have.  There's no question that many of the consultants have no trouble
whatsoever of taking things that they learned at a customer's site or learned
using other people's products and adopting them for their own use.  They don't
have a great deal of respect for the proprietary interests of others.  They
feel that's an interference.  Our lawsuit clearly showed that.  The firm we
were suing was so arrogant, they felt we had a lot of nerve trying to stop them
from using our proprietary know-how.  I see this all the time.  They're out to
earn money by selling their services by the hour.  I think any knowledgeable
person in this field should look at what some of these so-called 'System
Integrators' have done.  Whether they have successfully delivered the products
they are talking about or whether it was just an excuse to rip off the client.
I remember the New Jersey Motor Vehicle fiasco some time ago.  I think that was
just unprofessional and irresponsible behavior.  But it happens in this
industry just because the company auditors think they are experts in the area
of systems development.  This, of course, is not true.  They should be held
accountable to a higher standard.  When you see these people doing fixed price
contracts consistently, then you'll know that their working on a standard
basis.  But when its on a time and materials basis, I say 'caveat emptor!'

Q:  DOES THE INDUSTRY SUFFER FROM 'YELLOW JOURNALISM'?

BRYCE:  Back some years ago there was a magazine that was called the 'EDP
ANALYZER'.  It has since been replaced by something else.  But I do recall that
when this magazine came out they attempted to do real research and validate
their stories.  There was no advertising in it.  They tried to be as
technically accurate and honest as possible.  Now I see in the magazines
nothing more than what I consider hype.  I know first hand some companies and
applications that were real disasters.  Yet, when they come out in print, the
press tries to hype their success.  For instance, right now on CASE tools, you
hear all kinds of success stories.  But I think if you went out and
investigated you would find some rather shallow results.  You will also
probably find that nine times out of ten, the articles are written by the
vendors.  So I don't think our magazines are serving us well.  I think many of
the stories are nothing more than marketing hype; to do nothing more than to
promote advertising in the magazine.  I just have real trouble with what's
going on.  CASE tools are a classic example of this.  You also see it in the
areas of relational DBMS tools, 4GL's, etc.  We have to have more honesty and
integrity from these magazines, otherwise we'll never get to the truth.

The press is also indicative of what's going on in the industry.  Whereas you
used to have credible publications like the 'EDP ANALYZER' and 'INFOSYSTEMS'
which tried to serve the systems field, they have all gone by the wayside and
have been replaced by computer hardware/software publications.  Guys like Dick
Canning, Arnold Keller and Wayne Rhodes did a hell of a good job.  Yet, the
industry turned its back on them.

I have also been reading a great deal in the press about the industry's
history.  I've personally experienced a good bit of the history firsthand.
I've seen some relative newcomers talking about history and their facts are not
correct.  One of the most ridiculous things I've recently seen was a trivia
section where the author asked 'What is a punchcard?'  His answer, 'an 80
column card', was totally incorrect.  The first punchcard came out from the
Bureau of Census in 1890 and it was 45 columns, not 80 columns.  The point is,
what he was saying was only partially correct.  Yet, this is the typical
behavior by many people in the industry; they recall history to suit their
needs.  This is really disturbing to me.  We simply do not have a good sense of
history.  Consequently, the real pioneers, achievers, and innovators are
forgotten.  One of the things I find disconcerting is that people who have only
been associated with IBM computers also have a really distorted sense of
history.  Not only do they have a distorted sense of what occurred, but so does
IBM.  I remember what they said about Virtual Memory, they thought they
invented it, when actually it was invented by Burroughs a long time ago with
the B-5500; way before IBM.  So, I take most of this historical perspective
with a grain of salt.

Q:  WHY DID YOU WRITE THE ' IRM REVOLUTION' BOOK?

BRYCE:  We wrote the book for several reasons.  Number one, we wanted to set
the "PRIDE" concepts and philosophies in the public domain.  When we were only
selling a manual product, we needed to protect our concepts.  This is why we
had the lawsuit with the CPA firm.  But now this is not important.  We want
everyone to understand the concepts and philosophies in order to promote the
Information Factory.  The industry, in general, is very backward and we wrote
the book to help bring it out of the 'stone age.'

As an aside, the book is a best seller in Japan.  I would sure like to see it
become a best seller over here, but maybe that will be five to ten years from
now.  However, we are encouraged to see some universities beginning to use the
book in their curriculum, so maybe there's hope.

Q:  THE COMPANY WAS ORIGINALLY FOUNDED IN CINCINNATI, OHIO.  WHY THE MOVE TO
THE TAMPA BAY AREA OF FLORIDA IN 1985?

BRYCE:  As a Northerner I was becoming fed up with the harsh winters.  Since we
were already running on an international scale, it became rather obvious that
we could run our business from anywhere.  So, using "PRIDE", we developed our
requirements and began researching the country, from California to the East
Coast.  We looked as far north as North Carolina and as far south as Florida
and Texas.  We looked at Sacramento, San Diego, New Mexico, Arizona, Austin,
Houston, Myrtle Beach and places like that.  We looked at southern Florida but
then found out about the Tampa Bay area from one of our customers in the area.
Here, we found the answer.  It met our specifications, including a modern
international airport, easy access for our employees, and a place where our
customers would want to come for training.  Palm Harbor, Florida met all of our
needs and we moved.  We have never been sorry about that decision.  This is an
excellent place to conduct business and live.

Don't get me wrong.  Cincinnati was a great place to start the business. Its
geographical location was excellent for serving the U.S. mid-west, east coast
and Canada.

Q:  WHAT LIES AHEAD FOR "PRIDE"?  WHAT IS IT'S FUTURE?

BRYCE:  We feel our future now lies in the "PRIDE" Information Factory.  This
is the next evolutionary step in the development of "PRIDE".  We are developing
a whole approach under IBM's OS/2 and we're implementing the entire Information
Factory with LAN networks.  We're gambling that this is the wave of the future.
Naturally, we think we're absolutely correct.  We think that systems will be
developed on LAN networks using personal computers.  So, we're putting the
whole Information Factory on this platform. This will make "PRIDE" suitable for
all companies, from the smallest to the largest.  We also believe that our
field will come to see CASE tools as limited solutions and will have an
appreciation for this more comprehensive approach.

Up to now our approach was intellectually correct but lacked the sex appeal.
Now we're adding the sex appeal as provided through the personal computer. In
other words, we're getting around to putting facade on to the substance.  And
this can mean nothing more than success.

Back in 1974 when we started to build the supporting "PRIDE" software, we were
concerned with producing a generic product that would operate the same on all
mainframe platforms.  Although this provided customers with portability, it
somewhat limited our ability to produce flashy inputs and outputs.  Now with
the proliferation of the personal computer, with its graphical capabilities, we
are now going to add the flash that our customers want.

Q:  YOU HAVE ALWAYS MADE A CLEAR DISTINCTION BETWEEN "PRIDE" AND CASE; THAT IT
IS A 'CASE-COMPLEMENTARY' APPROACH.  DO YOU EVER FORESEE IT GOING AGGRESSIVELY
INTO THE CASE MARKET?

BRYCE:  We always think of the "PRIDE" Information Factory as much larger than
just software engineering.  We do have aspects in our product where we do
software engineering and we're moving into that area more rapidly. We're
putting some of our own CASE tools into the Information Factory.  Bear in mind,
techniques and tools are things that come and go, so we've still engineered our
product as a framework where if better techniques and tools come on the scene
we can easily incorporate them into the product.  We will provide our CASE
tools but will allow other CASE tools to be used in the Factory.  This is what
we refer to as having an 'Open Architecture'.  But our forte will still remain
to provide the environment, the culture, and the management tools for
developing integrated corporate-wide information systems.

END

COPYRIGHT (C) MBA 1995


ΓòÉΓòÉΓòÉ 12. Bryce's Laws on IRM ΓòÉΓòÉΓòÉ

                                 BRYCE'S LAWS ON

                         INFORMATION RESOURCE MANAGEMENT

Productivity = Effectiveness X Efficiency

Information = Data + Processing

There is nothing more unproductive than to build something efficiently that
should not have been built at all.

Organizations progress when the impact of good actions and decisions outweighs
the impact of poor actions and decisions.

IRM is the view of the enterprise from 50,000 feet.

We must apply the same discipline, organization and automation that we
recommend for other parts of the company.

IRM requires the creation of a new environment with an
engineering/manufacturing orientation.  This will require retooling and
retraining.

Technology alone will not solve our problems, only effective management will.

No amount of elegant programming or technology will solve a problem if it is
improperly specified or understood to begin with.

If anything in life is constant, it is change.  The only constant involved with
information is that it is seldom static.

If an information requirement is stated improperly to begin with, then
everything else that follows will be incorrect.

The only way that information systems communicate, both internally and
externally to other systems, is through shared data.

Data is stored, Information is produced.

Quality must be built into the product during design, not inspected in
afterwards.

Enterprises with identical missions will also be identical in terms of logical
structure.

Whereas logical IRM resources will remain relatively static, the physical
resources will change dynamically.

Information is a perishable commodity; it only has value at a particular point
in time.

Information is highly volatile in that it is greatly influenced by external
factors, such as government, economics, competition, customers, etc.

An elegant solution to the wrong problem solves nothing.

The day a company goes into business is the day when its information systems
are born.

Only when the systems analyst can walk in the moccasins of the user does the
analyst have a right to design a system for the user.

Information is for people, not for the computer.

An information system is a product that can be engineered and manufactured like
any other product.

      Systems =/= Computers
      Systems =/= Software
      Systems =/= Projects

 All information systems have the same structure.  In manufacturing terms, it
 is known as a "four-level bill of material."

 Systems are designed by 'explosion' and implemented by 'implosion.'

 No one has ever built a perfect system the first time, and no one ever will.

 Systems are built by evolution; not by revolution.  The day when a system is
 installed, is the day it begins to undergo change.

      Good Systems Design + Good Programming = Great Systems
      Good Systems Design + Bad Programming  = Good Systems
      Bad Systems Design  + Good Programming = Bad Systems
      Bad Systems Design  + Bad Programming  = Chaos

 How a system is implemented is of little importance if it solves the problem
 effectively.

 Programming is a translation function, going from human understandable
 specifications to machine readable instructions.

 Good specifications will always improve programmer productivity far better
 than any programming tool or technique.

 Beware of your "firefighters," they are probably your chief arsonists.

 The first on-line, real-time, interactive, data base system was double-entry
 bookkeeping which was developed by the merchants of Venice in 1200 A.D.

 All organizations have a data base; some are managed, most are not.

 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.

 There is only one problem with common sense; it's not very common.

 A methodology is nothing more than an assembly line that produces a finished
 product.

 Project management is only possible with an effective methodology.

 A methodology that simply keeps employees busy and doesn't produce anything is
 an exercise in futility.  This type of methodology is commonly referred to as
 "The Dance of the Fairies."

 Systems do not have a "life cycle."  They may go on forever if kept viable
 with change.  The only thing that has a "life cycle" is a project which has a
 beginning for planning, a middle for execution, and an end for review.

 It is one thing to enact legislation, it is another to enforce it.

 Project management is a philosophy of management, not a tool or technique.

 Most estimating errors are errors of omission, not commission. It is what we
 forget to estimate that gets us into trouble.

 An estimate improves in accuracy in relation to the level of detail
 considered.

 A project always has a critical path until it is completed or closed. The path
 can vary depending on accomplishments.

 A project requires a methodology, but a methodology does not require a
 project.

 It is just as bad to underrun a project as it is to overrun a project.

 If we lived in a perfect world, there would not be a need for managers;
 projects would be executed on time and within cost. However, the reality is,
 we live in an imperfect world.

 Managers do not create problems, they solve problems.

 Manage from the bottom up; not just from the top down; this creates personal
 commitment and accountability.

 Employees should be treated as professionals and held accountable for their
 actions.

 All companies have a culture.  In order for employees to function and succeed,
 it is essential they understand and believe in the culture.

 Time lost, is time lost forever.  You cannot buy it back.

 END

 COPYRIGHT (C) MBA 1995


ΓòÉΓòÉΓòÉ 13. About MBA ΓòÉΓòÉΓòÉ

                                    ABOUT MBA

                           M. BRYCE & ASSOCIATES, INC.
                                777 Alderman Road
                             Palm Harbor, FL  34683
                            United States of America
                               Tel:  [phone]
                               Fax:  [phone]
                               BBS:  813/786-4864
                            E-Mail:  [e-mail]
                               IBM Link:  DEV2643

            Since 1971:  Software for the finest computer - the mind.

                                    In Japan:

                                PRIDE Japan, Inc.
                                Masujima Building
                                  8-13, 1-Chome
                                 Higashi Gotanda
                             Shinagawa-Ku, Tokyo 141
                                Tel:  [phone]
                                Fax:  [phone]

CORPORATE PROFILE

M. Bryce & Associates, Inc. (MBA) is an international management consulting
firm specializing in Information Resource Management (IRM).  To this end, the
company develops and markets products and services aimed at IRM.  The company's
"PRIDE" product line includes methodologies, techniques and tools, which have
been used worldwide in every field of endeavor imaginable:

     Countries Served         Industries Served

     Australia                Aerospace
     Brazil                   Automotive
     Canada                   Banking
     Denmark                  Chemical
     Japan                    Communications
     Korea                    Construction
     Mexico                   Electronics
     New Zealand              Energy
     Norway                   Engineering
     Saudi Arabia             Government (Federal/State/Local)
     South Africa             Insurance
     Spain                    Manufacturing
     United Kingdom           Paper/Wood
     United States            Printing/Publishing
     Venezuela                Public Utilities
                              Retail/Wholesale
                              Shipbuilding
                              Steel
                              Transportation
In particular, "PRIDE" products have been used extensively by firms throughout
Japan, including several companies who have received the prestigious Deming
Prize for quality.

Since 1971, MBA has never failed to meet a customer implementation commitment,
regardless of the customer's geographical location or training requirements.

MBA is totally focused on the science of Information Resource Management.  IRM
is our only business.  We have invested over 23 years of research and
development into our product line, constantly upgrading and fine-tuning the
product line to suit customer and industry requirements.

              "(MBA's) strategy has included consistent, long-term
                    investment in research and development."

                                    - DATAPRO

Through the "PRIDE" product line, MBA has established several precedents and
introduced many new concepts to the industry:

   1. First to offer commercial methodologies for system design, data base
      design, and enterprise engineering.

   2. First commercial repository for capturing, controlling, and re-using
      information resources.

   3. First on-line methodology for accessing automated instructional
      materials.

   4. Concepts and Techniques introduced:  Information Driven Design,
      Structured Systems, Chronological Decomposition, Layered Documentation,
      Data Resource Management, 4 Data Base Models, Enterprise Decomposition,
      Priority Modeling, Bill of Material Processing for managing information
      resources, Mini-Project Manager, Estimate-to-do (versus percent
      complete), estimating by bill-of-materials.

 While many of MBA's competitors have come and gone, the "PRIDE" product line
 enters its third decade of use.  This is a testament to the integrity and
 durability of the product and the company who produced it.

                "With almost 1,500 installations worldwide and the
             fact MBA has existed in the methodology world for almost
               20 years, it is fair to say that the company is well
             capable of managing its revenues and balancing them off
              with consistent research and development by investing
                  about 80 percent of those revenues into R&D."

                                    - DATAPRO

 END

 COPYRIGHT (C) MBA 1995


ΓòÉΓòÉΓòÉ 13.1. MBA Product Offerings ΓòÉΓòÉΓòÉ

                              MBA PRODUCT OFFERINGS

The flagship of MBA's product line is the "PRIDE" INFORMATION FACTORY, an OS/2
based product for managing information resources.  It includes:

   1. Planning and design tools as used in support of the "PRIDE" methodologies
      (EEM, ISEM, and DBEM).

   2. The IRM Repository where information resources are cataloged and
      inventoried.  The IRM is the engine of the FACTORY software; all of its
      tools interface with the IRM to collect and analyze resources.  Further,
      the IRM has an "open architecture" enabling it to interface with a wide
      variety of third party software packages (e.g., CASE tools, DBMS
      packages, spreadsheets, word processors, program generators, other
      repositories/data dictionaries, etc.).

   3. An integrated Project Management system that works with the "PRIDE"
      methodologies as well other user defined Work Breakdown Structures (WBS).
      The system offers tools in support of project planning, estimating,
      scheduling, reporting, and control.

   4. The same "PRIDE" methodologies are embedded in the FACTORY software,
      allowing on-line access to narratives and examples, as well as printed
      documentation. In addition, the customer can add supplemental in-house
      standards thereby providing the means to maintain all standards
      documentation electronically.

 PRODUCT ARCHITECTURE

 The "PRIDE" INFORMATION FACTORY itself was engineered and manufactured using
 earlier versions of the "PRIDE" Family of Products.  In essence, "PRIDE" begat
 the next generation of "PRIDE."  As a "PRIDE"-built product, it consists of
 sub-systems, inputs, outputs, files, etc. like any other system developed
 under "PRIDE."  There are a total of eleven sub-systems in the product.
 GATEWAY FACILITY

 This represents the formal entry point to the product.  Users logon through
 the Gateway where their product privileges are checked.  After entering, they
 can modify file and printer assignments, call for their time screen to record
 their hours worked against project assignments (assuming the Project
 Management system has been enabled), or access the other FACTORY facilities
 (depending on their privileges).

 RESOURCE DEFINITION FACILITY

 This facility is used to search, display, edit, and print information
 resources.  A user may search the IRM using six different search techniques:

   1. Search by Resource Name.

   2. Search by Resource Control Number.

   3. Search by Logical Attributes (synonym words).

   4. Search down a Chain of resource relationships (e.g., display all data
      elements subordinate to a file or data base).

   5. Search through a Data Taxonomy for data descriptions.

   6. Search for data resources based on Program Label.

 As an engineer enters specifications about the various information resources,
 field entries are validated by the software.  HELP facilities are, of course,
 available.

 METHODOLOGY FACILITY

 This facility provides guidance when executing the various "PRIDE"
 methodologies (EEM, ISEM, DBEM).  There is an interactive portion which
 provides instructions on how to perform the phases and activities of the
 methodologies.  These instructions are also accessible through other
 sub-systems, such as the Resource Definition Facility, Graphics Facility,
 Deliverable Facility, Expert Facility, and the Import/Export Facility.  A
 glossary of "PRIDE" related terms is also available interactively.

 For those customers wishing to produce standards manuals, this facility
 provides the ability to generate "PRIDE" manuals, complete with text,
 examples, and worksheets.  The manuals can be produced in their entirety or in
 portions (such as a phase at a time).

 The "PRIDE" methodologies are maintained in the AIM Master File (Automated
 Instructional Materials), a computer accessible file. In addition to "PRIDE"
 specific text, the customer can add supplemental standards to the file.  For
 example, the customer may wish to add text regarding the use of special
 in-house tools, techniques, naming/numbering conventions, etc.  In this way,
 AIM is used to manage all corporate development standards.

 DELIVERABLES FACILITY

 All of the various reports produced as a result of following the "PRIDE"
 methodologies can be produced automatically.  The user has the option to build
 whole reports or request selected outputs.  The types of methodology
 deliverables include: Feasibility Studies, System Design Manuals, Flowcharts,
 User Manuals, Computer Run Books, Program Specifications, Data Base Designs,
 Audit Review Reports, Checklists, etc.

 Various Project Management reports are also included: Time Distribution
 Summaries, Project Progress Reports, Project/Personnel Estimates/Schedules,
 Effectiveness Rate Charts, Gantt Charts, Resource Allocation Charts, Skills
 Inventory, User Billing/Chargeback, etc.

 IMPORT/EXPORT FACILITY

 This represents the formal interface between the FACTORY and third party
 software products.  The "importer" consists of a converter routine to take an
 externally prepared data file and either reformats it or validates it in
 preparation for updating the IRM Repository.  The "exporter" allows the
 customer to extract information resources from the IRM.  The data can then be
 manipulated as required.  For example, a user can export resources from the
 IRM to a relational Data Base Management System (DBMS) which can then be used
 to massage the data and build special reports.  In this way, the user is
 provided with the capabilities of a report writer.  Data can be exported in a
 variety of formats:

   1. Text files for use in text/word processing packages.

   2. Delimited ASCI format (.DEL) for use in relational data base management
      systems and other programming aids.

   3. Standard 80 character records which can be edited and reapplied to the
      IRM Repository.

   4. A user defined format to accommodate any type of output.

 The INFORMATION FACTORY also makes available callable program modules which
 allows customers to develop seamless interfaces between the FACTORY and other
 external programs, thereby providing the ability to directly interrogate the
 IRM and retrieve data from it.  Customers can use this facility to build
 bridges to a variety of software tools, such as DBMS packages, CASE tools,
 program generators, report writers, etc.

 GRAPHICS FACILITY

 This sub-system provides the ability to draw "PRIDE" related graphics at the
 terminal and populate the IRM Repository at the same time.  For example:

      Hierarchy Charts/Indented Lists - including business function charts and
      organization charts.

      Matrices - to represent relationships between different types of
      information resources.

      Flowcharts - for Systems, Sub-Systems, and Computer Procedures.

      Information Flow Diagrams (IFD)

 These graphics are not stored as bitmaps or some other graphical format.
 Instead, they are dynamically drawn in accordance with the specifications
 maintained in the IRM Repository.  As a user establishes relationships between
 two or more resources in one diagram, it will be reflected in other diagrams
 automatically.  For example, should one user change the relationship of two
 resources in a hierarchy chart, the change will be seen by another user
 working with an indented list.  MBA refers to this approach as "interpretive
 graphics."  It means that graphics are based on specifications maintained in
 the IRM and, as such, documentation is kept current and up-to-date; as a
 resource relationship changes, so does the documentation.

 The user may print the graphics as desired (to a PostScript supported printer)
 or copy them to the OS/2 Clipboard for use in other applications or packages.

                             SAMPLE SYSTEM FLOWCHART

 EXPERT FACILITY

 This facility provides special routines to expedite the administrative tasks
 associated with the "PRIDE" methodologies. Features include:

     An "Impact Analysis" feature to study the effect of a proposed change to
      a resource, such as a data element, business function, or system.  Acting
      as a bill of materials processor, the "Impact Analysis" can generate a
      list of resources effected by the change.  This feature alone has proven
      invaluable to companies.  It permits them to play "what if" and allows
      them to make intelligent project decisions by providing a complete
      "roadmap" of all required resource changes.

     For "PRIDE"-EEM, an organization analysis aid is provided, along with a
      priority modeling tool used to automatically calculate the priorities of
      corporate objectives and supporting projects.

     For "PRIDE"-ISEM, a Computer Aided Design (CAD) tool is provided to
      automatically design enterprise-wide information systems (perfect for
      Business Process Re-Engineering).

     For "PRIDE"-DBEM, various data base design aids are provided.

     For "PRIDE"-PM, special aids are provided for planning, estimating,
      scheduling, and reporting.

 IRM FILE MANAGER FACILITY

 This facility provides the means to audit, expand, reorganize, and correct the
 primary files associated with the product.  This primarily consists of the IRM
 Master File and its subordinate files.  It is also used to set the basic
 operating parameters of the file (e.g., file size, print options, PM switch,
 DBCS switch, etc.).

 FILE MAINTENANCE FACILITY

 This sub-system represents the principal means for applying changes, additions
 and deletions to resource definitions in the IRM Master File.  All file
 maintenance activities includes a rigorous data validation check to assure
 resources are being defined according to standards.

 A "Resource Control" feature is provided for the "PRIDE" Coordinator to
 "activate" (freeze) resource definitions, thereby prohibiting further changes
 to the definitions.  As systems are completed and placed into production, the
 "PRIDE" Coordinator turns all of the associated resources into an "active"
 status. As it becomes necessary, the coordinator can also use the facility to
 place pertinent resources back into a "development" mode, thus allowing
 modification to the definition.

 INVENTORY ANALYSIS FACILITY

 Control logs are provided to serve as a manifest of an enterprise's
 information resources.  Resources are listed by type, and in either control
 number sequence or by name.  These logs also show redundant resource names,
 whether the resources are "not used" (not attached to other resources, and
 whether they are in an "active" status (production mode) or under
 "development."  A summary report is provided reviewing the development status
 of all resources in the organization.  In addition, special reports are
 provided to analyze such things as program labels, forms, computer schedules,
 etc.

 PRODUCT INSTALLATION

 This sub-system is used to initially install the INFORMATION FACTORY, to setup
 additional users and workstations, and to implement product upgrades.  The
 product is well packaged and easy to install.  Detailed instructions are
 provided through the computer which guides the customer through the
 installation process.

 TECHNICAL REQUIREMENTS

 The "PRIDE" INFORMATION FACTORY was designed to be compatible with IBM's
 Systems Application Architecture (SAA).  As such it was designed according to
 rigorous standards to give it the same "look and feel" as other SAA/CUA
 (Common User Access) compliant products.  This makes it easier to learn and
 implement.

 The FACTORY can be implemented either as a standalone product, or as a
 client/server application.

 OS/2 Version 2.x (or higher) is required on an Intel 486 based computer (or
 higher).  8mb of memory (or higher) is required for workstations, 16mb of
 memory required for a file server (or standalone).  All OS/2 supported Local
 Area Networks (LAN) can be used.  Text reports produced from the "PRIDE"
 software support all OS/2 supported printers.  Graphical reports require
 "PostScript" supported printers.  Consult the vendor for complete technical
 specifications.

 The product makes use of its own proprietary file management system and is,
 therefore, independent of third party DBMS packages.  Programs are written in
 "C" and "COBOL" and make use of the OS/2 "Presentation Manager" Graphical User
 Interface (GUI).

 TRANSLATION CONSIDERATIONS

 All of the screens, reports, and messages associated with the "PRIDE"
 INFORMATION FACTORY can be translated to suit a particular language.  Printed
 maps and messages can be edited as required.  The vendor can also provide the
 screen panels for translation.  The product provides for the Double Byte
 Character Set (DBCS), making it suitable for use with Japanese and Chinese
 character sets (Kanji).

 MATERIALS, SERVICE AND PRICING

 Included in the purchase price is an implementation guide and executable
 programs.  Training and consulting services are provided for the development
 staff, users, and executives.  The product is normally sold on a site license
 basis.  Consult the vendor for full pricing details.

 FOR ADDITIONAL INFORMATION:

 To learn more about the "PRIDE" INFORMATION FACTORY, either contact the
 vendor...

     About MBA

 ...or reference the following sources:

      IBM National Solutions Center
      OS/2 CD-ROM of ISV Applications
      The OS/2 Development Tools
      OS/2 Exploiting Applications Directory
      DATAPRO
      Data Sources
      And other fine software guides.

                                    "PRIDE"-PC

                       Thorough/Complete/Integrated/Proven

 For those who need proven methodologies, at an affordable price, comes
 "PRIDE"-PC, a desktop reference for the "PRIDE" methodologies, including:

                              Enterprise Engineering
                         Information Systems Engineering
                   (integrating BPR with Software Engineering)
                              Data Base Engineering
                                Project Management

 With "PRIDE"-PC, you can display, search, index, and print the "PRIDE"
 methodologies from your PC.  The product includes:

     Tutorials and instructions with hypertext
     Samples of deliverables
     Review Checklists (specifying acceptance criteria of deliverables)
     Functional Matrices (shows Who is to perform What, When)
     Supporting narratives (including sample job descriptions)
     Glossary of Terms

 Now you can have a desktop reference to your methodologies instead of
 voluminous "shelfware" manuals gathering dust.  And at a price of just $150
 per PC, why pay more?  "PRIDE"-PC requires OS/2 2.x (or higher) or MS Windows
 3.x (or higher).

            "No developer or IS manager should be without "PRIDE"-PC."

 Note:  Prices are in U.S. dollars and subject to change without written notice.

 END

 COPYRIGHT (C) MBA 1995


ΓòÉΓòÉΓòÉ 13.2. MBA Service Offerings ΓòÉΓòÉΓòÉ

                              MBA SERVICE OFFERINGS

            Professional Services for Information Systems Management

In addition to its "PRIDE" product line, MBA offers a full line of consulting
and training services.  This specifically includes the following areas:

      Methodology Customizing

      Training and Education

      General Consulting

 METHODOLOGY CUSTOMIZING

 The methodologies contained within "PRIDE" are universally applicable and
 independent of any particular tool or technique. However, there may be
 occasion where the customer may wish to customize "PRIDE" to accommodate
 specific requirements. In such an event, MBA can be contracted to develop a
 tailored version of "PRIDE".  Potential areas for development and inclusion in
 "PRIDE" include:

   1. Policies and Procedures.

   2. Job Descriptions.

   3. Specific Tools & Techniques to be used throughout the "PRIDE"
      methodologies and Project Management system.  For example:

           Performing a Cost/Benefit Analysis (including standard formulas for
           calculating Return on Investment and Break Even Points).

           Program Design - such as structured programming, object oriented
           programming, diagramming techniques to be observed, etc.

           File Design - to develop certain types of physical file/DBMS
           structures (e.g., hierarchical, network, relational, object
           oriented, VSAM, etc.).

           Writing Standards - for developing narratives, help text, user
           documentation, etc.

           Testing Standards - for uniform testing criteria.

           Naming and Numbering Conventions to be observed.

           Program Coding Standards

           Auditing Standards

           Change Control Standards

           Conducting a Meeting

           Rapid Application Development (RAD) and Joint Application
           Development (JAD)

           Use of a specific CASE tool

           Documentation Aids - e.g., diagramming aids, source code librarian
           aids, etc.

           Compilers

           Testing/Debugging Aids - including test data generators.

           Editors

           Application Development Aids - such as program generators. 4th
           generation languages, and report writers.

           Prototyping Aids - such as screen painters, and Graphical User
           Interfaces (GUI).

           Repositories/Encyclopedias/Data Dictionaries

           Project Management Aids - such as use of Gantt Charts, PERT
           diagrams, and other tools for planning, estimating, scheduling,
           reporting, and control.

   4. Corporate Tailoring - to include a corporate name, logo, and in-house
      standard deliverables (examples).

   5. Translation of the Product

 Methodology customizing is performed by MBA on a time and materials basis.
 Please discuss your requirements with MBA and let us quote you a price to
 tailor "PRIDE".

 TRAINING AND EDUCATION

 MBA offers a course curriculum oriented towards IRM related disciplines.
 There are three types of training courses available from MBA:

   1. Skills Training - aimed at teaching the basic skills required to perform
      Information Resource Management, Enterprise Engineering, Information
      Systems Engineering, Data Base Engineering, and Project Management.  This
      series of courses does not make use of any computer software.  Instead,
      it combines instructor lecture with active student participation.  Most
      courses involve practical workshop exercises involving teamwork.  Such
      team exercises promote group dynamics and the exchange of ideas between
      students, regardless of their level in the corporate structure.

   2. "PRIDE" Software Training - aimed at teaching the effective use of
      "PRIDE" products, such as the "PRIDE" INFORMATION FACTORY.  Lab exercises
      include use of the computer software.

   3. "PRIDE" Methodology Implementation - combined education/consulting aimed
      at facilitating the effective implementation of the "PRIDE" methodologies
      (EEM, ISEM, or DBEM).  This is particularly useful when initiating the
      use of "PRIDE."

 All courses are conducted in either a classroom or "roundtable" environment.
 Each student is provided with a workbook that includes such things as printed
 copies of the transparencies, workshop exercises, a glossary of terms, and a
 place for notes.

 Most MBA courses include a questionnaire at the end of the course to test the
 student's knowledge.  In addition, an evaluation of the course is performed by
 both the students and the instructor.  Consequently, the customer is provided
 with an analysis of the course at no extra charge.

 Having trained thousands of managers, analysts, engineers, and programmers
 from around the globe, MBA has extensive educational experience.  Our
 instructors are seasoned professionals with "hands-on" experience in the use
 of IRM concepts, methods, techniques and tools.  They are also effective
 communicators who are able to simplify complicated concepts and present them
 with practical real life examples.

 Contact MBA for a course catalog detailing the terms and conditions for
 training, along with the current prices of all courses.

 GENERAL CONSULTING

 The concept behind MBA Consulting Services is actually quite simple:  Provide
 clients with senior people who have extensive experience in I.S. and equipped
 with proven methodologies and tools, specifically the "PRIDE" INFORMATION
 FACTORY.

 MBA consultants are not junior programmers nor recent college graduates.  They
 are seasoned professionals with an average of 20 years of experience in I.S.
 management.  They are supported by MBA's "PRIDE" family of products, an
 integrated product line providing tremendous leverage for analyzing businesses
 and designing systems.  The "PRIDE" methodologies constitute the analysis,
 planning and development framework with which MBA consultants operate.
 "PRIDE" is an effective means for managing projects, producing quality
 deliverables at competitive prices, and assuring customer satisfaction.

 The area of expertise for MBA consultants encompasses a wide range of services
 related to Information Resource Management:

   1. ENTERPRISE ENGINEERING RELATED ACTIVITIES - This line of work is
      concerned with studying a business and formulating an enterprise
      information strategy synchronized with business objectives.  Activities
      within this area include:

           Modeling a Business, logically and physically.

           Defining the information required to operate and manage a business.

           Documenting a company's systems portfolio and technology portfolio.

           Performing an Organization Analysis and Skills Assessment.

           Calculating the priorities of business objectives and supporting
           projects.

   2. INFORMATION SYSTEMS ENGINEERING RELATED ACTIVITIES - This area is
      concerned with the design and development of enterprise-wide information
      systems, complete with business processes and specifications for software
      engineering (programming).  Activities within this area include:

           Performing Feasibility Studies to specify information requirements
           and devising a system solution (e.g., design a new system, modify an
           existing system, purchase a package, or combinations).

           Evaluating purchased packages.

           Designing integrated systems.

           Re-Engineering Business Processes.

           Documenting Current Systems.

           Writing User Manuals and Help Text.

           Specifying Software Requirements.

           Testing & Implementing Systems.

           Auditing Systems Development projects.

           Software specifications can be implemented by the client's in-house
           programming staff or by sub-contractors provided and supervised by
           MBA consultants.

   3. DATA BASE ENGINEERING RELATED ACTIVITIES - This area covers the design
      and development of the corporate data base so that it is naturally
      synchronized with applications. Activities include:

           Designing/Modeling the Logical Data Base.

           Evaluating Data Base Management Systems (DBMS).

           Designing the Physical Data Base.

   4. PROJECT MANAGEMENT RELATED ACTIVITIES - This includes planning and
      controlling the human resources required to implement project work.  This
      may include client personnel and/or contractors.  Activities include:

           Defining Work Breakdown Structures (WBS) and precedent
           relationships.

           Estimating and scheduling projects.

           Managing project personnel.

   5. OTHER CONSULTING SERVICES

           Conducting Computer Technology Appraisals.

           OS/2 related computing.

           I.S. related research assignments.

 MBA CONSULTANTS

 Our most valuable asset is our people.  MBA consultants consist of company
 employees as well as independent contractors skilled in the use of "PRIDE"
 products.  Because of this, MBA consultants are a united group of people who
 speak a common language and perform well as a team, and not a diverse group of
 individuals.

 MBA consultants have backgrounds in all facets of I.S. management.  They
 understand the problems plaguing I.S. and can call upon their experience to
 solve problems in a responsive manner.  They are not neophytes, but seasoned
 professionals with impeccable credentials.

 The consultants have graduate and undergraduate degrees in Business,
 Communications, Computer Engineering, Computer Science, Industrial
 Engineering, Industrial Psychology, Journalism, and Sociology.  They actively
 participate in professional and technical societies and hold various trade
 related certificates; e.g., CDP, CSP.  In addition, MBA actively participates
 in the IBM Developer Assistance Program (DAP).  Our expertise has put us in
 demand for speeches to prominent business groups and for editorial commentary
 in industry and trade publications.

                   "The company conducts business with many of
                   the most prominent companies from around the
                   globe and brings together professionals from
                     many different geographical locations."

                 "With such skilled workers, the company stays in
                tune with the products and services it markets and
               the individual needs of its diverse customer base."

                    "MBA is certainly a leader in its field."

                                    - DATAPRO

 WHAT'S DIFFERENT?

   1. MBA Consultants offer workable solutions described in common business
      terms.  They have a business and management perspective as well as
      possessing technical skills.  Esoteric methods couched in cryptic
      vocabulary is avoided.

   2. MBA Consultants offer depth and experience in a wide range of I.S.
      related subjects.  MBA does not offer inexperienced junior people
      requiring considerable supervision.

   3. MBA Consultants are supported by the "PRIDE" family of products which are
      demonstrably superior to other products of their kind in the industry.
      "PRIDE" methodologies, which have been tested by MBA customers around the
      world, improve communications between MBA consultants and clients,
      expedite project assignments, and promote quality deliverables.

   4. The MBA approach promotes the integration of information resources.
      Sharing and re-using resources unifies development activities and
      expedites the implementation of change.

   5. Through the "PRIDE" methodologies, MBA Consultants can make a smooth
      transition from a planning assignment to a design and development
      assignment.

   6. MBA Consultants conduct themselves in a professional manner according to
      high ethical standards.

 MBA is confident that we can offer you superior service at a competitive
 price.  For more information, please contact us at:

     About MBA

 Trademark:

   1. OS/2 is the registered trademark of the International Business Machines
      Corporation.

 END

 COPYRIGHT (C) MBA 1995


ΓòÉΓòÉΓòÉ 13.3. IRM Revolution Book ΓòÉΓòÉΓòÉ

        THE AUTHORITATIVE GUIDE FOR INFORMATION RESOURCE MANAGEMENT (IRM)
               THE IRM REVOLUTION:  BLUEPRINT FOR THE 21ST CENTURY
                               by Milt & Tim Bryce
                                    MBA Press
                          ISBN 0-9621189-0-7; 265 pages

Information Resource Management (IRM) represents an imaginative new way of
thinking and conducting business in the information age.  It is not just
another way of using computers.  Rather, it is concerned with the development
and control of all the resources required to produce information.  To many, IRM
will represent a radical departure from the mainstream of thinking in today's
data processing world which is generally technology oriented.  The purpose of
this book is to convey to executives a practical approach for the design and
development of information resources consistent with their business objectives.
Ultimately, the IRM approach demystifies the information systems development
process and puts control back in the hands of executive management where it
belongs.

CHAPTERS INCLUDE

     IRM:  The Prophecy
     IRM:  The Concept
     The Information Factory:  Implementing the Concept
     Project Management
     Enterprise Engineering
     Information Systems Engineering
     Data Base Engineering
     Glossary of Terms

 The concepts and ideas contained in this book represent over thirty years of
 practical experience in the field and have been proven effective by over 1400
 installations around the world.  Since 1976, many prominent Japanese companies
 have implemented these ideas, including top "Fortune 100" companies and
 several winners of the Deming Prize for quality.

                "This book belongs in every DP Manager's library."
                                      - DPMA

              "The information presented in this book reflects clear
                thinking based on years of practical experience."
                             - IRM Association (IRMA)

              "Covers in detail practical concepts and philosophies
                for utilizing information to increase productivity
                     and competitiveness in an organization."
                        - Applied Computer Research (ACR)

                             #1 Best Seller in Japan

 The book is priced at $50 (U.S.).  Quantity discounts are available.  Consult
 MBA for deliveries outside of the U.S. and Ontario, Canada.  Make checks,
 money orders or purchase orders payable to:

                           M. Bryce & Associates, Inc.
                                777 Alderman Road
                              Palm Harbor, FL  34683
                                Tel:  [phone]
                                Fax:  [phone]
                                BBS:  813/786-4864
                            E-Mail:  [e-mail]
                             CompuServe:  76235,2364

            Since 1971:  "Software for the finest computer - the Mind"

 END

 COPYRIGHT (C) MBA 1995