Management Information Systems Assignment

CHAPTER

12 System build, implementation and

maintenance: change management

LEARNING OUTCOMES

After reading this chapter, you will be able to:

■ state the purpose of the build phase, and its difference from changeover and implementation;

■ specify the different types of testing required for a system;

■ select the best alternatives for changing from an old system to a new system;

■ recognise the importance of managing software, IS and organisational change associated with the introduction of a new BIS.

MANAGEMENT ISSUES

Eff ective systems implementation is required for a quality system to be installed with minimal disruption to the business. From a mana- gerial perspective, this chapter addresses the following questions:

■ How should the system be tested?

■ How should data be migrated from the old system to the new system?

■ How should the changeover between old and new systems be managed?

■ How can the change to a process-oriented system be managed?

CHAPTER AT A GLANCE

MAIN TOPICS

■ System build and implementation 440

■ Maintenance 448

■ Change management 450

CASE STUDIES

12.1 Business-process management (BPM) 458

12.2 Play pick-and-mix to innovate with SOA 463

M12_BOCI6455_05_SE_C12.indd 439 10/13/14 5:56 PM

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT440

System build occurs after the system has been designed. It refers to the creation of software using programming or incorporation of building blocks such as existing software components or libraries. The main concern of managers in the system build phase is that the system be adequately tested to ensure it meets the requirements and design specifications developed as part of the analysis and design phases. They will also want to closely monitor errors generated or identified in the build phase in order to control on-time delivery of the system. System implementation follows the build stage. It involves setting up the right environment in which the test and finished system can be used. Once a test version of the software has been produced, this will be tested by the users and corrections made to the software followed by further testing and fixing until the software is suitable for use throughout the company.

Maintenance deals with reviewing the IS project and recording and acting on problems with the system.

Change management in this chapter is considered at the level of software, information systems and the organisation. Software change management deals with meeting change requests or variations to requirements that arise during the systems development project from business managers, users, designers and programmers. IS change management deals with the migration from an old to a new IS system. Organisational change management deals with managing changes to organisational processes, structures and their impact on organisational staff and culture. Business process management (BPM) provides an approach to this challenge.

INTRODUCTION

System build

The creation of software by programmers involving programming, building release versions of the software and testing by programmers and end-users. Writing of documentation and training may also occur at this stage.

System implementation

Involves the transition or changeover from the old system to the new and the prepararion for this, such as making sure the hardware and network infrastructure for a new system are in place, testing of the system and also human issues of how best to educate and train staff who will be using or affected by the new system.

Maintenance

This deals with reviewing the IS project and recording and acting on problems with the system.

Change management

The management of change which can be considered at the software, information system and organisational levels.

SYSTEM BUILD AND IMPLEMENTATION

System development, which includes programming and testing, is the main activity that occurs at the system build phase.

The coverage of programming in this book will necessarily be brief, since the technical details of programming are not relevant to business people. A brief coverage of the techniques used by programmers is given since a knowledge of these techniques can be helpful in managing technical staff. Business users also often become involved in end-user development, which requires an appreciation of programming principles.

Software consists of program code written by programmers that is compiled or built into files known as ‘executables’ from different modules, each with a particular function. Executables are run by users as interactive programs. You may have noticed application or executable files in directories on your hard disk with a file type of ‘.exe’ , such as winword. exe for Microsoft Word, or ‘.dll’ library files.

There are a number of system development tools available to programmers and business users to help in writing software. Software development tools include:

■ Third-generation languages (3GLs) include Basic, Pascal, C, COBOL and Fortran. These involve writing programming code. Traditionally this was achieved in a text editor with limited support from other tools, since these languages date back to the 1960s. These languages are normally used to produce text-based programs rather than interactive graphical user interface programs that run under Microsoft Windows. They are, however, still used extensively in legacy systems, in which there exist millions of lines of COBOL code that must be maintained.

System development

M12_BOCI6455_05_SE_C12.indd 440 10/13/14 5:56 PM

441ChaPter 12 SYSTEM BUILD, IMPLEMENTATION AND MAINTENANcE: chANgE MANAgEMENT

■ Fourth-generation languages (4GLs) were developed in response to the difficulty of using 3GLs, particularly for business users. They are intended to avoid the need for programming. Since they often lack the flexibility for building a complex system, they are often ignored.

■ Visual development tools such as Microsoft Visual Studio, Visual Basic and Visual C++ use an ‘interactive development environment’ that makes it easy to define the user interface of a product and write code to process the events generated when a user selects an option from a menu or button. They are widely used for prototyping and some tools such as Visual Basic for Applications are used by end-users for extending spreadsheet models. These tools share some similarities with 4GLs, but are not true application generators since programming is needed to make the applications function. Since they are relatively easy to use, they are frequently used by business users.

■ CASE or computer-aided software engineering tools (see Chapter 11 for coverage of CASE tools) are primarily used by professional IS developers and are intended to assist in managing the process of capturing requirements, and converting these into design and program code.

Computer-aided software engineering (CASE) tools

Primarily used by professional IS developers to assist in managing the process of capturing requirements, and converting these into design and program code. Software metrics are used by businesses developing information systems to establish the

quality of programs in an attempt to improve customer satisfaction through reducing errors by better programming and testing practices. Software or systems quality is measured according to its suitability for the job intended. This is governed by whether it can do the job required (Does it meet the business requirements?) and the number of bugs it contains (Does it work reliably?). The quality of software is dependent on two key factors:

1. the number of errors or bugs in the software; 2. the suitability of the software to its intended purpose, i.e. does it have the features

identified by users which are in the requirements specification?

It follows that good-quality software must meet the needs of the business users and contain few errors. We are trying to answer questions such as:

■ Does the product work? ■ Does it crash? ■ Does the product function according to specifications? ■ Does the user interface meet product specifications and is it easy to use? ■ Are there any unexplained or undesirable side-effects to using the product which may

stop other software working?

The number of errors is quite easily measured, although errors may not be apparent until they are encountered by end-users. Suitability to purpose is much more difficult to quantify, since it is dependent on a number of factors. These factors were referred to in detail earlier (in Chapters 8 and 11) which described the criteria that are relevant to deciding on a suitable information system. These quality criteria include correct functions, speed and ease of use.

Assessing software quality

Software or systems quality

Measures software quality according to its suitability for the job intended. This is governed by whether it can do the job required (Does it meet the business requirements?) and the number of bugs it contains (Does it work reliably?).

What is a bug? Problems, errors or defects in software are collectively known as ‘bugs’, since they are often small and annoying! Software bugs are defects in a program which are caused by human error during programming or earlier in the lifecycle. They may result in major faults

Software bug

Software bugs are defects in a program which are caused by human error during programming or earlier in the lifecycle. They may result in major faults or may remain unidentified.

M12_BOCI6455_05_SE_C12.indd 441 10/13/14 5:56 PM

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT442

Software quality also involves an additional factor which is not concerned with the functionality or number of bugs in the software. Instead, it considers how well the software operates in its environment. For example, in a multitasking environment such as Microsoft Windows, it assesses how well a piece of software coexists with other programs. Are resources shared evenly? Will a crash of the software cause other software to fail also? This type of interaction testing is known as ‘behaviour testing’.

Software metrics

Software metrics have much in common with measures involved with assessing the quality of a product in other industries. For example, in engineering or construction, designers want to know how long it will take a component to fail or the number of errors in a batch of products. Most measures are defect-based, measuring the number and type of errors. The source of the error and when it was introduced into the system are also important. Some errors are the result of faulty analysis or design and many are the result of a programming error. By identifying and analysing the source of the error, improvements can be made to the relevant part of the software lifecycle. An example of a comparison of three projects in terms of errors is shown in Table 12.1. It can be seen that in Project 3, the majority of errors are introduced during the coding (programming) stage, so corrective action is necessary here.

While the approach of many companies to testing has been that bugs are inevitable and must be tested for to remove them, more enlightened companies look at the reasons for the errors and attempt to stop them being introduced by the software developers. This implies that longer should be spent on the analysis and design phases of a project. Johnston (2003) suggests that the balance between the phases of a project should be divided as shown in Table 12.2, with a large proportion of the time being spent on analysis and design.

In software code the number of errors or ‘defect density’ is measured in terms of errors per 1000 lines of code (or KLOC for short). The long-term aim of a business is to reduce the defect rate towards the elusive goal of ‘zero defects’.

Errors per KLOC is the basic defect measure used in systems development. Care must be taken when calculating defect density or productivity of programmers using KLOC, since this will vary from one programming language to another and according to the style of the programmer and the number of comment statements used. KLOC must be used consistently between programs, and this is usually achieved by only counting executable statements, not comments, or by counting function points (function point analysis is covered in Chapter 9).

or may remain unidentified. A major problem in a software system can be caused by one wrong character in a program of tens of thousands of lines. So it is often the source of the problem that is small, not its consequences.

Computing history recalls that the first bug was a moth which crawled inside a valve in one of the first computers, causing it to crash! This bug was identified by Grace Hopper, the inventor of COBOL, the first commercial programming language.

Software metrics

Measures which indicate the quality of software.

Table 12.1 Table comparing the source of errors in three different software projects

Project 1 Project 2 Project 3

Analysis 20% 30% 15%

Design 25% 40% 20%

Coding 35% 20% 45%

Testing 20% 10% 20%

Errors per KLOC

Errors per KLOc (thousand lines of code) is the basic defect measure used in systems development.

M12_BOCI6455_05_SE_C12.indd 442 10/13/14 5:56 PM

443ChaPter 12 SYSTEM BUILD, IMPLEMENTATION AND MAINTENANcE: chANgE MANAgEMENT

A significant activity of the build phase is to transfer the data from the old system to the new system. Data migration is the transfer of data from the old system to the new system. When data are added to a database, this is known as ‘populating the database’. One method of transferring data is to rekey manually into the new system. This is impractical for most systems since the volume of data is too large. Instead, special data conversion programs are written to convert the data from the data file format of the old system into the data file format of the new system. Con-version may involve changing data formats, for example a date may be converted from two digits for the year into four digits. It may also involve combining or aggregating fields or records. The conversion programs also have to be well tested because of the danger of corrupting existing data. Data migration is an extra task which needs to be remembered as part of the project manager’s project plan. During data migration data can be ‘exported’ from an old system and then ‘imported’ into a new system.

When using databases or off-the-shelf software, there are usually tools provided to make it easier to import data from other systems.

The technical quality of software can also be assessed by measures other than the number of errors. Its complexity, which is often a function of the number of branches it contains, is commonly used.

Another metric, more commonly used for engineered products, is the mean time between failures. This is less appropriate to software since outright failure is rare, but small errors or bugs in the software are quite common. It is, however, used as part of outsourcing contracts or as part of the service-level agreement for network performance.

A more useful measure for software is to look at the customer satisfaction rating of the software, since its quality is dependent on many other factors such as usability and speed as well as the number of errors.

Table 12.2 Ideal proportions of time to be spent on different phases of a systems development project, focusing on details of build phase

Project activities Suggested proportion

Definition, design and planning 20%

Coding 15%

Component test and early system test 15%

Full system test, user testing and operational trials 20%

Documentation, training and implementation support 20%

Overall project management 10%

Data migration

Data migration is the transfer of data from the old system to the new system. When data are added to a database, this is known as populating the database.

Import and export

Data can be ‘exported’ from an old system and then ‘imported’ into a new system.

Testing is a vital aspect of implementation, since this will identify errors that can be fixed before the system is live. The type of tests that occur in implementation tend to be more structured than the ad hoc testing that occurs with prototyping earlier in systems development.

Note that often testing is not seen as an essential part of the lifecycle, but as a chore that must be done. If its importance is not recognised, insufficient testing will occur. Johnston (2003) refers to the ‘testing trap’, when companies spend too long writing the software without changing the overall project deadline. This results in the amount of time for testing being ‘squeezed’ until it is no longer sufficient.

Testing information systems

Data migration

M12_BOCI6455_05_SE_C12.indd 443 10/13/14 5:56 PM

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT444

During prototyping, the purpose of testing is to identify missing features or define different ways of performing functions. Testing is more structured during the implementation phase in order to identify as many bugs as possible. It has two main purposes: the first is to check that the requirements agreed earlier in the project have been implemented, the second is to identify errors or bugs. To achieve both of these objectives, testing must be conducted in a structured way by using a test specification which details tests in different areas. This avoids users’ performing a general usability test of the system where they only use common functions at random. While this is valid, and is necessary since it mirrors real use of the software, it does not give a good coverage of all the areas of the system. Systematic tests should be performed using a test script which covers, in detail, the functions to be tested.

Test specification

A detailed description of the tests that will be performed to check the software works correctly.

Test plan

Plan describing the type and sequence of testing and who will conduct it.

Jim Goodnight: crunching the numbers By Michael Dempsey

Addressing a recent business intelligence conference in London, Jim Goodnight’s considered responses and soft Southern drawl left the impression of a thoughtful figure who just happens to be chief executive of a $1.34bn business.

His taciturn aspect changed when the absolute quality of his company’s software was raised. ‘SAS is still quicker and better’, he states.

Despite the waves of re-labelling that have allowed his business to surf through management information systems and data warehousing to reach today’s focus on business intelligence and performance management, Mr Goodnight defines SAS in the light of a very old-fashioned customer grouse. ‘When we ship software, it’s almost bug-free. We learnt about doing that the hard way, many years ago.’

During the 1980s, SAS released some software before it was fully tested and provoked a vocal reaction from the users. ‘They let us know what was wrong with it.’ He jokes about the number of bugs that are still found in other large commercial systems and then generously redeems his competitors with the remark ‘but then we do so much more testing’.

Mini case study

Source: Dempsey, M. (2005) Jim Goodnight: crunching the numbers. Financial Times. 23 March. © The Financial Times Limited 2005. All Rights Reserved.

Given the variety of tests that need to be performed, large implementations will also use a test plan, a specialised project plan describing what testing will be performed when, and by whom. Testing is always a compromise between the number of tests that can be performed and the time available.

The different types of testing that occur throughout the software lifecycle should be related to the earlier stages in the lifecycle against which we are testing. This approach to development (Figure 12.1) is sometimes referred to as the ‘V-model of systems development’, for obvious reasons. The diagram shows that different types of testing are used to test different aspects of the analysis and design of the system: to test the requirements specification a user acceptance test is performed, and to test the detailed design unit testing occurs.

We will now consider in more detail the different types of testing that need to be conducted during implementation. This review is structured according to who performs the tests.

M12_BOCI6455_05_SE_C12.indd 444 10/13/14 5:56 PM

445ChaPter 12 SYSTEM BUILD, IMPLEMENTATION AND MAINTENANcE: chANgE MANAgEMENT

Developer tests

There are a variety of techniques that can be used for testing systems. Jones (2008) identifies 18 types of testing, of which the most commonly used are subroutine, unit, new function, regression, integration and systems testing. Many of the techniques available are not used due to lack of time, money or commitment. Some of the more common techniques are summarised here.

n Module or unit tests. These are performed on individual modules of the system. The module is treated as a ‘black box’ (ignoring its internal method of working) as developers check that expected outputs are generated for given inputs. When you drive a car this can be thought of as black box testing – you are aware of the inputs to the car and their effect as outputs, but you will probably not have a detailed knowledge of the mechanical aspects of the car and whether they are functioning correctly. Module testing involves considering a range of inputs or test cases, as follows: (a) Random test data can be automatically generated by a spreadsheet for module

testing. (b) Structured or logical test data will cover a range of values expected in normal use of

the module and also values beyond designed limits to check that appropriate error messages are given. This is also known as ‘boundary value testing’ and is important, since many bugs occur because designed boundaries are crossed. This type of data is used for regression testing, explained below.

(c) Scenario or typical test data use realistic example data, possibly from a previous system, to simulate day-to-day use of the system.

These different types of test data can also be applied to system testing.

n Integration or module interaction testing (black box testing). Expected interactions such as messaging and data exchange between a limited number of modules are assessed. This can be performed in a structured way, using a top-down method where a module calls other module functions as stubs (partially completed functions which should return expected values) or using a bottom-up approach where a driver module is used to call complete functions.

n New function testing. This commonly used type of testing refers to testing the operation of a new function when it is implemented, perhaps during prototyping. If testing is

Figure 12.1 The V-model of systems development relating analysis and design activities to testing activities

Initiation Implementation review

Requirements specification

User acceptance test

Overall design System test

Detailed design Unit test

Code

Module or unit testing

Individual modules are tested to ensure they function correctly for given inputs.

M12_BOCI6455_05_SE_C12.indd 445 10/13/14 5:56 PM

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT446

limited to this, problems may be missed since the introduction of the new function may cause bugs elsewhere in the system.

n System testing. When all modules have been completed and their interactions assessed for validity, links between all modules are assessed in the system test. In system testing, interactions between all relevant modules are tested systematically. System testing will highlight different errors to module testing, for example when unexpected data dependencies exist between modules as a result of poor design.

n Database connectivity testing. This is a simple test that the connectivity between the application and the database is correct. Can a user log in to the database? Can a record be inserted, deleted or updated, i.e. are transactions executing? Can transactions be rolled back (undone) if required?

n Database volume testing. This is linked to capacity planning of databases. Simulation tools can be used to assess how the system will react to different levels of usage anticipated from the requirements and design specifications. Methods of indexing may need to be improved or queries optimised if the software fails this test.

n Performance testing. This will involve timing how long different functions or transactions take to occur. These delays are important, since they govern the amount of wasted time users or customers have to wait for information to be retrieved or screens refreshed. Maximum waiting times may be specified in a contract, for example.

n Confidence test script. This is a short script which may take a few hours to run through and which tests all the main functions of the software. It should be run before all releases to users to ensure that their time is not wasted on a prototype that has major failings which mean the test will have to be aborted and a new release made.

n Automated tests. Automated tools simulate user inputs through the mouse or keyboard and can be used to check for the correct action when a certain combination of buttons is pressed or data entered. Scripts can be set up to allow these tests to be repeated. This is particularly useful for performing regression tests.

n Regression testing. This testing should be performed before a release to ensure that the software performance is consistent with previous test results, i.e. that the outputs produced are consistent with previous releases of the software. This is necessary, as in fixing a problem a programmer may introduce a new error that can be identified through the regression test. Regression testing is usually performed with automated tools.

End-user tests

The purpose of these is twofold: first, to check that the software does what is required; and second, to identify bugs, particularly those that may only be caused by novice users.

For ease of assessing the results, the users should be asked to write down for each bug or omission found:

1. module affected; 2. description of problem (any error messages to be written in full); 3. relevant data – for example, which particular customer or order record in the database

caused the problem; 4. severity of problem on a three-point scale.

Different types of end-user tests that can be adopted include:

n Scenario testing. In an order processing system this would involve processing example orders of different types, such as new customers, existing customers without credit and customers with a credit agreement.

n Functional testing. Users are told to concentrate on testing particular functions or modules such as the order entry module in detail, either following a test script or working through the module systematically.

Volume testing

Testing assesses how system performance will change at different levels of usage.

Regression testing

Testing performed before a release to ensure that the software performance is consistent with previous test results, i.e. that the outputs produced are consistent with previous releases of the software.

Functional testing

Testing of particular functions or modules either following a test script or working through the module systematically.

System testing

When all modules have been completed and their interactions assessed for validity, links between all modules are assessed in the system test. In system testing, interactions between all relevant modules are tested systematically.

M12_BOCI6455_05_SE_C12.indd 446 10/13/14 5:56 PM

447ChaPter 12 SYSTEM BUILD, IMPLEMENTATION AND MAINTENANcE: chANgE MANAgEMENT

n General testing. Here, users are given free rein to depart from the test specification and test according to their random preferences. Sometimes this is the only type of testing used, which results in poor coverage of the functions in the software!

n Multi-user testing. The effect of different users accessing the same customer or stock record. Software should not permit two users to modify the same data at the same time. Tests should also be made to ensure that users with different permissions and rules are treated as they should be, e.g. that junior staff are locked out of company financial information.

n Inexperienced user testing. Staff who are inexperienced in the use of software often make good ‘guinea pigs’ for testing software, since they may choose an illogical combination of options that the developers have not tested. This is surprisingly effective and is a recommended method of software testing. The staff involved often also like the power of being able to ‘break’ the software.

n User acceptance testing. This is the final stage of testing which occurs before the software is signed off as fit for purpose and the system can go live. Since the customer will want to be sure the software works correctly, this may take a week or more.

n Alpha and beta testing. These terms apply to user tests which occur before a packaged software product is released. They are described in the section on configuration management later in this chapter.

Benefits-based testing

An alternative approach to testing is not to focus only on the errors when reviewing a system, but rather to test against the business benefits that the system confers. A system could be error-free, but if it is not delivering benefits then its features may not have been implemented correctly. This approach can be used with prototyping, so that if a system is not delivering the correct features it can be modified. When undertaking structured testing, the software will be tested against the requirements specification to check that the desired features are present.

Testing environments

Testing occurs in different environments during the project. At an early stage prototypes may be tested on a single standalone machine or laptop. In the build phase, testing will be conducted in a development environment, which involves programmers’ testing data across a network on a shared server. This is mainly used for module testing. In the implementation phase, a special test environment will be set up which simulates the final operating environment for the system. This could be a room with three or more networked machines accessing data from a central server. This test environment will be used for early user training and testing and for system testing. Finally, the production or live environment is that in which the system will be used operationally. This will be used for user acceptance testing and when the system becomes live. When a system goes live, it is worth noting that there may still be major problems despite extensive testing.

Multi-user testing

The effect of different users accessing the same customer or stock record is tested. Software should not permit two users to modify the same data at the same time.

User acceptance testing

This is the final stage of testing which occurs before the software is signed off as fit for purpose and the system can go live.

Test environment

A specially configured environment (hardware, software and office environment) used to test the software before its release.

Live (production) environment

The term used to describe the setup of the system (hardware, software and office environment) where the software will be used in the business.

Producing documentation occurs throughout the software lifecycle, such as when requirements are specified at the analysis stage, but it becomes particularly import-ant at the implementation and maintenance stages of a project. At this stage user guides will be used as part of user acceptance testing and system developers will refer to design documents when updating the system. The main types of documentation required through the project are referred to in Figure 12.1. The important documentation used at the testing stage includes:

n the requirements specification produced at the analysis stage; this is used in the user acceptance test, to check that the correct features have been implemented;

Documentation

Documentation

Software documentation refers to end-user guidance such as the user guide and technical maintenance documentation such as design and test specifications.

M12_BOCI6455_05_SE_C12.indd 447 10/13/14 5:56 PM

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT448

n the user manual, which will be used during testing and operational use of the system by business users;

n the design specification, which will be used during system testing and during maintenance by developers;

n the detailed design, which will be used in module testing and during maintenance; n the data dictionary or database design, which will be used in testing and maintenance by

database administrators and developers; n detailed test plans and test specifications, which will be used as part of developer and

user testing; n quality assurance documents such as software change request forms, which will be used

to manage the change during the build and implementation phases.

The writing of documentation is often neglected, since it tends to be less interesting than developing the software. To ensure that it is produced, strong project management is necessary and the presence of a software quality plan will make sure that time is spent on documentation, since a company’s quality standard is assessed on whether the correct documentation is produced.

Example of a user guide structure User guides are normally structured to give a gradual introduction to the system, and there may be several guides for a single system. A common structure is:

1. A brief introductory/overview guide, often known as ‘Getting started’. The aim of this is to help users operate the software productively with the minimum of reading. The introductory section will also explain the purpose of the system for the business.

2. Tutorial guide. This will provide lessons, often with example data to guide the user through using the package. These are now often combined with online ‘guided tours’.

3. Detailed documentation is often structured according to the different screens in an application. However, it is usually better to structure such guides according to the different functions or applications a business user will need. Chapter titles in such an approach might include ‘How to enter a new sales order’ or ‘How to print a report’. This guide should also incorporate information on trouble-shooting when problems are encountered.

4. Quick reference guide, glossary and appendix. These will contain explanations of error messages and a summary of all functions and how to access them.

User guides

The user guide has become a less important aspect of systems documentation with the advent of online help such as the help facility available with Windows applications and web-site-based help. Online help can give general guidance on the software, or it can give more specific advice on a particular screen or function – when it is known as ‘context- sensitive’. It is often a good idea to ask business users to develop the user guide, since if programmers write the guide it will tend to be too technical and not relevant to the needs of users. Since business users are sometimes charged with producing a user guide, approaches to structuring these is covered in a little more detail.

MAINTENANCE

The maintenance phase of a project starts when the users sign off the system during testing and it becomes a live production system. After a system is live, there are liable to be some errors that were not identified during testing and need to be remedied. When

M12_BOCI6455_05_SE_C12.indd 448 10/13/14 5:56 PM

449ChaPter 12 SYSTEM BUILD, IMPLEMENTATION AND MAINTENANcE: chANgE MANAgEMENT

problems are encountered, this presents a dilemma to the system manager, since they will have to balance the need for a new release of the system against the severity of an error. It is not practical or cost-effective to introduce a new release of the software for every bug found, since each release needs to be tested and installed and fresh problems may exist in the new system. Most systems managers would aim not to make frequent, immediate releases to correct problems because of the cost and disruption this causes. Instead, faults will be recorded and then fixed in a release that solves several major problems. This is known as a maintenance release and it might occur at monthly, six-monthly or yearly intervals according to the stability of the system. This is usually a function of the age of the system – new systems will have more errors and will need more frequent maintenance releases.

With the advent of customer-facing e-commerce systems that need to be available 24 hours a day, 7 days a week for 365 days a year, periodic maintenance releases are not appropriate. Significant problems must be rectified immediately with the minimum of disruption. In 2001 Barclays Bank was censured by the UK advertising standard authority for suggesting in their television adverts that their systems were continuously available 24 hours per day. In fact, some users of their system complained that it was not available for a short period after midnight each night due to maintenance. Consequently Barclays had to change the advert, and may eventually change their approach to maintenance.

Maintenance releases will not only fix problems, but may also include enhancements or new features requested by users.

Major and minor releases are denoted by the release or version number. If a system changes from version 1.1 to 2.0, this will be a major release. When moving from version 2.0 to 2.1, some new features might be involved. From version 2.1 to 2.1.1 might represent a patch or interim release to correct problems.

To help make the decision of installing a new release to correct the problem, a scale of severity of the fault is used by companies to govern what action is required. Such a scale may form part of the contract if a company has outsourced its systems development to a third party. An example of such a scale is shown in Table 12.3.

Most systems now have a modular design such that it is not necessary to reinstall the complete system if an error is encountered – rather the module where the error lies can be replaced. This is described in a rather primitive way as applying a patch to the system. Patches to off-the-shelf systems are now available for download over the Internet. Because

Maintenance

Maintenance occurs after the system has been signed off as suitable for users. It involves reviewing the project and recording and acting on problems with the system.

Table 12.3 Fault taxonomy described in Jorgenson (1995)

Category example action

Mild Misspelt word Ignore or defer to next major release

Moderate Misleading or redundant information Ignore or defer to next major release

Annoying Truncated text Defer to next major release

Disturbing Some transactions not processed correctly, intermittent crashes in one module

Defer to next maintenance release

Serious Lost transactions Defer to next maintenance release may need immediate fix and release

Very serious Crash occurs regularly in one module Immediate solution needed

Extreme Frequent, very serious errors Immediate solution needed

Intolerable Database corruption Immediate solution needed

Catastrophic System crashes, cannot be restarted – system unusable

Immediate solution needed

Infectious Catastrophic problem also causes failure of other systems

Immediate solution needed

Software patch

This is an interim release of part of an information system that is intended to address deficiencies in a previous release.

M12_BOCI6455_05_SE_C12.indd 449 10/13/14 5:56 PM

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT450

CHANGE MANAGEMENT

The main activities undertaken by a manager of systems development projects are essentially concerned with managing change. Managing change takes different forms. First, we will look at managing technical changes to the software requirements as the system is developed through prototyping and testing. We will then look at how organisations can manage the transition or changeover to a new information system from an old system. Another important aspect of change we will review is how the introduction of a new system can affect the business users and action that can be taken to manage this organisational change. The role of organisational culture in influencing this will also be considered.

At each stage of a systems development project, change (modification) requests or variations to requirements will arise from business managers, users, designers and programmers. These requests include reports of bugs and of features that are missing from the system as well as ideas for future versions of the software.

These requests will occur as soon as users start evaluating prototypes of a system and will continue through to the maintenance phase of the project when the system has gone live. As the users start testing the system in earnest in the implementation phase, these requests will become more frequent and tens or possibly hundreds will be generated each week. This process of change needs to be carefully managed, since otherwise it can develop into requirements creep, a problem on many information systems projects. As the number of requirements grows, more developer time will be required to fix the problems and the project can soon spiral out of control. What is needed is a mechanism to ensure, first, that all the changes are recorded and dealt with, and second, that they are reviewed in such a way that the number of changes does not become unmanageable.

Software change management

Change (modification) requests

A modification to the software thought to be necessary by the business users or developers.

A post-implementation review or project closedown review occurs several months after the system has gone live. Its purpose is to assess the success of the new system and decide on any necessary corrective action. The review could include the following:

n faults and suggested enhancements with agreement on which need to be implemented in a future release;

n success of system in meeting its budget and timescale targets; n success of system in meeting its business requirements – has it delivered the anticipated

benefits described in the feasibility study? n development practices that worked well and poorly during the project.

An additional reason for performing a post-implementation review is so that lessons can be learnt from the project. Good practices can be applied to future projects and attempts made to avoid techniques which failed.

Post-implementation review

Post-implementation review

A meeting that occurs after a system is operational to review the success of the project.

of the competitive pressures of releasing software as soon as possible, a large number of off-the-shelf packages require some sort of patch. For example, web browser software such as Netscape Navigator and Microsoft Internet Explorer has required frequent patches to correct errors in the security of the browser which permit unauthorised access to the computer on which the browser is running.

M12_BOCI6455_05_SE_C12.indd 450 10/13/14 5:56 PM

451ChaPter 12 SYSTEM BUILD, IMPLEMENTATION AND MAINTENANcE: chANgE MANAgEMENT

The main steps in managing changed requirements are:

1. Record the change requests, indicating level of importance and module affected. 2. Prioritise them with the internal or external customer as ‘must have’, ‘nice to have’ or

‘later release’ (Priority 1, 2 or 3). This will be done with reference to the project con- straints of system quality, cost and timescale.

3. Identify responsibility for fixing the problem, since it may lie with a software house, internal IS staff, systems integrator or hardware vendor.

4. Implement changes that are recorded as high-priority. 5. Maintain a check of which high-priority errors have been fixed.

When a system is being implemented, it is useful to have a three-way classification of errors to be fixed, since this highlights the errors or missing features that must be implemented and avoids long discussions of the merits of each solution.

When the system is live, a more complex classification is often used to help in deciding how to ‘escalate’ problems up the hierarchy according to their severity. This could be structured as follows:

1. Critical problem, system not operational. This may occur due to power or server failure. Level 1 problems need to be resolved immediately, since business users cannot access the system at all. With customer-facing applications such as e-commerce systems, this type of problem needs to be corrected as soon as possible since every minute the system is not working transaction revenue is lost.

2. Critical problem, making part of the system unusable or causing data corruption. These would normally need to be resolved within 12 to 24 hours, depending on the nature of the problem.

3. Problem causing intermittent system failure or data corruption. Resolve within 48 hours. 4. Non-severe problem not requiring modification to software until next release. 5. Trivial problem or suggestion which can be considered for future releases.

If the system has been tailored by a systems integrator, these will be their responsibility to fix and this will be specified in the contract or service-level agreement (SLA), together with the time that will be taken for the change to be made. If the system has been developed or tailored internally by the IS department or even within a department, an SLA is still a good idea. If the problem occurs from a problem with packaged software, you will have to hope that an update release that solves the problem is available; if not, you will have to lobby the supplier for one.

Software quality assurance

As we have seen, procedures should be followed throughout the software lifecycle to try to produce good-quality systems. These quality assurance (QA) procedures have been formalised in the British Standard BS 5750 Part 1 and its international equivalent ISO 9001 (TickIT). These procedures do not guarantee a quality information system, but their purpose is to ensure that all relevant parts of the software lifecycle, such as requirements capture, design and testing, are carried out consistently. Business users can ask whether suppliers have quality accreditation as a means of distinguishing between them. QA procedures would not specify a particular method for design or testing, but they would specify how the change was managed by ensuring that all changes to requirements are noted and that review mechanisms are in place to check that changes are agreed and acted on accordingly.

If a business buys software services from a company that has achieved the quality standards, then there is less risk of the services’ being inadequate. For a company to achieve a quality standard it has to be assessed by independent auditors and if successful it will be audited regularly.

M12_BOCI6455_05_SE_C12.indd 451 10/13/14 5:56 PM

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT452

Choosing the method to be used for migrating or changing from the old system to the new system is one of the most important decisions that the project management team must make during the implementation phase. Changeover can be defined as moving from the old information system to the new information system. Note that this changeover is required whether the previous information system is computer- or paper-based. Before considering the alternatives, we will briefly discuss the main factors that a manager will consider when evaluating them. The factors are:

n Cost. This is, of course, an important consideration, but the quality of the new system is often more important.

Configuration management: builds and release versions

Configuration management is control of the different versions of software and program source code used during the build, implementation and maintenance phases of a project.

Throughout the implementation phase, updated versions of the software are released to users for testing. Before software can be used by users it needs to be released as an executable, built up from compiled versions of all the program code modules that make up the system. The process of joining all the modules is technically known as the linking or build process. The sequence can be summarised as:

1. programmers write different code modules; 2. completed code modules are compiled to form object modules; 3. object modules are linked to form executables; 4. executables are installed on machines; 5. executables are loaded and run by end-users testing the software.

Each updated release of the software is therefore usually known as a new ‘build’. With large software systems there will be hundreds of program files written by different developers that need to be compiled and then linked. If these files are not carefully tracked, then the wrong versions of files may be used, with earlier versions causing bugs. This process of version control is part of an overall process known as configuration management, which ensures that programming and new releases occur in a systematic way. One of the problems with solving the millennium bug was that in some companies configuration management was so poor that the original program code had been lost!

During the build phase, updated software versions will become more suitable for release as new functions are incorporated and the number of bugs is reduced. Some companies, such as Microsoft, call these different versions ‘release candidates’, others use the terminology alpha, beta and gold to distinguish between versions. These terms are often applied to packaged software, but can also be applied to bespoke business applications.

n Alpha releases and alpha testing. Alpha releases are preliminary versions of the software released early in the build phase. They usually have the majority of the functionality of the complete system in place, but may suffer from extensive bugs. The purpose of alpha testing is to identify these bugs and any major problems with the functionality and usability of the software. Alpha testing is usually conducted by staff inside the organisation developing the software or by favoured customers.

n Beta releases and beta testing. Beta releases occur after alpha testing and have almost complete functionality and relatively few bugs. Beta testing will be conducted by a range of customers who are interested in evaluating the new software. The aim of beta testing is to identify bugs in the software before it is shipped to all customers.

n Gold release. This is a term for the final release of the software which will be shipped to all customers.

Configuration management

Procedures that define the process of building a version of the software from its constituent program files and data files.

Alpha release

Alpha releases are preliminary versions of the software released early in the build process. They usually have the majority of the functionality of the system in place, but may suffer from extensive bugs.

Alpha testing

The purpose of ‘alpha testing’ is to identify bugs and any major problems with the functionality and usability of the software. Alpha testing is usually conducted by staff inside the organisation developing the software or by favoured customers.

Beta release

Beta releases occur after alpha testing and have almost complete functionality and relatively few bugs.

Beta testing

Will be conducted by a range of customers who are interested in evaluating the new software. The aim of beta testing is to identify bugs in the software before it is shipped to a range of customers.

IS change management

Changeover

The term used to describe moving from the old information system to the new information system.

M12_BOCI6455_05_SE_C12.indd 452 10/13/14 5:56 PM

453ChaPter 12 SYSTEM BUILD, IMPLEMENTATION AND MAINTENANcE: chANgE MANAgEMENT

Figure 12.2 Alternative changeover methods for system implementation

A B

C

All modules implemented

Modules Phased

1 2

3

National rollout

Time

Pilot regions Pilot

Parallel running

Direct cutover

Live dateOld system New system

n Time. There will be a balance between the time available and the desired quality of the system which will need to be evaluated.

n Quality of new system after changeover. This will be dependent on number of bugs and suitability for purpose.

n Impact on customers. What will be the effect on customer service if the change-over overruns or if the new system has bugs?

n Impact on employees. How much extra work will be required by employees during the changeover? Will they be remunerated for this?

n Technical issues. Some of the options listed below may not be possible if the system does not have a modular design.

There are four main alternatives for moving from a previous system to a new system. The options are shown in Figure 12.2 and described in more detail below.

Immediate cutover or big-bang method

The immediate cutover method involves moving directly from the original system to the new system at a particular point in time. On a designated date, the old system is switched off and all staff move to using the new system. Clearly, this is a high-risk strategy since there is no fallback position if serious bugs are encountered. However, this approach is adopted by many large companies since it may be impractical and costly to run different systems in parallel. Before cutover occurs, the company will design the system carefully and conduct extensive testing to make sure that it is reliable and so reduce the risk of failure. The case study shows a relatively successful example of the cutover method and indicates why this is necessary for the implementation of large systems. The success factors of this project are described.

Parallel running

With parallel running the old and new systems are operated together for a period until the company is convinced that the new system performs adequately. This presents a lower risk than the immediate cutover method, since if the new system fails, the company can revert to the old system and customers will not be greatly affected. Parallel running

Immediate cutover (big-bang changeover)

Immediate cutover is when a new system becomes operational and operations transfer immediately from the previous system.

Parallel running

This changeover method involves the old and new systems operating together at the same time until the company is certain the new system works.

M12_BOCI6455_05_SE_C12.indd 453 10/13/14 5:56 PM

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT454

sometimes also involves using a manual or paper-based system as backup in case the new system fails.

The cost of running two systems in parallel is high, not only in terms of maintaining two sets of software and possibly hardware, but also in the costs of the human operators repeating operations such as keying in customer orders twice. Indeed, the increase in workload may be such that overtime or additional staff may be required. The parallel method is only appropriate when the old and new systems perform similar functions and use similar software and hardware combinations. This makes it unsuitable for business re-engineering projects where completely new ways of working are being introduced that involve staff in working on different tasks or in different locations.

Phased implementation

A phased implementation involves delivering different parts of the system at different times. These modules do not all become live simultaneously, but rather in sequence. As such, this alternative is part-way between the big-bang and parallel running approaches. Each module can be introduced as either immediate cutover or in parallel. In a modular accounting system, for example, the core accounting functions, such as accounts payable, accounts receivable and general ledger, could be introduced first, with a sales order processing and then inventory control module introduced later. This gives staff the opportunity to learn about the new system more gradually and problems encountered on each module can be fixed as they are introduced.

Although this may appear to be an attractive approach, since if a new module fails the other modules will still be available, it is difficult to implement in practice. To achieve a phased implementation requires that the architecture of the new system and old system be designed in a modular way, and that the modules can operate independently without a high degree of coupling. For all systems, however, data exchange will be required between the different modules and this implies that common data exchange formats exist between the old and the new systems. This is often not the case, particularly if the software is sourced from different suppliers. Designers of systems are using techniques such as object-oriented design to produce modules with fewer and clearer dependencies between them. This should help in making phased implementations more practical. In the example given for the modular accounting system, modules in the old and new systems would have to have facilities to transfer data.

Pilot system

In a pilot implementation, the system will be trialled in a limited area before it is deployed more extensively. This could include deploying the system in one operating region of the company, possibly a single country, or in a limited number of offices. This approach is common in multinational or national companies with several offices. Such a pilot system usually acts as a trial before more extensive deployment in a big-bang implementation.

Using combinations of changeover methods

The different changeover methods are often used in conjunction for different stages of an implementation. For example, in a national or international implementation it is customary to trial the project in a single region or country using a pilot of the system. If a pilot system is considered successful there is then a choice of one of the following:

n immediately implementing the system elsewhere using the big-bang approach; n running the new and old systems in parallel until it is certain that the new system is

stable enough;

Pilot implementation

The system is trialled in a limited area before it is deployed more extensively across the business.

Phased implementation

This changeover method involves introducing different modules of the new system sequentially.

M12_BOCI6455_05_SE_C12.indd 454 10/13/14 5:56 PM

455ChaPter 12 SYSTEM BUILD, IMPLEMENTATION AND MAINTENANcE: chANgE MANAgEMENT

n if the new system is modular in construction, it is possible for the implementation to be phased, with new modules gradually being introduced as they are completed and the users become familiar with the new system;

n parallel running will probably also occur in this instance, in case there is a need to revert to the old system in the event of failure of the new system.

Once the system is proved in the first area, then further rollout will probably occur through the big-bang approach.

The advantages and disadvantages of each of these changeover methods are summarised in Table 12.4.

Deployment planning

A deployment plan is necessary to get all ‘kit’ or hardware in place in time for user acceptance testing. A deployment plan is a schedule that defines all the tasks that need to occur in order for changeover to occur successfully. This includes putting in place all the infrastructure such as cabling and hardware. This is not a trivial task, because often a range of equipment will be required from a variety of manufacturers. A deployment plan should list every software deliverable and hardware item required, when it needs to arrive and when it needs to be connected. The deployment plan will be part of the overall project plan or Gantt chart. A deployment plan is particularly important for large implementations involving many offices, such as the Barclays system referred to earlier in the chapter. Several people may be responsible for this task on large projects.

When planning deployment, advanced planning is required due to possible delays in purchasing and delivery. The burden of purchasing will often be taken by a systems integrator, but it may be shared by the purchasing department of the company buying the new system. This needs careful liaison between the two groups.

With installation of new hardware, a particular problem is where changes to infrastructure are required – for example upgrading cabling to a higher bandwidth or installing a new router. This can take a considerable time and cause a great deal of disruption to users of existing systems.

Deployment plan

A deployment plan is a schedule that defines all the tasks that need to occur in order for changeover to occur successfully. This includes putting in place all the infrastructure such as cabling and hardware.

Table 12.4 Advantages and disadvantages of the different methods of implementation

Method Main advantages Main disadvantages

Immediate cutover Rapid, lowest cost High risk if serious errors in system

Parallel running Lower risk than immediate cutover Slower and higher-cost than immediate cutover

Phased implementation Good compromise between immediate cutover and parallel running

Difficult to achieve technically due to interdependencies between modules

Pilot system Essential for multinational or national rollouts Has to be used in combination with the other methods

This section deals with managing changes to organisational processes, structures and their impact on organisational staff and culture.

In the early-to-mid 1990s organisation-wide transformational change was advocated under the label of business process re-engineering (BPR). It was popularised through the pronouncements of Hammer and Champy (1993) and Davenport (1993). The essence of BPR is the assertion that business processes, organisational structures, team structures and

Organisational change management

Business process re-engineering (BPR)

Identifying radical, new ways of carrying out business operations, often enabled by new IT capabilities.

M12_BOCI6455_05_SE_C12.indd 455 10/13/14 5:56 PM

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT456

employee responsibilities can be fundamentally altered to improve business performance. Hammer and Champy (1993) defined BPR as:

the fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in critical, contemporary measures of performance, such as cost, quality, service, and speed.

The key words from this definition that encapsulate the BPR concept are:

n fundamental rethinking – re-engineering usually refers to changing of significant business processes such as customer service, sales order processing or manufacturing;

n radical redesign – re-engineering is not involved with minor, incremental change or automation of existing ways of working. It involves a complete rethinking about the way business processes operate;

n dramatic improvements – the aim of BPR is to achieve improvements measured in tens or hundreds of per cent. With automation of existing processes only single-figure improvements may be possible;

n critical contemporary measures of performance – this point refers to the importance of measuring how well the processes operate in terms of the four important measures of cost, quality, service and speed.

Willcocks and Smith (1995) characterise the typical changes that arise in an organisation with process innovation as:

n work units changing from functional departments to process teams; n jobs change from simple tasks to multidimensional work; n people’s roles change from controlled to empowered; n focus of performance changes from activities to results; n values change from protective to productive.

In Re-engineering the Corporation Hammer and Champy have a chapter giving examples of how IS can act as a catalyst for change (disruptive technologies). These technologies are familiar from those described earlier (in Chapter 6) and include tracking technology, decision support tools, telecommunications networks, teleconferencing and shared databases. Hammer and Champy label these as ‘disruptive technologies’ which can force companies to reconsider their processes and find new ways of operating.

Many re-engineering projects were launched in the 1990s and failed due to their ambitious scale and the problems of managing large information systems projects. Furthermore, BPR was also often linked to downsizing in many organisations, leading to an outflow of staff and knowledge from businesses. As a result BPR as a concept has fallen out of favour and more caution in achieving change is advocated.

Less radical approaches to organisational transformation are referred to as business process improvement (BPI) or by Davenport (1993) as ‘business process innovation’. Taking the example of a major e-business initiative for supply chain management, an organisation would have to decide on the scope of change. For instance, do all supply chain activities need to be revised simultaneously or can certain activities such as procurement or outbound logistics be targeted initially? Modern thinking would suggest that the latter approach is preferable.

If a less radical approach is adopted, care should be taken not to fall into the trap of simply using technology to automate existing processes which are sub-optimal – in plain words, using information technology ‘to do bad things faster’. This approach of using technology to support existing procedures and practices is known as business process automation (BPA). Although benefits can be achieved through this approach, the improvements may not be sufficient to generate a return on investment. These alternative terms for business process change are summarised in Table 12.5.

Business process improvement (BPI)

Optimising existing processes typically coupled with enhancements in information technology.

Business process automation (BPA)

Automating existing ways of working manually through information technology.

M12_BOCI6455_05_SE_C12.indd 456 10/13/14 5:56 PM

457ChaPter 12 SYSTEM BUILD, IMPLEMENTATION AND MAINTENANcE: chANgE MANAgEMENT

A staged approach to the introduction of BPR has been suggested by Davenport (1993). This can also be applied to e-business change. He suggests the following stages that can be applied to e-business as follows:

n Identify the process for innovation – these are the major business processes from the organisation’s value chain which add most to the value for the customer or achieve the largest efficiency benefits for the company. Examples include customer relationship management, logistics and procurement.

n Identify the change levers – these can encourage and help achieve change. The main change levers are innovative technology and, as we have seen, the organisation’s culture and structure.

n Develop the process vision – this involves communication of the reasons for changes and what can be achieved in order to help achieve buy-in throughout the organisation.

n Understand the existing processes – current business processes are documented. This allows the performance of existing business processes to be benchmarked and so provide a means for measuring the extent to which a re-engineered process has improved business performance.

n Design and prototype the new process – the vision is translated into practical new processes which the organisation is able to operate. Peppard and Rowland (1995) provide a number of areas for the potential design of processes under the headings of Eliminate, Simplify, Integrate and Automate (ESIA) (see Table 12.6). Prototyping the new process operates on two levels. First, simulation and modelling tools can be used to check the logical operation of the process. Second, assuming that the simulation model shows no significant problems, the new process can be given a full operational trial. Needless to say, the implementation must be handled sensitively if it is to be accepted by all parties.

Table 12.5 Alternative terms for using IS to enhance company performance

term Involves Intention risk of failure

Business process re-engineering Fundamental redesign of all main company processes through organisation-wide initiatives

Large gains in performance (>100%?)

Highest

Business process improvement Targets key processes in sequence for redesign (<50%) Medium

Business process automation Automating existing process Often uses workflow software

(<20%) Lowest

Table 12.6 ESIA areas for potential redesign

eliminate Simplify Integrate automate

Over-production Forms Jobs Dirty

Waiting time Procedures Teams Difficult

Transport Communication Customers Dangerous

Processing Technology Suppliers Boring

Inventory Problem areas Data capture

Defects/failures Flows Data transfer

Duplication Processes Data analysis

Reformatting

Inspection

Reconciling

Source: Peppard and Rowland, 1995.

M12_BOCI6455_05_SE_C12.indd 457 10/13/14 5:56 PM

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT458

Business process management (BPM)

Business process management (BPM) is an important approach to process management that can be considered both in terms of a philosophy towards process change and as a supporting technology to process change in the form of tools for process design.

The philosophy of BPM recognises that business processes, and the way they are managed, are the key mechanisms that allow the organisation to deliver value to its customers. The approach thus entails an analysis of the structure of the organisation, the way people work together and the way technology is utilised. The focus of business process change will be provided by performance objectives for business processes that are derived from an analysis of how the company achieves its competitive advantage. Due to the far- reaching nature of the BPM approach it is likely that in most organisations a significant degree of organisational change, including a change of culture will be required. These aspects are covered in the later organisational culture section in this chapter.

Underpinning the philosophy of BPM are a number of process design tools that allow the approach to be put into operation. These tools include process maps, business process simulation, business activity monitoring and service-oriented architecture.

When image document circulation first appeared in the 1990s, the idea of applying computer technology to this kind of labour-intensive business process was considered cutting edge. Everyone in IT understood the potential of centralised computing for numerical computation and transaction processing, but few envisioned that this type of application would fit a broader set of distributed business processes.

Since the 1990s, leading companies have found more innovative ways to automate their business processes. E-forms, process modelling, simulation, EAI, integration services, rules engines, event services, real-time monitoring and process analytics are among the systems being applied to processes that include order management, billing, financial reporting, credit-card issuance, product returns and dispute resolution.

IT and operations executives have now understood that their current technology has done little to link the processes that run their companies to the transactions that result from those processes – transactions at the heart of corporate growth and profitability. This disconnect is rooted in a basic misunderstanding of the purpose of enterprise resource planning (ERP) and the role of business-process management – relationships that are now examined more carefully.

It is no secret that work gets done by people through business processes and that technology only supports those processes, whether distributing goods to customers, collaborating with suppliers, or co-ordinating employee efforts, business processes add value to products and brands.

Yet most ERP systems have a functional focus and lack process models that explain business operations. As a result, when managers tried to innovate or solve business problems – customer satisfaction was one of the most widespread – the ‘fix’ is often myopic and transaction-centric. What is missing is good business- process management.

Business-process management provides methods to automate and/or improve activities and tasks for particular business purposes. Its goal is not only efficiency and productivity, but also control, responsiveness and improvement. Control assures that company resources are aligned to execute strategies. Responsiveness and improvement support the competitive differentiation that enables a company to excel.

IT executives can assert control by basing the direction and flow of transactions on a predefined set of rules and work flows – for example, determining how a purchase order is acknowledged or merchandise is returned. Responsiveness enables individuals to react quickly to business events and maximise interactions, as when expediting a critical customer order across the customer-service and warehouse teams. As for improvement, you want to systematically measure and monitor processes; doing so will lead to innovation and optimal performance.

An integral part of business-process management is performance management, which is intended to steer the organisation and its partners toward corporate goals. Performance management focuses on the collaboration and empowerment of all individuals in the business

Business-process management (BPM)

CASE STUDY 12.1

Business process management (BPM)

Both a philosophy towards process change and a collection of supporting technologies for process change.

M12_BOCI6455_05_SE_C12.indd 458 10/13/14 5:56 PM

business software market has changed the landscape of business-process management systems significantly. It has been recommended that you evaluate all viable options including service-oriented architectures. Also, be wary of promises from vendors of single solutions that do only BAM or only process modelling – these products may not be functionally rich enough.

It was also recommended to keep performance management capabilities in mind when making vendor evaluations as good business-process management requires both simulation and BAM tools. Simulation aids process design and modelling by letting designers preview how a process flows and look at how the logic, events and rules work together – before the process is rolled out into a production environment. Using such a tool should discover and remove bottlenecks and accurately predict process performance. The best process models allow multiple simulation scenarios to be performed across sub- processes. The engine should be able to track resource usage, including cost and time analysis, and monitor usage that exceeds preset thresholds.

Other things to consider: a robust simulation tool will allow you to deploy new versions of processes without interrupting those already in use and the best solutions allow controlled migration from old processes to new ones. This capability is critical not only for safety reasons but also for benchmarking and measuring results.

Business-activity monitoring aggregates, analyses and presents relevant and timely internal information as well as data involving your customers and partners. BAM solutions can alert individuals to changes in the business that may require action from them. Once again, the purpose is to produce rapid insight into process innovations by identifying issues in real time, improving process performance and reducing operating costs.

Most BAM solutions provide post-process metrics, such as when and how many times the process was executed and which user performed which tasks. Some go further to provide visual representations of business activity with maps, technical drawings, charts, blueprints or graphs.

However, keep in mind that real-time process monitoring requires considerable development and integration work. Consider tying these activities to a company’s performance management objectives, measuring and tracking them in an active, balanced scorecard. It is well worth the effort. After all, how will you know if you are aligning current process activities to your performance objectives if you don’t properly score the results?

Once you have evaluated all software and architecture options, the fifth and final step is to roll out your solution and ensure widespread adoption of your business-process management initiative. To succeed, you must understand how to minimise interruptions to your current business processes, culture and technology usage.

network or value chain. It enables them to work across strategic, tactical and operational levels to align actions that produce rapid and effective responses to business challenges.

In the same way you define and document processes, you need to detail performance-management objectives. These objectives are the analytics used to measure all process-improvement projects. The metrics will provide the basis for an ongoing cycle of measurement, evaluation and improvement. It is also critical that your company tie these process-improvement metrics to high-level performance- improvement goals, not to low-level or transaction-oriented metrics.

Done right, performance management should shed light on why some processes do not function well and how to go about improving them. During analysis, the tools will provide the project teams with data to assess the productivity impact of proposed solutions. That data should also help business and IT departments arrive at a common understanding of particular business needs and their solutions. Collaboration between these groups is particularly important in good business process management.

Once you have addressed the overall issue of performance management and built the framework for a sustainable business-process management practice, you can begin to assess requirements for the IT systems that will support it. For this part of the project, five components are necessary: assessing current systems, building a business case, developing and communicating the plan, evaluating software and architecture options and, lastly, deploying the initiative. Here is further detail on each of the steps.

First, conduct an independent assessment of the process you want to innovate and the systems that currently support it. Establish a benchmark for the current levels of efficiency and effectiveness, and then identify areas for improvement. Of course, you will need to evaluate financial and operational requirements in this approach, including ROI and total-cost-of-ownership calculations.

Next, build a business case to demonstrate the value and results that the project will deliver, citing clear definitions of the value and cost of your programme, as well as compelling productivity and financial reasons for going ahead. Address the cultural, business and technology barriers to ensure you have support for your initiative.

Third, create a well-defined plan and communicate it to the process owners and participants. This will have to be articulated at different levels of the organisation, so make clear to all stakeholders what is in it for them. It should also show how the effectiveness of operations will improve through this process innovation.

After that, architecture and software needs should be identified in several ways. First, evaluate solutions with appropriate criteria to ensure that the programme is timely and responsive to the organisation. Consolidation in the

459ChaPter 12 SYSTEM BUILD, IMPLEMENTATION AND MAINTENANcE: chANgE MANAgEMENT

➨

M12_BOCI6455_05_SE_C12.indd 459 10/13/14 5:56 PM

Tools for business process management

Tools and techniques that are used to assist in the implementation of the business process management approach include:

n diagramming techniques such as process mapping; n modelling techniques such as business process simulation (BPS); n improvement approaches such as business process reengineering (BPR); n implementation of information technologies such as workflow systems; n use of performance management technologies such as business activity monitoring (BAM); n use of the service-oriented architecture (SOA) and web services.

BPR is considered earlier is this section. (Workflow systems are covered in Chapter 6 and BAM is covered in Chapter 4.) This section now considers process mapping, business process simulation, service-oriented architecture and web services.

Process mapping

Documenting the process can be undertaken by the construction of a process map, also called a flowchart. This is a useful way of understanding any business process and showing the interrelationships between activities in a process. For larger projects it may be necessary to represent a given process at several levels of detail. Thus a single activity may be shown as a series of sub-activities on a separate diagram. Table 12.7 shows the representations used in a simple process mapping diagram.

Figure 12.3 shows a process map of activities undertaken by traffic police in response to a road traffic accident (RTA) incident in the UK. The process map shows that following the notification of a road traffic incident to the police by the public, a decision is made to attend

Make sure you do not skip any of these steps – especially the second, where you benchmark your current process performance and build a business case. Doing so will enable you to showcase the value of your innovation after adoption. Following these steps will increase efficiency and effectiveness and improve the alignment of your operational processes. Through a simple organisation-wide approach, you can transform your staff, processes and systems in an efficient manner that ultimately will be reflected on the company’s bottom line.

Source: Based on Optimize, September 2005, Issue 47

QUESTIONS

1. How does the article suggest that business thinking and practice have evolved since the exhortations for business process re-engineering in the 1990s?

2. Summarise the benefits for BPM discussed in the article.

3. Discuss the need for a concept such as BPM when all new information systems and information management initiatives are ultimately driven by process improvement.

Process mapping

The use of a flowchart to document the process incorporating process activities and decision points.

Table 12.7 Symbols used for a process map

Meaning Symbol

Process/activity

Decision point

Start/end point

Direction of flow ▶

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT460

M12_BOCI6455_05_SE_C12.indd 460 10/13/14 5:56 PM

461ChaPter 12 SYSTEM BUILD, IMPLEMENTATION AND MAINTENANcE: chANgE MANAgEMENT

the scene of the incident. If it is necessary to attend the RTA scene the officer travels to the location of the incident. After an assessment is made of the incident the officer returns to the station to complete and submit the appropriate paperwork. If a court case is scheduled and a not guilty plea has been entered then the officer will be required to attend the court proceedings in person. Otherwise this is the end of the involvement of the officer.

Process maps are useful in a number of ways. For example, the actual procedure of building a process map helps people define roles and see who else does what. This can be particularly relevant to public-sector organisations in which modelling existing processes can be used to build consensus on what currently happens. The process map can also serve as a first step in using business process simulation as it identifies the processes and decision points required to build the model.

Business process simulation

The use of a simulation model on a computer to mimic the operation of a business means that the performance of the business over an extended time period can be observed quickly and under a number of different scenarios. Business process simulation (BPS) is usually implemented using discrete-event simulation systems which move through time in (discrete) steps. BPS software is implemented using graphical user interfaces employing objects or icons that are placed on the screen to produce a model (see Figure 12.4).

Although BPS requires a significant investment in time and skills it is able to provide a more realistic assessment of the behaviour of organisational processes than most other process design tools. This is due to its ability to incorporate the dynamic (i.e. time- dependent) behaviour of organisational systems. The two aspects of dynamic systems which need to be addressed are variability and interdependence. Most business systems contain variability in both the demand on the system (e.g. customer arrivals) and the durations (e.g. customer service times) of activities within the system. The use of fixed

Figure 12.3 A road traffic accident reporting process map

No

Attend court

No

OutNoNo

YesGuilty plea?

No

Yes

Out

Out

Digital mapping

Map geocode

Yes

Fax PBE

Contact division

Get statement in person

No Further action?

Attend RTA

Attend RTA?

Completed? Essential? RTA in

division?

Travel to RTA

Witness proforma

Yes No

No

No

Yes

No

RTA

Out

Yes

Injury?

Fax form 54

Fax form 55

Yes

No YesFatal accident?

Further action?

Yes Collate forms

Yes YesWrite abstract

Letter to drivers

Prosecution? Court case?

Out

Business process simulation

The use of computer software, in the context of a process-based change, that allows operation of a business to be simulated.

M12_BOCI6455_05_SE_C12.indd 461 10/13/14 5:56 PM

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT462

Source: courtesy of Oracle corporation

Figure 12.4 Simulation of a textile plant using the ARENA™ Visual Interactive Modelling system

(e.g. average) values will provide some indication of performance, but simulation permits the incorporation of statistical distributions and thus provides an indication of both the range and variability of the performance of the system. Most organisational systems also contain a number of decision points that affect the overall performance of the system. The simulation technique can also incorporate the ‘knock-on’ effect of these many interdependent decisions over time.

Service-oriented architecture (SOA)

The concept of SOA is to develop a number of reusable business-aligned IT services that span multiple applications across the organisation. SOA defines the services in such a way as to be utilised in a manner that is independent of the underlying application and technology platforms. A collection of standardised services forms the basis of a service inventory or service catalogue. Individual services from the service inventory can be deployed in multiple business processes. Each collection of services used in a particular business process is termed a service composition. The advantage of this approach for business process management is that a business process can link with the business services which are activated by the business processes without the need to know about the underlying application and technology platforms. The relationship between the business process, services, application and technology layers is shown in Figure 12.5. The use of SOA provides interoperability, the ability to allow computer systems from different manufacturers to work together and loose coupling, the capability of services to be joined together on demand to create composite services. These capabilities are particularly useful in increasing the flexibility of enterprise systems covered earlier (in Chapter 6). Read Case Study 12.2 ‘Service-oriented architecture’ for more details of SOA.

Service-oriented architecture (SOA)

An approach that incorporates reusable business-aligned IT services that can be utilised in a manner that is independent of the underlying application and technology platforms.

Service inventory/ service catalogue

A collection of standardised services that are designed to be used in a number of business processes.

Service composition

A selection of services from the service inventory that are allocated to a particular business process.

Interoperability

The ability to allow computer systems from different manufacturers to work together.

Loose coupling

The capability of services to be joined together on demand to create composite services.

M12_BOCI6455_05_SE_C12.indd 462 10/13/14 5:56 PM

463ChaPter 12 SYSTEM BUILD, IMPLEMENTATION AND MAINTENANcE: chANgE MANAgEMENT

Figure 12.5 Relationship between the business process, services, application and technology layers in the organisation

Layer

Order processing Materials management Financial reporting

Examples

Planning services HR services Finance services

ERP Custom applications Legacy applications

Windows Java C11 Unix .NET

Business process layer

Services layer

Web services platform

Application layer

Technology layer

Web services

SOA will most often be implemented on the web platform and the term web services is used for the technology which is derived from the convergence of service-oriented architecture and internet technologies. The web services platform is defined through a number of industry standards including WSDL (web services description language) which provides a means to define the functionality of a web service in terms of the XML schema definition language (Chapter 11). Another standard SOAP (simple object access protocol) consists of a framework for XML format messages sent between distributed information systems.

In practical terms a web service is really just reusable software code that can be combined with other web services to develop new applications. In order to use a web service a consumer searches for existing services in a web services registry either inside the organisation (private registry) or outside the organisation (public registry). Once the service is found it is retrieved and a fee is paid if appropriate. The service provider is then able to provide the web service to the service consumer.

Web services

A collection of industry standards which represents the most likely technology connecting services together to form a service-oriented architecture.

WSDL (web services description language)

Provides a means to define the functionality of a web service in terms of the XML schema definition language

SOAP (simple object access protocol)

consists of a framework for XML format messages sent between distributed information systems.

Business opportunities abound for financial institutions with the flexibility and agility to respond to rapidly changing market conditions and regulatory pressures. But when it requires a lengthy IT project to create

new products or services, those business opportunities remain tantalisingly out of reach.

Services-Oriented Architecture offers the ability for non-technical business users to build new products and

Play pick-and-mix to innovate with SOA By George Ravich, Executive Vice-President and Chief Marketing Officer of Fundtech

CASE STUDY 12.2

➨

M12_BOCI6455_05_SE_C12.indd 463 10/13/14 5:56 PM

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT464

Approaches such as business process management are concerned with the implementation of change involving both IS systems and employees. Implementation of processes that are performed by employees requires consideration of organisational change management including factors such as managing a change in culture.

An essential part of managing change associated with IS introduction is education to communicate the purpose of the system to the staff – in other words, to sell the system to them. It is not sufficient to simply provide training in the use of the software. This

Achieving organisational change

services by picking and choosing from existing processes contained within an “SOA services catalogue”.

An SOA services catalog promises to have the same impact on enterprise computing as the MP3 playlist has had on listening to music.

Before MP3 players, people listened to songs on a vinyl record or a CD in the order that the publisher determined. If you wanted to play several songs from different albums, it was a complicated and time- consuming activity. Now an MP3 player can take individual songs and create an endless number of playlists. Each song is reusable in different settings and situations, under the full control of the listener.

Before SOA, enterprise applications placed business processes within inflexible workflows. Without extensive IT development, reuse of any single business process was not feasible within these systems, leading to multiple versions of the same process being developed separately for different applications and channels.

Now, with SOA, individual business processes can be discovered, modified and recombined dynamically without having to involve the IT department. Business users can create new composite services and reuse services outside of their original context.

In the current environment, it is virtually impossible to define in advance the workflow that best fits the needs of the business. With services-oriented payments architecture (Sopa), managers can respond to the evolving needs of the business by tapping into a complete set of reusable, SOA-enabled business assets.

An example would be a fee calculation for a foreign exchange transaction. Given any currency pair, an amount, a transaction date and a customer type, the fee calculation service would determine the applicable fee to the customer. Usually, a function such as this would be part of a point solution for foreign exchange

capabilities, and you would only be able to use it in a prescribed set of circumstances.

Tapping into the SOA services catalog, you would be able to embed the same fee calculator into other SOA-ready systems, including web applications, mobile applications, branch applications and ATM systems.

Using the fee calculator, product specialists could model the revenue impact of a price change, marketers could craft special offers for preferred customers, and service agents could help customers to choose the most appropriate service plan.

All of these business users would be able to use the same fee calculation service, with the knowledge that it’s the most up-to-date version available, meeting all pertinent regulatory standards and company policies.

Sopa can transform an enterprise from a reactive consumer of pre-built systems into an active creator of innovative new services. Whether it’s modifying terms and conditions, updating service-level agreements for key clients or creating new products based on parts of existing services, business users will have unprecedented access to powerful capabilities without having to embark on costly and time-consuming IT projects.

Instead, they will have a nimble response to external regulatory pressures, and be able to build products faster, and deploy new capabilities at a cost advantage to competitors.

The role of IT doesn’t go away with the adoption of SOA. When it’s time to improve the underlying services by making them faster or more efficient, or when expanded capabilities are called for, IT developers can create new versions of existing services or build entirely new ones.

Once completed, these new and improved services are immediately available through the SOA services catalog for enterprise use.

QUESTIONS

Explain the advantages and disadvantages of the SOA approach

Source: Ravich, G. (2009) Play pick-and-mix to innovate with SOA. Financial Times. 13 July. © The Financial Times Limited 2009. All Rights Reserved.

M12_BOCI6455_05_SE_C12.indd 464 10/13/14 5:56 PM

465ChaPter 12 SYSTEM BUILD, IMPLEMENTATION AND MAINTENANcE: chANgE MANAgEMENT

Culture

This concept includes shared values, unwritten rules and assumptions within the organisation as well as the practices that all groups share. corporate cultures are created when a group of employees interact over time and are relatively successful in what they undertake.

education should target all employees in the organisation who will be affected by the change. It involves:

n explaining why the system is being implemented; n explaining how staff will be affected; n treating users as customers by involving them in specification, testing and review; n training users in use of the software; n above all, listening to users and acting on what they say.

Kurt Lewin and Edgar Schein suggested a model for achieving organisational change that involves three stages:

1. Unfreeze the present position by creating a climate of change through education, training and motivation of future participants.

2. Quickly move from the present position by developing and implementing the new system.

3. Refreeze by making the system an accepted part of the way the organisation works.

Note that Lewin and Schein did not collaborate on developing this model of personal and organisational change. Lewin developed the model in unpublished work and this was then extended by Edgar Schein who undertook research into psychology based on Lewin’s ideas (Schein, 1956). Later, Kurt Lewin summarised some of his ideas (Lewin, 1972). More recently, Schein (1992) concluded that three variables are critical to the success of any organisational change:

1. the degree to which the leaders can break from previous ways of working; 2. the significance and comprehensiveness of the change; 3. the extent to which the head of the organisation is actively involved in the change process.

‘Change’ was defined by Kurt Lewin as a transition from an existing quasi-equilibrium to a new quasi-equilibrium. This model was updated and put into an organisational context by Kolb and Frohman (1970). Although this is now an old model, it remains relevant to the implementation of information systems today.

Organisational culture

Understanding social relationships within an organisation, which are part of its culture, is also an important aspect of change management. The efficiency of any organisation is dependent on the complex formal and informal relationships that exist within it. Formal relationships include the hierarchical work relationships within and between functional business areas. Informal relationships are created through people working and socialising with each other on a regular basis and will cut across functional boundaries. Major change, such as the move to e-business, has the capacity to alter both types of relationships as it brings about change within and between functional business areas.

Schein (1992) also claims that the notion of organisational culture provides useful guidance on what must be changed within a corporate culture, if organisational change is to be successfully accomplished. He provides a threefold classification of culture that helps to identify what needs to be done:

n Assumptions are the invisible core elements of an organisation’s culture such as a shared collective vision within the organisation. One of the challenges in change management is to question core assumptions where appropriate, especially if they are seen to be obstructing organisational change.

n Values are preferences that guide behaviour such as attitudes towards dress codes and punctuality within an organisation or ethics within a society. Often such values

M12_BOCI6455_05_SE_C12.indd 465 10/13/14 5:56 PM

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT466

are transmitted by word of mouth rather than being enshrined in written documents or policy statements. As with organisational assumptions, values are hard to change, especially when the views that embody them are firmly held.

n Artefacts are tangible material elements of cultural elements. These will be identifiable from the language used in the policies, procedures and acronyms of the organisation, and the spoken word and dialects of the society. In some ways they are also the easiest to change. Policies can be created or rewritten, but it is the organisation’s values and assumptions that will determine how they are perceived and acted upon.

The implications of organisational culture for information systems implementation are important. While the ‘artefacts’ associated with information systems developments may be clear, it is the ‘assumptions’ and ‘values’ that will ultimately determine the success of the implementation and it is to these that the change management process must be largely directed.

Boddy et al. (2005) summarise four different types of cultural orientation that may be identified in different companies. These vary according to the extent to which the company is inward-looking or outward-looking, in other words to what extent it is affected by its environment. They also reflect whether the company is structured and formal or has a more flexible, dynamic, informal character. The four cultural types of cultural orientation are:

1. Survival (outward-looking, flexible) – the external environment plays a significant role (an open system) in governing company strategy. The company is likely to be driven by customer demands and will be an innovator. It may have a relatively flat structure.

2. Productivity (outward-looking, ordered) – interfaces with the external environment are well structured and the company is typically sales-driven and is likely to have a hierarchi- cal structure.

3. Human relations (inward-looking, flexible) – this is the organisation as family, with inter- personal relations more important than reporting channels, a flatter structure and staff development, and empowerment is thought of important by managers.

4. Stability (inward-looking, ordered) – the environment is essentially ignored with managers concentrating on internal efficiency and again managed through a hierarchical structure.

Different approaches to change management that may be required according to the type of culture are explored in the activity.

The purpose of this activity is to identify appropriate cultural changes that may be necessary for e-business success.

Review the four general categories of organisational cultural orientation summarised by Boddy et al. (2005) and take each as characterising four different companies and then suggest which will most readily respond to the change required for a move to an e-business. State whether you think the cultures are most likely to occur in a small organisation or a larger organisation.

Changing the culture for e-businessActivity 12.1

Achieving user involvement

Efforts should be made to involve as many staff as possible in the development. The following types of involvement (summarised by Regan and O’Connor, 2001) can occur in a systems development project:

1. Non-involvement – here, users are unwilling to participate or are not invited to. 2. Involvement by advice – user advice is solicited through interviews or questionnaires

during analysis.

M12_BOCI6455_05_SE_C12.indd 466 10/13/14 5:56 PM

467ChaPter 12 SYSTEM BUILD, IMPLEMENTATION AND MAINTENANcE: chANgE MANAgEMENT

3. Involvement by sign-off – users approve the results produced by the project team, such as requirements specifications.

4. Involvement by design team membership – active participation occurs in analysis and de- sign activities (including interviews of other users, creation of functional specifications and prototyping).

5. Involvement by project team membership – user participation occurs throughout the project since the user manages and owns the project.

While it will not be practical to involve everyone, representatives of all job functions should be polled for their requirements for the system at the analysis stage. As many user and manager representatives as possible should be involved in the active analysis and design involved in prototyping.

Promotion of the system can also be achieved by appointing particular managers to champion the new system:

n Senior managers or board members are used as system sponsors. Sponsors are keen that the system should work and will fire up staff with their enthusiasm and stress why introducing the system is important to the business and its workers.

n System owners are managers in the organisation who will use the system to create the business benefits envisaged.

n Stakeholders should be identified at every location in which the system will be used. These people should be respected by their co-workers and will again act as a source of enthusiasm for the system. The user representatives used in specification and testing can also fill this role.

n Legitimisers protect the norms and values of the system; they are experienced in their job and regarded as the experts by fellow workers; they may initially be resistant to change and therefore need to be involved early.

n Opinion leaders are people whom others watch to see whether they accept new ideas and changes. They usually have little formal power, but are regarded as good ‘ideas’ people who are receptive to change, and again need to be involved early in the project.

Resistance to change

Some resistance to change is inevitable, but this is particularly true with the introduction of systems associated with business process re-engineering, because of the way that work is performed and people’s job functions will be changed. If the rationale behind the change is not explained, then all the classic symptoms of resistance to change will be apparent. Resistance to change usually follows a set pattern. For example, Hopson and Scully (1997) have used the transition curve in Figure 12.6 to describe the change from when staff first hear about a system to when the change becomes accepted.

While outright hostility manifesting itself as sabotage of the system is not unheard of, what is more common is that users will try to project blame on to the system and will identify major faults where only minor bugs exists. This will obviously damage the reputation of the system and senior managers will want to know what went wrong with the project. Another problem that can occur if the system has not been introduced well is avoidance of the system, with users working around the system to continue their previous ways of working. Careful management is necessary to ensure that this does not happen. To summarise the way in which resistance to change may manifest itself, the following may be evident:

n aggression – in which there may be physical sabotage of the system, deliberate entry of erroneous data or abuse of systems staff;

n projection – where the system is wrongly blamed for difficulties encountered while using it;

System sponsors

System sponsors are senior managers or board members who are responsible for a system at a senior level in a company.

System owners

These are managers who are directly responsible for the operational use of a system.

Stakeholders

All staff who have a direct interest in the system.

M12_BOCI6455_05_SE_C12.indd 467 10/13/14 5:56 PM

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT468

Figure 12.6 Transition curve showing reaction of staff through time from when change is first suggested

Shock

Denial Emotional turmoil:

Fear Anger Guilt Grief

Integration

Search for meaning

New ideas and strategies

Acceptance – letting go

Time

S en

se o

f w el

l-b ei

ng a

nd pe

rf or

m an

ce

n avoidance – withdrawal from or avoidance of interaction with the system, non-input of data, reports and enquiries ignored, or use of manual substitutes for the system.

There are many understandable reasons for people to resist the technological change that comes from the development of new information systems. These include:

n social uncertainty; n limited perspectives and lack of understanding; n threats to power and influence of managers (loss of control); n perception that costs of the new system outweigh the benefits; n fear of failure, inadequacy or redundancy.

It is evident that training and education can be used to counter many of these issues. Additionally, other steps can be taken to reduce resistance to change, namely:

n ensure early participation and involvement of users; n set realistic goals and raise realistic expectations of benefits; n build in user-friendliness to the new system; n don’t promise too much and deliver what was promised; n develop a reliable system that is easy to maintain; n ensure support of the various stakeholders; n bring about agreement through negotiation.

Training

Appropriate education and training are important in implementation. Many companies make the mistake of not training staff sufficiently for a new system. This is often because of the cost of training or of taking staff away from their daily work for several days. If companies do provide training, it is often the wrong sort. Practical, operational training in how to use the software, such as which menu options are available and which buttons to press, is common. What is sometimes missing is ideological training: an explanation of why the system is being brought in – why are the staff ’s existing ways of working being overturned? This educational part of training is very important. Previous projects or examples of how systems have improved the business of competitors may be used here.

M12_BOCI6455_05_SE_C12.indd 468 10/13/14 5:56 PM

469ChaPter 12 SYSTEM BUILD, IMPLEMENTATION AND MAINTENANcE: chANgE MANAgEMENT

SUMMARY Stage summary: systems build Purpose: To produce a working system Key activities: Programming (coding), system and user documentation, testing Input: Design specification and requirements specification Output: Preliminary working system which can be tested by end-users

Stage summary: systems implementation Purpose: To install the system in the live environment Key activities: Install computers and software, user acceptance test, change-over, sign off Input: Preliminary versions of software Output: Tested, release version of software

Stage summary: systems maintenance Purpose: To ensure system remains available to end-users Key activities: Monitoring errors, reviewing and fixing problems, releasing patches Input: Tested, release version of software Output: Revised version of software

1. The build stage of systems development involves programming, testing and transferring data from the old system to the new system.

2. The main types of testing are unit testing of individual modules, system testing of the whole system by developers and user acceptance testing by the business. Sufficient time for testing must be built in using a quality assurance system to ensure that the delivered system is of the right quality.

3. The implementation stage involves managing the changeover from the old sys-tem to the new system. There are several alternative changeover approaches that can be used together if required:

n run the old and new systems in parallel; n a phased approach where different modules are gradually introduced; n cutover immediately to the new system; n pilot the system in one area or office before ‘rolling out’ on a larger scale.

4. Some of the main reasons that information systems projects may fail at the build or implementation stage include:

n Forgetting the human issues. New systems are usually accompanied by a new way of working, so managers need to explain through training why the change is occurring and then train people adequately in the use of the system.

n Cutting corners through using RAD. Some corners cannot be cut, especially in design, optimising system performance and testing. If insufficient time is spent on these activities, the system may fail. Documentation may also be omitted, which is serious during maintenance.

n Computer resources are inadequate. The project managers need staff to check, for example, that the server can handle the load at critical times of the day, such as when scanning is occurring or at peak times in a call centre. Checks will also be made to ensure that the system performance does not degrade as the number of users of the systems or customers’ records held increase.

n Poor management of change process. Staff who are involved with the new system should be trained so that they can use the software easily and understand the reasons for its introduction.

n Lack of support from the top or from stakeholders. Top management and appropriate stakeholders must support the cultural changes necessary to introduce the new system.

n Using a big-bang method of changeover. Using this approach is high-risk unless there has been extensive testing and methodical design.

5. The maintenance phase is concerned with managing the system once it is live. This will involve responding to errors as they are found. If serious, the problems will have to be solved immediately through issuing a ‘patch’ release to the system; otherwise they will be recorded for a later release.

6. A post-implementation review will occur to assess the success of the systems development project so that lessons are recorded for future projects.

7. Change management can be considered at the software, IS and organisational levels. ➨

M12_BOCI6455_05_SE_C12.indd 469 10/13/14 5:56 PM

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT470

8. Software change management involves managing the process of modification to software thought to be necessary be business users or developers.

9. IS change management involves managing the change from the old to the new information system. The four main alternative methods of changeover are immediate cutover, parallel running, phased implementation and pilot system.

10. Organisational change management deals with managing changes to organisational processes, structures and their impact on organisational staff and culture. Business process management (BPM) provides a methodology for change management in the organisation.

1. What are the main activities that occur in the build and implementation phases of a systems development project?

2. What is the difference between unit and system testing?

3. How can resistance to change among staff affect a new information system?

4. What are the most important factors in reducing resistance to change?

5. Why is it important to manage software change requests carefully?

6. What is the difference between the direct changeover method and the parallel changeover method?

7. What is the best option for an end-user to program a system?

8. What is the purpose of a post-implementation review?

9. What is the purpose of the concept of SOA?

EXERCISES

Self-assessment exercises

Discussion questions

1. ‘All the different project changeover methods are likely to be used on any large project.’ Discuss.

2. ‘The most important aspect of software quality assurance is to make sure that bugs are identified during the testing phase.’ Discuss.

3. ‘Companies should aim to minimise the number of patch releases, provided that no serious system errors occur.’ Discuss.

4. ‘The combination of BPM and SOA is more powerful than either is alone.’ Discuss.

1. You are a business manager responsible for the successful implementation of a new information system. What problems would you anticipate from staff when the new system is introduced? What measures could you take to minimise these?

Essay questions

M12_BOCI6455_05_SE_C12.indd 470 10/13/14 5:56 PM

Boddy, D., Boonstra, A. and Kennedy, G. (2009) Managing Information Systems: Strategy and Organisation, 3rd edition, Financial Times Prentice hall, harlow

Davenport, T.H. (1993) Process Innovation: Re-engineering Work through Information Technology, harvard Business School Press, Boston

Hammer, M. and Champy, J. (1993) Re-engineering the Corporation: A Manifesto for Business Revolution, harpercollins, New York

Hopson, B. and Scully, M. (1997) Transitions: Positive Change in Your Life and Work, Prentice hall, harlow

Johnston, A.K. (2003) A Hacker’s Guide to Project Management, 2nd edition, Butterworth- heinemann, Oxford

Jones, C. (2008) Applied Software Measurement: Global Analysis of Productivity and Quality, 3rd Edition, Mcgraw-hill, New York

Jorgenson, P. (1995) Software Testing: A Craftsman’s Approach, cRc Press, Boca Raton, FL

Kolb, D.A. and Frohman, A.L. (1970) ‘An organizational development approach to consulting’, Sloan Management Review, 12, 51–65

Lewin, K. (1972) ‘Quasi-stationary social equilibria and the problems of permanent change’, in N. Margulies and A. Raia (eds), Organizational Development: Values, Process and Technology, Mcgraw-hill, New York, pp. 65–72

Examination questions

References

2. Discuss the advantages and disadvantages of the different methods of changeover from an old system to a new one. Which is the optimal method?

3. Discuss the philosophy and describe the tools of BPM.

1. Describe the direct changeover method. How does this differ from phased implementation?

2. What different classes of fault will a user be aiming to identify in a user acceptance test?

3. What are the three classical signs of resistance to change by end-users?

4. Distinguish between system testing and unit testing.

5. What different types of documentation will be used during the implementation phase of a project?

6. What elements of staff training should a new system receive?

7. What is the purpose of volume testing?

8. Which criteria should be used to measure the successful outcome of a systems development project?

9. In the maintenance phase of the systems development lifecycle, why might an information system need to be maintained?

10. Briefly outline the considerations that a company needs to take into account in deciding between the two main methods of changeover to a new information system: direct and parallel running.

11. Evaluate the concept of BPM.

12. How could BPS and BAM work together?

471ChaPter 12 SYSTEM BUILD, IMPLEMENTATION AND MAINTENANcE: chANgE MANAgEMENT

M12_BOCI6455_05_SE_C12.indd 471 10/13/14 5:56 PM

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT472

Peppard, J. and Rowland, P. (1995) The Essence of Business Process Re-engineering, Prentice hall, hemel hempstead

Regan, E.A. and O’Connor, B.N. (2001) End-user Information Systems: Implementing Individual and Work Group Technologies, 2nd edition, Prentice-hall, Upper Saddle River, NJ

Schein, E. (1956) ‘The chinese indoctrination program for prisoners of war’, Psychiatry, 19, 149–72

Schein, E. (1992) Organizational Culture and Leadership, Jossey Bass, San Francisco

Willcocks, L. and Smith, G. (1995) ‘IT enabled business process reengineering: organisational and human resource dimension’, Strategic Information Systems, 4, 3, 279–301

Further reading

Erl, T. (2007) Service Oriented Architecture: Principles of Service Design, Prentice-hall, Upper Saddle River, NJ.

Greasley, A. (2008) Enabling a Simulation Capability in the Organisation, Springer Verlag.

Hallows, J. (2005) Information Systems Project Management: How to Deliver Function and Value in Information Technology Projects, 2nd edition, Amacom, New York.

Kerzner, H. (2013) Project Management: A Systems Approach to Planning Scheduling and Controlling, 11th edition, John Wiley, New York.

Newcomer, E. and Lomow, G. (2005) Understanding SOA with Web Services, Addison Wesley, Upper Saddle River, NJ.

Smith, H. and Fingar, P. (2006) Business Process Management: The Third Wave, Meghan Kiffer, Tampa, FL.

Weske, M. (2012) Business Process Management: Concepts, Languages, Architectures, 2nd edition, Springer, Berlin, New York.

Web links

www.bitpipe.com A repository for white papers on many IT topics including systems testing, change management and business process management. Many of these are sponsored by vendors so research is not independent.

www.bpm.com Provides news and in-depth articles about both the business and technology perspectives of business process management.

www.bptrends.com Provides a source of news and information relating to all aspects of business process change, focused on trends, directions and best practices.

www.bpmi.org Business Process Management Institute. An introduction to the concept and specifications for modelling business processes.

www.computerweekly.com This online trade paper for the IT industry has many case studies of the problems that can occur if the build process is not managed adequately.

www.cio.com CIO.com for chief information officers and IS staff has many articles related to analysis and design topics in different research centres such as security.

www.service-architecture.com consultancy website containing information on SOA.

www.scs.org The Society for Modeling and Simulation International. conference details and links to journal and publications.

www.scs-europe.net The Society for Modeling and Simulation: European council. European conference details and links to journal and publications.

www.stickyminds.com Portal with articles on software test, measurement and defect removal techniques.

M12_BOCI6455_05_SE_C12.indd 472 10/13/14 5:56 PM