CHAPTER 6: USING IT TO CATALYSE BUSINESS TRANSFORMATIONS

Introduction

This chapter revisits our introductory themes, and amplifies some of the points we made there in regard to the symbiotic (some would argue parasitic) link between business and IT. IS and IT may be painful to control and manage, and the long-standing belief that it is both expensive and under-performing, not to say unresponsive, often leads to IT being relegated to a subsidiary role, as we discussed, being engaged very late in strategic planning. The role of IT capabilities and deployment in making the transformations should not be underestimated.

Merger or acquisition

If, for example, your organisation is to be taken over, responsibility for the future of IT support to your business may be in the hands of the new owner. However, you will still need to think about business continuity to make sure that IT support to your business continues to be provided and managed during any transition period. The change facing ‘your IT’ might be a simple handover to new management, or it might be a much riskier move to equivalent IT systems already used by the new owners. Here, IT may well be considered to be a pain, but the situation can be turned to the advantage of both parties by thinking about new capabilities and business transformations that could be planned as part of the organisational changes that will inevitably follow.

Most often, merging businesses will involve merging IT providers (internal, external or a combination!). A useful checklist when in the merger/acquisition position follows:

• Is information provided accurately and on time?
• How many databases are in use in each business?
• Are the businesses content with their provider?
• How much does IT cost?
• Is IT perceived as poor value?
• How long does it take to develop new systems?
• Are they delivered on time, to budget, and are they reliable?
• Which IT organisation’s services are provided and used in the most coherent way?
• Which has a fragmented approach to applications and technology?
• What cultural differences will need to be resolved?
• Does one provider work to recognised standards and methods, such as IS020000, ISO27001, PRINCE2^®, and so on?
• Are there different skill sets?
• Will different technologies combine harmoniously?
• Is there a need for a single set of applications and a single technology platform – if so, how will it be achieved?
• What is the cost of parallel running of the IT organisations?
• Are the business processes different?
• Must they be rationalised – when and how?
• Are pay structures different – is this a problem?
• What is the strategic direction of the businesses?
• How are projects involving radical change managed now and will this change?
• Which business will need to adapt its IT most, e.g. to match strategic direction?
• Can IT expenditure be saved – where and how?
• Which business processes could be the focus for IT effort to deliver maximum value to the merged businesses?
• Which business skills must be developed by the new, merged IT function?
• Which IT skills should be developed by the business to create a true partnership with IT?
• Is a central IT function needed? Should it be organised to reflect the needs of the businesses?

Don’t forget to justify any proposals with a business case! Mergers and acquisitions are such an important consideration to change in modern times, that a separate appendix (Appendix 1) is included, with more discussions.

Defining requirements

To assist with making changes to the organisation as smooth as possible, you should try to define requirements and user acceptance criteria (what functions and operational issues a new service must satisfy, in order to be accepted by the business for operational use) by using one or more of the following:

• Business or business models
• Business threads
• Existing user procedures manuals
• System boundary definitions
• User task scenarios.

Business models

You can build a model of business activities after the change (or at least after the new IT application is delivered) which is not information system oriented. For example, you can use a soft systems approach to define the business processes that satisfy business goals, define monitoring, feedback and control mechanisms for these processes, and define processes to resolve conflicting goals.

Business threads

As part of the business or business model you can define what may be called ‘business threads’ which describe your key business processes, by following a case from its beginning to end. A business thread may take weeks or months to complete and ends in a payment, or other business objective.

Existing user procedure manuals

These are useful, provided that they actually represent what people do (very often they do not) and provided that they, or the new IT applications, will continue to do so after the new IT application is delivered.

System boundary definitions

From the documents described, you can define the boundary of an information system (or various possible information systems) needed to support the business activities, business threads and user procedures.

User task scenarios

Having defined a system boundary, you can define what may be called user task scenarios, which are the activities that a user will be expected to undertake in some form of short-term dialogue with the information system. One of the best ways to do this is by means of specific examples, which can be used as test cases in system testing and user acceptance testing.

Changing business capabilities

Every organisation will need new, or altered, IT capabilities, and to deploy IT differently as time goes on; as legislation is created; as mergers and acquisitions take place … the list goes on. You can use the conceptual model given in Figure 14 (first discussed in Chapter 1) and take a before-and-after perspective to help you to scope the areas of the business that are going to be changed. That will help to focus your attention on where the IT capabilities and IT deployment of the business may have to change. However, before you go too far down that track, you should link back to the business capabilities you will need and how much they will have to change from what you have now.

The business capabilities that a change is intended to create, or alter, should be clear from the motivation for the change, or, if not, it should, at least, be possible to identify the capability changes needed. You can again use the conceptual model in Figure 14 to help you to scope the changes. You may need professional help to carry out business analyses in order to fully identify the changes in business capabilities that you will need.

At this stage incidentally, you should be concentrating on business added value capabilities. If you have an IT service catalogue, you will know which IT services provide the IT capabilities; if you have a software inventory, you will know which IT applications provide the capabilities. Unless you are unlucky, you should find that there is a simple mapping between business capabilities and IT applications (unless you are very lucky, you will not find it so easy to map these to IT devices and networks!). If the information linking business capabilities to IT services and applications is not readily available, and if there isn’t a simple mapping, you will have to call in your internal IT experts, or outside consultants, to get this information.

For those business capabilities that do not have to change as a result of the proposals, you will be able to form an initial assessment of the IT applications that are likely to remain unchanged. From a knowledge of the business capabilities that are no longer needed, you will be able to deduce which IT applications are unlikely to be needed in the future. That leaves the trickier problem of new, or altered, business capabilities, that may need new, or altered, IT capabilities, which may, in turn, mean modifying existing IT applications, or developing, or acquiring, new applications (the various options for modification were discussed in Chapter 3).

It isn’t just IT applications that are designed to support particular business functions that you should consider. You also need to consider general purpose IT capabilities, such as e-mail, that you may already have, to assess whether you will still need them in the same way, and, if so, whether they need to be improved or modified – or sourced from the Cloud … For example, you may want your electronic mail system to be accessible to third-party personnel, who are either out on the road, or working from home. You may also need new generic IT capabilities, such as video conferencing at the desktop. E-mail is so ubiquitous that it is often overlooked as something that has been around for a long time; the fact is that it may still be a source for innovation and part of organisational change.

Sharing and integrating computerised information (to make information sharing easier within the business) is probably the single most important business capability/issue that IT should be facilitating. Often misconstrued as knowledge management, information sharing is a cornerstone of knowledge management and can be a driver for transforming the organisation

To make the change effective, you may need to increase the deployment of IT in support of particular business areas or support functions, such as personnel, development/management or marketing – or maybe all of these.

Opportunity

Now is the time to think about rectifying other problems with your existing IT capabilities. For example, if you know you will run out of IT capacity in six months, you should make sure a capacity upgrade is included in your requirements for IT change to support the business change. Neither the business nor the IT organisations should require alteration resulting from technology upgrades, though appropriate training to specific areas will be needed.

As another example, if you are dissatisfied with the control you have over your IT infrastructure, you should think about improving management as one of your IT change requirements. If you are locked in to a legacy application that no one dares change, which is actually stifling business improvement, now might be the time to take decisive action.

You should distinguish between wants and needs. If you ‘need’ certain new, or altered, IT capabilities to enable the rapid change, the chances are that you will need them from day one of the new business operation, so these changes must get priority. You may even need some of the capability during the change itself. You must be clear about what is needed when. If you only ‘want’ other changes to IT capabilities, maybe you can make do without them for a while, to give yourself more time to make the urgent changes work.

However, you must know where your IT is heading, if you are to harness it and make it play a full and successful part in the ongoing effectiveness of your business. Each successive change should be a step on the way to your IT of the future, not an advance down a blind alley.

Future proofing

You need to make sure your IS/IT planners have a target architecture for the IT applications and IT infrastructure to which they are working. New applications and new infrastructure should, wherever possible, be architecture-conformant, with the objectives of making it easy to:

• Change the portfolio of applications without having to change the underlying technology.
• Change the underlying technology without having to change the applications.
• Facilitate the interworking of applications and the sharing of data across the IT infrastructure and across the business, perhaps also with the partners of the business.

In times of radical change

A fundamental issue for business managers to consider in times of radical change is that organisational characteristics and information sources will be relatively unstable; fluctuating with changing conditions and as thinking evolves – perhaps even as new technology is acquired.

However, many of the core business processes and the underlying data are likely to be relatively stable, and once they are properly understood, the organisational characteristics and IT needed to conduct those aspects of the business become apparent. The most significant improvements are often made through examination and re-engineering of the business processes and data repositories, rather than through the restructuring of the business’s organisation and information flows.

Fundamental changes require lots of time, people, patience, cold towels, money, food and water. In times of change, time is often the component in shortest supply. Go for early, demonstrable wins, and easy targets. Introduce change progressively, concentrating on high-priority aspects.

Obtain blueprints for the new IT infrastructure

Unless your needs for new, or altered, IT capabilities result in simple and straightforward changes to the IT infrastructure, you will probably find it helpful to get your IT planners to formulate a series of blueprints for the IT infrastructure. These blueprints will cover the major milestones in the transformation of the IT infrastructure, from supporting the pre-change business, through the change itself, into ‘what we must have’ to bring the change into operation, through to a steady state in which the IT infrastructure is brought into an optimised state for the new business and developed as the new business needs evolve.