To apply an integrated business and IT policy we must have a frame of
reference in which we can place the various aspects of the policy and
the changes to be implemented. In this frame of reference, the relationship
between business and IT is systematically analysed. We call this the
distinction between the business domain and the IT domain. With this
division in domains, the coherence between IT problems and business
problems can be made clear. This is laid down in the framework as represented
in figure 2.8.
Within each domain, a distinction is being made between strategy,
resources and transformations.
In the business strategy, choices are involved with respect to the
products and services,
the relations with customers and suppliers, the competition or co-operation
with other companies and the focus on the core
activities or the core competences
of the company.
Business resources concern the configuration of human and other resources
for the new business operations, based on the formulated strategy. This
concerns amongst other things choices with respect to the future business
operations and the required staff and resources. IT resources and the
IT staff are excluded.
Business change is the process to arrive at the new configuration of
resources and the new business operations to realise a business transformation.
IT strategy concerns the choices with respect to products, concepts
and knowledge in the field of IT, that need to be available within the
company. This is of course closely related to the business strategy
and is intended to facilitate new or improved products, services or
business processes.
The IT resources can be subdivided into the IT infrastructure, the IT
applications and the IT organisation.
The IT infrastructure includes the hardware and the 'hard' infrastructural
software necessary to develop, manage and run the applications. The
IT applications include the formal applications, aimed at specific business
processes, and the generic applications, aimed at generic tasks. The
IT organisation consists of the business operations necessary for the
development, configuration, management and support of the IT infrastructure
and the IT applications, including the necessary IT staff and tools.
IT transformation concerns the process of arriving at a new or innovated
configuration of the IT infrastructure, IT applications and IT organisation.
Looking at the process of formulating a policy, we notice three subprocesses
in the framework:
- Aim - this refers to the definition of a strategy and the
goals with respect to business operations and application of IT;
- Configure - this refers to the configuration of the resources
for the business operations, with specific attention for the IT applications,
IT infrastructure and IT organisation;
- Change - this refers to the process of change that must be
gone through to arrive at the new business operations and configuration
of resources.
The strategy gives direction to the organisation and the transformation
of the company. The human and other resources determine a company's
capacity to change. The strategy determines the course of the
changes and the configuration of resources determines the feasibility
of the changes. The strategy will therefore have to concentrate above
all on the reinforcement of the company's capacity to change. This can
mean that people with the right knowledge and skills will have to be
recruited first, and advanced resources (such as IT) will have to be
purchased, before the desired change processes can take place. In other
words: the company first enhances its core competences to be able to
implement the desired transformations. This way, the strategy determines
the intent of the company, while the configuration of the resources
determines its ability.
In the framework there is a special interaction between the business
domain and the IT domain, in which IT and business operations can influence
each other to an important degree.
Figure 2.7 Interaction in framework.
Business operations and IT affect each other in the following way:
Alignment
When the company actively applies the IT domain for the realisation
of the business goals, we call this alignment of the IT domain to the
business domain. A company for example purchases new IT to facilitate
the desired form of business
operation.
Transformation
If the company deliberately reinforces the IT domain in order to provide
the business domain with many new possibilities for development, we
call this transformation of the business domain by means of IT.
The business domain and the IT domain show the same relationship between
'intent' and 'ability' as strategy and configuration of resources. The
business domain determines a company's intent in terms of IT support,
while the technology as a resource determines the ability of the company.
If the ability does not correspond with the intent, a
change process will be initiated to align the configuration of resources
and the business operations. This change process itself, which can take
place in either the business domain or the IT domain, is the third layer
in the framework.
Internal versus external focus
Within the framework as we described it, we also have to take into account
the distinction between internal and external area of attention, besides
the division in strategy, resources and transformation.
Externally, the company looks at the developments and opportunities
in the environment. These could
lead to changes. Externally, the attention is focused on customers,
the competition, partners and suppliers, and on relevant social developments.
Internally, the company mainly focuses on the configuration of human
and other resources that form the core competences that allow for changes
with respect to services, products and business operations.
With respect to business operations, the company internally focuses
on the possibilities to change the business processes by which the products
and services are realised for the environment. External business operations
concern the processes involved with the relationships with the environment,
for instance with customers and suppliers, and the use of services and
resources provided by third parties. This also concerns external installations
of third parties, for instance a telecommunication
network.
Figure 2.8 The lemniscate of policy
making.
In the formulation of the strategy, there is an interaction between
the internal and external areas of attention. If the focus is on the
environment, the internal organisation is implicitly taken into account,
and vice versa. In the course of time, internal and external focus alternate
constantly. This alternation between internal and external can be shown
in a lemniscate.
A company can first focus on the environment to see which developments
are taking place, and derive the changes that are necessary in the own
organisation. The other way around, a company can first make an internal
inventory of the core competences and then lookaround to determine the
opportunities and possibilities it can utilise, for example by first
innovatively determining the products or services it can offer the environment,
and then look for potential customers.
With respect to IT there can also be an interaction between internal
and external focus. Externally, the company investigates the possibilities
offered by existing and new IT, and the way in which IT is applied in
other companies. This provides a handle for the application of IT in
the own organisation. This development of IT is aimed at the desired
transformation of the company. The company will - more quickly, perhaps
- go through the learning process with certain IT in order to accumulate
sufficient experience and IT resources.
At the turning point in the lemniscate the company always keeps the
balance between external opportunities and threats and the internal
strengths and weaknesses of the own organisation. This prevents the
internal organisation from dominating the formulation of the policy
too much, which would prevent the company from responding to external
developments. It also prevents an undesirable dominance of external
focus, in which the alignment to the environment and the anticipation
of the wishes of customers takes its toll on the attention for the development
of the own, internal organisation.
2.7.2 Approaches To Change
In the previous section, we described a number of important aspects
of an integrated business and IT policy. A company then formulates a
strategy for its business operation and its IT. This strategy determines
the future configuration of business operations and IT.
In this section, we indicate how the company can subsequently set out
a change trajectory to implement the transformation in the company and
in the IT. This trajectory on the one hand consists of steps aimed at
the transformation of the company, and on the other hand of steps in
which the IT infrastructure and applications are gradually expanded.
Uncertain factors in transformations of business and IT
There are three uncertain factors companies face in the transformation
process:
Uncertainty with respect to business operations
An uncertain factor in many companies is the development of the business
operations. The increasing changes in society, in the business
sectors and in the markets force companies to adapt and respond
quickly. The development of new products and services, and the design
of adequate, flexible business processes, purchasing channels and sales
channels are therefore becoming increasingly important.
Uncertainty with respect to IT infrastructure
Since IT is still developing, the IT infrastructures
are also uncertain. This does not apply so much to the specific IT infrastructure
that supports the present, stand-alone applications. It mainly concerns
the future infrastructure of the entire computer network, that will
emerge as a result of the Digital
Highway. The technological standards for hardware and networks
are often still under development. This is a great source of uncertainty.
Uncertainty with respect to IT applications
The previous two aspects of uncertainty cause a double uncertainty with
respect to the development of IT applications. It is not always known
which business operations the applications are to support and it is
unknown which IT infrastructure they will be using. The application
architectures are also still being developed. There are no generally
accepted standards with respect to client/server
architectures and in particular object-oriented
architectures.
Choosing an approach to change
The uncertainty with respect to business operations, IT applications
and IT infrastructure can cause companies great problems. If the company
decides in favour of drastic business and IT transformations, the company
management faces the choice for an approach to be used. This choice
is in fact between the 'blueprint' approach, the 'growth' approach or
a hybrid of these, the 'development plan' approach.
The blueprint approach
The blueprint approach is based on the assumption that an organisation
can be 'moulded'. The new business operations, the IT applications to
be developed and the configuration of human and other resources can
be accurately described beforehand in documents
and models, the 'blueprint' of the future organisation. The approach
allows for the design and realisation of transformations of which the
results can be formally described in advance. This blueprint approach
is generally applied in the design and construction of conventional
information systems. The development process of an information system
is strictly formalised in this approach. The IT focus dominates. The
starting point is the current or a desired new situation with respect
to business operations. Possible transformations of the business operations
and business processes are usually considered to be tasks of the company
itself. These are therefore not included in the development path. The
deliberate introduction of new IT to facilitate a certain transformation
is a rare practice. The blueprint approach prefers the use of proven
technology.
The blueprint approach uses a separate development organisation that
prepares the transformation and a user organisation that undergoes the
transformation. The development organisation handles the application
development and the purchasing of resources. The transformation is then
implemented through integration of the infrastructure and the applications
in the business operations. The user organisation switches to the new
infrastructure, applications and procedures all at once.
An implicit assumption in the blueprint approach is often that the
new or existing business operations will remain unchanged for a long
period. The current dynamic external environment is the reason that
companies often have to quickly adapt their business operations. So
quickly, in fact, that the blueprint on which the transformation is
based, is already outdated before the information system and the new
business operations could be realised. The dynamics of the environment
create a quicksand foundation underneath the blueprint, whereas the
blueprint was in fact the basis for planning the change activities.
The continuous adaptation of the plans could gradually start to form
an obstruction, whereas these plans were in fact meant to provide a
footing for the long-term system development. As a result, the transformation
often remains incomplete, or does not happen at all.
The growth approach
In dynamic environments the growth approach is a more logical choice.
This approach aims at implementing a change in the business operations
through providing the right resources and through training or recruiting
staff. The actual change is left to the self-organisation of the employees
involved. The strategy points out the direction of the change. An important
basis for acquiring the desired flexibility in this approach is formed
by making available (non-specific) generic, infrastructural facilities.
With the support of such an infrastructure, the company is able to adapt
its business operations relatively fast and still introduce new applications
and change existing ones. A simple example is providing a PC on which
a number of software packages are installed, with which the user can
configure his own, personal applications. Such 'informal' PC applications
are of a completely different nature than the formal applications on
the conventional central information systems. A word processor on the
PC is an example of a generic 'informal' application. The user can use
it to create his own documents and pictures. This is a much more flexible
way of working than the on-line applications on a central system with
specific, formal applications, for these force the user to retrieve
and edit data in a specific way. The
growth approach therefore leaves much room for the personal responsibility
of employees.
There are, however, also a number of risks to the use of a growth approach
for the application of IT:
- there can be a proliferation of all kinds of stand-alone applications
and hardware;
- after the phase of island automation the stand-alone applications
will turn out to be unfit for integration into one network
system.
A result may be that in the long run there will be no large IT platform
that facilitates large transformations of the company by means of collaborative
applications.
The development plan approach
The choice between blueprint and growth is a difficult one with large
transformations. With the blueprint approach, the transformation can
often not be realised. A lack of the flexibility necessary for interim
changes and a lack of room for creativity of the designers and users,
are the causes for the fact that the result often does not meet the
initial expectations. The growth approach does not offer a solution
either. There is often too much room for flexibility and personal creativity,
which stands in the way of a coherent result in the long run. A well-chosen
hybrid form of the two approaches provides an answer to the dilemma:
the development plan approach. This approach is possible as soon as
a company is able to form a reasonable idea of its future.
The development plan approach can be used to realise the necessary
changes in the business operations, including the use of IT, in case
of a long, complex and large operation. So large, that the transformation
cannot be realised in one step, but only in a series of small steps.
An incremental form of transformation is chosen. In the development
plan, the outlines are given for the ideal situation in the long run.
A development plan covers the following aspects:
- the future business operations;
- the necessary transformation of the current business operations;
the order and coherence of the incremental transformation;
- the kind of IT applications required;
- the nature of the necessary infrastructure.
A development plan allows for some control
in times of rapid changes in a dynamic environment, in leading the change
processes in the course of change the company wishes to take. The desired
situation is roughly described on the basis of the business goals, without
defining a time span.
The incremental changes that are elaborated and realised, do not provide
ideal situations in the long run, but they are feasible situations in
the short term, that all contribute to realising the long-term goals.
Each feasible situation is tangible and can be realised within an acceptable
time span. The situations are defined in terms of given preconditions,
starting points and limitations. The feasibility in terms of quantity,
quality and time is tested for each step in the change process.
One step at a time
For each step in the change process a choice is made for either 'blueprint'
or 'growth', or for a hybrid form, so-called 'iterative development'.
Blueprint means: formally designing and realising the transformation
of the business processes, the IT applications and the IT infrastructure
in advance.
Growth means: providing the right people and resources (including
IT) to facilitate a transformation of certain business processes.
Iterative development means: building applications in a number
of iterative steps in consultation with the user, including the implementation
of the changes in the business processes. This works well in situations
in which the application and the corresponding business
process cannot be completely described in advance. Iterative development
is also a good way to test and introduce new IT infrastructure.
Each step can be executed like a project. As a result of the gradual,
step-by-step realisation, the necessary room remains available to respond
to unforeseen changes. This makes it possible to not only make interim
adaptations to the policy and the development plan, but to also execute
the detailed project plans step by step, with the necessary budgets,
people and resources.
Software building blocks
Recently, a new trend has developed in application building: the construction
of IT applications by means of software components. This is possible
through the use of object orientation and corresponding application
architectures. This orientation provides a parallel with the manufacturing
of so-called pre-fabricated houses. System developers assemble applications
from a set of 'building blocks". By combining building blocks,
new applications can be constructed relatively fast - often on a situational
basis. This makes it relatively easy to meet the need for certain IT
applications.
As a result, the strict separation between blueprint and growth becomes
vaguer. The approach is aimed at both creating company-specific software
building blocks and at purchasing generic software building blocks from
software vendors. The more specific and generic building blocks a company
has, the faster can applications be constructed. The specific custom
applications are easy to make, and easy to adapt - since they are flexibly
made out of building blocks. They will therefore more and more be developed
and changed in an iterative way. Only new building blocks are still
created from scratch. The other applications can be developed iteratively
in consultation with the user, or they will grow as users construct
their own applications from the available building blocks.
More and more applications will be a mixture between generic and specific,
since they will consist of both types of components.
A development plan helps to be able to determine in advance which
software building blocks will be needed in the applications to be realised.
Since the use of software building blocks enhances the flexibility of
applications, they are also important resources to be able to use the
development plan approach. In the realisation of large transformations
it is much easier to change existing applications or applications that
are still being developed.
Development plan versus blueprint
In figure 2.9 the differences between the development plan approach
and the conventional blueprint approach are summarised.
In the conventional blueprint approach, the development process for
an information system is
highly formalised. The present or desired situation is taken as the
starting point. The classic development starts with the formulation
of the information strategy, followed by the definition of the architecture
of the information system and the detailed description of the IT applications
(grouped into subsystems). Architecture and detailed descriptions form
the blueprint for the realisation of the IT applications and the IT
infrastructure. At the most, the building phase can be divided into
subprojects that focus on the IT applications per subsystem. This results
in a large, rather inflexible information system. The whole working
order is more or less linear. The development path must in fact be gone
through from the beginning to the end. Plans or detailed descriptions
can hardly be reversed. If at some stage it turns out that mistakes
were made at an earlier stage, or that the principles of for example
business operations are radically different, the development is in dire
straits.
Figure 2.9 Development plan versus blueprint.
The development plan approach corresponds well to the framework for
an integrated business and IT policy, described in section 2.7.1. The
combined business and IT strategy is the starting point for the definition
of a development plan. Thus, the realisation of the proper configuration
of the business operations and IT can be led in the right direction.
Strategy and development plan form the basis for more detailed plans
on a tactical level. The company draws up an incremental plan for the
changes. The various steps are gone through in the right order in the
form of projects. For each step the appropriate approach (blueprint,
growth, or iterative) is chosen, based on the situation and the right
people and resources are assembled to allow for the implementation of
the changes. Changes in the business operations can be executed by the
employees themselves. This particularly applies to the growth approach,
after the right infrastructure has become available. For more drastic
steps, a separate project organisation must be set up, with the task
of realising this step in the transformation.
Each change project designs and realises its own portion of change in
the business operations and the IT. All processes of policy making,
planning and change at the various levels take place on a constant basis
and with a continuous interaction. This way, the change process can
be controlled and adapted if the situation changes.
Development plans and collaborative systems
The development plan approach does not result in one large information
system, but in a business operation in the form of a flexible network
of people, resources and business processes. This business operation
is supported by a flexible network of IT applications consisting of
specific and generic software components. These applications are in
turn supported by an infrastructure in the form of a flexible computer
network. In short, a collaborative system of people and resources.
The development plan therefore goes very well with collaborative systems.
The approach combines the step-by-step construction of specific, formal
applications with the growth of generic, informal applications. In uncertain
situations, the iterative approach is used to realise the right applications
and infrastructure. At the same time, the IT infrastructure is allowed
to grow to such an extent that it offers sufficient room for all applications.
The development plan has to guarantee that the future integration into
one network of hardware and collaborative applications remains possible.
This way, the company deliberately and gradually goes through the learning
IT process. It is also prevented that investments are made into all
kinds of applications and hardware that turn out not to fit in the network
system.
The eventual result is one large IT platform for the entire company
or interorganisation. By
means of collaborative systems on this platform, large transformations
of the entire company are possible, for example logistics chain integration
or new forms of front-office and extended office in administrative environments.