D400 - Design / Prototype - Implementation Papers
DEFINITION
Design or define each topic within the project, using prototyping techniques wherever appropriate, documenting the requirements, options, recommended approach and details in an Implementation Paper per topic.
SUMMARY
A key feature of the Application Software Implementation approach is the division of the overall work into a number of discrete topics. This allows rapid and effective progress with the design. Business Process Redesign techniques will be applied as appropriate. Normally, prototyping techniques will be used to elaborate the design and to validate its overall coherence. Prototyping by the project team may be supplemented by iterative prototyping sessions with a wider user audience.
Implementation Papers are used to manage these discrete topics. As requirements, options and design details are defined, they are recorded in the Implementation Paper. These topics will cover functional, technical and environmental design issues.
Implementation Papers should be drafted, reviewed, agreed and signed off in accordance with the Definition of Topics (DoT) - see Process D100.
The Implementation Paper is the hub of the flow of design information. Information in it will normally be gathered from earlier work, and will normally be used as the basis for design documentation, user documentation, testing plans, training plans etc.
PATH PLANNING GUIDANCE
Normal practice. A number of individual topics will be defined and agreed in the Definition of Topics (DoT). In the segment plan these would normally be given numbers in the range D4xx.
DEPENDENCIES
Prerequisites (Finish-Start):
- Definition of Topics (Process D100)
Prerequisites (Finish-Finish):
- individual papers will have dependencies with other individual papers; the details of such dependencies will vary according to the precise nature of the project.
- prototyping tasks will require the development system to be set up and usable (see process D130).
Dependent procedures (Finish-Finish):
- overall freeze / sign off of design
- development of full solution - processes D7xx
Dependent procedures (Finish-Start):
- individual papers will have dependencies with corresponding development tasks under processes D700 / D710 for package parameterisation and tasks within the D6xx processes for any areas of custom development; certain parts of the procedural and organisational processes (eg human procedures, training, test plan) will also depend on results from this process.
RECEIVABLES
- Definition of Topics (DoT)
- IP Control Log (IPCON)
- Delivery Approach Definition (DAD) or similar definition of high-level design
DELIVERABLES
- Implementation Papers (IP) as defined by the Definition of Topics (DoT)
- Prototypes of various components, eg screens, reports, processes, tables
- Updated segment plan (if required)
TOOLS
- Skeleton Implementation Paper
- Guidelines: Functional Design
- Guidelines: Modelling Techniques
- Guidelines: Various guidelines are available for specific topics - see the “IP Guidelines” Library
- Various example implementation papers
- Some common Implementation Papers are considered in more detail under other specific processes which create them, eg
- Technical Plan - D110,
- Project Training Needs Analysis - D120
- Development System Admin - D150,
- Integration Issues - D160,
- Data Availability and Purity - D180
- Organisational Impact - D 730
- System Handover plan - D830
- System Support and Administration - D850
- Transition to Live Service - D870
DETAILED DESCRIPTION OF TASKS
The IDDI Concept
Integrated Design Development and Implementation (IDDI) remains the single most powerful feature of an Application Software Implementation Project in comparison to other approaches. IDDI assumes that package components are technically reliable and coherent such that the project team do not need to take a serial approach to the design work.
By relying on the technical coherence of the solution, it is possible to work on different functional or environmental aspects of the system independently in parallel. This leads to substantial savings in elapsed time, in effort and in scheduling staff resources.
Each individual aspect of the system will undergo its own cycle of design, delivery and implementation with appropriate sign offs in between. The key differences are:
- these are small manageable amounts of work that encourage good full review by user management with a minimum drain on their time and the avoidance of bottlenecks caused by large volumes of paper to review in a short time,
- when little work can be performed on one topic, the team can be concentrating on others, thus making the best use of their time.
It is the Implementation Paper which is used to manage these discrete topics. As requirements, options and design details are defined, they are recorded in the Implementation Paper.
Prototyping
The package-based components of the solution will be ready to use as soon as the applications have been installed. This makes them an excellent design aid. Ideas can be tried out and tested before becoming fixed in the design.
During an Application Software Implementation Project’ Integrated Design Development and Implementation (IDDI), prototyping is often used to confirm requirements and to validate options. It is then used to select and demonstrate a preferred approach. Finally, the development and implementation details will be documented, often by copying them directly from the design prototype into the detailed instructions section of the Implementation Paper.
This design prototyping is commonly conducted in two different ways:
- the project team explore the requirements, options and recommendations in detail using prototyping techniques,
- partially complete subsets of the possible solution are presented to a wider user audience in iterative prototyping workshops for further comment, review and input.
Development of the system can be carried out as an extension to the design prototyping to build a full system prototype ready for formal testing. Depending on the environment, the target system may be developed directly from the design prototype or it may be created from the detailed instructions in the Implementation Papers. This subsequent development will also be conducted in parallel tasks, some of which may overlap with non-dependent design tasks. This “final” version of the system is built in subsequent processes - see, for example, processes D700 - Set up system parameters, codes, structures etc and D710 - Set up screens, queries & reports etc.
Business Process Redesign
Major aspects of Business Process Improvement/Redesign (BPI/R) may have been considered and defined already:
- prior to the project,
- during the requirements segment, and,
- in particular, in the Delivery Approach Definition (DAD).
During the design and prototyping activities, Business Process Redesign concepts and techniques should be applied to seek the best solution to the organisation’s business needs. This must, however, be confined to the defined scope of the project as may be defined in the Project Constitution (PCON) and Delivery Approach Definition (DAD). Typically, level 2 BPR/I techniques would be performed during the requirements work and only the level 1 “process optimisation”, ie fine tuning and design, would be carried out during the detailed design work in this process.
Any beneficial redesign outside this scope should be noted, but should not be developed until formal changes to the project’s scope have been agreed using the Change Control procedures (see process D140).
Implementation Papers
The Implementation Paper (IP) is used to manage the design prototyping process per topic. A separate paper is produced for each topic, as defined in the Definition of Topics (DoT). It is used to document and log progress through the prototyping process - ie it is written as the work is done as part of that work - it is not a separate task to document the results of the design or prototyping process.
The objectives of the paper are:
- to assist key management and team members to understand and agree upon the business requirements for the topic,
- to explore all options to address the business requirement (including procedural, process redesign, non-automated solutions),
- to indicate the preferred solution and to identify why that recommendation is being made such that key management and team members will understand and accept the recommendation,
- to define how the recommendation will be implemented in sufficient detail that no further design decisions will need to be taken (ie no further consultation, agreement or sign off is required),
- to highlight any unresolved issues which may affect the various details, recommendations and decisions presented in the paper - such outstanding issues should normally be resolved before the paper is finalised.
Format and content of an Implementation Paper
The basic contents of an Implementation Paper (IP) have been defined to meet the objectives stated above. Although the purpose and contents are defined, there is some flexibility in the layout and sequencing of the paper, the basic rule being to meet the overall objectives as simply as possible.
Topics should be defined such that they are of a manageable size. Clearly the underlying issues will vary in size and complexity and the Implementation Papers will do likewise. It may be possible to join together a number of small related aspects of the design into one topic, for example, all the individual accounting control requirements could be grouped together. It might conversely be necessary to divide large difficult topics into a number of smaller areas. As a guide, the size of the actual text in the resulting Implementation Paper (ie excluding control sheets, table of contents etc) could be described as follows:
1-5 pages - small
5-15 pages - normal
15-25 pages - large
25-35 pages - very large
over 35 pages - too large
The following table summarises the nature of each section and the tasks which may be performed.
Section
|
Content / Tasks required
|
Sign-off Control
|
This section forms a status control sheet for the IP. For control purposes this information should also be logged in the IP Control Log (IPCON). The control sheet shows responsibilities, other circulation, sign-off status, amendment history. Further details about the purpose and meaning of this information can be found in Process D100 - Prepare / review / agree IP / Topic descriptions and sign-offs.
|
Scope of this document
|
This section provides a definition of the scope and objectives of the IP. It may be taken directly from the Definition of Topics (DoT). It is used to allow all readers to understand what should be covered by the paper and what is not relevant to this paper. Further details about this information can be found in Process D100 - Prepare / review / agree IP / Topic descriptions and sign-offs.
|
Management Summary
|
A brief management summary may be written to allow review by senior management and communication of the basic principles to other interested parties. Note that the sign off for a paper must always be at a detailed level. The summary is only relevant to other readers. The management summaries of all IPs may be collected together to form an overall management summary for the system.
|
Requirements
|
The basic requirements should already have been established at an earlier stage in the project. Where practical, the relevant aspects of these can be copied into this section of the IP to remind the readers what the business requirement is. This will also lead to an amount of re-validation of those requirements. In certain cases it may be more appropriate to retain detailed requirements in other existing documents to which cross references are made. Where the requirements are not already expressed in a sufficient level of detail for the design work, further investigation, definition and agreement of detailed requirements may be required.
|
Options
|
This section lists the options which have been identified and considered. All reasonable options to meet the business requirements may be considered including technical options, procedural changes or business process redesign. Some options may have been identified in the selection segment of the project. Further options may be identified from the knowledge of the participants, from further research and by testing out scenarios using the prototype system. The advantages and disadvantages of each option are considered and validated. In some cases, part of this evaluation may be taken from the Selection Segment. Where appropriate the options can be tried and tested using the prototype. Key user management may be invited to see the options in operation and to confirm the extent to which they address the true business requirements. The advantages and disadvantages will be noted in this section of the IP.
|
Recommended Approach
|
This section describes the recommended approach and gives an explanation for the recommendation. The choice may be made for a number of reasons, for example necessity, cost, simplicity, benefit, risk etc. Normally the logic for this will be discussed and agreed with the responsible user and other key management and team members before continuing to explain the full details of the preferred solution as described in the following section.
|
Detailed Approach
|
Details showing how to build and implement the preferred solution will be formulated. This may not necessarily be the complete detail, but it should cover all design decisions such that no further consultation, review, agreement and sign off will be required. Very often, the design details can be drawn directly from the design prototype, for example, by copying prototype parameter tables and screen layouts etc. The detailed instructions are also used as the prime source for the generation of user and operational documentation, training materials and test definitions/scripts. Wherever possible, this section should be written such that it can be reformatted for the other purposes without redrafting.
|
Issues
|
This section notes any outstanding issues that need to be resolved. By the time the IP has been finalised there should normally be no outstanding issue, although, in some cases, it may be possible to defer the issue or agree not to address it. Issues noted should be entered into the project’s issues control and resolution system - see Process D190.
|
The conventional format of an Implementation Paper may follow the pattern described above, ie:
Sign-off control
Scope
Management Summary
Requirements
- item 1
- item 2
- item 3
- etc
Options
- item 1
- item 2
- item 3
- etc
Recommended Approach
- item 1
- item 2
- item 3
- etc
Detailed Approach
- item 1
- item 2
- item 3
- etc
Issues
Where there are a number of separate considerations grouped together in a single paper, it may be more useful to lay it out as follows:
Sign-off control
Scope
Management Summary
Item 1
- Requirements
- Options
- Recommended Approach
- Detailed Approach
Item 2
- Requirements
- Options
- Recommended Approach
- Detailed Approach
Item 3
- Requirements
- Options
- Recommended Approach
- Detailed Approach
- etc.
Issues
Both of these formats are acceptable - the key requirement is that the format chosen should give the best overall benefit.
The central role of the Implementation Paper
The Implementation Paper (IP) links together many of the earlier pieces of information and is in turn used as a source for later documentation - it is an objective of an Application Software Implementation Project that text and other information be re-used as much as possible to minimise the work required. Accordingly, the approach to style and level of detail for any Application Software Implementation Project document should always be decided with this requirement for re-usability in mind.
Sequencing of topics / IPs
It is necessary to sequence the design and prototyping work allowing for in-built dependencies. These will vary according to the package concerned and the needs of the project team. Sequencing design tasks requires careful consideration by a specialist at the time the detailed plan is established and during Process D100 - prepare / review /agree topics / IP descriptions and sign offs.
Where iterative prototyping workshops are being held with the user population, the stages of design need to be tied up with the scheduling of workshops so that users can review a coherent part of the system. These needs may clash with the normal dependencies of the design work. In such cases, the design topics may need to be closed “in principle” but re-opened as they come under review during the prototyping workshops.
Sequencing with Application Software systems
It is best to configure the Application Software System through the IMG, keeping the status memo up to date. Additionally, textual documentation should be maintained detailing screen customisation.
- Set up Organisational Structures as previously defined. Included are the settings of the client codes, company codes, plants, storage locations, valuation areas, sales organisations (if SD is implemented), purchasing organisations (if MM is implemented), and warehouses (if WM is implemented)
- Configure and Customise Master Data in terms of fields to be used, the numbering structure, type of number assignment, the numbering intervals, match code tables, and other options tables for master data.
- Configure and Customise Transaction Data in terms of fields to be used, types of number assignment, the numbering intervals, document flow, match code tables, and other option tables for transaction data.
- Configure Periodic Data, i.e. the batch processes and long-running transactions that are activated on a periodic basis:
- Review previously defined periodic processes
- Review the schedule timing of periodic processes
- Review the established backup procedures
- Integrate tune-up and reorganisation runs into the system
- Customise procedures such as purchasing authorisation process, availability check in SD, etc.
- Configure and Customise Reports and Forms required by the various business functions.
- Customise standard reports using the Application Software utilities
- Update documentation on report usage
- Configure user master records and authorisation for persons who should use the Application Software System.
- Identify users
- Assign users to organisational structures
- Create user master records
- Set up user authorisations
- Approve user authorisations.
Authorship and Review
Some implementation papers will require inputs from more than one team member. In such cases one person should be allocated responsibility for the production of the paper and assume authorship, accepting and editing contributions from the others. However, wherever possible, no more than two staff should be involved with any one paper. These responsibilities should have been defined in the Definition of Topics (DoT).
All papers must pass through some form of quality assurance procedure. The quality assurance may be of two types:
- technical quality assurance to ensure that the proposed solution is technically sound and maximises the use of package facilities,
- user quality assurance to ensure that the designed solution meets the user requirements.
Technical quality assurance will primarily be carried out within the project team. This may have been defined in the project’s Quality Plan. At least two other team members should read the paper, raise queries and suggest amendments before it is issued. These staff should be from the appropriate professional discipline and/or background to enable them to comment effectively. The paper must be signed-off by the team leader to confirm that this has been done.
In some cases it may be useful to issue discussion papers relating to parts of the subject covered by a single implementation paper (see Process D300). This should be done if the subject matter is thought to be potentially contentious. The use of discussion papers provides early warning and allows such issues to be settled or defused before the final implementation paper is issued.
Discussion papers are also a useful vehicle for sounding out user and management opinion if there are several viable options available. However, if discussion papers are to be used then:
- they should be short,
- circulation should be restricted to only those directly concerned with the subject matter,
- recipients should be asked to respond in writing.
It is sometimes possible to issue parts of an implementation paper as discussion papers as they are written so that most, if not all, of the final implementation paper has already been effectively quality assured before it is issued for formal quality assurance.
Those responsible for the quality assurance of any paper should respond with any queries or suggested amendments in writing before an agreed date.
Once responses have been received, three possible courses are available:
- if the queries or changes are minor, simply amend the paper and re-issue the paper for signing off,
- if there are a significant number of queries or changes, hold a formal meeting with the quality assurance staff to discuss and agree the resolution of the queries; the prototype may be used to demonstrate the issues - the paper can then be amended and issued for sign off,
- if there are major objections to the paper it may be necessary to restart the prototyping and design process altogether and then restart the quality assurance process.
Sign off
All implementation papers must be agreed by client users and should normally be formally signed off according to the responsibilities defined in the Definition of Topics (DoT),. This might include:
- the nominated quality assurer to indicate that it meets the correct technical standards,
- the user manager (Project Director) to indicate that the solution outlined in the implementation paper satisfies the user requirements,
- at least one other member of the steering committee.
Due to the complexity inherent in any integrated systems implementation, it is necessary to allow for issues to be raised in other parts of the project which may affect the current topic. Since there can be no linear set of dependencies through the various aspects of a complex project, these issues may be raised after the current topic has been reviewed and agreed.
Normally IPs will first be signed off “in principle”. This indicates that all key reviewers accept the IP but recognise that the topic may need to be re-opened if issues occur elsewhere. At this stage the IP is only open to amendment where issues are raised from other parts of the project through the Issues Control mechanism - see Process D190. Further sign-off is required if a subsequent change affects a significant aspect of the paper.
At specific times IPs or groups of IPs will be frozen or baselined after which no change can be tolerated without full change control authorisation. The issues control and resolution process handles all cross-aspect / IP issues.
Types of topic / Implementation paper
Topics and the implementation papers that describe them cover all aspects of design. There are three main types:
- Functional - examine the required functionality and how it will be achieved using the package.
- Environmental - examine the requirements and actions relating to the project, user or technical environment rather than the functionality of the system, eg security requirements and training needs.
- Technical - describe technical work required to implement the system, eg interface programming, conversion programming, technical set up.
The list of topics to be used on any one project is defined in Process D100 - Prepare / review / agree IP / Topic descriptions and sign-offs.
The following table gives some example lists of topics and implementation papers for a range of applications.
Environment Papers
(not application specific)
Acceptance testing
Change control
Control procedures
Data take on approach
Database implications
Documentation standards
Feeder testing
Handover
Languages
Operational readiness
Operations procedures
Organisational impact
Package tuning
Prototyping standards
Report distribution
Report standards
Security
Screen design/standards
Vendor liaison
System upgrade policy
Technical testing
Testing plan
Training needs
Training plan
User procedures
Volume testing
Materials
Functional papers
Budgeting
Cycle counting
Dynamic binning
Common vendor details with AP and purchasing
Goods inspection
Goods inwards/reception
Materials on loan
Materials returned
Material scrapping/disposal
Multiple Storage locations
New materials issue/return
Stocktaking
Storage location coding
Vendor codes
Used material issue/return
Technical papers - feeders:
- Fixed Assets
- GL
- Maintenance interface
- Production scheduling
- Purchasing
General Ledger
Functional papers
Accounting issues
Allocations/recharges
Archiving
Budgets
Chart of Accounts
Numbering
Controls
Financial reporting
Foreign currency
Joint venture accounting
Management reporting
Modelling/decision support
Other reports
Period end
Project accounting
Security
Screen enquiries
Statistical data
Year end
Technical papers - feeders:
- Accounts payable
- Accounts receivable
- Fixed Assets
- Manufacturing
- Purchasing
- Inventory
Accounts Payable
Functional papers
Accounting issues
Contractors payments
Foreign currency
Invoice processing
Invoice matching
Joint venture billing
Payment processing
Vendor numbering
Technical papers - feeders:
- GL interface
- Purchasing
- Inventory
Accounts Receivable
Functional papers
Accounting issues
Credit management
Controls
Customer numbering
Customer records
Foreign currency
Joint venture sales
Period end
Receipts handling
Voucher processing
Year end
Technical papers - feeders:
- GL interface
- Sales Order Processing
- Shipping & distribution
Purchasing
Functional papers
Foreign currency
Import documentation
License control
Order/delivery expedition
Materials/parts numbering
Purchase order
Purchase request
Vendor numbering
Tendering control
Technical papers - feeders:
- Accounts Payable
- Production scheduling
- Inventory interface
Maintenance
Functional papers
Budgeting
Common numbering standards with inventory
Common/standardised spare parts
Equipment coding
Equipment tracking/history
Parts numbering
Periodic servicing
Planning/scheduling
Tag numbers
Technical specification
Time/cost analysis
Time/cost recording
Works Orders
Technical papers - feeders:
- Fixed Assets
- GL
- Inventory interface
- Production scheduling
- Personnel/payroll
- Process Control
- Production Planning
- Project Planning
Owners manual & Work Book
The finished Implementation Papers may be used as the definitive documentation for the project. If they are of permanent value in documenting the design and construction of the system they can be filed in an “Owner’s Manual”. If they were of temporary value during the project, they will be filed in the project’s “Work Book”. This should have been identified in the Definition of Topics (DoT).
No comments:
Post a Comment