sop for erp programme - design review and completeness checks
TRANSCRIPT
8/18/2019 SOP for ERP Programme - Design Review and Completeness Checks
http://slidepdf.com/reader/full/sop-for-erp-programme-design-review-and-completeness-checks 1/13
SOP for ERP Programme - Design Review &
Completeness Checks(SOP_00000227189)
Role and Reason for Approval
Job Title or Role Reason for Approval
Author
The author is signing to confirm that this document has been preparedin accordance with an approved document management process, thatrelevant input from any contributory authors has been included and thatan appropriate review / editing process has been conducted.
Head TSSThe Approver is signing to confirm that the Document meets therequirements for which it is defined.
PrincipalFunctionalConsultant
The Approver is signing to confirm that the Document meets therequirements for which it is defined.
QRCTo confirm compliance with applicable regulatory expectations and ITCorporate Policy and standards
QA To confirm compliance with applicable pharmaceutical regulatoryagency expectations and Company standards.
8/18/2019 SOP for ERP Programme - Design Review and Completeness Checks
http://slidepdf.com/reader/full/sop-for-erp-programme-design-review-and-completeness-checks 2/13
Table of Contents
1 Process Overview.................................................................................................3
2 Instructions ...........................................................................................................42.1 Design and Blueprint Phase-Gate Checkpoint........................................................52.1.1 Process Flow ..........................................................................................................52.1.2 Process Step Description........................................................................................62.2 Entry to Formal Testing Checkpoint........................................................................62.2.1 Process Flow ..........................................................................................................62.2.2 Process Step Description........................................................................................82.3 Go-Live Go-No-Go Checkpoint.............................................................................102.3.1 Process Flow ........................................................................................................102.3.2 Process Step Description......................................................................................10
3 Role and Responsibilities ..................................................................................11
4 Training................................................................................................................12
5 References ..........................................................................................................12
6 Revision History..................................................................................................12
7 Risk, Control and Monitoring Matrix ................................................................. 12
8/18/2019 SOP for ERP Programme - Design Review and Completeness Checks
http://slidepdf.com/reader/full/sop-for-erp-programme-design-review-and-completeness-checks 3/13
1 Process Overview
The purpose of this LSOP is to describe and formalise the Design Review approach andCompleteness Check activities during Waves/Sub-Projects with a programme Release. It alsodescribes the Report form to be populated, the frequency of approval and the risk basedapproach to design review.
Supplier InputsProcessPurpose/Mainsteps
OutputsCustomer
Design Authority(DA) /TemplateReview Board
(TRB)EnterpriseProcess Owners(EPOs) / GlobalProcess Owners(GPOs)
PrincipalFunctionalConsultants
Technical Leads
Detail Design &Build Teams
ApprovedMarket/SiteSituation Target
Proposals (STPs)Business ProcessSolution Designdocuments(BPSDs)
FRICE SystemRequirements(FRICE SRs)
DesignSpecifications(DSs)
Configuration
Documents (CDs)Nodes andLinkages with theSolution Managertool
Identifyrequirementsdocuments
impacted by STPs.Track to approvalfor Design &Blueprint PhaseGate exit.
Identify designdocumentsimpacted by STPand check contentcoverage.
Identify if anydesign documentsare non-standarddesign and raise arisk on DA.
Trackrequirements anddesign documentsto approval forFormal Test EntryCheck.
Trackrequirements anddesign documentsto approval for Go-Live Checkpoint
Design Review &CompletenessReports approved at
1. Exit from Design& Blueprint Phase
2. Entry Checks forFormal Testing
3. Go-Live Go-No-Go checks
Project Mgt Office
Test Management
Cut-Over Governance
functionQuality Functions
8/18/2019 SOP for ERP Programme - Design Review and Completeness Checks
http://slidepdf.com/reader/full/sop-for-erp-programme-design-review-and-completeness-checks 4/13
Process Owner Wave Solution Delivery Manager
Exclusions None
Customerexpectations
Project Management Office:
Evidence that the requirements capture and high level design phase of theWave has completed
Test Management:
Evidence that input documentation to the testing activity is complete and hencetest scripts are valid
Cutover Governance:
Evidence that key wave documentation is approved and ready for supportfunctions
Quality Function:
Evidence that completeness checks have been performed
Evidence that design risk has been mitigated
2 Instructions
The end to end process for the design review aspect starts before the Wave commences.Prior to the Wave commencement all STPs are design reviewed by the Design Authority whodrive them towards standard SAP solutions, or where a bespoke solution is necessary,towards ERP Programme development standards. This reduces design risk and increasessupportability before the Wave commences. This process is described in SOP_000224026SOP for ERP Programme Design Authority [1]
Once the Wave commences, further Design Review and Completeness Checks areconducted at three points in the Wave as described in the 3 sections below. A standardtemplate is used to capture the information and is issued as an Approved report.
Risk based approach: the Review Report template [2] captures the minimum requiredinformation and is approved a minimum of three versions per Wave. Additional columns androws may be added by a Wave or sub-Project to capture additional level of detail andadditional versions may be approved as deemed necessary.
8/18/2019 SOP for ERP Programme - Design Review and Completeness Checks
http://slidepdf.com/reader/full/sop-for-erp-programme-design-review-and-completeness-checks 5/13
2.1 Detail Design Phase-Gate Checkpoint
2.1.1 Process Flow
1) Identify & recordSTPs in scope forWave
2) Identify impactedBPSDs
3) Identify impactedFRICE SRs
4) Check BPSDsare in ‘Approved’status. Record ‘Y’or ‘N’
5) Check FRICESRs are linked toBPSDs and in‘Approved’ status.Record ‘Y’ or ‘N’
6) Report Reviewerscheck standardConclusions forCheck Point 1
8) Some items arefalse incomplete,
so complete riskand actions section#4
9) Approve Reportand provide data toProjectManagement
Office Phase Gatecheck.
7) Are all items
complete &Conclusionstrue ?
No
Yes
8/18/2019 SOP for ERP Programme - Design Review and Completeness Checks
http://slidepdf.com/reader/full/sop-for-erp-programme-design-review-and-completeness-checks 6/13
2.1.2 Process Step Description
Step Description
1 Identify STPs approved by Template Review Board as in scope for the Wave. Recordthese STPs in the Review Report form for the Wave.
2 From the in scope STPs identify the impacted BPSDs (new or existing to be updated).Record these BPSDs in the Review Report form against their respective STPs.
3 Identify the impacted FRICE SRs (new or existing to be updated). Record these FRICESRs in the Review Report form against their respective BPSDs.
4 Check all BPSDs for ‘Approved’ status in Solution Manager
5 Check all FRICE SRs are linked to their respective BPSDs in Solution Manager and for‘Approved’ status in Solution Manager.
6 Report Reviewers confirm the standard Conclusions are met for Checkpoint 1 (Note:The standard Conclusions should not be altered).
7 The standard Checkpoint #1 Conclusion is:
1.1 All Stream requirements in scope for the Wave / Project have been captured in thelisted BPSDs.
1.2 Each FRICE SR's contents cover all the development requirements identified byDevelopment IDs in the BPSD -
1.3 All the FRICE SRs are linked to their corresponding BPSDs in Solution Manager 1.4 All Detail Design Phase design deliverables have been approved in SolutionManager
Identify and record each of the above as True of False
If any of the conclusions above have not been checked as True, go to Step 8; else goto Step 9
8 The specific incomplete item(s) with associated Risks and mitigating Actions must bedescribed in Section #4 of the Conclusions
9 Approve the first iteration of the Report and feed data to Project Management Office to
support the Design & Blueprint Phase Gate.
2.2 Entry to Formal Testing Checkpoint
2.2.1 Process Flow
8/18/2019 SOP for ERP Programme - Design Review and Completeness Checks
http://slidepdf.com/reader/full/sop-for-erp-programme-design-review-and-completeness-checks 7/13
1) Update status ofBPSDs and FRICESRs since previouscheckpoint
2b) Identify DesignSpecifications (DS)impacted by STPs
3b) Check all DSsare linked and Approved in SolutionManager.
4) Confirm DS contentcovers all FRICE SRrequirements. Recordnamed individualproviding theconfirmation.
5) Perform technicalcheck that DS contentconforms to ERPprogramme designstandards. Record ‘Y’ or‘N’
7) Raise
Programme Riskfor non-standarddesign. RecordRisk #
8) Record ‘N/A’.
6) DSconforms toDesignStandard?
No
Yes
2a) IdentifyConfigurationDocuments (CDs)impacted by STPs
3b) Check all CDsare linked and Approved in SolutionManager.
8/18/2019 SOP for ERP Programme - Design Review and Completeness Checks
http://slidepdf.com/reader/full/sop-for-erp-programme-design-review-and-completeness-checks 8/13
2.2.2 Process Step Description
Step Description
1 Take a copy of the previously approved Design Review Report and update status of
BPSDs and FRICE SRs since the previous checkpoint in a new version. The status ofthese may have changed due to updates.
2 Identify
a) Design Specifications
b) Configuration Documents
impacted by the in-scope STPs (new or updates) and record in a new version of theReport
9) Track closurestatus of Risks #s (ifany) until Reportversion 2 approvaldate. Record ‘Y’ or‘N’
12) Some itemsare false/incomplete, soupdate risk andactions section#4
13) Approve
Report and providedata to TestManagement forTest Entry CriteriaChecks.
11) Are allitems complete& Conclusions1 & 2 true?
No
Yes
10) ReportReviewers checkstandardConclusions for
Check Points 1 and2
8/18/2019 SOP for ERP Programme - Design Review and Completeness Checks
http://slidepdf.com/reader/full/sop-for-erp-programme-design-review-and-completeness-checks 9/13
3 a) Check all Design Specifications are linked to their respective BPSDs in Solution
Manager and for ‘Approved’ status in Solution Manager.
b) Check all Configuration Documents are linked to their respective BPSDs in SolutionManager and for ‘Approved’ status in Solution Manager. If the Configuration documentis a Package Configuration Specification, then check for approval status CDMS
4 Confirm each Design Specification’s content covers all the associated FRICE SRrequirements. Record named individual providing the confirmation in the ReviewReport.
5 The Technical Lead for the Wave / sub-Project Perform must do a technical check toensure that the DS content conforms to ERP programme design standards. Record ‘Y’or ‘N’ for each DS.
6 If the design does not conform, Go To Step 7,Else go to Step 8
7 Raise a Programme Risk for non-standard design and assign to an appropriate Design Authority member. Record the Risk #.
8 Record ‘N/A’
9 Track closure status of Risks #s (if any) until Report version 2 approval date. Record‘Y’ if Risk has been closed or ‘N’ if still open.
10 The Report enters the review cycle. Report Reviewers confirm the standardConclusions are met for both Check Points 1 and 2
The standard Checkpoint #1 Conclusion is:1.1 All Stream requirements in scope for the Wave / Project have been captured in thelisted BPSDs.
1.2 Each FRICE SR's contents cover all the development requirements identified byDevelopment IDs in the BPSD -
1.3 All the FRICE SRs are linked to their corresponding BPSDs in Solution Manager
1.4 All Design & Blueprint Phase design deliverables have been approved in SolutionManager
The standard Checkpoint #2 Conclusion is:
2.1 All FRICE SRs have a corresponding approved Design Specification(s)
2.2 The Design Specification elements cover the FRICE SR requirements
2.3 All the Design Specifications are linked to their corresponding BPSDs in SolutionManager
2.4 All Designs conform to ERP standards and where not, a Risk has been raised andescalated to ERP Design Authority for resolution
2.5 All Design Risks have been closed by a Design Authority member.
8/18/2019 SOP for ERP Programme - Design Review and Completeness Checks
http://slidepdf.com/reader/full/sop-for-erp-programme-design-review-and-completeness-checks 10/13
Identify and record each of the above as True of False
11 If any of the conclusions above have not been checked as True, go to Step 12; else go
to Step 13
12 The specific incomplete item(s) with associated Risks and mitigating Actions must bedescribed in Section #4 of the Conclusions
13 Approve the Report and provide data to Test Management for Test Entry CriteriaChecks prior to entry into Formal Testing Phase.
2.3 Go-Live Go-No-Go Checkpoint
2.3.1 Process Flow
2.3.2 Process Step Description
1) Update all statuschecks for STPs,BPSDs and FRICESRs.
2) Update Checkpoint 1Conclusion and relatedRisks & Actions
3) Update all status
checks for DSs,CDs & DesignRisks
4) Update Checkpoint 2
Conclusions and relatedRisks & Actions
7) Review andapprove Reportversion 3 and reportdata to Go Live GNGcheckpoints.
5) Are all itemscomplete &Conclusions 1& 2 true?
6) Some items arefalse incomplete,so complete riskand actions section#4
No Yes
8/18/2019 SOP for ERP Programme - Design Review and Completeness Checks
http://slidepdf.com/reader/full/sop-for-erp-programme-design-review-and-completeness-checks 11/13
Step Description
1 Update all status checks for STPs, BPSDs and FRICE SRs as these may haveundergone updates due to late changes or testing defect fixes.
2 Update Checkpoint 1 Conclusion by checking the conclusion is still valid and amendingor adding related Risks & Actions.
3 Update all status checks for CDs and DSs as these may have undergone updates due
to late changes or testing defect fixes.
4 Update Checkpoint 2 Conclusion by checking the conclusion is still valid and amendingor adding related Risks & Actions
5 If any of the conclusions above have not been checked as True, go to Step #6; else goto Step #7
6 The specific incomplete item(s) with associated Risks and mitigating Actions must bedescribed in Section #4 of the Conclusions
7 Review and approve Report version 3 and report data to Go Live Go-No-Gocheckpoints.
3 Role and ResponsibilitiesWave Delivery Lead / Sub-Project Manager:
Ensure the checks in this SOP are planned and carried out.
Ensure the versions of this report are issued to coincide with the key programmemilestones:
o Design & Blueprint Phase Gate Exit
o Entry Checks for Formal Testing
o Go Live Go-No-Go Checkpoints
Principle Functional Consultant (or delegate):
All checks in this SOP associated with STPs, BPSDs, FRICE SRs and ConfigurationDocuments
Wave Technical Lead (or delegate):
All checks in this SOP associated with Design Specifications, Design Risks and ERPDesign Standards
Notes:
1. Process Owner: This process is jointly owned by Technical Shared Services andPrincipal Functional Consultants.
8/18/2019 SOP for ERP Programme - Design Review and Completeness Checks
http://slidepdf.com/reader/full/sop-for-erp-programme-design-review-and-completeness-checks 12/13
4 TrainingThe following user groups must complete MyLearning TEC-190-227189:
Delivery Leads / Project Managers
Functional Consultants
Technical Leads
QRC
5 References
No Document ID Document Title
1 SOP_00000224026 GSS SOP for ERP Programme Design Review
2 REC_ 00000228282 Review Report Template with Guidance
6 Revision History
Version Reason for Revision
1.0 This is the first issue of this procedure
2.0
Changes to this version are not considered to be Technical Changes; therefore there is norequirement for existing users to retrain in this new version.
Reference section updated from SOP_00000224026 – SOP for ERP Programme Design Authority to SOP_00000224026 – GSS SOP for ERP Programme Design Authority
Please note that the signature box on this document reflects the workflow panel from theprevious version. This is an admin change and so requires only 2 signatures.
3.0
Administrative change in accordance with INS_16038 to correct title in reference sectionfor document SOP_00000224026.
Please note that the signature box on this document reflects theworkflow panel from theprevious version. This is an admin change and so requires approval by QA
7 Risk, Control and Monitoring Matrix
ID Process/RiskArea
Key Risks Key Control(s)
Test of Key Control(s)
1 Incompleterequirements and
Build rework. Existing Design &Blueprint Phase Gate
Test:
That the key controls are
8/18/2019 SOP for ERP Programme - Design Review and Completeness Checks
http://slidepdf.com/reader/full/sop-for-erp-programme-design-review-and-completeness-checks 13/13
ID Process/RiskArea
Key Risks Key Control(s)
Test of Key Control(s)
designdocumentation.
Actual Design hasdrifted away fromstandard designintentions of theDesign Authoritywhen scoping theWave.
Avoidable failures intesting.
Support hasincompletedocumentation aftergo-live.
Design becomescomplex, non-standard andsupportability suffers
Check. This SOPsupports that control.
Existing EntryChecks to FormalTesting. This SOPsupports that control.
Existing Go-Live Go-No-Go Checks ondocumentation. ThisSOP supports that
control.
ExistingComplexity/Non-Standard designchecks at the STPstage prior to theWave scope beingfinalized. This SOPsupplements thatcheck.
operating and this process isfeeding into those controls asintended.
Frequency:
This sample frequency willchange as necessary – defaultwill be defined in IT QRCControls Framework.
Responsible Group
QRC