imat1906 systems development lecture week 19: system implementation

IMAT1906 Systems Development

Lecture week 19: system implementation

Today’s Agenda

IMAT 1906 Lecture Week 19 (c) De Montfort University 2010-112

Business procedures Training Installation Deployment strategies

Direct changeover Parallel running Pilot followed by roll-out

Summary

Purpose


There are some important issues to understand when implementing a newly-developed system

So that the new system helps the users in their work…

…and doesn’t hinder them

System implementation - overview


Recall that the final stage in system development is implementation The system has been designed and developed It has been tested as a system and has passed all

the tests The users have done their testing and found the

system acceptable Now it is time to hand the system over to the

business people and get it up and running

System implementation - activities


Recall that there are several activities in implementation: Install system as appropriate Populate the relevant databases - migrate or input User guide and other documentation User training Include new system functions in business procedures

These were in lecture 16 in the discussion of the traditional system development life cycle, but they are also relevant to other methodologies

We have looked at user guides in other sessions Today we look at the other issues

Business procedures


When a computer system is developed for a business area, it includes functions for the different types of user: Clerical users have operational functions that help

with tasks in the day-to-day job Managers have overview functions that help with

monitoring trends and exceptions and managing the business area

The functions provided by the computer system need to be built into the business processes carried out in doing those tasks

Operational business procedures


Thinking first about clerical users and their tasks…

Clerical or operational tasks tend to be detailed and repetitive, some examples might be: Take catalogue orders over the phone Input and process applications for credit cards Process bookings for holidays Pack and despatch goods ordered over the

internet Look more closely at one of these….

Operational procedure in detail


To take catalogue orders over the phone, what steps are involved?

User is on the phone, with a headset to keep the hands free to type

Customer calls in There are two conversations going on

User and customer User and computer

Let’s assume the customer knows what they want to order and aren’t asking advice etc

Procedure for taking order


Likely steps are: Identify customer

Search for customer number or name and postcode Open new order Confirm customer address details

Search billing address and update if necessary Search delivery address and update if necessary

Fill in order lines from customer responses Open new order line Input item number - confirm description with

customer Input quantity required Check stock available - confirm to customer

Procedure for taking order, contd


Process payment using payment sub menu link Includes confirming delivery charge with customer Includes confirming total order charge with customer

Return from payment sub menu Confirm despatch date and likely delivery date

Confirm these dates suitable for customer Ask customer if there is anything else you can

help with Close call

Things to note about procedure


What do we notice about the procedure? Includes both user and customer Includes both actions for user and functions in

system Not detailed at a field-by-field level Assumes all goes well

Exceptions or what to do if a step fails might be in a different step or might be in an alternative procedure

Similar to Successful Completion steps in use case description

Refers to another procedure and system (payments) Including the return from that procedure

Includes start and end of process

Managerial business procedures


Turning now to managerial users and their tasks…

Managerial or strategic tasks tend to be less well-defined and more analytical, some examples might be: Analyse sales of products showing regional

variation Analyse credit card applications by age range Report on holiday bookings comparing this year

with last year for each month Look more closely at one of these….

Managerial procedure in detail


To analyse sales showing regional variation, what is involved?

Manager has system on desktop or laptop Summary reports and graphs displayed on

screen User inputs search criteria User specifies subtotal and ordering parameters Can be printed on screen

Conversation between user and system….

Procedure for regional sales analysis


Likely steps are: Select sales analysis function Identify product range to be analysed

Select product range from drop-down list Specify groupings for subtotals

Select regions and areas within regions Select fields to be summed in subtotals

Specify report order Select type of ordering for example:

Alphabetic North-to-south South-to-north Total sales in descending order

Procedure for sales analysis, contd


View report as set of subtotals and totals Examine report data in tabular format as columns of

numbers View report in graphical view

Pie chart Bar chart or histogram Percentage bar chart

Possibly print report Print report to get hard copy of tabular view Print graph to get hard copy of graphical view Print combination to get hard copy including both

views Close report

Return to main menu

Things to note about procedure


What do we notice about the procedure? Includes both actions for user and functions in

system Guides user through procedure without too much

detail Gives or suggests options where appropriate Assumes all goes well

Exceptions or what to do if a step fails might be in a different step or might be in an alternative procedure

Similar to Successful Completion steps in use case description

Includes start and end of process

Where are we on agenda




Summary

User training


When a new system is being implemented, all the people who will use it will need to be trained Operational users Managerial users Support or help desk team

Adequate time needs to be allocated All users cannot be trained at once Operational training likely to need several sessions Can take several weeks to train all new users

Train using realistic set of sample cases and data Some users may have been trained for user

testing

User training - documentation


Likely documentation to use in user training: User guide Business procedures at appropriate level Supplementary material for example product

catalogue Any special stationery Input forms, filled in for sample cases Sample output reports, letters etc Frequently-asked questions

These can be compiled during training sessions

User training - formats


Several possible formats for user training: Classroom with trainer and system-specific workstations Classroom with trainer and general-purpose

workstations System-based tutorial in classroom setting System-based tutorial on intranet to use at workstation

Tutorial can be built into system help facility

Include how to get help From system help facility From help desk From support teams Within user guide and other documentation

User training - operational users


Points to bear in mind for operational user training: Typically based in separate classroom away from

work area Groups of users rather than one at a time Uses detailed sample cases covering all likely

options Include sample cases covering all exceptional

conditions Cover what to do when actions are unsuccessful Daily operations and procedures End of week/month/quarter/year procedures

User training - managerial users


Points to bear in mind for managerial user training: Can be based in separate classroom away from work

area Typically carried out at manager’s desk, one at a

time More sample cases but with less detail Cover all likely functions and options Cover correct and incorrect option selections Explain correlation between operational data and

summary levels and functions





Summary

Installation - overview


Installing the system sounds simple But there are several things to consider

Live environment as opposed to test environment Distribution of software and database Program-code independence Communication networks Data migration

Look at each briefly…

Installation - environment


In our teaching we tend to use one environment for development and testing Lab machines, network, H drive, your pen drives

Students tend not to implement developed systems nor to make them operational

Most real organisations segregate the development, test and operational environments Operational environment also called live environment Developers and testers access test environment

Access to live environment strictly limited Business users access live environment Support teams can also access live environment

Installation - distribution


Once the live environment is confirmed and ready, software installation can start

Copy of system software on central server or computer Program code, screen definitions

Copy of desktop application on each user workstation Screen definitions Might be just an interface to the central server system Might be part of the system that runs on the

workstation Often done remotely in large organisations

Installation - independence


Program code and database are kept separate Equally important in single-user systems as multi-user ones

No data in the code and no code in the database Simpler to implement program updates Data might change and should always be in database or file Data embedded in code is hard to find when

troubleshooting

Some databases allow use of specific chunks of program code to process individual tables Use with great care if at all Can have unpredictable effects on transaction time

Installation - networks


Communication channels link central server with… Workstations Database if in separate server Intranet, internet and other systems as relevant

Channels can include: Local Area Network within corporate building Wide Area Network outside building Virtual Private Network for secure data transmission

All the connections need to be configured, built and checked

Installation - data migration


Implementation includes data - how does it get there

Essentially two options Migrate data from existing data stores Input data from new operations

Migrate Dynamic data about eg customers, accounts, products Usually needs to be converted into new system’s format

This can be problematic and must not be underestimated

Input User details as each is trained or registered to system Static details such as titles, postcodes and towns, regions

These could also be migrated





Summary

Deployment strategies - overview


Three major options for putting the system into operation - also called deploying the system Direct changeover Parallel running Pilot followed by roll-out

Look at each briefly…

Direct changeover - what it is


Direct changeover is also called Big Bang

In this strategy, system is ‘turned on’ on day one Old system is ‘turned off’ if there was one All data has been migrated All users start using new system at once Usually scheduled during a business quiet time Least expensive strategy but riskiest

What if system fails in some way? Support team on hand Developers and testers usually on hand as well

Direct changeover - when to use


When to use No existing system to replace All users have been trained and ready System has been completely tested and found

acceptable All system functionality needed at same time

Phased implementation not a viable business option

Direct changeover - example


For example… A small company is automating its order processing All users in the order department have been trained User guide and documentation are ready System has been completely tested and is

acceptable Product data and customer data has been input Implementation taking place over bank holiday

weekend after all existing orders filled and sent out Old paper-based orders filed in archive boxes From day one, new orders are entered and

processed on the new system





Summary

Parallel running - what it is


In this strategy, both old and new systems running For an agreed period of time, say one month or six

weeks Sometimes by separate user teams

Data and transactions input and run on each system Care is needed to ensure all transactions are run on

both systems Outputs from each system compared to ensure

correct Care is needed not to mix up operations

Ensure only one set of outputs used eg customer letters

Parallel running - when to use


When to use Customer communication must not be wrong New system is direct replacement of old system Fail-safe option is needed To check end-of-period processing eg month end

Month-end processing on old system Month-end processing on new system Results compared to ensure exactly the same

Parallel running - example


For example… New system replaces customer account processing

system Both systems run in parallel for three months Account processing includes sending out monthly

statements and processing customer payments Customer statements compared from the two

systems to ensure new system processing in same way as old system

Only one statement sent to customer each month - preferably the one from the new system





Summary

Pilot followed by roll-out - what it is


In this strategy, new system used in small area For an agreed period of time, say three months Often in one self-contained business area If problems occur they are fixed before full

implementation When ready, system is implemented in rest of

business area

Pilot followed by roll-out - when to use


When to use Many similar areas to implement, geographically

spread System is entirely new and not replacing existing

system New hardware or network configuration needs to be

proven There is a business imperative to implement one

part of the system while other departments prepare For example launching a new product

Pilot followed by roll-out - example


For example…. Implementing system enhancements in retail chain Implement in two branches to prove it works in a live

setting When proven, implement in all other branches

For example…. A large company launches a new product across the

country Launch in one or two towns first, to test the market Can also prove the system and find any problems Make any required amendments and release the

changes When stable, implement in rest of country





Summary

Summary


System implementation includes several activities System functions included in business procedures Users trained and documentation distributed Software installed on relevant hardware and

networks Data migrated, converted or input as required

Different strategies for changeover to new system Direct changeover or ‘Big Bang’ Parallel running followed by changeover Pilot followed by roll-out

Further information


Further information can be found in many textbooks on systems development or systems analysis, for example:

Skidmore & Eva (2004) Chapter 16 Systems Implementation Also look up implementation in the index and see

what you find Shelly & Rosenblatt (2010) pp 524-533 Bocji P, A Greasley and S Hickie (2008) chapter 12

imat1906 systems development lecture week 19: system implementation

Documents

montfort university

computer system

tasks imat

implementationthe system

system implementationc

issues imat

system acceptablenow

order imat