Here sharing recent communication on options to implement oracle Apps, i like you all to share you thoughts on this below scenario

I need the list of points or concerns we need to take care of at the time of migration from 11.5.9 to 11.5.10.2.

Also I am in need information for M&A (merger and acquisition) perspective.
Say Company A acquires Company B. Company A is on 11.5.10.2 and Company B is on 11.5.9
Now A wants to get B on the same instance (11.5.10.2) as a separate operating unit. In this case what are the areas we need to concentrate on.
e.g. Common Item Master, Customer base.., B’s interfaces with some 3rd party system, Transaction between A and B…… etc

It would be very great if you could help me with this information …

—————————————————————–

Here if we consider this M&A , where Company A on 11.10 is target/ parent and company B is on 11.9 as legacy / secondary.

This case is like adding new operating unit in 11.10 for Company A , where it has advantage that Company B is already on Oracle with a lower version. Now here I think few thought to start with
GL Chart Of Accounts – This need to review the COA structure between A and B , having more different will make things more complex , having same will be great benefit. COA structure will drive the complexity of whole exerercise.
SOB and MRC – need to review the kind of SOB and MRC setup in both A & B , this will drive the kind of impact it will have and complexity of whole exercise.

As point 1 and 2 will form the foundation for merging B in A , and will outline the base architecture for remaining transaction and mater data to move in Company A.
Supplier/ Party / Customer / Employee/ Item / Inventory – all these master data need to review for company B and see if it duplicating or it need some mapping/ merging / cleaning or translation etc ,
GL transaction / GL history / GL Balance – this need to bring in A , this will depend on GL COA and GL SOB structure changes happened from B to A
AP ( open Invoice, payment history ) – this will business decision if they like to bring , the strong advice is to close all open invoice and keep history transaction in kind of archinve database for Company B till legally it require, This need to review if these are really require to bring in Company A where they may or may not useful.
AR ( Transaction , receipts , history etc ) – This is recommended to bring in A , because this is surely impact the cash flow and allow lot of benefit to make future analysis and drive cash operations. Company A having any kind of Datawahrehouse , then I would recommend to bring all AP and AR transaction and history there directly rather bringing them in Apps and then send to DWH.
For fixed assets – I don’t see it could be much issue, all assets need to bring in A , and surely this can be manually if they are less in volume or in automated way if large enough.

Another aspect to look for is Third party integration, Customization , Extension, Custom Reporting – As company B is moving to higher version so it need to consider as upgrade for them , from that point of view, you need to review if any changes needed in integration, or enhance/decommission customization, any more reports or less report need to migrate from B to A.

All above thoughts are surely very high level and brief , based on complete study , it will be more than 200 action items or more will outline only for fianancials to bring from Company B to A , so it is very much driven from GL Structure between B and A and IT strategy of organization.

Like this:

When implementing new a ERP system, implementing on time and on budget is not by chance. As with any project plan, a detailed and methodical process is required for success. A plan for selecting and implementing new ERP software is no different than any major project being undertaken by a corporation. It requires a significant investment of time and resources, requires the involvement of virtually the entire organization, as well as a considerable amount of research, planning, and reevaluation along the way.

The best project is well thought out and fully researched. It is not limited to a budget and time line, but focuses on tasks, owners, goals, and milestones. It begins at the time of software selection and goes well beyond go-live. And although most projects will stumble along the way, successful implementations that actually end on time and on budget are quite possible if managed properly.

we preach the importance of a solid selection and implementation plan. So much so, that we will voluntarily chose not to participate in the evaluation project if we feel the prospect’s selection process lacks structure. Why would we ever do that? Because the company will never be happy. If they do not know how to evaluate their own requirements or communicate those needs to others, they’ll never be able to successfully evaluate if a vendor’s ERP solution is a good fit for their unique requirements. And unfortunately if we can’t review their requirements with them, we cannot help evaluate if our package is a good fit either.

A solid evaluation project for new ERP software is broken out into some fairly set project goals and milestones. Regardless of the company, a proper project plan should include:

In reality, you can easily execute on time, on task, and on budget by controlling the entire project through conception and go live. Led by in house or through an outside professional, flawless executions of software implementations are possible. They do not happen by chance, on their own, or without effort. But they are certainly a reality if given the right team and project plan.

Follow me on Twitter

Shivmohan Purohit - A Learner by Heart and ERP Professional by Work. Contribution to success of my organization and people around. Learning new things everyday.
Belongs to family, being a son, brother, a husband and a father of a joyful son. Looking to Collaborate with people around the work.
Looking forward to connect and learn with you