The following diagram summarises the 'V' integration testing approach, that I have used on my projects.

Each blue lozenge on the left represents a requirement or specification baseline.  The corresponding lozenge(s) on the right represent a test level which verifies or validates the implementation against the requirement or specification. 

The green boxes represent reviews at which the artefact is approved and baselined, i.e. becomes subject to formal change control.The diagonal dark blue arrows, making up the “V” show at a high level the flow of traceability.  Requirements traceability is a technique used to provide relationships between requirements, design and implementation of a system in order to manage the effect of change and ensure the success of the delivered systems.

I have received multiple emails on ERP cutover , in the next couple of blogs will write about go-live readiness, project plan, the importance of data cleansing and cutover dependencies with the business counterparts.

One thing that I learned throughout my career is the importance of teamwork. Human nature is complex and one of the areas I believe I have done extremely well from employer feedback is my self knowledge:

how you respond to conflict, what motivates you, what causes you stress, and how you solve problems and how to adapt your own style to get along better with others

Having been to many corporations because of my profession, one key mistake that is made often, most people hire in a tribal way. They recruit people like themselves; people they feel comfortable with and who they know or have worked with before. But to hire well for your project to be successful.  You should seek out diversity, diversity of thought, people who bring different ideas, experiences, and perspectives to your organization, expecially on difficult enterprise wide change projects like CRM, ERP and SAAS projects

Now, here’s my methodology so you can do this, too:

• Let go of judgment. The first step in recognizing talent is recognizing talent! You can only do this if you are able to put aside your own issues and prejudices and see others for who they are. You’ve got to be able to compensate for your own “perceptions” when assessing others.
• Let go of jealousy. If you’re jealous of what they’ve got, you’ll feel it, they’ll feel it, and it will end bad.
• Let go of labels. Strong people don’t need anyone to define a relationship with labels because they’re able to figure it out on their own. Trying to label a relationship can scare a strong person off. (If you’re not comfortable with ambiguity? Keep that to yourself.)
• Let go of doubt. Great people want people around them who are even better then themselves. If you don’t believe you belong, you don’t belong.
• Let go of control. Great people will do things you don’t understand and can’t explain. Insisting on living in a world you fully understand will keep you from experiencing people who can open you up to new and bigger ideas. Great people approach their worlds with innocence, wonder, and curiosity.
• Let go of you. Help the people around you shine brighter. The strong one’s will keep you around and start feeding your gift back to you. (The weak ones will show their true colors by trying to take advantage—easy to deal with once you’re prepared for it.)
• Let go of safe. Surrounding yourself with extraordinary people guarantees one thing: change. Scary, risky, life-altering change. No-more-comfort-zone change. Great people require us to abandon the safe harbor of our routines.

Did you get it yet? Greatness happens when you let go. It’s the ultimate “chicken soup;” you bring only your true self and all the other ingredients you think you need actually are provided by others when the time comes. It takes an incredible amount of self-confidence and faith to play this game—but I never did say it was easy.

That’s my recipe. I hope you can make it work for you!

Some real case customer scenarios looking to upgrade towards Oracle R12, Happy new year!

From: XXXXX
Sent: Friday, December 3, 2011 2:24 PM
To: Alex Antonatos
Cc:
Subject: Advice on R11 upgrade to R12

Hello Alex,

 I am a reader of your blog, enjoy the content. We have embarked in upgrading our R11 instance 

We face issues on patching, can we arrange a call to discuss, would like to hear your expert advice on our situation,

We operate in 27 countries mostly EMEA, Asia and few sites in North America.

Kind regards, 

______________________________________________________________________________________________________________________________________________________ 

As we all learned upgrades are always time-consuming and complex, so anything that makes the task easier and reduces the downtime needed is worth investigating.

The way this works a staged Applications system represents an exact physical copy of a production system, including all APPL_TOPs and the production database.

You can apply patches to a staged system while the production system remains in operation. After that, you connect the staged system to the production system,

update the database, and synchronise the APPL_TOPs. This means that the downtime for the production system only needs to begin after all patches have been successfully applied to the staged system.

After the patches have been applied to the staged system, and the production system updated, you must export applied patches information from the staged system and import it into the production system.

This ensures that the production patch history database is up-to-date.The principles of using the staged approach for upgrading are simple: after meeting the applicable AutoConfig and Rapid Clone patch prerequisites,

you create the R11i staged system.

You then upgrade the staged system to R12.1.3 by updating the production APPL_TOP and database. Finally, you synchronise the patch histories of the production and staged systems.

Feedback received for above mentioned client shaved up to 10 hours from cutover plan.

Metalink note for more information:Using a Staged Applications System to Reduce Patching Downtime in Oracle E-Business Suite Release 12 (Doc ID 734025.1) 

We bought a company and we need to replace SAP with Oracle EBS:The following Oracle Modules will replace SAP.

Financials: GL,AP, AR, FA, PA

HRMS

Discrete manufacturing INV, BOM, MRP, WIP

Order Management and Procurement

Where do we begin with the migration of data?

We are a conservative global company, what plan/approach/timeline do you recommend for the upgrade?

Thank you,

__________________________________________________________________________________________________________________________________________________________________________________

Data

In my experiences with SAP this type of migration of data is better served using a third party tool, you should look into more4apps.com excel based suite of software, ideal in this situation to empower the users in deciding on what to take across from SAP into Oracle.

Plan/Timeline

Once support exists for the R12 Upgrade and the Business is on board, since this will take a lot of their time. 

Here is my rule of thumb that i would use as a baseline using this clients footprint , they have 22 EBS modules in production:

R11 instance will little or no interfaces, extensions and reports, project plan of 4 months

R11 instance with some interfaces, extensions and reports(12-24 objects), project plan of 6 months

R11 instance with many interfaces, extensions and reports (25+ objects) project plan of 9 months

Approach

In this case what was recommended was as follows:The areas of technical below were outsourced to a specialized partner:

1) Understand installed components, system sizing information, NLS considerations
2) Prepare for upgrade using Upgrade Manual Script.
3) Upgrading to R12. This includes upgrading the database and applying the required patches through AutoPatch.
4) Post-Upgrade process. Complete the upgrade process by applying the latest patches to keep the system most current.All the functional upgrade tasks, testing including uat, setups were all done internally.

Architecture

In this client scenario, what was recommended was to upgrade the R11 instance into a new instance of R12, then merge the instances using a consolidation project methodology. (below are the high level steps)

Consolidation Methodology

·         Proof of concept phase

·         Consolidation of AOL, general ledger modules

·         Consolidation phases

·         Standardization of globalsetups

·         Analysis of custom data model

·         Two practice runs to perfect consolidation process

·         Unit/System testing usingcompanies test cases

·         Functional testing using client specific test cases 

·         Documentation and execute the Multiple instance consolidations at the same time during second cycle

 ·         Data integrity scripts

·         Generalized custom scripts tovalidate the data integrityafter consolidate

·         Go Live

·         Project ends after firstmonth-end process