In the business information systems field, failures can happen for several reasons, including missed deadlines, users’ needs that are not met, dissatisfied customers, lack of support from top management, and exceeding budget allotments.
> Provide a situation where there is a need for an information system.
> Analyze the need for the information system using the four Ws—why, who, when, and what.
Need 5-7 page paper in APA format with introduction and conclusion and minimum of 5 peer-reviewed sources.
cHAPTER
7 An introduction to acquiring
and developing BIS
CHAPTER AT A GLANCE
MAIN TOPICS
■ How and why are information systems acquired? 264
■ Software acquisition and the systems development lifecycle 269
■ Bespoke development 274
■ Purchase of an off-the-shelf package 282
■ User developed software 285
CASE STUDIES
7.1 Lloyds Bank Insurance Services applies RAD 275
7.2 Use of waterfall v. agile methods at Mellon Financial 280
7.3 Lascelles Fine Foods 286
LEARNING OUTCOMES
After reading this chapter, you will be able to:
■ evaluate the different alternatives for acquiring BIS;
■ distinguish between the typical stages involved in building BIS;
■ explain the purpose of each stage in building a system;
■ select the best alternative type of approach or methodology for building a BIS.
MANAGEMENT ISSUES
Managers need to select the optimal method for introducing a new BIS once an opportunity is identifi ed. From a managerial perspective, this chapter addresses the following questions:
■ What are the alternatives for systems acquisition and how is the most suitable approach selected?
■ What alternative models are there for the different stages for introducing a BIS? Which is most appropriate?
■ Which activities need to occur at each stage for the project to be successful?
M07_BOCI6455_05_SE_C07.indd 263 30/09/14 7:20 AM
Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT264
This chapter provides the foundation for subsequent chapters in Part 2 by taking a broad look at the main activities involved in acquiring and building new business information systems. The word ‘acquire’ is used deliberately here, since ‘development’ implies the writing of bespoke software for a business information application. However, since many business applications can be purchased off the shelf without the need for any detailed design or programming activity, ‘acquisition’ more precisely defines the process we are going to outline here.
This chapter will start by reminding ourselves about the business rationale for information systems. We will then consider, in broad terms, alternative approaches to the acquisition of new computer-based information systems, ranging from creating new bespoke systems through to purchasing off-the-shelf applications.
BIS acquisition describes the method of obtaining an information system for a business. The main choices are off-the-shelf (packaged), bespoke (tailor-made) applications developed by an in-house IT department or a software house, and systems that are end- user-developed (i.e. by non-IS/IT professionals).
We will then review the traditional systems development lifecycle (SDLC), sometimes known as the ‘waterfall model’ of systems development within the specific context of bespoke software development. This defines the different SDLC stages involved in developing a new system. Any BIS project follows a logical series of development phases. Typical stages are: initiation, feasibility study, analysis of business requirements, systems design, system build and implementation and, finally, review and maintenance. The stages will be summarised in this chapter in preparation for a more detailed description in subsequent chapters. The analysis of bespoke software development will also incorporate some of the different methodologies for building systems such as rapid applications development (RAD).
From bespoke development, we will move on to consideration of factors affecting the acquisition of packaged software, and in particular software selection factors. We will also consider how the traditional systems development lifecycle applies to the purchase of packaged software and where the key differences lie when compared with bespoke software development.
Finally, while end-user computing is addressed in more detail (in Chapter 16), we will look briefly at user-developed applications where information systems are developed by IS users for their own or their department’s usage in the context of the steps of the SDLC that apply.
INTRODUCTION
BIS acquisition
The process of evaluating and implementation for a BIS.
Systems development lifecycle (SDLC)
Any information systems project follows a logical series of development phases. These are known as the systems development lifecycle.
SDLC stages
Initiation, feasibility study, analysis of business requirements, systems design, system build and implementation and, finally, review and maintenance.
HOW AND WHY ARE INFORMATION SYSTEMS ACQUIRED?
Organisations spend significant sums on information systems and it is important to understand the business context within which information systems are acquired. Earlier (in Chapters 1 and 2) we looked at a number of topics including:
■ the qualities of ‘good’ information to support effective decision making; ■ the business environment, both internal and external, and the ability of information
systems to impact positively on it; ■ the information needs of managers at different levels of an organisation and how this
results in different categories of business information system; ■ how BIS can produce a strategic advantage for an organisation.
Figure 7.1 demonstrates that an organisation’s information systems needs are driven by business strategies and policies which in turn are driven by both the internal and external business environment.
M07_BOCI6455_05_SE_C07.indd 264 30/09/14 7:20 AM
265ChaPter 7 AN INTRODUcTION TO AcqUIRINg AND DEVELOPINg BIS
An organisation’s business strategy will determine where the business is going, and why. This in turns creates ‘demand’ for information and the applications software that can provide it. What remains is the need to acquire, implement and manage these solutions and this is the stimulus for the software acquisition process.
Whilst many texts deal admirably with the range of tools and techniques available to the systems analyst for bespoke systems development to meet these needs, there is a tendency to forget that bespoke development is only one method of software acquisition. In fact for many businesses, especially small and medium-sized enterprises, bespoke applications development is not a viable option because of the costs and practical difficulties involved. It is necessary, therefore, to begin by looking at the range of acquisition methods and consider which is most appropriate for the needs of a particular business.
There are three main methods for acquiring the information system necessary to support a particular business need. These are bespoke development, off-the-shelf software and end- user development. Figure 7.2 summarises these three alternatives.
Figure 7.1 Drivers for information systems acquisition
Business strategy and
policies
Information systems needs
Internal business
processes
External business
environment
Bespoke development is the term for when an information system is developed ‘from scratch’ by one or more information systems professionals to meet the business requirements of the application.
1. Bespoke development
Figure 7.2 An example of a typical evaluation of alternatives for BIS acquisition
Methods of BIS acquisition
User- developed O�-the-shelf
Tailored Standard
Bespoke development
In-house Outsourced
Bespoke development
An IS is developed ‘from scratch’ by an IS professional to suit the business requirements of the application.
M07_BOCI6455_05_SE_C07.indd 265 30/09/14 7:20 AM
Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT266
Here a new BIS will be developed from scratch by a team of information systems professionals. The IS professionals will either work for the business, in which case we refer to this as ‘in-house’ bespoke development, or for a third party such as a software house, in which case we say that the software development has been ‘outsourced’. Bespoke development has the benefit of producing software tailored to the precise requirements of the business. There is also the benefit that the creation of a bespoke information system may confer specific competitive advantage since competitor organisations do not have the same software solutions. On the downside, there are a number of difficulties:
■ Expense. Bespoke development is the most expensive way of developing new information systems.
■ Time. Bespoke development, especially when using formal structured development methodologies, is notorious for time overruns, with delays of months or years not uncommon.
■ Quality. Bespoke software is not usually free from bugs; software bugs can range from the trivial to the catastrophic, the latter often attributable to poor analysis of requirements.
2. Purchasing ‘off-the-shelf’ software
Off-the-shelf purchase of packaged software is an acquisition method that involves direct purchase of a pre-written application used by more than one company.
This type of software is pre-written and is available for a whole variety of hardware platforms from PCs to mainframes. Off-the-shelf software is written to offer a broad functionality that will suit a wide range of different businesses. This broad range of functions has the benefit of fitting the requirements of a large number of businesses. It also may offer too many features for any particular business, which may then feel that it is paying for things it will not use. At the same time, it may require businesses to process information in a particular way that is at odds with the way they normally do business. Alternatively, a certain off-the-shelf software package may not offer sufficient features. For example, a well-known accounting package in the UK only offered an eight-character code for the customer’s order number, though it would appear that some 50 per cent of UK companies use longer order number codes. The major benefit, however, of off-the- shelf software packages is their low cost when compared with acquiring bespoke software with the same level of functionality. In addition, because packaged software has been developed for a commercial market, it is less likely to suffer from the bugs that afflict bespoke software.
In a tailored off-the-shelf package, pre-written software is purchased from a supplier, but it is possible to configure it to be specific to the company by altering software code as required for the customer as well as enabling the customer to define (within the limits set by the package vendor) how the software will run using pre-written configuration parameters. A standard off-the-shelf package may be similarly configurable, whilst in a component off- the-shelf package, different modules may be purchased from different suppliers and built together. Visual Basic controls for graphing is a good example of a component that can be added to an off-the-shelf application.
Off-the-shelf purchase
An acquisition method that involves direct purchase of a pre- written application used by more than one company.
User-developed software
Software written by non-IS professionals, i.e. the business users.
User-developed software is software written by non-IS professionals, i.e. the business users. Senn (2004) estimated that 50 to 75 per cent of all computing applications will be classed
as end-user applications (as distinct from institutional applications) and that many of these systems will be developed by end-users (i.e. non-IT professionals).
3. User-developed software
M07_BOCI6455_05_SE_C07.indd 266 30/09/14 7:20 AM
267ChaPter 7 AN INTRODUcTION TO AcqUIRINg AND DEVELOPINg BIS
Enterprise resource planning or institutional applications are those that affect general corporate activities, cut across more than one department or functional area, or systems that involve organisational data held in corporate databases. Examples include accounting systems, sales order processing systems and materials requirements planning.
End-user applications are more limited in scope. Applications may be departmental or personal in nature and are usually output- or report-oriented rather than input-driven. These applications may either be written by IT professionals or by the end-users themselves. If the latter is the case, they are often referred to as user-developed applications.
User-developed applications may be simple (e.g. a spreadsheet or a small PC database) or less commonly they may be more sophisticated (e.g. a production planning system based on sales forecast data from several branches of the same organisation). Such applications are typically for individual or departmental use, although in the case of the second example the system may have company-wide relevance. The main benefit of end-user-developed software is that it is normally used by those who develop it, and so the requirements are not subject to mistranslation or the provision of over-sophisticated solutions. The negative side to this is that in some cases inappropriate software development tools might be used (such as complicated spreadsheets instead of the construction of a database). A further significant concern with end-user development is that software may be riddled with bugs as a consequence of corner-cutting (poor or non-existent design, little or no testing, or no documentation). The end-user development approach is described in more detail later (in Chapter 16).
There are also a number of hybrid approaches to acquisition. A group of organisations in the same business or activity area may have information systems requirements that individually may be very expensive to develop. A solution may be for a bespoke system to be developed by a third party, which allows the development costs to be spread among all the organisations involved. Good examples here are a university student records system and various systems used in police forces across the UK.
Similarly, an off-the-shelf package may provide 80 per cent of the required features, but others may need to be added through some bespoke development by either IS/IT professionals or by end-users.
Enterprise application integration (EAI)
Software used to facilitate communications between business applications including data transfer and control.
The approaches to systems acquisition described above are not mutually exclusive to a given project or within an organisation. Where the software is generic to all businesses, as is the case with systems software and office productivity packages, off-the-shelf software will be purchased. Where the business has more specific needs and wishes to achieve a competitive advantage, bespoke and tailored approaches to acquisition will be used. With e-business systems there is often a need to integrate in-house legacy systems and systems purchased from different vendors. This uses a building block approach of different components including data sources that are integrated together. This is referred to as enterprise application integration (EAI), and achieving this is a significant challenge facing project managers and systems designers.
Hybrid approaches to systems acquisition
There are a number of factors that will influence the choice of acquisition method. Three critical ones are time, cost and quality considerations.
If an organisation has a pressing problem that requires a new information system quickly, it is probable that a package or tailored package will be sought. Similarly, an organisation that needs a ‘quality systems solution’ may well consider the packaged software route, especially if its requirements are straightforward.
Factors affecting software acquisition
M07_BOCI6455_05_SE_C07.indd 267 30/09/14 7:20 AM
Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT268
The different acquisition options have different strengths when considered in terms of the three critical criteria. Table 7.1 shows how the alternatives compare in terms of these three criteria. Quality of the delivered product is considered from two respects: the number of bugs or errors found and the suitability of the software in meeting the requirements of the business user. Note that good quality in terms of the number of bugs that typically occur for packaged software may coincide with poor quality in terms of the business fit.
The benefit of packaged software occurs because the cost of developing and debugging the software is shared between more than one company. This results in lower costs and fewer bugs than bespoke development for a single company. The use of packaged software by more than one company is also its greatest weakness, since its features must suit the typical company. As a consequence, it may not meet the needs of an individual company.
Other factors affecting software acquisition include the following:
■ Organisation size. A small or medium-sized business will inevitably have relatively limited resources for the purchasing of information systems and information technology (IS/IT). This suggests that there will be a tendency for such organisations to favour the purchase of off-the-shelf packages or possibly end-user applications development.
■ In-house IS/IT expertise. Where little in-house IS/IT expertise exists, either in the form of IS/IT professionals or experienced end-users, there will be a need to use third parties in the acquisition of new business information systems. These may include software vendors for off-the-shelf software packages, the use of consultants and/or software houses. Precisely what form of third party is used will depend on the other factors discussed here.
■ Complexity of the required information system. Where a business information system requirement is particularly complex, or for an unusual application not available as a packaged solution, it is possible that one may view bespoke software (either developed in-house or by a third party) as the only viable solution. However, complexity does not necessarily equate to ‘uniqueness’. For example, one could regard a materials requirements planning system or a complete accounting system as complex, but many packages exist for a variety of hardware platforms. Therefore, complexity is not necessarily an indicator that an off-the-shelf package should be ruled out.
■ Uniqueness of the business or business area to be supported. The higher the degree of uniqueness that exists in the area to be supported, the less likely it is that a suitable off-the-shelf package can be found. This is clearly an indicator, therefore, for bespoke development of some kind. As before, we must not confuse uniqueness with complexity. It may well be feasible for a non-IS/IT specialist to develop a solution using tools available to end-user developers. Of course, if the required system is complex and also carries a high degree of uniqueness, then bespoke development by IS/IT professionals is probably the best acquisition method.
■ IS/IT expertise among end-users. A certain degree of IS/IT literacy and expertise is necessary if end-users are to be able to develop information systems. In addition, such
Table 7.1 An evaluation of alternatives for BIS acquisition
acquisition option
Delivery time
Cost Quality: bugs
Quality: fits business needs
Bespoke in-house Poor Poor Poor Good
Bespoke software house Good Very poor Medium Medium End-user development Poor Medium Poor Good Tailored – off-the-shelf Good Good Good Medium
Standard – off-the-shelf Very good Very good Very good Poor
M07_BOCI6455_05_SE_C07.indd 268 30/09/14 7:20 AM
269ChaPter 7 AN INTRODUcTION TO AcqUIRINg AND DEVELOPINg BIS
literacy is desirable when selecting suitable off-the-shelf packaged software, as it can help the business focus more clearly on its precise requirements from both a functional and a technological perspective. If an organisation has little end-user IS/IT expertise of its own, but has its own IS/IT department, it will be very much dependent on solutions provided by IS/IT professionals with or without third-party support.
■ Linkages with existing applications software. Where new business software needs to integrate very tightly with existing information systems, there is a higher probability that at least some bespoke development work will need to be done to integrate the two systems. Also, a high degree of integration may imply that the new information system has to be developed in a bespoke fashion in order to achieve the desired level of integration. Having said that, many software vendors supply packages for different business areas which integrate very well with each other.
By looking at combinations of the above, it is possible to come up with a ‘best-fit’ acquisition method. Figure 7.3 illustrates the relationship between the complexity of the required application (as driven by the business needs) and the uniqueness of the application under consideration. The reader should note that bespoke development may be performed either by in-house IS/IT specialists or by a third party.
Similar relationships can be established with other pairs of selection acquisition factors. For example, when comparing the expertise of end-users in developing applications with the complexity of the desired application, a relatively simple information system may need professional IT staff involvement if the end-users do not have sufficient IS/IT capability.
Figure 7.3 Application complexity versus uniqueness
O�-the-shelf package
O�-the-shelf package or
end-user-development
Bespoke development
Bespoke or end-user-development
High
Low
Complexity of application
Low HighUniqueness of desired application
SOFTWARE ACQUISITION AND THE SYSTEMS DEVELOPMENT LIFECYCLE
The systems development lifecycle (SDLC) model was developed and launched by the National Computing Centre in the UK in 1969. Until then, the emphasis in systems development was on programming. It was recognised, however, that many systems being developed at that time failed to meet user needs, because they were either functionally inadequate or too inflexible to meet changing business needs. The SDLC approach recognises that systems are developed in a series of steps or phases and that each phase needs to be completed before the next one commences. Recognition is also given to the fact that the programming activity (part of the build phase) should only commence once user requirements have been determined and the system design produced. Figure 7.4 illustrates the normal steps found in the systems development lifecycle.
Within the diagram it will be noted that in addition to the lifecycle phases, the concepts of project management and change management have been added. This reinforces the notion that information systems projects do not take place by chance, but that they must be managed carefully.
We will now summarise the basic steps that most systems development projects follow.
M07_BOCI6455_05_SE_C07.indd 269 30/09/14 7:20 AM
Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT270
Initiation phase
The startup phase in an IS development project. Its aims are to establish whether the project is feasible and then prepare to ensure the project is successful.
Initiation phase context
Input: creative thought and/or systematic evaluation of IS needs. Output: idea for initiation of a new information system.
Feasibility assessment
An activity at the start of a project to ensure that the project is a viable business proposition. The feasibility report analyses the need for and impact of the system and considers different alternatives for acquiring software.
Feasibility assessment context
Input: idea for initiation of a new information system. Output: feasibility report and recommendation to proceed.
The initiation phase is the initiation or startup phase and is the first phase in an information systems development project. Its aims are to establish whether the project is feasible and then prepare to ensure the project is successful. The initiation phase context is:
Input: creative thought and/or systematic evaluation of IS needs. Output: idea for initiation of a new information system.
The initiation phase contains the stimulus from which the need to develop a new BIS arises. This stimulus may come about as a result of some external event such as a change in legislation, or it may arise from a desire internally to develop an information system that better supports the business needs of the organisation. The source of this initiation process may be one of the following:
■ Managing director or other senior management. Systems initiated from this point are likely to have the support necessary for successful development.
■ Information systems department. A system may be initiated here as part of the organisation’s overall IS/IT strategy; to maximise the chances of success the system will still need high-level management support.
■ Functional business area. A system initiated here will be competing for attention with all other development projects then being undertaken; often an organisation will have a steering committee to decide on development priorities.
Initiation (Chapter 8)
Figure 7.4 The systems development lifecycle (SDLC)
Project and change
management
Initiation
Feasibility study
Requirement analysis
Kill
Maintain
Build
System designImplement
Feasibility assessment is the activity that occurs at the start of the project to ensure that the project is a viable business proposition. The feasibility report analyses the need for and impact of the system and considers different alternatives for acquiring software. The feasibility assessment context is:
Feasibility assessment (Chapter 8)
M07_BOCI6455_05_SE_C07.indd 270 30/09/14 7:20 AM
271ChaPter 7 AN INTRODUcTION TO AcqUIRINg AND DEVELOPINg BIS
Input: idea for initiation of a new information system. Output: feasibility report and recommendation to proceed.
The feasibility assessment can be considered to be part of the initiation phase. It will establish whether a computer-based information system fits certain feasibility criteria. Three criteria are usually cited:
1. It must be established whether the information system is technically feasible. To be technically feasible, either the technology exists or it can be created to support the required system.
2. To be economically feasible, an information system must generate more in the way of benefits than the cost needed to produce it. One of the problems here is that benefits are often difficult to quantify in monetary terms, while costs are far easier to estimate.
3. Assuming that a proposed information system is both technically and economic-ally feasible, an assessment must be made of whether the project is operationally and organisationally feasible. By operationally feasible, we mean that the system must be capable of performing within the required speed, volume, usability and reliability parameters. Also, to be feasible for the organisation, the proposed information system must either be capable of running alongside work patterns or existing work patterns must be capable of being adapted or re-engineered to run alongside the new information system. Organisational feasibility will involve a review of how the potential users’ skill sets and attitudes will affect the system.
Part of the feasibility process may be the invitation to tender for some or all of the information system elements. These may include application software, hardware, communications technology or systems software. Different alternatives from different vendors will then be assessed.
The output from this step (and, therefore, the input to the next step of the model) is a stage review and a feasibility report, which will recommend either that the project proceeds or that the project is re