Thursday, December 31, 2015

Selection and implementation of packaged software - Introduction

Introduction

The next few blogs will be focused on the selection and implementation of integrated packaged software.  It is designed to provide a best practice approach to the definition and generation of business solutions which are primarily constructed using standard, configurable software components - referred to as “packages”. 
We will use many special techniques which are only appropriate in a package-focused solution. The techniques will allow the project to be conducted more effectively and efficiently; and hopefully, they also lead to a better overall business solution.
However, neither this approach nor any other approach can provide a good package-based solution if packages are not the right answer for the business needs of the customer organisation.  It is important, therefore, that the organisation evaluates the business imperatives before defining and instigating an integrated packaged software solution project. 
During the next few articles I will address the full life-cycle of a business system from conception through to the appraisal and/or replacement of old systems.  It deals with the life-cycle in terms of the following segments:


  • Project Launch - definition of the scope, objectives, terms of reference for the project then setting up the appropriate team and infrastructure,
  • Requirements - definition of business needs, requirements and priorities, plus an initial “vision” of how they may be addressed,
  • Selection - evaluation of options, normally using a formal tendering process, and the definition of the preferred overall business solution,
  • Delivery - the achievement of the desired business solution in terms of the successful integration of people, skills, organisation, processes, technology, and systems; this may involve such activities as design, development, documentation, testing, training, conversion of data etc,
  • Post-implementation management - the management, control and support of the operational systems at strategic, tactical and routine levels,
  • Post-implementation review - the evaluation of a new system after it has had time to settle down to establish how successful its introduction has been and what further actions might be taken to realise maximum benefit,
  • Business Benefit Assessment - A review of an old system to identify the extent to which it is providing benefit to the organisation and what actions might be taken to ensure the best overall business solution is provided for the organisation; typically such a review would recommend improved business practices, upgrades, re-implementation or replacement, and thus the assessment may become the start of a new life-cycle.

A Structured Implementation Approach

Each process will be defined and documented separately.  This allows them to be revised, regrouped or supplemented as desired.  The different ways in which individual processes are combined for a specific purpose is called a “Path”.  Path Templates are documented to provide guides to sample approaches.  Typically these might show the most complete approach, the minimum possible approach and the validation of work already performed by other people not following this approach.

Processes

Each group of related activities or tasks is detailed as a “Process”. Processes may be mandatory, normal or optional.  In some cases, alternative processes can be defined for the same part of a project where there are differing needs and market conditions to address.  There are alternative processes depending on the circumstances of the client or of the scope or requirement.  In this way the apprach has been left open so that many different valid paths can be defined through the processes.
Where a new need is identified, new or revised processes can be added into this framework without disturbing the overall design.  This allows the approach to be made extensible simply and rapidly to meet all needs in the ever-changing marketplace.
For each process there is an explanation of its purpose and content coupled to an example sub-plan for the process.  This is known as a Process Plan. This approach also provides the means to develop a project plan aligned to the process paths

Paths

The combination of optional processes and alternative processes that is chosen and agreed for any segment of work is defined as a Path.  A number of standard paths have been identified.  These are described as Path Templates, ie a list of all processes normally conducted within a segment when a given approach is called for.
Path Templates do not define all possible paths.  On the contrary, Path Templates only define example paths.  The approach permits any path to be selected, provided that it leads to a valid combination of processes and meets the custome organisation’s needs.
The combination of processes for any given project is defined in the project’s Path Plan.  This is agreed before or during the project launch.

Saturday, December 26, 2015

Channelled BPI

BPI (Business Process Improvement)

With Business Process Improvement (BPI) you identify your true business processing needs and compare these with the actual way things are done to form an idealised view of how the business would best operate.  This can provide: dramatic cost reduction, improved quality, reduced cycle time, enhanced customer service. It challenges existing assumptions, paving the way for an improved design of business processes.  
Improvement is achieved through identify and assess the impact of redesigned processes on the people, structure, culture, technology and physical infrastructure of the organisation. 
A BPI programme is built on recognised principles of change management. Customers can receive short-term payback from “quick hit” changes identified early in the programme; they can also receive the benefit of uninterrupted sequenced longer-term change that becomes an integral part of their continuous improvement initiatives.

Exploiting packages

Another  common  way to achieve greater benefit from business systems is to bring in packaged software solutions.  This has two main advantages.  Clearly there should be significant savings in time, effort and cost - both to build the system and to maintain it.  In addition, packages are normally the result of intensive research and development, pulling together a range of best business solutions for a range of businesses and industries. With the constant advances in the package marketplace, packaged solutions can now meet the majority of business systems needs in a majority of businesses - not only meet those needs but often they offer better solutions than would be achieved by commissioning a custom development to the organisation’s own specifications.

“Pure” BPR

BPI and packaged solutions are frequently combined to bring about radical improvements in business processing.  Traditionally, the idealised view of the business processing plus the detailed specific requirements are used to select appropriate packaged solutions.  These are then modified and customised to build best-fit practical solutions.
We call this a “pure” approach to BPI - “pure” because the business processes are developed into an ideal form bearing in mind the technological possibilities and absolute constraints, but without being contaminated by assumptions or negotiable constraints.
Pure BPI often produces excellent results.  There are, however, some potential drawbacks with this approach.  

“Channeled” BPI

Getting the best value from a packaged solution usually implies that the business adopts specific practices already supported in the package.  To implement unsupported processing requires modifications and custom development.  Each modification of a package detracts from its value.  Modifications cost time and money, then leave the business with a partially unsupported solution.  This is often compounded when upgrades become available to the base package - it can prove costly if not impossible to apply them, and eventually the package supplier will cease support altogether on the previous versions.
No package solution will ever be able to support fully all the process designs unless those designs were made with the capabilities of a specific package in mind.  The selection process will identify the best-fit solution - but it is unlikely to provide perfect results. 
That is the rationale behind an alternative approach when BPI is used with packages - it is called “Channeled BPI”.  With channeled BPI you base your idealised business process design on the known capabilities of a package.  As no two packages are identical in their capabilities, this implies that a strategic choice of package needs to be made before the BPI is undertaken.  That choice would be made based on the business’s vision and key needs.  The choice of an appropriate package supplier will be fundamental to the success of the process.  The BPI process is then channeled to exploit the strengths and business processing capabilities of the package.
Typically, a BPI exercise deals with a multi-functional, inter-departmental piece of the business.  A package solution in such cases would normally call for a high level of integration across functional modules.  Leading packages of this nature, for example SAP, Oracle and Microsoft Dynamics, have well developed business process options that are already documented and modelled by the supplier.  The package’s  detailed business process designs are used as a starting point for the business process modelling - typically using package-specific modelling tools.
Channeled BPI is conducted in a similar way to the pure approach, except that the capabilities of the package are used as a constraint on the design.  This has two main advantages.  Much effort is saved as the details of business processes are already fully documented by the supplier and only need to be selected and aligned with the specific business needs.  When the solution is then built, the business process model can be implemented by configuring the standard facilities of the package according to the rules in the package-based process model.  This dramatically reduces the amount of modification or custom programming required and should ensure that the final solution is a perfect match to the process design.

Wednesday, December 23, 2015

Documentation Design

Finalise Reference Documentation Design

Objectives:

  • Identify the additional reference materials needed for client management, user and MIS support personnel to effectively operate the new system, take full advantage of its capabilities and minimise the effects from turnover

Hints:

  • Reference documentation provided by the supplier is usually written in generic terms and is limited to the standard system functions and operations.  This provides an opportunity to develop additional reference material covering customer-specific manual procedures, workflow and operations.  However, it is important to balance the value added from custom-developed reference documentation with the ongoing cost of maintaining it.  Supplementary reference documentation may include:
  • System Reference Guide – customer-specific instructions on using the system functions
  • User Reference Guide – customer-specific instructions on performing the related manual procedures
  • Operations Reference Guide – technical instructions on executing system processes
  • Management Reference Guide – functional system overview with emphasis on on-line enquiry and reporting.
  • In developing procedures for manual tasks, special attention should be given to finding ways to eliminate unnecessary tasks and streamlining the entire flow of information.  This requires looking beyond what is being done and evaluating why it is being done.
  • If available, the Implementation Strategy Report developed during the evaluation and selection process can provide a starting point for determining the detailed reference and documentation requirements for the new system.

Steps:

  • Evaluate the impact of the new system on existing manual procedures and company policies
    • Transaction preparation, review and approval workflow
    • Transaction entry and reconciliation
    • Security, audit trails and controls
    • Form and report filing and retention
    • System support, maintenance and implementation of enhancements
  • Evaluate the system impact on the technical support and operations procedures
    • Data collection and entry cutoffs
    • System processing, report generation and distribution schedules
    • System operations and technical support coverage
    • Backup frequencies and retention periods
    • System maintenance and enhancement
    • Manual change control
    • Implementation tasks
  • Identify any significant organisational improvements to maximise workflow efficiency and effectiveness
    • Organisation structure
    • Reporting responsibilities
    • Manpower requirements
    • Position responsibilities
    • Individual skills or expertise
  • Identify any outside parties that would be affected by the new system
    • Customers
    • Banks
    • Suppliers
    • Service bureau
    • Auditors
  • Review existing customer manuals and supplier-provided manuals, identify any supplementary reference documentation needed and prepare tables of contents
    • System guide
    • User guide
    • Operations guide
    • Management guide
  • Determine content and distribution of reference documentation to be developed
    • Level of detail
    • Format
    • Number of copies
    • Printing and binding
    • Distribution list
    • Ongoing maintenance and control
  • Evaluate reference documentation alternatives and select approach
    • Complexity
    • Cost
    • Resources
    • Timeframe
    • Organisational Impact
  • Organise analysis and prepare Implementation Papers for reference documentation:
    • Background
    • Requirements
    • Alternative options
    • Recommended approach and justification
    • Details of recommended approach
  • Review Implementation Papers with client sponsor and obtain approval

Tools:

  • Implementation Strategy Report (from evaluation and selection)
  • Example: Management Reference Guide TOC
  • Example: Operations Reference Guide TOC
  • Example: System Reference Guide TOC
  • Example: User Reference Guide TOC

Deliverables:

  • Reference Documentation Implementation Paper

Tuesday, December 22, 2015

Custom Development

System enhancements are any additions or changes in functionality of the base system in order for it to operate effectively in the customer environment. System enhancements include missing system functions, additional reports, customised screens, special interfaces and conversion programs. It is not a system enhancement (in this context) where such additional functionality is achieved using the standard facilities of the package such as a report generator or screen customiser.
Software warranties are usually invalidated if any changes are made directly to the Supplier’s software. They can also make implementing future releases costly and time consuming. Where possible, system enhancements should be developed around the standard system programs and should take advantage of any software user exits.
Timing should be considered when developing system changes. For instance, it is not necessary to prioritise a needed annual report prior to implementation if that report is not needed for another twelve months.
Even if the programming changes are being made by the supplier or an outside contractor, it is important that the project team fully understand what actual code changes are made. This will help in pinpointing problems if processing errors occur.

 Program Specifications

On occasions, the project team will find the need to generate program specifications. If there is no specific methodology in use, the following example task list could be used:

 Objectives:

  •  Identify precise requirements for custom programming work.
  • Collect sufficient functional and technical documentation to enable the identified system changes to be correctly developed.
  • Finalise the sources for developing the system changes.

 Hints:

  • Software warranties are usually invalidated if any changes are made directly to the Suppliers’s software. They can also make implementing future releases costly and time consuming. Where possible, system enhancements should be designed around the standard system programs and should take advantage of any user exits.
  • Most software suppliers have significant development resources and can be contracted to design and develop needed enhancements. If a contract for custom enhancements is negotiated with the supplier, it should clearly state who has ownership of the enhanced software and if the vendor will support the enhancements in future software releases.
  • In some cases, the supplier will agree to support enhancements they did not develop. The stipulations usually include that they design the changes, oversee the development and have ownership of enhancements made.
  • If available, the Implementation Strategy Report developed during the evaluation and selection process can provide a starting point for determining the detailed system enhancement requirements for the new system.

 Steps:

Review customer’s requirements and System Change Requests for software changes and conversion programs and finalise how the changes will be implemented. Document and agree these details in a technical Implementation Paper. Possible approaches include:
  • Modify vendor software
  • User exit programs
  • Stand alone programs and system modules
  • Report writer and report shells
  • Additional data elements
 If the project team are undertaking the work directly, prepare program specifications, for example:
  • Program Specification Checklist
  • System Change Request
  • System Flow Diagram
  • Program Structure Chart
  • Data Element Description
  • Data Base and Master File Layout
  • Screen Description & Layout
  • Screen Fields Worksheet
  • Report Layout
  • Source Document Description and Layout
  • Source Document Fields Worksheet
  • Summary of Test Conditions
Finalise approach and resources for developing system changes and prepare System Enhancements Worksheet
  • Consultant
  • Customer MIS
  • Software vendor
  • Other outside contractor
Prepare cost estimates and justification, if needed
Finalise implementation priority for change specifications
  • Critical to initial implementation
  • As time and staff are available
Acquire source code of supplier’s software and technical documentation, if needed and available. (supplier’s source code will not necessarily be available unless agreed in the contract with the vendor.)

 Tools:

  • Example: Program Specification Checklist
  • Example: System Change Request
  • Example: System Flow Diagram
  • Example: Program Structure Chart
  • Example: Data Element Description
  • Example: Data Base and Master File Layout ** Example missing
  • Example: Screen Layout
  • Example: Screen Fields Worksheet
  • Example: Report Layout
  • Example: Report Fields Worksheet
  • Example: Source Document Layout
  • Example: Source Document Fields Worksheet
  • Example: Summary of Test Conditions
  • Example: System Enhancements Worksheet

 Prepare Programming Environment

 Objectives:

  • Make any needed preparations for developing the system enhancements
  • Hints:
  • For consistency, if changes are being made to the software package, it is recommended that the vendor’s naming conventions and programming standards are followed.
  • System development controls should be established and maintained, including:
    • Separate development, testing and production libraries
    • Formal procedures for moving programs between libraries
    • System Error and Resolution logs
    • Formal program signoffs.

 Steps:

  • Review the coding standards and conventions used by the vendor and establish programming standards
  • Install development equipment and tools
  • Create development libraries
  • Load source code into development libraries

 Tools:

  •   (None)

 Deliverables:

  •   (None)

 Program and Document System Changes

 Objectives:

  •   Program, unit test and document the system enhancements

Hints:

  • It is important to document thoroughly any changes made to provide backup and reference.

 Steps:

  • Conduct structured walk-throughs of program specifications with development team, revise program specifications as needed and prepare System Enhancement Checklist
  • Program custom system enhancements
  • Define test conditions and expected results
  • Create unit test environment and prepare test data
  • Execute unit tests, validate results and log program errors
  • Correct program errors and retest as needed
  • Document system enhancements, as needed
    • Program Specification
    • Interim change requests
    • Final program listing
    • Unit test plan
    • Final test results
    • Unit Test Issue log (completed)
  • Update vendor documentation to reflect system enhancements
  • Review System Enhancements Worksheet and note any differences in development costs or schedule
  • Prepare System Enhancements Signoff Letter, if needed
  • Review enhancements with client sponsor and obtain approval
  • Load programs into the system test libraries

Tools:

  • System Change Requests
  • System Enhancements Worksheet
  • Program Specifications
  • Unit Test Issues Log
  • System Enhancements Checklist

Deliverables:

  • Enhanced application software and documentation
  • System Enhancements Signoff Letter

Saturday, December 19, 2015

Functional Design - Software

Objectives:

  • Finalise the functions and reports of the base software package to be used and determine how they will be used
  • Finalise the system enhancements needed to meet any unique needs not available in the standard system and determine how they will be developed

Hints:

  • The primary objective of implementing a new system is generally not more information, but more effective information.  The project team should focus on understanding how and why existing forms, reports and processes are being used, and how the same objectives can be accomplished more simply with the new system.  Implementing new systems and technologies may allow some existing forms, reports and processes to be combined or eliminated.
  • If Consultant was not involved in the system evaluation and selection decision, it may be necessary to gain an understanding of business before designing how the new system should be integrated into the business.  The Functional Questionnaires may be useful in gathering information about operation and functions.
  • Every attempt should be made to adapt the business processes to the standard processing features of the software package and reduce the number of enhancements needed.
  • Organisations should also be encouraged to fully utilise the system’s features and functions, as appropriate.
  • The Implementation Strategy Report developed during the evaluation and selection process can provide a starting point for determining the detailed configuration requirements for the new system.
  • If appropriate, implementation papers for each major system function can be separately prepared and approved.

Steps:

  1. Compare the manual and automatic functions of the existing system and the new system, identify any changes and complete a System Functions Worksheet
    1. Manual procedures and calculations that can be incorporated into the new system or eliminated
    2. Changes to current procedures and methods to take advantage of system features
    3. New functions not currently performed
  2. Compare the reports and inquiry screens of the existing system with the new system, identify any changes and complete a Report & Inquiry Screens Worksheet
    1. Enhancement to standard reports (i.e., transaction, management and control)
    2. Additional reports
    3. Additional data required
    4. Preprinted output forms (i.e., checks, statements, stationery)
    5. Specific parameter settings and run time options of standard package reports
  3. Compare the existing input forms with the new system input screens, identify any changes and complete a Forms & Input Screens Worksheet
    1. Content, format and sequence
    2. Printing EOQs, lead times and reorder points
    3. Storage and distribution
    4. Disposition of existing forms (e.g., use up existing supplies, discontinue and destroy)
    5. Printing method (e.g., in-house copier, outside printer)
    6. Approved suppliers (for preprinted forms)
    7. Responsibility for monitoring quantities and reordering
    8. Control of sensitive forms (e.g., checks, vouchers)
  4. Finalise system controls and audit trails
    1. Source document completion and authorisation
    2. Input validation and reconciliation
    3. Transaction processing and reconciliation
    4. Form, report filing and retention
    5. Backup and storage
    6. Table and parameter maintenance
  5. Finalise system security and complete Security Access Worksheet
    1. Physical access controls to equipment, files, forms and reports
    2. Logical access levels for each system user
    3. Remote access procedures
    4. Access hours and locations
  6. Evaluate implementation alternatives and select approach
    1. Complexity
    2. Cost
    3. Resources
    4. Time-frame
    5. Organisational Impact
  7. Organize analysis and prepare the implementation paper for each system function
    1. Background
    2. Alternatives
    3. Recommended Approach
  8. Review implementation paper with the sponsor and obtain approval to proceed
  9. Complete System Change Requests for any identified system enhancements
    1. Functions
    2. Reports
    3. Input screens
    4. Security and controls

Tools:

  1. Implementation Strategy Report (if available)
    1. System Functions Worksheet
    2. Reports & Inquiry Screens Worksheet
    3. Forms & Input Screens Worksheet
    4. System Change Request

Deliverables:


  1. Implementation Paper (for major system functions)