Strategy for two companies sharing JDE

timallen

timallen

Well Known Member
(short version: what is the best strategy for putting two separate but associated companies in OneWorld?)

We have a client who has acquired another company (can't tell you anything about it: all very hush-hush). Their lines of business are very similar. The client has recently told me that they want to allow the second company to use OneWorld.

Originally they had told me that the two companies should have all the same programs, but that their data would be completely separate. So I thought I should make a copy of the original environment and change its OCM mappings for Business Data to new data sources for the new company.

But now they tell me that eventually the idea is to merge the two companies together in some foreseeable future. I started experiencing stabbing pains behind my left eye and developed a tic thinking about shoehorning the two sets of data sources back into one.

To complicate issues, it seems that due to a difference in the way accounts are named for the two companies, at least for now, the two companies won't be able to use the same reports and interactive apps (so that idea that they could use the same programs was, well, wrong). At this point my innards started making sounds like a Canadian moose charging a VW microvan.

I thought of some options, though maybe others exist. Should we:
1) Copy the original environment to a new environment using the P0094 Environment Master, create new data sources, and change the OCM mappings of the second environment to the new data sources? Will this be a problem when we have to re-integrate the two companies?
2) Put all the data in the same data sources and handle data separation with row-level security? Does this mess up reports that do aggregation? I reckon that this would at least make the problem of reintegrating the companies trivial.
3) Create a new environment from scratch and treat the second company as a completely separate company? This would address the problem of having programs that don't work for both companies, but make re-integration Really Hard.
4) Buy stock in both companies? (joke, joke)
5) Some other thing?

Thanks in advance.
 
Hi Tim,
Row security is a really nice way to accomplish the seperate but equal environments. It is also very, very easy to implement.
Regards,
Dave
 
Row security is easy to implement but is hard on the server, depending on how you need to set it up. since it is all hush hush, it must mean the deal must not have even gone through yet. I'd set up the separate environment and worry about merging data either in a data warehouse or with a later project when you can actually communicate with their IT dept.
 
Tim,

My $.02 worth - kick the two company issue upstairs. A CNC should be concerned with technical support, not "the big issue" of business structure. That's an issue for the big boys in the business side to decide how to structure your company. Let them decide how the business will operate and then you give them the possible JDE solutions.

May the force be with you JDE jedi master!
 
We are doing this on our system via row security on the business units. In our case the business units and companies are in discrete ranges. The goal is for it to appear to each user group that they are the only ones on the system. It generally works very well, but it's not perfect. For example, the grid where batch headers display is driven by the user ID, not the company. Users from Company A see the batch headers for users in Companies A and B, although the batch contents are shielded. Likewise apps like the server job display will show all UBEs, unless you restrict users from changing the user ID field. If they come up with naming conventions they could even filter the versions displayed so just JDE versions and those created for their company are listed.

If this merger is an open secret within the two organizations I really think the row security approach could work for you. It would also be much more simple to merge later if you can coordinate things like the COA, next numbers, naming standards, UDCs, etc. in a single system now. But if they really want the users from the two organizations to see no hint of each other, I don't see how it can be done without two separate instances of OneWorld..
 
Tim,
I don’t know, but I have a solution that might be ideal in your case..may be it looks complicated…but heyy that’s way the pay us.
From my experience as ASP, we should maintain separately each company business data, objects, specs..,etc.. This way you will have the option to joined both of them or separate. This option will be based on the case you have (which changed day by day as business needs) so sometimes they want it to be separate other time no.
If I was in your shoes, I will create two separate mirrored Production environments (check OTI-01-0056 from the KG), one for each company, each has its own set of business data, and objects.
Easily you can transfer objects among all the environments you want with many ways (P98604, P9860 “after enabling them”, or you can modify the name and the INFs files for any package you did to be able to install it for another environment than you did for, OR you can configure the OMW to make the check-in to all needed environments “ should make this setup before any developing be done”)
Then I will create the THIRD Production environment, which will be the merge of the first two. For the objects as I said before you can easily transfer them, for the business data I will set data replication even by JDEdwards Data replication tool, or by SQL tools which I prefer.
By this solution you will achieve the followings:
-You maintain each company set of data and objects separately
-You didn’t use the row security, because it will not work with the reports if you using *ALL instead of the report name you have to setup a row security for each individual report!!!
-Easier security schema.
-You free the developers of making special selection (which company I have to retrieve the data for???) for each reports or application.
-For top management (I don’t know if you have this case) they will be using mostly the third environment….then they can use one the 2 companies environment …. This option they will like it 2222222 much. “Remember me the next paycheck”
-Many other things that I don’t remember now, but it was the reasons why they fired me
My final advice is to be always prepared by keeping your signed resignation in your pocket just in case of any thing happened :))
 
Back
Top