sop for erp programme - design review and completeness checks

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.



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



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



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.



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



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



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.




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



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.



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


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


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



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


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.



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



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