Who's Online Now
0 registered members (), 2 guests, and 16 spiders.
Key: Admin, Global Mod, Mod
Newest Members
dpf6jbez9, hcmconfig, Christine, BBH, vjnanda
1290 Registered Users
Recent Posts
IR35 Legislation
by delboy. 03/09/19 09:37 AM
Top Posters(30 Days)
CT 4
delboy 2
Popular Topics(Views)
484,679 PAYE RTI
58,210 HR_PF.K RUP4
Previous Thread
Next Thread
Print Thread
Rate This Thread
#12211 - 07/03/19 10:20 PM Major Organization Restructure  
Joined: Mar 2019
Posts: 2
KVS Offline
stranger
KVS  Offline
stranger

Joined: Mar 2019
Posts: 2
Hi,



We are planning to do a major organization restructuring in Oracle EBS. The existing organization structure and hierarchy was setup at the time of HR implementation and has never been maintained or kept up to date when people/departments moved. As a result, all the reporting out of HR is not meaningful anymore. People have been manipulating reporting lately in order to obtain some meaning from data, but overall it is a mess. So, now we are at a point where everyone agrees that its not the reporting that needs patching but the underlying organization structure needs to be recreated as a whole. We are still in very initial stage but here are some activities which we have identified:

1. End date existing organizations and positions.

2. Create new organizations and new positions.

3. Build a new Organization and position hierarchy with new org/positions.

3. Move employee assignments to new organizations and positions.



Does anyone ever had a similar experience in their organizations. Basically I am looking for any suggestions/best practices which we can follow and roadblocks which we might face while doing this whole exercise. And also, any possible impacts it might have on other applications like Payroll, Finance, Purchasing, SCM.



Thanks in advance.

#12212 - 08/03/19 12:39 PM Re: Major Organization Restructure [Re: KVS]  
Joined: Mar 2005
Posts: 2,107
CT Offline
CT  Offline

****

Joined: Mar 2005
Posts: 2,107
Off the top of my head, I would imagine that it could potentially impact costing, element eligibility criteria (whether by links or eligibility profiles), purchasing (e.g. authorisation levels)

In terms of an approach, I'd be inclined to do the thing programatically (using appropriate APIs of course) - mainly from the point of view of being better able to control the whole process, verify the results of each stage, repeat end-to-end tests more readily, and doing the whole thing as quickly as possible, thus minimising downtime.

Oh, and test it all to hell, too.

Good luck!


CT
#12213 - 11/03/19 03:40 PM Re: Major Organization Restructure [Re: CT]  
Joined: Mar 2019
Posts: 2
KVS Offline
stranger
KVS  Offline
stranger

Joined: Mar 2019
Posts: 2
Thanks for the reply. We are good on the costing part as there is no costing defined on Organization level. It comes from Element entry/assignment and element links. Also, element eligibility criteria (whether by links or eligibility profiles) is defined on people groups rather than organizations, so, that part is safe as well. But yes, we do need to review and do an impact assessment on purchasing (e.g. authorisation levels).

And we are still thinking about If using the seeded 'Mass Move' functionality would be a better idea than writing APIs. I know Mass Move would be quicker, as we will save on time to write and test APIs, but It could also be less flexible than custom code using APIs. Any thoughts ??

Thanks. :)

#12214 - 12/03/19 11:40 AM Re: Major Organization Restructure [Re: KVS]  
Joined: Mar 2005
Posts: 2,107
CT Offline
CT  Offline

****

Joined: Mar 2005
Posts: 2,107
This is only my opinion, so take it with the required amount of salt. To me, Mass Move would be viable, if:

1. All the changes you need to make are within its remit

2. The Mass Move process can run in the background as a concurrent job, and preferably make use of any multi-threading capability your target system may possess (harking back to my comment about getting things wrapped up ASAP)

3. Mass Move has the ability to run in 'validate only' mode - to allow you to resolve whatever errors you are likely to encounter over the entire population, thus avoiding the risks associated with doing a piecemeal move (e.g. some moved and some didn't because of some data or other error).

There was a time when I could have answered 2 and 3 for you, however my memory is not that good any more - if it ever was to start with wink

Bear in mind that from your initial task list above, Mass Move will only do the last one for you. Also, you might be setting yourself up for a fall if you try end-dating 'defunct' organisations/positions (your step 1 above) before you've successfully moved the assignments over to their new orgs/positions. In fact, I'd have that as the last step. Ultimately even Mass Move will be using APIs to do its work. From bitter experience the update_assignment APIs (for example) will attempt to validate the target assignment record as it stands before attempting the required change, and will fail if it sees the assignment with an end-dated org/position.

If nothing else, all of the above should be enough to reinforce the need for some rigorous end-to-end testing!


CT

Moderated by  Administrator, Geoff Dixon 

Forum Statistics
Forums60
Topics2,224
Posts12,007
Members1,291
Most Online90
Mar 5th, 2017
Today's Birthdays
No Birthdays
Recent vacancies
Top Posters(All Time)
CT 2,107
delboy 1,299
bcooper 1,291
paulgos 436
SBi 426
pat 254
Gus 252
vkumar 223
September
S M T W T F S
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30
Powered by UBB.threads™ PHP Forum Software 7.6.0
Page Time: 0.023s Queries: 15 (0.005s) Memory: 2.7578 MB (Peak: 2.9106 MB) Zlib disabled. Server Time: 2019-09-16 10:07:49 UTC