Introduction to System Implementation
Welcome to your study guide for System Implementation! In the Systems Development Life Cycle (SDLC) for CCEA AS 1 (Approaches to Systems Development), implementation is the exciting phase where a newly built and tested system is finally put into live operational use. Think of it as moving from the rehearsal stage to opening night on Broadway!
In this chapter, you will master four essential areas that frequently appear on the examination:
• System Changeover Strategies: How an organisation switches over from an old legacy system to a new one.
• Data Conversion and Migration: How existing business data is cleaned, reformatted, and moved securely.
• System Documentation: The differences between Technical Documentation and User Documentation.
• Staff Training: Preparing users so the business transition is smooth and successful.
Don't worry if some terms seem daunting at first — we will break down every single concept step-by-step with clear real-world examples and exam tips.
1. System Changeover Strategies
When an organisation decides to introduce a new system, it cannot just guess how to transition from the old (legacy) system. Systems analysts must choose a specific changeover strategy based on cost, risk, business size, and how critical the system is to everyday operations. The CCEA specification covers four key methods:
A. Direct Changeover (Immediate / "Big Bang")
• What it is: The old system is completely stopped at a specific set date and time (such as midnight on a weekend), and the new system is switched on immediately to take over all live operations.
• Analogy: Throwing away your old mobile phone on Sunday night and using only your brand new phone starting Monday morning.
• Advantages:
- Lowest operational cost: The organisation does not need to pay for duplicate hardware, extra electricity, or double staffing.
- Fastest method: The new system and its modern features are immediately available to all staff.
- No data synchronisation issues: Staff do not have to worry about keeping two different systems up-to-date at the same time.
• Disadvantages:
- Highest risk of catastrophic failure: If the new system crashes or encounters severe bugs, there is no backup system to fall back on.
- High stress for staff: Users must adapt instantly with no gradual transition.
• Suitability: Best suited for non-critical systems, systems that have been exhaustively tested, or situations where running two systems at once is technically impossible.
B. Parallel Running
• What it is: The old system and the new system run simultaneously side-by-side on live data for a temporary transition period until the new system is proven to be completely stable and reliable.
• Analogy: Carrying both your old phone and your new phone for two weeks, sending messages on both to make sure the new one doesn't lose any contacts.
• Advantages:
- Lowest risk: If the new system fails or encounters unexpected errors, the legacy system is still fully operational and acts as an immediate fallback.
- Direct comparison: Results, calculations, and outputs from both systems can be compared side-by-side to verify accuracy.
• Disadvantages:
- Most expensive method: Requires duplicate hardware licences, running costs, and extra electricity.
- Heavy workload: Staff face extra stress and double the work because they must enter all data twice (once into the old system and once into the new system).
• Suitability: Essential for mission-critical systems where system failure cannot be tolerated under any circumstances, such as hospital patient management, banking systems, or payroll processing.
C. Pilot Running
• What it is: The entire new system is rolled out in full, but only within one single branch, department, or selected user group (known as the "pilot site"). Once proven successful, it is rolled out to the rest of the organisation.
• Analogy: A supermarket chain testing a brand-new self-checkout system in just their Belfast store before installing it across all stores in Northern Ireland.
• Advantages:
- Low organisational risk: If errors or bugs occur, only the single pilot branch is affected, leaving the rest of the business safe.
- Staff training hub: Workers at the pilot site become experts and can help train colleagues during the wider rollout.
• Disadvantages:
- Delayed implementation: It takes much longer for the entire business to benefit from the new software.
- Communication bottlenecks: Data discrepancies can occur when the pilot branch tries to share files with branches still using the old system.
• Suitability: Ideal for multi-site organisations, retail chains, and companies with separate regional offices.
D. Phased Implementation (Phased Conversion)
• What it is: The new system is introduced module-by-module or part-by-part across the organisation over time. Each module replaces a part of the old system until the entire transition is complete.
• Analogy: Renovating a house one room at a time (e.g., redoing the kitchen first, then the bathroom, then the bedrooms) rather than rebuilding the whole house all at once.
• Advantages:
- Targeted adaptation: Staff only need to learn one small subsystem or module at a time, reducing training overload.
- Isolated risk: If a problem occurs with a new module, only that specific business function is disrupted.
• Disadvantages:
- Interface complexity: Writing temporary software bridges so that newly installed modules can exchange data with remaining legacy modules can be technically complex and expensive.
- Prolonged rollout: Full deployment takes a long time.
• Suitability: Large, modular software suites (such as Enterprise Resource Planning - ERP systems) where components like Inventory, Invoicing, and Human Resources can be separated.
Memory Aid: Pilot vs. Phased (Do Not Mix These Up!)
CCEA examiners frequently report that students confuse Pilot and Phased running. Remember this simple golden rule:
• PILOT = WHOLE system in ONE location (e.g., all modules tested in the Derry/Londonderry branch only).
• PHASED = ONE PART of the system across the WHOLE company (e.g., only the Invoicing module launched across all branches).
Key Takeaway for Changeover: Choose Direct for fast/low-cost changes where risk is low; Parallel for high-risk mission-critical systems where safety is paramount; Pilot for multi-site organisations; and Phased for large, modular systems.
2. Data Conversion and Migration
When transitioning to a new system, you cannot leave valuable historical records behind. Data migration is the process of transferring data from the old legacy storage structures to the new system. This involves three critical stages:
A. Data Cleansing (Scrubbing)
Before moving data into a new database, old files must be cleaned. Data cleansing involves finding and fixing errors such as duplicate records, incomplete entries, corrupted files, and outdated customer details. Moving "dirty data" into a brand-new system will cause immediate errors and wasted storage.
B. Data Mapping and Translation
The old system and the new system often store data in different structures, formats, or field lengths. Data mapping defines how a field in the old system corresponds to a field in the new system.
• Example: Converting legacy dates stored as \(DD/MM/YYYY\) into a modern database SQL timestamp format, or expanding a customer ID field from 5 characters to 8 characters.
C. Data Validation and Verification
Once data is transferred, teams must ensure it is accurate and complete:
• Validation: Automated software checks ensuring data follows sensible rules (e.g., range checks, format checks, presence checks).
• Verification: Checking that the migrated data matches the original source data exactly (e.g., double-entry checks or visual proofreading of sample records).
Key Takeaway for Data Migration: Always cleanse data before migration, map/translate field formats correctly, and perform validation and verification to guarantee data integrity.
3. System Documentation
A system is incomplete without clear documentation. Different groups of people need completely different information about how the system works. CCEA breaks documentation down into two distinct categories:
A. Technical Documentation (System Documentation)
• Target Audience: Systems analysts, software developers, network administrators, and future maintenance programmers.
• Purpose: To explain how the system is constructed internally so it can be maintained, upgraded, or fixed when bugs appear.
• Key Contents Include:
- System architecture and Data Flow Diagrams (DFDs)
- Entity Relationship Diagrams (ERDs) and Data Dictionaries
- Fully annotated and commented source code
- Minimum hardware and software specifications
- Installation scripts and configuration parameters
- Error codes, testing logs, and trace tables
B. User Documentation
• Target Audience: End-users, office workers, non-technical operators, and data-entry clerks.
• Purpose: To guide everyday users on how to operate the software to carry out their day-to-day jobs without needing technical programming knowledge.
• Key Contents Include:
- Step-by-step guides and tutorials for common tasks
- Screen mockups and user interface navigation guides
- Frequently Asked Questions (FAQ) and troubleshooting tips
- Clear instructions on how to fill in input forms and enter data
- Helpdesk contact numbers/emails and a glossary of non-technical terms
Examiner Trap: Documentation Mix-Ups
Never write in an exam that User Documentation contains program source code, algorithms, or ERDs! Similarly, do not state that Technical Documentation contains simple navigation buttons or end-user login tips. Keep the technical build details separate from everyday operating guides.
Key Takeaway for Documentation: Technical documentation is for the technicians who maintain the system backend; User documentation is for the end-users operating the system frontend.
4. Staff Training Methods
Even the most powerful digital system will fail if employees do not know how to use it. System implementation requires structured user training. Organisations commonly use several approaches:
• Hands-on Workshops / Interactive Training: Staff practice tasks using simulated data in a safe sandbox environment. This allows users to make mistakes and build muscle memory without risking real business data.
• User Manuals and Digital Reference Guides: Providing printed or electronic guides (user documentation) that staff can refer to at their desks whenever they encounter an unfamiliar screen or task.
• "Train the Trainer" (One-to-One Cascade Training): Selected super-users (such as staff from a pilot site) receive in-depth training and then return to their departments to train their direct peers one-on-one.
Key Takeaway for Staff Training: Effective training combines hands-on practice, accessible reference manuals, and peer support to build user confidence.
5. CCEA Exam Focus: Common Mistakes to Avoid
Review these examiner-reported pitfalls before answering scenario questions in your AS 1 exam:
• Avoid Vague Financial Statements: Never simply state "it is cheaper" or "it saves money". Always explain why. Write: "Direct changeover reduces operational costs because the organisation does not need to pay for duplicate hardware or duplicate data entry staff as required in parallel running."
• Contextualise to the Scenario (AO2 Marks): If the exam scenario involves a hospital, an airline control tower, or emergency payroll, you must explain that Parallel Running is appropriate because the high risk of human life or massive financial loss requires an active fallback system.
• Precision with Definitions: Ensure you accurately identify whether an organisation is rolling out the whole system to one branch (Pilot) or one module to the whole organisation (Phased).
Quick Review Summary Checklist
Before moving on, verify that you can confidently answer the following questions:
• Can you describe the 4 changeover methods and provide 2 advantages and 2 disadvantages for each?
• Can you explain the difference between data cleansing, data mapping, and validation/verification?
• Can you list at least 4 items found in Technical Documentation and 4 items found in User Documentation?
• Can you justify why Parallel running is best for a bank, while Direct changeover might be chosen for a small club website?