Oracle AIM for Business Flow

AIM for Business FlowsOverview

ABFEjaz HussainOracle Consultant0Traditional AIMIt is known as Ask and Do.It is requirements drivenand solution is derived based on the requirements during the project.The approach is taken on a modular basis.

AIM for Business FlowIt is Show and Tell solution driven approach.Solution Flows are defined before the start of project. It is based on iterative approach based where multiple runs of CRPsare done.It aims at avoiding customizations and prioritizes all changes.There is a strong emphasis on integrated view and focus is on cross module process flows.AIM For Business Flows 1Definitions1AIM For Business Flows 2Traditional AIM vs. ABFTraditional AIMAIM For Business Flows (ABF)Requirements drivenSolution DrivenSolution defined during project based on requirementsFlow solution defined before start of projectTraditional Waterfall approachIterative approach based on CRPsDefines customisations where std functionality does not meet reqsSeeks to avoid customisation and prioritises all changesFocus on individual modulesFocus on cross module process flows2Traditional AIM implementations can be characterized as starting with a blank piece of paper and asking the customer: What do you want? and then mapping these requirements to Oracle applications. The focus is on what the customer would like to have, which frequently includes nice to haves and elements that the applications cannot provide without custom extensions.

AIM for Business Flows, on the other hand, seeks to reduce implementation time and cost by focussing on a pre-defined flow solution, reducing the need for extensive requirements analysis and avoiding expensive customisations.

You could add that in AIM for Flows the system testing begins early an is iterative vs. one testing cycle in AIM. End users are exposed to the solution during the whole cycle of the project. Use of predefined flows as starting pointApproach is solution driven not requirements drivenUse of iterative Conference Room Pilots (CRP) with a live systemUse of pre-existing delivery assets, if availableCustomers willingness to adopt basic elements of E-Business Suite best practices as described in flows

AIM For Business Flows 3What makes an implementation Flow Based?3Accelerated implementation timeframesImproved communications Improved quality of resulting business systemReduced number of custom extensions, reduced riskImproved ROI

AIM For Business Flows 4Benefits of Using AIM for Business Flows4

AIM For Business Flows 6AIM for Business Flows with AcceleratorsCRP Definitions (for EBS)AIM For Business Flows 7Phase CRP Objectives Definition CRP 1.0 Familiarize the customer with the Business Flows being implemented and map Business Flows to the customers business and identify potential changes. Elaboration CRP 2.0 Validate customer Chart of Accounts, Multi-Org Structure, TCA structure and other personalized setups identified during CRP 1. Refine mapping of Business Flows to the customers business and identify any remaining changes necessary. The conclusion of CRP 2.0 should result in a frozen solution scope. Build CRP 3.0 Business System Test of tailored solution including custom extensions and sample converted legacy data. Refinement of solution is still an option at this point, but the scope of changes should be small by this time. Significant changes at this point may indicate the need for an additional CRP 3 iteration. 7Talk About:This is taken from the old SDGNote that Business Architecture workshops are separate from CRP1CRP 1FamiliarizationInitial mapping & identify gapsIdentify setup required for CRP2 instance (e.g. COA, Multi-Org, TCA)CRP 2Refine mapping and gapsValidate flow setup Validate business process (flows)Identify & build extensions, interfacesFreeze scopeCRP 3Business System Test (test extensions, interfaces, performance)

AIM For Business Flows 8CRP Objectives8The iterative, hands-on business system design refinement evolutions utilized in the AIM for Business Flows approach are conducted in a Conference Room Pilot, or CRP, style. A Conference Room Pilot (CRP) refers to the technique and activities surrounding the planning and execution of one or more business scenarios aimed at validating the application system against the clients business needs. The origin of the term comes from the practice of placing workstations in a conference room and arranging them in a particular order (usually by logical process or Business Flow) for testing. Test scripts were then passed down the line from one tester to the next according to the natural flow of the business process. Traditionally, a CRP usually involved performing tests to check the validity of application setups, the integration of business flows within the target application system, the validity of converted data, and the adequacy of end-user procedural documentation. In the context of AIM for Business Flows, a CRP is employed primarily to determine the degree to which a defined Business Flow matches a customers business need, and to identify changes that are necessary and appropriate for the customer scenario. It is important to establish the goal of each CRP ahead of time and to then review the execution of the CRP to determine whether or not the goal was achieved. The objective of CRP 1 is to familiarize the customer with the Business Flows being implemented and map Business Flows to the customers business to identify any potential changes. The objective of CRP 2 is to validate customer Chart of Accounts, Multi-Org Structure, TCA structure and other personalized setups identified during CRP 1. Refine mapping of Business Flows to the customers business and identify any remaining changes necessary. The conclusion of CRP 2.0 should result in a frozen solution scope. CRP 3s objective is to conduct a Business System Test of the tailored solution including custom extensions and sample converted legacy data. Refinement of the business solution is still an option at this point, but the scope of changes should be small by this time. Significant changes at this point may indicate the need for an additional CRP 3 iteration.

AIM For Business Flows 9Summary of ABFGeneral Flow Solution DocumentsGeneral Document NameCRP1CRP2CRP3High Level Solution Documentv 1v 2-Financial & Operation Structure v 1--Future Business Modelv 1v 2-Business Requirements Mapping Gapsv 1v 2-Test Scripts (test results)v 0v 1v 2Set up Documentsv 0v 1v 2Apps Extension Functional Designv 0v 1= Sign off9Talk about:These are the essential general names of ABF documents. Actual names and code numbers can and will vary according to country tradition. We are waiting for final names from Methods and Tools .High-Level Solution Document Combines Business Flow Diagrams and narrative description of business processesPreliminary version may be available from pre-sales activities/workshopsClearly defines whats included/not included Prepared (or updated) after completion of CRP 1Updated again after completion of CRP 2 Defines scope of business solution to be system tested/validated during CRP 3Future Business Models include the Flow PPTs and basic process stepsBusiness Requirements Mapping Gaps will include all gaps, issues etc that needs to be closed before CRP2 can be closedv 0 = it might be available or might just be a template

AIM For Business Flows 10Definition PhaseObjectives: Plan the project Familiarize customer with Flows Map Flows to the Business Identify potential changes

Key Activities: Build/update Delivery Assets Prepare CRP 1 Environments Conduct Business ArchitectureWorkshops Customer Education on CRP Process Conduct CRP 1

Outputs: CRP 1 Results Preliminary Conceptual Architecture Key Configurations (COA, TCA, Multi-Org)DefinitionTransitionProductionElaborationBuild Tasks & ActivitiesBusiness Architecture WorkshopsCRP 1 DeliverablesBusiness Flows mapped to Customers businessHigh Level Solution Document10Now, lets look at each of the AIM for Business Flows Phases in order:The goal of the Definition phase is to plan the project, and rapidly establish a pre-configured and tested environment for familiarizing the customer with the Business Flows being implemented. During Definition, workshops are conducted to educate the customer about critical decisions to be made regarding application architecture components, such as the Chart of Accounts Structure, Multi-Org Structure, and Trading Community Architecture. These workshops are also intended to assist the customer in defining those entities. One Conference Room Pilot (CRP) is programmed for the Definition Phase CRP 1. The focus of CRP 1 is to familiarize the customer with the Business Flows being implemented and map the Business Flows to the customers business, while identifying any potential changes that are required to personalize the system to better fit the customers needs. Key outputs of the Definition Phase include, CRP 1 Results, Preliminary Conceptual Architecture and definition of key configurations for the COA, TCA and Multi-Org structures.

AIM For Business Flows 11Definition PhaseTask and DeliverablesTaskDeliverablesCRP1 workshop Future Process ModelingBF.015 V1Map Business RequirementsBF.003 baseline (previously known as BR030)BF.040 Change CatalogSetup Document for CRP2BF.016 Setup Document V1Test ScriptsTE.040 System Test Script V1Data ConversionCV.010 Define Data conversion Requirements and StrategyPhase End ReviewBF.100 conduct phase end reviewAIM For Business Flows 12Elaboration PhaseDefinitionTransitionProduction ElaborationBuildObjectives: Validate COA, TCA, Multi-Org Setups Refine mapping of Flows Identify remaining changes Design Custom Extensions Determine/freeze scope of solution

Key Activities: Prepare CRP 2 Environment Design custom extensions Conduct CRP 2 Solution Review and Sign-off

Outputs: Refined Configuration Approved designs for customizations Conversion Data Mapping Updated Test Scripts High-Level Solution Document Tasks & ActivitiesGap HandlingCRP 2sUpdate documentsDesigns for conversions, extensions, interfaces DeliverablesAccepted Solution with updated documentsDesigns for conversions, extensions, interfaces approved12The goal of the Elaboration phase is to refine the solution through a second Conference Room Pilot (CRP) cycle. This second Conference Pilot provides the first opportunity to validate the customers tailored Chart of Accounts structure, Multi-Org structure and Trading Community Architecture. It also provides an initial look at some of the other changes resulting from process or configuration modifications identified during CRP 1.

Elaboration also encompasses the design of custom extensions, refinement of the technical architecture design, and a number of Data Conversion and Performance Testing preparatory activities.

Key outputs of the Elaboration Phase include a refined configuration, approved designs for custom extensions, the conversion data mapping and program designs, updated Test Scripts and a final version of the High-Level Solution document detailing the scope of the business system to be implemented.

TaskDeliverablesCRP2 WorkshopsBF.040 Conduct WorkshopFuture Process ModelingBF.015 Future Process Model V 2 (FINAL)Setup Document for CRP3BF.016 Setup Document V2Customizations:MD.050: Functional Extension Design V1MD.060 Database Extension Designs V1MD.070 Technical Design V1Test ScriptsTE.040 System Test Scripts V2Data MigrationCV.050 Define Manual Conversion ProceduresPhase End ReviewBF.100 v2 Conduct Phase End Review AIM For Business Flows 13Elaboration PhaseTask and DeliverablesAIM For Business Flows 14Build PhaseDefinitionTransitionProductionElaborationBuildObjectives: Develop, test, and accept custom software Propose a transition strategy Execute performance test Conduct a system test Finalize the solution

Key Activities: Create & test custom extensions Prepare CRP 3 Environment Conduct CRP 3 Conduct User Acceptance Test

Outputs: System Tested Applications User Acceptance Test Results Performance Test Report Transition and Contingency Plan Tasks & ActivitiesFinalize conversions, interfaces, extensionsCRP 3 = System and Integration TestingUser Acceptance Testing

DeliverablesTested SolutionFinal designs for extensions, interfacesTransition Plan14The goal of the Build phase is to confirm that the overall solution meets the customers business needs. During the Build phase, custom extensions are developed and Unit and Link tested, the CRP 3.0 environment is prepared incorporating custom extensions for the first time, and also incorporating sample converted legacy data, if applicable. Application configuration changes resulting from CRP 2.0 are also validated during this test cycle. Only minor changes, if any, should be identified during this phase.

Key outputs of the Build Phase include, System Tested applications, User Acceptance test results, a Performance test report if in scope, and the transition and contingency plan.

TaskDeliverablesKey User TrainingBuild Extensions, Interfaces and ConversionsMD.050 Functional Extension Design V2MD.060 Database Extension Design V2MD.070 Technical Design V2MD.120 Create Installation Routines

CRP3 System and Integration TestingTE.040 System Test Scripts V3 (FINAL)Conduct UATUser Acceptance Testing on Final SolutionSetup Document for PRODUCTIONBF.016 Setup Document V3 (FINAL)Security ProfilesBF.170 Security ProfilesUser ManualsDO.070 User Guide V1AIM For Business Flows 15Build PhaseTask and DeliverablesAIM For Business Flows 16Transition PhaseDefinitionTransitionProductionElaborationBuildObjectives: Prepare Production Environment Convert and verify legacy dataTrain user personnel Transition to Production

Key Activities: Plan Transition Go-Live Checklist Final System Check Users & Support Ready Convert & Load DataDeploy extensions and interfacesProduction Readiness Review Fallback Plan

Outputs: Converted and verified data Skilled Users Production Support Infrastructure Production system ready GO-LIVE16During Transition, the project team deploys the new system into the organization. All the elements of the implementation must come together to transition successfully to production. The project team trains the users, while the technical team prepares the Production Environment and converts legacy data.

During Transition, users verify that the new system is ready for Production use. Transition is a demanding experience for the project team, and in particular, for the users who may have to maintain two systems until a new production system is declared.

Key outputs of the Transition Phase include converted and verified legacy data, trained users, and a production ready applications system with support infrastructure in place. The Transition Phase culminates with GO-LIVE.

AIM For Business Flows 17Production PhaseDefinitionTransition ProductionElaborationBuildObjectives: Maintain the Production System Measure System Performance Promote user acceptance Propose and plan future direction

Key Activities: Assess effectiveness of system Reinforce adoption of system Recommend Business direction Recommend technical direction

Outputs: Effectiveness Assessment Business Direction RecommendationsTechnical Direction Recommendations17Production begins immediately with the cutover to production. It marks the last phase of the implementation and the beginning of the system support cycle. A series of refinements and performance measurement steps are included in this final phase.

Thank You!It is Business Process Mapping, the goal is to familiarize the Customer with Oracle Business Flows and conduct the initial mapping of flows to the clients business.

AIM For Business Flows BF ProcessTechnical Architecture Process: Its goal is to design an information system architecture that realizes the business vision.

AIM For Business Flows TA ProcessModule Design and Build process:It focuses on the design and development of customizations to satisfy functionality gaps.

AIM For Business Flows MD ProcessData Conversion: The goal is to convert all legacy data necessary for the operation of the new system.AIM For Business Flows CV ProcessThe Documentation or DO process augments Oracle Applications manuals with information about customizations and business procedures.

AIM For Business Flows DO ProcessThe Business System Testing or TE process has the goal of refining the business solution through iterative Conference Room Pilots and testing the quality of all elements of the application system

AIM For Business Flows TE ProcessThe Performance Testing or PT process involves the definition, construction, and execution of a performance test

AIM For Business Flows PT ProcessThe Adoption and Learner (AP) process fosters acceptance of the new applications by all users - UAT

AIM For Business Flows AP Process26The goal of the Production Migration (PM) process is to migrate the organization, systems, and people to the new enterprise system

AIM For Business Flows PM Process