The Hidden Benefit of PeopleSoft Selective Adoption December 12, 2014
Posted by Duncan in TW.trackback
There has been a lot of talk over the last couple of weeks about PeopleSoft Selective Adoption, the recently-coined term for the PeopleSoft Update Manager delivery model. Much of this has been on the direct benefits to the customer, which is how it should be. Greg Parikh has linked to some of the posts on LinkedIn.
While discussing this with a colleague at the recent Apps14 conference we noticed that there is another implication that I’ve not seen anyone else call out yet. Although at first glance it seems an immediate advantage to Oracle it’s not difficult to see how the customer is also going to reap significant rewards.
Getting everyone onto 9.2, and then delivering innovation on that version means that PeopleSoft development can operate on a single codeline. Currently, a legislative update will have to be coded and applied for all supported releases (and each version might require the update to be different, depending upon the underlying pages), meaning a lot of extra complication and repeat work. A Global Payroll update might need to be created for v9.2, v9.1 and v9.0, for instance, which is a significant burden.
Once updates are only being created on the v9.2 codeline then they only have to be done once, saving development staff time (and support staff a lot of troubleshooting time also) and thereby freeing them up to concentrate much more time on delivering extra value to the customers in the way of faster updates and more innovative new functionality. This can only be a big plus in the long-run.
Comments
Sorry comments are closed for this entry
The PeopleSoft Tipster Blog 
Hi Duncan. I agree that there will be many benefits for Oracle’s customers using this model which will allow them to choose when and how they apply code changes delivered by Oracle. And it will be a benefit to Oracle’s Development Team to get all customers on the same Major Version Release as you’ve pointed out in this blog post. But I disagree that everyone will be on the same codeline. I guess Oracle Development will be, but the customers won’t. And what about Oracle Support? They support the customers, not the Development Team.
Why the same Major Release but not the same codeline for customers? Because customers can selectively adopt what bits of code they want to apply.
Lets make up a simple example: Most of the 9.2 Apps were released in March 2013. 3 customers (A, B and C) have gone live on HCM 9.2 since that time: Customer A in Jan 2014, Customer B in June 2014 and Customer C in Dec 2014. In the time since HCM 9.2 was released there have been 3 Patches (X, Y and Z) have been released that have touched the Personal Data component: Update X in Sept 2013, Update Y in March 2014 and Update Z in October 2014.
If we assume the customers went live with all the current Updates that were available to them and the other customers have chosen not to apply any updates since they have gone live, we have a matrix like this:
Customer App/Version Patches Applied
A HCM 9.2 X
B HCM 9.2 X, Y
C HCM 9.2 X, Y, Z
Everyone is on the same release but not everyone is on the same codeline. That is just an example with 3 customers and 3 patches. How many customers have gone live and how many patches have been released since March 2013? I think that will cause a lot of headaches for Oracle Support, don’t you?
Neil
You’re right in that the combination of fixes running on client sites will differ as they’ll each have taken their own choice of fixes from the PeopleSoft Images. If there’s a bug, Oracle will only have to fix it once though (in the 9.2 codeline) rather than the current practice (of developing a fix for 9.2, one for 9.1 and maybe one for 9.0). For the different customers to get the fix for the bug, they’ll all take the same code (i.e. the same fix) from that single codeline (via the PeopleSoft Image).
This is what I was trying to point out (although perhaps not very clearly). For each bug Oracle will only have to fix it once, and customers will all be applying the same fix to resolve it. Although the ability to select different fixes will mean that customers’ systems diverge over time, it’ll still be the same fix that they apply (plus any prereqs). As customers perform a ‘get current’ they’ll all converge back towards the same codeline again.
Yes, I totally agree. And I think you were pretty clear. I was just bringing up what I thought was a separate issue – re the problems Oracle Support might encounter.
BTW, always enjoy reading your blog posts. Cheers.
We enjoy your http://getlevel0.blogspot.co.uk/ blog too, Neil.
kind regards,
Duncan
Great blogs. But, I wouldn’t call this the “hidden” benefit. It is THE benefit. And, it is advantageous for both Oracle and customers. Oracle will have a lower cost of support. Customers will be able to adopt fixes and enhancements at lower cost. Most customers skip a release so they’ve been upgrading every 6 years at major cost/effort with little/no benefits in between (unless they are building customizations at their cost). Now they can take PUMs on an annual basis making ERP updates more of a routine maintenance task.
With Oracle’s lower cost of support, do you think they should/will lower maintenance fees for PeopleSoft customers? I think they should but won’t. They’d be more likely to retain maintenance customers during these turbulent times. Blending the line of applying fixes and enhancements while lowing upgrade/update costs will keep customers more current (like saas does) but lowering maintenance fees would also keep customers from looking to the cloud.
#longlivepeoplesoft
Bill