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

Text File | 1995-05-26 | 231KB | 4,485 lines

=============================================================================                                       i
                                THE BEST OF MBA
=============================================================================                                       i

                 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
                           E-Mail:  [e-mail]
                            CompuServe:  76235,2364
                              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.

=============================================================================                                       i
                                THE BEST OF MBA
                               TABLE OF CONTENTS
=============================================================================                                       i

     1.0     INTRODUCTION

     2.      ARTICLES

     2.1         SOME COMMON SENSE ABOUT IMPROVING PRODUCTIVITY

     2.2         MOVING IRM FROM AN ART TO A SCIENCE

     2.3         THE FOUR STAGES OF IRM GROWTH

     2.4         CORPORATE CULTURE

     2.5         TODAY'S CHIEF INFORMATION OFFICERS:  THE UNTOUCHABLES

     2.6         IN JAPAN - "MAYBE YES" MEANS "NO"

     2.7         THE LADY OR THE TIGER?

     2.8         BACK TO THE FUTURE:  RE-INVENTING RE-ENGINEERING

     2.9         AN INTERVIEW WITH MILT BRYCE

     3.0     BRYCE'S LAWS ON IRM

     4.0     ABOUT MBA

     4.1         MBA PRODUCT OFFERINGS

     4.2         MBA SERVICE OFFERINGS

     4.3         IRM REVOLUTION BOOK




END

COPYRIGHT (C) MBA 1995

=============================================================================                                       i
 1.0                              INTRODUCTION
=============================================================================                                       i


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:

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.

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

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

=============================================================================                                       i
 2.1             SOME COMMON SENSE ABOUT IMPROVING PRODUCTIVITY
=============================================================================                                       i
                               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

=============================================================================                                       i
 2.2                   MOVING IRM FROM AN ART TO A SCIENCE
=============================================================================                                       i
NOTE:  This article first appeared in the August 1993 issue of MBA's
       Management Visions newsletter.

                 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:

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

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

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 (see Figure 1).

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 (see Figure 2).

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 (see Figure 3).
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 (see Figure 4).

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 (see Figure 5).  A similar
tool can be used to inventory and standardize information resources
(see Figure 6).

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 (see Figure 7).

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

=============================================================================                                       i
 2.3                      THE FOUR STAGES OF IRM GROWTH
=============================================================================                                       i
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.


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

=============================================================================                                       i
 2.4                           CORPORATE CULTURE
=============================================================================                                       i
NOTE:  This article first appeared in the May 1987 issue of MBA's
       Management Visions newsletter.


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.

                           ---- PEOPLE <---
                          /                \
                         V                  \
Personal            RESIDENT             CORPORATE      Professional
 Lives              CULTURE               CULTURE          Lives
                         \                   A
                          \                 /
                           ---> PEOPLE ----/


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

=============================================================================                                       i
 2.5        TODAY'S CHIEF INFORMATION OFFICERS:  THE UNTOUCHABLES
=============================================================================                                       i
NOTE:  A modified version of this article appeared in COMPUTERWORLD
       (August 3, 1992; "CIOs, Get Out of Your Cocoons").


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

=============================================================================                                       i
 2.6                  IN JAPAN - "MAYBE YES" MEANS "NO"
=============================================================================                                       i
NOTE:  This article first appeared in the ICP Business Software Review,
       December 1987

                               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

=============================================================================                                       i
 2.7                        THE LADY OR THE TIGER?
=============================================================================                                       i
NOTE:  This article first appeared in the October 1991 issue of MBA's
       Management Visions newsletter.


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

=============================================================================                                       i
 2.8              BACK TO THE FUTURE:  RE-INVENTING RE-ENGINEERING
=============================================================================                                       i
                                  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

=============================================================================                                       i
 2.9                      AN INTERVIEW WITH MILT BRYCE
=============================================================================                                       i
NOTE:  This article first appeared in the April 1991 issue of MBA's
       Management Visions newsletter.


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

=============================================================================                                       i
 3.0            BRYCE'S LAWS ON INFORMATION RESOURCE MANAGEMENT
=============================================================================                                       i


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

=============================================================================                                       i
 4.0                              ABOUT MBA
=============================================================================                                       i

                          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

         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

=============================================================================                                       i
 4.1                         MBA PRODUCT OFFERINGS
=============================================================================                                       i

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.

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 is required (or higher) 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 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

=============================================================================                                       i
 4.2                        MBA SERVICE OFFERINGS
=============================================================================                                       i


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

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


END

COPYRIGHT (C) MBA 1995

=============================================================================                                       i
 4.3                          IRM REVOLUTION BOOK
=============================================================================                                       i

         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
                                United States

                              Tel:  [phone]
                              Fax:  [phone]
                              BBS:  813/786-4864
                           E-Mail:  [e-mail]
                            CompuServe:  76235,2364
                              IBM Link:  DEV2643

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


END

COPYRIGHT (C) MBA 1995