This path deals with the iterative design,
prototyping and construction of an integrated packaged system, which forms the
heart of the implementation project. It
would normally follow a “Project Model” which would have established the
high-level requirements and design for the system along with global design
issues.
It would normally be followed by the
“Readiness Roll-out” path.
It is divided into five main parts:
- Prepare to Prototype
- Plan and Initiate Team Training Process
- Build base model
- Prototyping process
- Build
Ref
|
Process
|
Optionality
|
Definition
|
||||
| |||||||
Prepare to Prototype |
|
|
|||||
D100
|
Prepare / review / agree design topics,
IP descriptions and sign offs.
|
Normal practice
|
Review or create the definitions of
topics to be used in structuring the work into discrete logically independent
parts. Work will be assigned,
executed, controlled, documented, reviewed and signed-off within these divisions.
|
||||
D111
|
Review technical environment and plan
ERP installation
|
Optional - usually required when
insufficient detail was included in the Delivery Approach documentation and
segment plan.
|
Plan in detail the physical
installation of the ERP software, additional systems software, hardware,
communications equipment, servers, PCs etc.
|
||||
D130
|
Install hardware, communications
equipment, system software, and ERP modules as required for development,
implementation and live running.
|
Optional - required when insufficient
provision is already available for the project.
|
Install and commission items required
for design, development, implementation and live running. This includes system environment
requirements, eg log ons, access security, accounts, budgets etc.
|
||||
D135
|
Design and set up backup/recovery
provisions (development & test environment)
|
Normal practice
|
Ensure the development environment is
adequately backed up.
|
||||
D136
|
Design and set up system security
provisions
|
Normal practice
|
Ensure that adequate system security is
in place for the development and testing of the system.
|
||||
D140
|
Define, agree and instigate change
control procedures
|
Optional - normal practice where there
are several key users and/or several people on the team. (When no formal mechanism is in use - all
changes must still be documented and agreed in writing.)
|
Formal Change Control procedure must be
in place and used. The baseline for
controlling changes is the definition of requirements. Changes from the defined requirements, must
be agreed before becoming firm in the design.
|
||||
D150
|
Define and instigate Project Team
responsibilities and techniques for technical support, bug reporting, fixing,
ERP liaison etc.
|
Optional - normal practice where there
are several people in the team.
|
During development there is a need for
clear responsibilities to be defined for running and supporting the
development system. For example, who
applies bug fixes? Who runs the batch jobs?
Who sets up the security access rights?
|
||||
D190
|
Issues - control, escalate, resolve
|
Optional - used where there are several
people involved in the project
|
Issues that arise during the design
work are noted, logged, controlled and resolved. Escalation and tie-breaking mechanisms are
used where necessary.
|
||||
D211
|
Plan & prepare ERP prototyping
facilities
|
Normal practice for iterative
prototyping
|
Agree and set up the procedures and
facilities for the iterative prototyping work. Make sure developers will not adversely
impact upon the work of others.
|
||||
|
|
||||||
Plan and Initiate Team Training Process |
|
||||||
D120
|
Plan, prepare and conduct ERP and
general training for project participants
|
Optional - usually required unless
whole team have requisite experience in all aspects of the solution.
|
Normally, team members need training
before productive work can commence.
Training may also be appropriate for management and other staff
working with the project team.
|
||||
D115
|
Team building and education
|
Optional - good practice with large
teams
|
General workshops and events for the
project team may be used to ensure a common commitment to the project's
objectives and approach.
|
||||
L200
|
Present approach to user community and
team
|
Optional - good practice where there is
a large or diverse user base involved
|
General workshops and events for client
management and affected users may be used to ensure a common understanding of
the project's objectives and needs.
|
||||
|
|
|
|||||
Build base model |
|
|
|||||
D322
|
Define, agree and set up global ERP parameters
|
Normal practice in Prototyping
|
Essential global parameters must be
configured before the general prototyping work can be undertaken. These will often affect future phases or
modules so it is important they are considered in detail for the full defined
programme.
|
||||
D324
|
Define, agree and set up ERP Organisational Structures
|
Normal Practice for ERP implementations
|
The ERP organisation structures should
be determined, set up and agreed.
|
||||
D354
|
Select Business Processes from ERP Reference Model
|
Normal Practice for ERP implementations
where the reference model is being used.
|
Select processes from the ERP Reference
Model. Examine any business process
options which remain outstanding and agree the best practice to be adopted
within the capabilities of ERP.
|
||||
D364
|
Configure initial ERP system as
prototyping model
|
Normal Practice for ERP implementations
|
Set up essential initial master data,
transaction data, periodic data, procedures, reports etc (not organisational
structure). Use preconfigured standard
solutions where available.
|
||||
D383
|
Build core testing data for prototyping
|
Normal Practice for ERP implementations
|
Build test data scenarios for use
during the iterative prototyping process
|
||||
D400
|
Design / prototype by topic
|
Optional - In Base Model relatively few
issues will require fresh design decisions as the basic design will have been
established in the Project Model (iterative design is undertaken in the
"Prototyping Process" - see below).
Can alternatively use D450
|
Design or define each topic using
prototyping techniques wherever appropriate,
documenting the requirements, options, recommended approach and
details in an Implementation Paper per topic.
|
||||
D450
|
Design / prototype by topic (brief)
|
Optional - In Base Model relatively few
issues will require fresh design decisions as the basic design will have been
established in the Project Model
(iterative design is undertaken in the "Prototyping Process"
- see below). Can alternatively use
D400
|
Design or define each topic within the
project, using prototyping techniques wherever appropriate, documenting the recommended approach and
details in a Brief Implementation Paper (BIP) per topic.
|
||||
D466
|
Users present model to client
organisation in workshop
|
Optional - used where value is added
|
"User" members of the project
team present the model to a wider audience of management and users. This builds commitment and understanding,
and helps to reinforce the team members' understanding of both the needs and
the prototype solution.
|
||||
D160
|
Consider, review and plan approach to
interfacing and systems integration
|
Optional - used where there will be significant
interfacing or integration.
|
This process looks at the issues which
arise out of the desired levels of integration between separate elements of
the overall project and with external systems. Plans and approaches will be modified
accordingly.
|
||||
D167
|
Consider and review needs for development software or
custom development and modifications
|
Optional - used where gaps in
functionality have been identified and the client organisation wishes them to
be addressed by custom development
|
Where gaps in the available functionality
have been identified, the use of custom development may be considered. This may involve the use of ERP customising tool, external
report writers or programming languages.
Normally such changes increase the costs and risks.
|
||||
D170
|
Build / maintain data dictionary / data
model
|
Optional - not recommended except where
required by the client, or where the technical solution is part of a larger
database, or where an enterprise data model is in use.
|
Build or revise a data model for the
system. Normally a formal approach
would be used depending on the
organisation’s usual practice.
|
||||
| |||||||
Prototyping process |
|
|
|||||
D180
|
Data Conversion Strategy
|
Optional - used where existing data
will be brought into the new system
|
A study should be made into the needs
for data conversion. Data availability
and integrity is often wrongly assumed during design work. ERP specific tools should be considered. Recommendations will be made for securing
data as required.
|
||||
D300
|
Prepare discussion papers
|
Optional - discussion papers may have
been identified in the segment plan or may be used to explore any particular
issue that arises as the team see fit.
|
These are short papers covering a
particular subject. They are not
formally controlled, reviewed or signed off.
Their purpose is to assist in the process of deciding an issue during
the design work.
|
||||
D392
|
Set up, execute & manage ERP prototyping workshops
|
Normal Practice in prototyping
|
Identify detailed design &
policy/procedure issues on differences between the base ERP package
functionality and business processes.
Develop recommendations, eg modify the package or procedures, or
elevate issue to senior management for policy decision.
|
||||
D393
|
Manage, control, refresh core data for
prototyping
|
Normal Practice in prototyping
|
The test data bed should be proactively
managed to ensure consistency during the iterative prototyping stages, to
explore new areas and to correct earlier errors.
|
||||
D400
|
Design / prototype by topic
|
Normal practice
|
Design or define each topic using
prototyping techniques wherever appropriate,
documenting the requirements, options, recommended approach and
details in an Implementation Paper per topic.
|
||||
D450
|
Design / prototype by topic (brief)
|
Normal practice
|
Design or define each topic within the
project, using prototyping techniques wherever appropriate, documenting the recommended approach and
details in a Brief Implementation Paper (BIP) per topic.
|
||||
D471
|
Consolidate ERP prototyping results
|
Normal Practice in iterative
prototyping
|
Review the findings and conclusions
from the iterative prototyping.
Consider, in particular, what (if anything) needs to be refined
further in future iterations.
|
||||
D481
|
Resolve outstanding policy issues
|
Optional
|
Identify outstanding detailed policy /
procedure issues. Agree
recommendations, eg modify the package or procedures, or elevate issue to
senior management for policy decision.
|
||||
D488
|
Final ERP Gap Analysis
|
Normal Practice with ERP implementations
|
A final analysis of the business
solution that evolved during the prototyping process in comparison with the
originally stated business needs.
Consequences of any shortfall will be analysed and agreed. Any appropriate action will be reviewed and
agreed.
|
||||
|
|
|
|||||
Build |
|
|
|||||
D600
|
Create detailed specifications for
non-siips IT development work
|
Optional - used where non-siips IT
development tasks are involved in the overall technical solution
|
Define the technical requirements to a
sufficient level that they can be used in the detailed design, programming
and construction of a component. (nb
Most common custom needs are considered explicitly below.)
|
||||
D602
|
Finalise interface design
|
Optional - used where the are
interfaces to be developed
|
Finalise the design of components of
the interfaces based on specifications of design phase.
|
||||
D604
|
Finalise data conversion design
|
Optional - used where existing data
will be converted by automated methods
|
Finalise the design of the extraction,
validation, translation, control and input systems for data conversion.
|
||||
D606
|
Finalise design for functional
modifications / additions / custom reports
|
Optional - used where required
|
Finalise the design for functional
modifications / additions / custom reports that will be custom developed to
supplement the ERP system functionality.
|
||||
D650
|
Instigate non-siips parallel tasks
|
Optional - used where non-siips tasks
are required in the overall technical solution
|
Tasks should be instigated as
appropriate. Typically these will be undertaken by a separate programming
team. Controls may be set in place to
monitor progress, to ensure adequate quality and to ensure delivery will be
on time and within budget.
|
||||
D700
|
Configure system parameters, codes,
structures, etc
|
Normal Practice
|
Each aspect of the system's basic
configuration system should be set up in accordance with the agreed
implementation papers. Most basic
parameters will have been set during the prototyping. At this stage the full tables are
populated.
|
||||
D711
|
Set up screens, queries & report
writer etc
|
Optional - as required.
|
Each agreed optional customisation of
the system should be set up in accordance with the agreed implementation
papers. Most basic parameters will
have been set during the prototyping.
At this stage the full tables are populated.
|
||||
D656
|
Build / modify existing non-ERP application software
|
Optional - as required
|
Any software development work not based
upon the ERP Basis system is undertaken (but not necessarily by the ERP project team).
|
||||
D658
|
Build / modify ERP package software
|
Optional - as required
|
Produce and unit test development software
components of the system based on specifications. Create interface, new application/
conversion programs, plus modification of existing applications/system
software, installation of supplementary software etc.
|
No comments :
Post a Comment