CRP for Oracle R12
Conference Room Pilots (CRPs) are interpreted by different organizations in different ways and can be used in a variety of project types. The R12 project will have 3 conference room pilots followed by user acceptance testing (UAT). The overall goals will be to allow discrete transactional areas of the solution to be validated, with later CRPs building towards demonstrating end to end business scenarios in the new solution.
CRP1 will include:· Process:
An overview of current WU process and best practice process recommendations from ESolutions.
· System:Demonstration of a subset of the standard Oracle R12 functionality, with small amounts of representative data. (CRP1 is not a user training session. User participants will not follow along on their own PCs.)
· Scope:Discussion of ESolution’s recommendations for best practice where applicable to Western Union. Scope review based on ESolution’s recommendations together with the steering committee recommendations to determine the scope baseline for the Oracle R12 project. Gathering of high-level requirements - identify how well the application meets business needs, and identify gaps, whilst still in the design phase of the project.
· User Input:An opportunity for users to ask questions and get feedback on the proposed configuration and use of the software. Business attendees will provide many observations and areas of feedback to the project team which will be recorded by the functional team. If these cannot be resolved during the session they will be processed once the CRP is completed with feedback provided to the representatives prior to the next CRP.
Between CRP1 and CRP2: · Detailed requirements gathering interviews will be conducted.
· “As-Is” business process modelling and gap analysis.
· Draft to-be process flows and initial software configuration completed prior to the CRP2.
· Prioritization of requirements/processes (based on business ranking and level of config/customization/development required) to be demonstrated in CRP2 or CRP3.
· Completion of requirements for “bucket one” for custom development delivered to technical team.
CRP2 will include: · Process:Functional leaders walk cross-functional teams and potential system users through flow charts. Review of key business scenarios against predefined scripts. The scenarios will be driven from the business process and requirements mapping activities carried out earlier in the project to show how the business processes, are mapped onto system functionality.
· System:Functional leaders will take the group through on-line scenario exercises. Various questions and additions to the foreseen problems are raised and alternative approaches are tested.
· User Input:User will use predefined scripts to carry out key process in the system. Most issues should be resolved by the team during the exercises or delegated for further action. Signoff by the business on high priority requirements.
· Scope:Requests for additional functionality (an increase to the baselined requirements) would need to be handled as part of the scope management process within the project and that observations raised are not automatically included in scope. Changes to the scope baseline will result in change requests to the steering committee.
Between CRP2 and CRP3:· Finalization of “To-Be” process models and gap resolution.
· Detailed requirements validation and sign-off.
· Completion of requirements for “bucket two” of requirements for custom development delivered to technical team.
· Development of training materials.
Objectives of CRP3:· Process:Functional leaders walk cross-functional teams and potential system users through final “To-Be” process models.
· System:Most converted data available for review in CRP environment.
Some RICE (Reports, Interfaces, Conversions, Enhancements / Extensions) components available for business review.
· User Input:User will be hands-on in the system completing real business scenarios from end-to-end.
Validate that any gaps identified during CRP2 have been addressed.
Continue to uncover any system / process issues and potential future phase business requirements.
· Scope:Requests for additional functionality (an increase to the baselined requirements) would need to be handled as part of the scope management process within the project and that observations raised are not automatically included in scope. Only items critical for go-live will be considered.
In summary the CRP sessions will focus on the following:
CRP-1: Discrete transactional activities
CRP-2: Proposed business processes (No RICE – custom Reports, Interfaces, Conversions, Enhancements / Extensions)
CRP-3: End to end business scenarios. Processes with converted data and some RICE components
UAT: Test 100% of functionality and end-to-end integration testing including all RICE components
CRP1 will include:· Process:
An overview of current WU process and best practice process recommendations from ESolutions.
· System:Demonstration of a subset of the standard Oracle R12 functionality, with small amounts of representative data. (CRP1 is not a user training session. User participants will not follow along on their own PCs.)
· Scope:Discussion of ESolution’s recommendations for best practice where applicable to Western Union. Scope review based on ESolution’s recommendations together with the steering committee recommendations to determine the scope baseline for the Oracle R12 project. Gathering of high-level requirements - identify how well the application meets business needs, and identify gaps, whilst still in the design phase of the project.
· User Input:An opportunity for users to ask questions and get feedback on the proposed configuration and use of the software. Business attendees will provide many observations and areas of feedback to the project team which will be recorded by the functional team. If these cannot be resolved during the session they will be processed once the CRP is completed with feedback provided to the representatives prior to the next CRP.
Between CRP1 and CRP2: · Detailed requirements gathering interviews will be conducted.
· “As-Is” business process modelling and gap analysis.
· Draft to-be process flows and initial software configuration completed prior to the CRP2.
· Prioritization of requirements/processes (based on business ranking and level of config/customization/development required) to be demonstrated in CRP2 or CRP3.
· Completion of requirements for “bucket one” for custom development delivered to technical team.
CRP2 will include: · Process:Functional leaders walk cross-functional teams and potential system users through flow charts. Review of key business scenarios against predefined scripts. The scenarios will be driven from the business process and requirements mapping activities carried out earlier in the project to show how the business processes, are mapped onto system functionality.
· System:Functional leaders will take the group through on-line scenario exercises. Various questions and additions to the foreseen problems are raised and alternative approaches are tested.
· User Input:User will use predefined scripts to carry out key process in the system. Most issues should be resolved by the team during the exercises or delegated for further action. Signoff by the business on high priority requirements.
· Scope:Requests for additional functionality (an increase to the baselined requirements) would need to be handled as part of the scope management process within the project and that observations raised are not automatically included in scope. Changes to the scope baseline will result in change requests to the steering committee.
Between CRP2 and CRP3:· Finalization of “To-Be” process models and gap resolution.
· Detailed requirements validation and sign-off.
· Completion of requirements for “bucket two” of requirements for custom development delivered to technical team.
· Development of training materials.
Objectives of CRP3:· Process:Functional leaders walk cross-functional teams and potential system users through final “To-Be” process models.
· System:Most converted data available for review in CRP environment.
Some RICE (Reports, Interfaces, Conversions, Enhancements / Extensions) components available for business review.
· User Input:User will be hands-on in the system completing real business scenarios from end-to-end.
Validate that any gaps identified during CRP2 have been addressed.
Continue to uncover any system / process issues and potential future phase business requirements.
· Scope:Requests for additional functionality (an increase to the baselined requirements) would need to be handled as part of the scope management process within the project and that observations raised are not automatically included in scope. Only items critical for go-live will be considered.
In summary the CRP sessions will focus on the following:
CRP-1: Discrete transactional activities
CRP-2: Proposed business processes (No RICE – custom Reports, Interfaces, Conversions, Enhancements / Extensions)
CRP-3: End to end business scenarios. Processes with converted data and some RICE components
UAT: Test 100% of functionality and end-to-end integration testing including all RICE components
No comments:
Post a Comment