The
foundation of the EKD-CMM change management framework: EKD Method
Introduction: What EKD is and isn’t
Experience shows that one of the most important issues that need to
be clarified when introducing EKD to a potential application (customer)
is the "nature" of the method and the contributions it can make. At the
same time, the purpose of applying it must be made clear, i.e. what results
are expected.
What EKD is
-
EKD is a structured method primarily:
-
to tackle (to tame) ill-structured problems,
-
including a notation in terms of a set of model types and relationships
-
a set of guidelines for working and using it in different situations.
To tackle means here to define, to analyse and to formulate possible solutions
to ill-structured problems.
-
A successful use of EKD is strongly dependent on “situational factors”,
the purpose of applying it, as well as on user expectations.
-
The result of an EKD application can be either documents describing problems
and/or solutions to problems, or it can be people with an improved perception
and understanding of a particular set of issues. The result of an EKD application
is in most cases documents which describe problems and/or solutions to
problems. Even if solutions are not found, the stakeholders involved in
the EKD process have gained improved understanding of the set of issues
at hand. This means the EKD process produces knowledge in two forms; in
the form of documents and in the form of knowledge in the minds of the
people involved.
-
The use of EKD may facilitate change management in ESI companies (and in
other kinds of companies as well).
-
EKD may improve analysis and design of areas of the ESI sector by supplying
a set of generic patterns for products, business processes, as well as
for ways of working.
What EKD is NOT
-
EKD is not a tool-set. The existence of a tool-set may, however, improve
the efficiency and effectiveness of working and using EKD in certain respects.
-
EKD is not “an expert system” for managing change in the ESI sector. The
use of EKD may, however, significantly facilitate change management in
the ESI sector, if applied properly.
-
EKD is not a “miracle cure”. It is, however, a “help for stakeholders to
sort out their own problems, directions, and solutions”, and as such it
requires non-trivial work by all involved stakeholders.
[Top of Page]
The EKD way of modelling
The models underlying EKD are Enterprise Models which purpose is to represent
various views of an enterprise. The inter-connected set of EKD models describing
an enterprise can be visualised in three levels of concern as shown in
the following figure: Enterprise Goal Model, Enterprise Business
Process Model and Enterprise Information System Model. The first
one describes the enterprise objectives and the second one describes various
aspects of enterprise processes. The latter is used when the EKD approach
is applied to define the requirements for an information system. The focus
is thus the computerised system which has to support the goals, the processes
and the actors of the enterprise as defined in the previous models.
[Top of Page]
The EKD way of working
The EKD way of working describes the modelling process to be followed
by application engineers to construct the set of enterprise models. Due
to its participative and innovative nature, the EKD process can not be
fully prescribed. A method for participative modelling process should allow
to select dynamically the next task to be performed depending on the situation
at hand. Thus the EKD way of working is represented using a navigational
structure allowing the application engineer to determine a route from Start
intention to Stop intention. This navigational structure is called a road
map by analogy of a real 'road-map' in which we can observe that going
from one place to another, say from A to B, there may be many routes. The
choice of a route depends on one's desired intention (destination), and
availability or choice of the vehicle (speed, scenery,...). The road map
representing the EKD way of working supports the dynamic selection of the
modelling intention to be achieved next and the appropriate strategy. Accordingly,
the set of EKD models can be constructed following differents routes in
this map.
The figure below shows three examples of routes in the EKD road map.
It can be seen that the EKD method may be used for various purposes allowing
for instance:
(1) forward engineering (from business objectives to business processes
and from business processes to information systems development),
(2) reverse engineering (from legacy information systems to the information
system level which may be than used to model the business processes level),
(3) business process reengineering (from business processes level to
the business objectives for change).
A detailed description of the EKD method can be found in the EKD
user guide.
[Top of Page]
Copyright
ELEKTRA