Design, Prototyping & Construction
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 & Rollout” path.
It is divided into five main parts:
- Prepare to Prototype
- Plan and Initiate Team Training Process
- Build base model
- Prototyping process
- Build
This path has been created primarily for Package Software implementations. The processes are referred to by Package Software (SAP) specific names. Some generic processes have different titles.
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 SAP installation
|
Optional - usually required when insufficient detail was included in the Delivery Approach documentation and segment plan. (SAP-specific variant of D110.)
|
Plan in detail the physical installation of the SAP software, additional systems software, hardware, communications equipment, servers, PCs etc.
| ||||
D130
|
Install hardware, communications equipment, system software, and SAP 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, SAP 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 SAP 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 SAP 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 SAP 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 SAP R/3 Organisational Structures
|
Normal Practice for R/3 implementations
|
The R/3 organisation structures should be determined, set up and agreed.
| ||||
D354
|
Select Business Processes from SAP R/3 Reference Model
|
Normal Practice for R/3 implementations where the reference model is being used.
|
Select processes from the R/3 Reference Model. Examine any business process options which remain outstanding and agree the best practice to be adopted within the capabilities of R/3.
| ||||
D364
|
Configure initial SAP R/3 system as prototyping model
|
Normal Practice for R/3 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 R/3 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 ABAP 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 ABAP, 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 such as ARIS toolset, SSADM or Merise, 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. SAP 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 SAP prototyping workshops
|
Normal Practice in prototyping
|
Identify detailed design & policy/procedure issues on differences between the base SAP 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 SAP 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 SAP Gap Analysis
|
Normal Practice with SAP 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 SAP system functionality.
| ||||
D650
|
Instigate non-siips parallel tasks
|
Optional - used where non-siips tasks are required in the overall technical solution
|
Non-siips 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. (SAP-specific variant of D710.)
|
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-SAP application software
|
Optional - as required
|
Any software development work not based upon the SAP Basis system is undertaken (but not necessarily by the SAP project team).
| ||||
D658
|
Build / modify SAP package software
|
Optional - as required
|
Produce and unit test ABAP 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