Business & Technology Nexus

Dave Stephens on technology and business trends

Oracle E-Business Suite – Chapter 3

with 2 comments

Now leave it to Larry to look at this incredible business transformation Oracle was undergoing and say, "hey, this makes a ton of sense, we're savings over a $1B, everybody should do this". It was a wildly idealistic notion, and more rooted in solving the technology problem than anticipating the massive organizational inertia of the Global 2000. Sure, global-company-XYZ had 1400 different operational systems. But their CEO wasn't about to force the company to change. And to be sure, while a global single instance is a really amazing thing, it comes with huge, huge, problems too.

Let me now move on to technology and how the notion of a global single instance impacted how Oracle built Procurement.

(And hey, I probably should spice this up with pictures of pyramids or ancient Mayan culture, but it's technical, so beware..)

Let's start with the basics.

Remember, I said we endeavored to integrate applications at the schema level. There was 1 employee record, one model for currencies, one model for accounts (well, sort of), one model for suppliers, one model for customers, one model for categories (I've covered this previously).

This was a massive double-edged sword. For example, when we introduced Services Procurement it meant that by definition when it came to recording time for contractors, or doing things like co-employments checks, or even introducing a workflow process for hiring, this was all the job of the HRMS system. So, as the head Procurement guy, I had to lobby the HRMS team to build it before I could get it on the schedule. Very frustrating, but very understandable. The HRMS team was working on important priorities for their customers, same as me. The delay in getting to market was probably 2 or 3 (wait for it) YEARS.

But besides the inevitable delay in building capabilities that kept pace with the market, there were other issues. First, there was a lot of old stuff that just wasn't competitive that you needed to rely on from other teams. Continuing the Services Procurement example, onboarding and offboarding of contractors and employees used legacy "Oracle Forms" interfaces that we tried, as much as possible, to pretend didn't exist. You certainly would never see them in a sales presentation or demo.

Procurement Applications development was embarrassed by the quality of the HRMS integration and the HRMS flows. And I'm sure HRMS was likewise embarrassed by our work. The teams just operated on different planets when it came to requirements. A simple flow, like creating a contractor record from information gathered in Procurement screens, wasn't possible. Why? HRMS localizations were embedded in the ugly, throwback Forms version and not in API's. Therefore, the only way you could make sure local laws were being respected was to force the buying agent into a contractor/employee entry screen and (if you were lucky) default over everything you think you might need.

On the positive side, customers of the solution really got some amazing functionality – very, very deep on the HRMS side for the contractor flow. If you were running HRMS and Oracle Advanced Procurement, you were golden – all you need do is push Oracle to iron out the wrinkles. But in optimizing for the Global Single Instance, we were late to market and we eliminated the majority of customers in the world who might buy it. On the other hand, we had almost unimaginable differentiation. So for those customers where it fit, it fit like a glove & it really would be silly to even think of doing anything else.

Peoplesoft, by contrast, took the opposite approach with Services Procurement. They built it as a start-up would, almost without regard for their existing Procurement functionality. If memory serves, it started with the SkillsVillage acquisition. Which I always thought was silly because the big problem with Services is the invoicing and reconciliation piece, not getting resumes. That aside, Peoplesoft "SRM" built the time keeping themselves. Remember, HR was in a separate database for Peoplesoft.

Ironically, we gave Peoplesoft WAY too much credit for their efforts in Services Procurement. What we thought was going on was Peoplesoft was trying to grow out from their HR presence into Supply Chain. But it wasn't until after Oracle acquired Peoplesoft that Peoplesoft Services Procurement integrated with Peoplesoft HR.

The net result of the Peoplesoft choices for Services Procurement: quick time to market, point solution focus for potentially really broad market, and all kinds of integration challenges. So it sold pretty well and for a good average sales price but live customers and references might have been a different story.

Who made the better choice? It's really unclear. There are an awful lot of customers who just couldn't use the Oracle solution – they had too much heterogeneity in their operating environments. And the Peoplesoft solution lacked some very basic integration, driving up TCO and making implementation and usability all the more challenging.

But this thread of posts is on the E-Business Suite, not Peoplesoft, so I'll end my musings about them now.

Next post (Chapter 4 I guess) I'll head back to Oracle's implementation & the growing challenges of Global Single Instance.


Written by Dave Stephens

04/18/06 3:49 PM at 3:49 pm

Posted in Opinion

2 Responses

Subscribe to comments with RSS.

  1. I was close to the people involved with the PeopleSoft Services Procurement product, so I think I have my recollections about 60% right, but since I wasn’t involved day-to-day, it may be my interpretation of events myself.

    (yes, that was a disclaimer)

    Actually, PeopleSoft Services Procurement “leveraged” quite a number of objects from other applications — I would say that it was truly the first live composite application in that sense. The requisition and approval was built on top of eProcurement, the bid management built on top of Strategic Sourcing and so on. Of course there were a lot of other objects and functionality that were built from scratch, but there was significant leveraging going on. That’s why the conversion from SkillsVillage happened so quickly.

    Unfortunately, given the time and the state of PeopleTools, some of the leveraging was more copying and augmenting than object-oriented inheritance that the later versions of PeopleTools supported.

    You also touched on a limitation with PeopleSoft HR at the time of building sPro — the fact that HR couldn’t handle non-employees that well. The Person ID concept was still on the drawing board for HR when sPro first went out the door. Also the multiple database approach did allow for different parts of ERP to go out the door at different times, which had it pluses and minuses too. Getting on HR’s radar screen was tough as well. The plan was to integrate into HR (eRecruit) by 8.4(? — definitely by 8.8), I believe, but it had to slip to conflicting schedules and priorities

    I think the single instance is great in concept, but when you have applications at different states of maturity in the same instance (SRM being tied to Financials is an example), customers have to wait — sometimes for years — for an upgrade or try to implement an older, less functional product.

    Believe me, a lot of us wanted SCM (which owned SRM) to break away into our own instance.


    04/18/06 9:20 PM at 9:20 pm

  2. I’m sure your recollection on Peoplesoft is more accurate than what I learned from being on the Oracle post-merger analysis SWAT team. As you mention, leverage really meant copy. From an outsider’s point of view, for example, there were actually 4 different versions of the requisition data model – each extending and offering overlapping and unique functionality, across the Peoplesoft SRM product. That’s probably worth a post in it’s own right, and should I ever get around to it, Henry, you’ll need to make sure I get it right!

    Dave Stephens

    04/19/06 5:30 AM at 5:30 am

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: