What's Wrong with IT and Business Process Re-engineering?
Why do 50% of Large Software and Re-engineering Projects Fail?
The primary problem with developing complex IT based systems is the
difficulty in coming up with a specification or blueprint of what should be
developed. The root cause of nearly every failed software project is a lack of
clear understanding and common interpretation of what the software should do.
INFOLOGISTIK believes that developing blueprints or engineering
drawings, as practiced in the mature engineering disciplines, also applies to software engineering and to
business process re-engineering. Fads and poorly conceived approaches have stood in the
way of a paradigm shift.
Large and Small Systems Are Not One and the Same
In general, small systems can be built effectively without a blueprint;
large systems, which require a large team and have different stakeholders,
Just as no one would dream of building a skyscraper without a blueprint, no
one should undertake a major system implementation or business process change
without one. A blueprint serves to:
- Communicate concepts and solutions among stakeholders of different
backgrounds (owners, managers, users, IT professionals),
- Recognize/reflect complex interdependencies and see/illustrate the global impact of a local
optimization, as well as local impact of a global optimization,
- Visually recognize/reflect incomplete or inconsistent parts of a specification.
How to Improve the Conventional Way
When a new software application or technology, such as e-commerce, is introduced, it impacts its environment --
the organizations that use it. Therefore, the software application should
be conceived and modeled as an integral part of the enterprise.
The conventional way of developing a software application or introducing
e-commerce to support vague,
often conflicting ideas about the "to be" business processes often
leads to poor software. Much faster and better results can be achieved if the
"to be" business processes are firmed up first and the software
application is designed to support them. This also applies to implementation of
standard ERP software systems, taking into consideration what support could be
provided by IT (customization makes different scenarios possible).
The Faulty Focus of the IT Profession
Computer Aided Software Engineering (CASE) efforts have failed to bring about the desired results,
with the IT
profession focusing primarily on:
- Tools and techniques for producing software fast, but leaving largely
unsolved the issue of determining what software should be developed to solve
a particular business problem or to optimize business processes and
- Very elaborate methodologies that describe all facets of the process but
don't provide convincing, practical tools and techniques for producing a
blueprint of the sociotechnological system to be implemented.
- Pursuit of fads and promotion of the misconception that software
engineering by its nature needs to be different from the mature engineering
Dealing With Complexity in an Understandable Manner
Is there a straightforward way of dealing with sociotechnological system
complexity? We believe there is, if the objective is to conceive an improved
process and develop a specification
or blueprint for implementing it.
A primary precondition is that the concepts and terminology of the technique
be easily understandable by all stakeholders, not just software professionals,
as is the case with the popular methodologies.
We apply the same concepts to modeling of a company or of a software system,
i.e., to any discrete event system, therefore looking at both together as one
"whole" and designing optimization of both is quite natural. In fact,
a software or re-engineering project is a "system" in this view and
should be modeled prior to implementing it.
Fundamental Building Blocks of Systems
GRADE is based on concepts and terminology derived from observable reality.
We view a sociotechnological system and its representation in a model as being
made up of three "fundamental building blocks":
- Active objects (or "result" producers), e.g., an IT
system, a manufacturing plant, a supplier, a customer
- Passive objects (or produced "results"), e.g., an order,
parts, an assembled PC, an e-mail message
- Processes (or activities that produce "results"), e.g.,
processing an order, assembling a PC
An active object is active and supports a process.
A process can consume,
produce or modify a passive object.
A passive object can be
created, sent to another active object and used or modified by an active object.
Decomposing Fundamental Building Blocks and Keeping Track of Details
Active objects, passive objects and processes can be very complex, and
therefore it must be possible to represent each on different levels of detail or
decomposition. Furthermore, to ensure integrity of a model, it must be clear
which active object deals with which passive objects and what process it
supports, i.e., an integrated view of structure, behavior and data.
Different Views of a Model
It must be possible to derive different views to serve different needs. For
example, in some cases it is important to see a business process from the
perspective of a single active object, and in other cases to see how a process
spans multiple active objects.
In other situations it is important to describe fragments of a process, such
as individual tasks, with their preceding and succeeding events and have them
automatically combined into task sequences, based on these.
We have found that the modeling approach based on fundamental building blocks, from which different views are derived to serve different audiences and
needs, permits us to understand and manage seemingly unmanageable complexity and
thus makes possible global process optimization in a systematic and practical manner.
Ten Primary Issues Addressed by GRADE
Our experience with complex systems has led us to believe that the following
are the major issues to be addressed by a technology for developing system
- Effectively communicating concepts, needs and solutions among people of
different backgrounds and orientation.
- Representing complexity on different levels of detail, yet in a consistent
and unambiguous manner.
- Making complex interrelationships among parts of a system understandable and
presenting the consequences of changing one part on the rest of the system.
- Validating assumptions before committing to implementation, either
visually or through prototyping or simulation.
- When optimizing business processes, presenting the enterprise
organization, its IT systems and the external organizations with which there
is interaction as an integral whole.
- Keeping information about a system so that there is a place for everything
and everything is in its place, and allowing rapid registration of known
facts, which can be displayed in their graphical context.
- Facilitating thinking in terms of processes and results rather than
- Allowing the user to start structuring a model for a system of seemingly overwhelming
- Facilitating the transition from "as is" to "to be" in a systematic
- Presenting model information to suit different objectives and audiences,
e.g., suppressing diagram details, enhancing diagrams with pictures,
presenting different views, etc.
Click here to go to the GRADE product page.