13
Menu, Functions and Security Profile Regintala Chandra Sekhar Page 1 [email protected] Oracle HRMS Functional Document AIM Phases and Documentations Part 0.3 Note: This Document is created only for Class Room Training Purpose By Regintala Chandra Sekhar [email protected]

0.3 aim phases_and_documentations

Embed Size (px)

DESCRIPTION

AIM Phases, Application Implementation Methodology Business Groups Setup,Payroll,Elements,Oracle HRMS,Ora17hr,Employee Creation,Regintala,Responsibility,User ID,Values,Key Flexfield,Work Location,SIT,EIT, Position,Grade,People Group,Cost Allocation,Competence,Job,Soft Code,Bank Details,SIT,Specical Information Type,DFF,KFF,Business,Payment Method,BACS,Salary Basis,Payroll,GL Mapping,oraclepayroll,payroll

Citation preview

Page 1: 0.3 aim phases_and_documentations

Menu, Functions and Security Profile

Regintala Chandra Sekhar Page 1 [email protected]

Oracle HRMS Functional Document

AIM Phases and Documentations

Part 0.3

Note: This Document is created only for Class Room Training Purpose

By

Regintala Chandra Sekhar

[email protected]

Page 2: 0.3 aim phases_and_documentations

Menu, Functions and Security Profile

Regintala Chandra Sekhar Page 2 [email protected]

Table of Contents

Oracle Project AIM ....................................................................................................................................................................... 3

AIM Phases: .................................................................................................................................................................................... 3

1. Project Definition ........................................................................................................................................................... 3

2. Operation Analysis ......................................................................................................................................................... 4

3. Solution Design ................................................................................................................................................................ 4

4. Build .................................................................................................................................................................................... 4

5. Transition .......................................................................................................................................................................... 5

6. Production ......................................................................................................................................................................... 5

Trying to understand AIM (Application Implementation Methodology): ............................................................... 6

1. Understand the Existing Business Processes and current business baseline .............................................. 6

2. Creating Future Business Model .................................................................................................................................... 6

3. Business Mapping and Gap Resolution ....................................................................................................................... 7

4. Creation of Application and Technical architecture .............................................................................................. 8

5. Gaps and Interfaces Resolution ..................................................................................................................................... 9

6. Business System Testing ............................................................................................................................................... 10

7. Data Migration .................................................................................................................................................................. 11

8. Documentation ................................................................................................................................................................. 13

Page 3: 0.3 aim phases_and_documentations

Regintala Chandra Sekhar Page 3 [email protected]

Oracle Project AIM Documents which are Prepared at the time of Implementation

Documents BR Business Mapping and Gap Resolution 10 30 50 90 100 110

MD Gaps and Interface Resolutions 50 70 80 90 110 120

TE Business System Testing 20 30 40 50 60 70 80 100 110 120 130

BP Business Process Document 40 70 80

CF

CV Data Migration 10 50 60 70 80 90 100 110 130

RD Business Requirement Document 20 50 80

TA Creation of Application and Technical Architecture 10 120 140 150

DO Documentation 50 70 90

AIM Phases:

1. Project Definition

This is the phase of project scoping; project planning, resource planning, phase planning, budgeting and

defining constraints and facilitate crucial informed project startup decisions.

This is also the phase to lay down the communication channel, design an effective infrastructure for delegation

and ensure project executive team is in place. In this phase executive team is engaged in interactive sessions

and project team is organized and oriented.

In case, business process change is applicable, then high-level process scenarios are developed.

The main tasks in this phase are:

Understanding the current business process and baseline current business process.

Develop the Preliminary Conceptual Architecture (TA.030).

Develop TO-BE process model, i.e. determine the high-level architectural, technological, and

configuration requirements to support the functional and information needs of the application system

(BP.080).

Design improved high-level business processes (BP.070).

Page 4: 0.3 aim phases_and_documentations

Regintala Chandra Sekhar Page 4 [email protected]

2. Operation Analysis

This phase is mainly to drill down to the next levels of details from where it was in the previous phase.

In this phase flow of information, function and process models are captured and detailed with all possible

variants.

This is also the phase to define the detailed function, data, and operational requirements that the new

application system must support and map business requirements to application capabilities and propose

solutions to gaps. This will demonstrate that the proposed business process design is feasible for the

organization. The technical architecture of hardware and software is refined and a transition strategy is for

moving from the current system to the new application system is drawn.

Performance testing models and scenarios should be developed and proposed.

3. Solution Design

The objectives of Solution Design are to produce a design that meets functional requirements within

business, technical, and financial constraints and document the design specifications in a way that facilitates

and supports future maintenance of the system.

In this phase functional and technical designs for custom extensions, interfaces, conversion programs and

database extensions are developed along with security architecture and application set-up and test plans. Also

unit, link, system, and system integration test scripts are developed. Test scripts, test transaction programs and

test data load programs are prepared for taking up system performance testing. User-learning needs and User

Learning Plans are developed in this phase.

4. Build

The objectives of the Build phase is to Develop, test, and accept custom software, including application

extensions, interface programs, data conversion software, custom application subsystems integrated with

Oracle Applications, temporary bridge subsystems which transaction data between legacy and new systems

during multiple

Deployments.

The Application and Database Server Architecture (TA.090), Platform and Network Architecture (TA.120) and

Development Environment (MD.090) are defined prior to start the development work.

In this phase, all documentation deliverables are developed and delivered to customer.

They may be User Reference Manual (DO.060), User Guide (DO.070), Technical Reference Manual (DO.080) and

System Management Guide (DO.090).

The database extension and installation routines are created, tested, and accepted along with performance

testing and reports.

Page 5: 0.3 aim phases_and_documentations

Regintala Chandra Sekhar Page 5 [email protected]

5. Transition

The transition phase is to plan cut-over and actual scheduling of cut-over. This phase calls for preparation of

going live in terms of application, operating environment, user readiness and cut-over plans. This is the period

of end-user training, users learning and adoption plans is executed.

After the application environment is prepared for production instance and all application, database extensions

are in place, the application is loaded with initial configuration set-ups.

Once the initial configuration set-up is ready, the environment is prepared to load application set-ups for

individual modules and master data files are loaded either using loading scripts are using manual process.

The master data is then verified with users and legacy files to assess data accuracy and ensure that masters are

loaded error-free.

The dynamic data files are then extracted from the legacy and verified for their correctness and then loaded

inside application tables using loading scripts or manual process. All these data are cut-off data on a given date.

Generally, the amount of legacy data to be loaded in the new system is as per the agreed migration strategy.

However, the dynamic data needs to be validated to ensure accuracy and its reliability.

By this time all jobs and routines must have been set. Once the migration process is successful, the system is

handed over to production support.

6. Production

This is the period of hand-holding support for the system newly gone live and devote attention to post-

implementation issues like user acceptance

Page 6: 0.3 aim phases_and_documentations

Regintala Chandra Sekhar Page 6 [email protected]

Trying to understand AIM (Application Implementation Methodology):

1. Understand the Existing Business Processes and current business baseline

RD.020 – Conduct Current Business Baseline (C)

Understand current processes and practices and document the main activities that keep the

organization operating today.

Output: Current Business Baseline

BP.040 – Develop Current Process Model (O)

Examine current business processes and practices and to identify how the existing business system

meets current business requirements.

Output: Current Process Model

2. Creating Future Business Model

RD.050 – Gather Business Requirements (C)

Define detailed business requirements and perform an initial assessment of

application fit to these requirements.

Output: Business Requirement Scenarios

BP.070 – Develop High-Level Process Designs (C)

Produce high-level designs, documenting how the new organization will operate after

the applications are implemented.

Output: High Level Process Design

BP.080 – Develop Future Process Model (C)

Defining the future business model in the form of integrated process flows built on the

business processes supported by the new applications.

Output: Future Process Model

RD.080 – Identify Reporting and Information Access Requirements (C)

Identify organization’s future reporting requirements.

Output: Master Report Tracking List

AS-IS Business Model

TO-BE Business Model

Page 7: 0.3 aim phases_and_documentations

Regintala Chandra Sekhar Page 7 [email protected]

3. Business Mapping and Gap Resolution

BR.030 – Map Business Requirements (C)

Assess the fit of standard application and system features to detailed business

requirements.

Output: Mapped Business Requirements

BR.010 – Analyze High Level Gaps (C)

Compare the process as envisioned in the High-Level Process Designs (BP.070) with

the processes supported by Oracle Applications. The differences (gaps) revealed by this analysis need to be

resolved by producing alternatives that balance change in the application against change in processes and

organization.

Output: High Level Gap Analysis

BR.050 – Conduct Integration Fit Analysis (O)

Identify the new integration points that you require, based on your conceptual

architecture and the mapping of the new applications onto the existing architecture.

Output: Integration Fit Analysis

BR.090 – Confirm Integrated Business Solution (O)

Secure approval for proposed business alternatives.

Output: Confirmed Business Solution

BR.100 – Define Application Set-up (C)

Capture the setup decisions and implement them in the appropriate environment.

Output: Application Setup Document

BR.110 – Define Security Profile (O)

Gather role and function information and relate them to application security and

responsibilities. As business requirements are established and mapped to application features, you also begin

to define the user security necessary to support the selected alternative in a controlled environment.

Output: Security Profile

Mapping and Gap Identification

Page 8: 0.3 aim phases_and_documentations

Regintala Chandra Sekhar Page 8 [email protected]

4. Creation of Application and Technical architecture

TA.010 – Define Architecture Requirements and Strategy (C)

Identify the application and technical architecture requirements and strategy that

would be used for the design and development of the system being implemented. This includes support for

both the final production environment and interim development and project support requirements.

Output: Architecture Requirements and Strategy

TA.120 – Define Platform and Network Architecture (C)

Define the physical platform and network configuration to support your final platform

and network architecture. You map the physical application and database server architecture onto specific

computing platforms. This task focuses on the future production environment and not interim environments to

support the project activities. This includes ongoing production supporting testing and learning environments.

Output: Platform and Network Architecture

TA.140 – Assess Performance Risk (C)

Identify any performance risks that are apparent based on the proposed architecture

and suggest techniques to mitigate the risks. This task focuses on the future production environment and not

interim environments to support the project activities. This includes ongoing production supporting testing

and learning environments.

Output: Performance Risk Assessment

TA.150 – Define System Management Procedures (O)

Design the procedures and specify the tools that the client staff will need to manage

the new system. After you design the procedures in this task, you need to test and refine them later in the

project, prior to incorporating them into the System Management Guide (DO.090) and conducting learning

events for the system support staff. This task focuses on the future production environment and not interim

environments to support the project activities. This includes ongoing production supporting testing and

learning environments.

Output: System Management Procedure

System Installation and Environment Creation

Page 9: 0.3 aim phases_and_documentations

Regintala Chandra Sekhar Page 9 [email protected]

5. Gaps and Interfaces Resolution

MD.050 – Create Application Extension Functional Design (O)

Document the functional features, use, and behavior of required customizations. The

Application Extensions Functional Design confirms that you understand user requirements, and allows users to

evaluate and approve the resulting features that the new modules will provide.

Output: Application Extension Functional Design

MD.070 – Create Application Extension Technical Design (O)

Document the technical specifications for modifications, extensions, and configurable

extensions.

Output: Application Extension Technical Design

MD.080 – Review Application Extension Functional and Technical Designs (O)

Set up a design review meeting between business analysts, key users, technical

analysts, and developers. The goal is to secure final acceptance of the complete designs.

Output: Approved Designs

MD.090 – Prepare Development Environments (C)

Establish a platform and software environment that supports custom development.

Output: Development Environments

MD.110 – Create Application Extension Modules (O)

Produce the modules to support customizations to the Applications. You also perform

the first round of testing as part of this task.

Output: Module Source Code

MD.120 – Create Installation Routines (C)

In this task, you develop automated functions and detailed instructions to install

customizations in the testing and production environments.

Output: Installation Routines

GAP Resolution

Page 10: 0.3 aim phases_and_documentations

Regintala Chandra Sekhar Page 10 [email protected]

6. Business System Testing

TE.020/070 – Develop/Perform Unit Test Scripts (C)

TE.020 - Develop the script to test individual application extension components. The tests

validate that the application extension inputs, outputs, and processing logic function as designed.

Output: Unit Test Scripts

TE.070 - Test application extension components on an individual basis to verify that the inputs, outputs, and

processing logic of each application extension component functions without errors. Unit testing is performed in

either the development environment or a testing environment. The goal is to find errors in the smallest unit of

software before you logically link it into larger units. If successful, subsequent link testing should only reveal

errors related to the integration between application extensions.

Output: Unit-Tested Modules

TE.030/080 – Develop/Perform Integrated Test Scripts (C)

TE.030 - Develop scripts to test modifications to standard Oracle Applications as well as new

application extensions as part of a business flow. This uncovers any integration problems with other

application extension components that provide or use the data manipulated by the target modules.

Output: Integrated Test Scripts

TE.080 - Test several application extension components together as part of a business flow to uncover any

integration problems with other application extension components that provide or use the data manipulated by

the target component. Link testing is performed in either the development environment or a testing

environment. The scope of each link test typically includes the set of components that support or are affected

by a single application extension. An application extension is defined for each gap identified during

requirements mapping and is described by a functional design and corresponding technical design document.

Output: Link-Tested Modules

TE.100 – Prepare Key Users for Testing (C)

Provide basic training to key users participating in Business System Testing. A test

environment is used to prepare key users for testing.

Output: Prepared Key Users

TE.040/110 – Develop/ Perform System Test Scripts (C)

TE.040 - Develop the script to test the integration of application extensions with Oracle

Applications modules. A system test script contains detailed steps which testers follow to verify the system

setup and the integrity of custom application extensions for supporting business processes.

Output: System Test Scripts

TE.110 - Test the integration of all business system flows within the target application system, including all

standard and custom processes and reports. This task is equivalent to a full conference room pilot (CRP) where

the environment simulates the future production environment. The system test is performed in a test

environment.

Output: System Tested Applications

CRP and Module Testing

Page 11: 0.3 aim phases_and_documentations

Regintala Chandra Sekhar Page 11 [email protected]

TE.050/120 – Develop/ Perform System Integration Test Scripts (O)

TE.050 - Develop the test script that validates the integration between your new application

system and other third-party and legacy systems.

Output: System Integration Test Scripts

TE.120 - Test system’s integration with other application systems in a production-like environment. The

systems integration test is performed in a test environment.

Output: Integration Tested System

TE.060 – Develop Testing Environments (C)

Install and configure one or more testing environments to support all testing activities.

Output: Testing Environments

TE.130 – Perform Acceptance Testing (C)

Support users in performing their acceptance test of the new production system. The

acceptance test is performed in the Production Environment. This task also involves scheduling the acceptance

test team, support staff, and user facilities.

Output: Acceptance Test Results

7. Data Migration

CV.010 – Define Data Conversion (Migration) Strategy (C)

Define the scope of the conversion project, conversion objectives and approach, and

prepare a strategy for converting information from the legacy systems to the new application

environment. Part of defining the scope is documenting your conversion requirements at the

application and business object level. Additionally, this task provides a roadmap for performing the

conversion of data from the legacy system to the new Oracle system and defines the task steps and

resources needed to fulfill this strategy.

Output: Data Conversion Requirements and Strategy

CV.050 – Define Manual Data Conversion (Migration) Procedures (C)

Define the plan to convert the business objects that require manual conversion. The

resulting procedure provides a detailed guide for manually converting data to successfully meet

conversion project milestones.

Output: Manual Conversion Procedures

CV.060/070/080 – Design/ Prepare/ Develop Conversion Programs (O)

CV.060 - Design and document the conversion programs. Completion of this task provides the

developer with the necessary information for writing an accurate conversion program.

Output: Conversion Program Designs

Migration

Page 12: 0.3 aim phases_and_documentations

Regintala Chandra Sekhar Page 12 [email protected]

CV.070 - Outline the testing plans for the unit, business object, and validation testing for

conversion. The unit tests confirm that each module successfully completes the task it is designed to

perform. For example, a unit test should verify that the download program has extracted the expected

number of records from the legacy system. The business object test verifies that the quality of the data

converted to the Oracle system is accurate and a function properly in the individual Oracle Application

to which it has been converted. Validation testing verifies that the converted legacy data performs

accurately within the entire suite of Oracle Applications.

Output: Conversion Test Plans

CV.080 - Create the conversion programs that perform all of the functions required to convert legacy

business objects to the target Oracle Applications. The conversion of each business object typically

involves the creation of five types of programs, including a download program, interface table

creation program, upload program, translation program, and an interface and validation program. The

download program is used to extract the data from the legacy system and create an ASCII flat file that

can be uploaded to the Oracle tables. The interface table creation program creates tables that store the

legacy data before the data is validated and inserted into the production tables of the Oracle

Application. The upload program uploads the legacy ASCII flat file data to the interface tables, while

the translation program performs any data-required translation, transformation, or manipulation

required before moving the data to the production tables. Finally, the interface and validation

program performs validation of the data in the interface tables and updates the data into the Oracle

production tables.

Output: Conversion Programs

CV.090/100/110 – Perform Conversion Unit/ Business Object / Validation Tests (C)

CV.090 - Test the conversion programs to verify that all programs work without errors

and according to the conversion testing specifications pre-defined in the conversion unit testing

components of the Conversion Test Plans (CV.070).

Output: Unit Tested Conversion Programs

CV.100 - Test the complete conversion of each business object by executing all conversion modules

for the business object in the appropriate sequence and verify that the resulting data is correct.

Output: Business-Object Tested Conversion Programs

CV.110 - Validate that the target applications function correctly with the converted business objects.

Output: Validation Tested Conversion Programs

CV.130 – Convert and Verify Data (C)

Convert and migrate the production data from the old system to the new Oracle

production environment. Completion of this task provides data that is ready for production use.

Output: Converted and Verified Data

Page 13: 0.3 aim phases_and_documentations

Regintala Chandra Sekhar Page 13 [email protected]

8. Documentation

DO.050 – Produce Documentation Prototypes and Templates

Build and review a single prototype for each type of documentation deliverable. The results

conform to the look and feel of each documentation deliverable, as well as present a clear expectation

of what will be delivered. You also create templates for later use.

Output: Documentation Prototypes and Templates

DO.070 – Publish User Guide

Publish a User Guide that defines a set of detailed procedures for using the applications. This

task is often performed in parallel with Perform System Test (TE.110).

Output: User Guides

DO.090 – Publish System Management Guide

Gather material for the System Management Guide and publish the final version. Perform this

task in parallel with the execution of the business system test.

Output: System Management Guide

Thank you.......

Regintala Chandra Sekhar

You can get more documents on my blogger: http://ora17hr.blogspot.com

Facebook Group: www.facebook.com/groups/ora17hr

Documentation