Tip:
Highlight text to annotate it
X
Hi, this is Paco Aubrejuan, Senior Vice President of the PeopleSoft product line here at Oracle.
I wanted to spend a couple of minutes today to quickly tell you about some changes that we've made
to the PeopleSoft product delivery model, going forward.
Just to reiterate our primary objectives, product objectives, that we're working on in PeopleSoft.
Really, we're focused on three primary areas: The first is to modernize the applications, to make them simpler and more intuitive,
and to really leverage common consumer Internet metaphors and paradigms that people are used to using, to simplify the overall
experience and make people want to use the applications.
Number two is: focus on increasing the productivity of the workforce -- using who's using it and how easy it is to use the applications
and how to make the applications fit your particular industry, and your role in those product areas that we're focused on.
And a lot of this comes down to the features and functions we build.
And then the third, and this is where I'm going to spend a little bit of time talking today
and that is, we're focused on changing the PeopleSoft applications to allow you to stay current at a lower cost,
than you have historically been able to stay current at.
Upgrades have traditionally been more expensive and more difficult than we would like,
given that a lot of our customers do customize our product. But the problem is that as customers try to push these out,
and do them as infrequently as possible, the problem this causes then
is that you don't get any new capabilities from the Oracle Development teams.
Because our new features historically, have been delivered in the new releases.
The challenge has been: you push it out to avoid the cost,
but then you get stuck on an older system that doesn't have the new capabilities that your line of business wants.
Let me show you very quickly, how we've historically done new releases.
What we would have done is when we released 9.2 to the market, we give customers the opportunity to upgrade to the 9.2 release.
This is what we would have done before we made a change. And then we would start delivering maintenance on that 9.2 codeline.
Legislative updates, bug fixes, maybe a few little features. But for the most part, just maintenance.
And customers would upgrade to it, and then for as long as they're on that version, the 9.2 version,
they would just get maintenance, not a lot of new stuff.
At the same time, we would split off a new codeline - we would call 9.3, as an example -
that we would on for, sometimes a couple of years. Putting all of the new functionality, all the new technology, all the new user experience,
all the mobile applications, things lilke that, onto this new version. The problem is:
customers can't get to that version. without doing an upgrade.
And it takes them a long time to get to that version, and it creates this disjointed context, Where customers are on one version
of the product, and the development teams are always working on another version that's not available, yet.
The problems with this is it takes a long time to get the new functionality, our customers are always behind us in this model,
we're always working on something they can't get. There is a large amount of change, so the upgrade from 9.2 to 9.3, in this example,
is going to be fairly large. Because if we spend a couple of years putting new functionality into the release,
then that represents a very large delta going from 9.2 to 9.3. And that is a big step function change
which means, it's potentially more cost.
And this leads to infrequent and expensive upgrades, and unfortunately
a product that doesn't get the updates as quickly as it should because customers don't want to upgrade.
So, there's two areas where we've made changes. And this really started in the maintenance area.
As we looked at where the cost was of staying current, it's really in change management.
Taking change into the system, in any application, creates potential problems, creates potential errors,
which then you had to test to make sure the changes don't create any new errors in your production system.
and that, therefore, takes time and money.
Before I tell the changes we made, I want explain the way we've historically done things.
These colorful blocks on the lefft-hand side represent projects that we have on a current release of the application. Let's say HCM 9.1.
And each block can be a different project. It can be a bug that we fixed in the application, it can be a legislative or tax update that we've made,
it could be a new enhancement. And the requests for these projects can come from any number of customers.
They can be problems that we've found internally and are fixing,
There's a lot of change that we create, especially early in the life cycle of a release.
What we've historically done, and what almost all on-premise software product lines do, is every three months, or so,
We put all these changes that we've been working on internally together into one big change
that we call a bundle, or sometimes we roll up bundles and call them a maintenance pack. And we do all of our testing with that bundle,
and then we deliver that bundle to our customers on My Oracle Support.
Now the challenge with this model, the problem with this model, is that all customers are expected to take the entire bundle,
with all of the changes. Whether they need the changes or not, whether the asked for the changes or not, and regardless of
whether the changes impact something in their system in a negative way. The expectation has historically been that you take those changes.
To make matters worse, in order to take the changes for the bundle that we put out at a particular time on one month,
you had to have taken the bundle we put out three months ago. Because we're always building on the latest version of our codeline,
we expect that customers have that latest version, that they're going to apply these changes to.
The big problem with this whole thing is, it represents a cost to customers; to take these changes that we've given them,
That they may not need, or certainly don't need all of them. And that cost has been one, historically, that's been fairly prohibitive.
What we've found, is a lot of our customers, if they do take this, are spending a lot more taking this maintenance than they expected.
If they don't, they're running a risk of having a problem that we can't then help them with.
As we started to look at how do we reduce the change to stay current, we focused first on this area around software maintenance
and how we deliver change to our customers and how do we lower that change.
So what we've done, starting with 9.2, is we've fundamentally changed everything, almost, about how we deliver maintenance,
bug fixes, legislative updates, any change on a given version of the product, how we deliver that to our customers.
We still do the projects like we did them before, but now, instead of delivering these things in a static, one-size-fits-all bundle,
we effectively have a new application called the PeopleSoft Update Manager,
that's a set of files we put out on My Oracle Support every three months, or so.
As a customer, you come and you download those files and it starts up a virtual appliance,effectively.
On a technology we call VirtualBox. That has a fully patched version of PeopleSoft HCM, or Financial/Supply Chain, or CRM.
You can get that up and running, literally about thirty minutes after you've downloaded the file. And when you get that up and running,
you point it at your maintenance logs. What it allows you to do is two things, one is you can go in and demo the new version of PeopleSoft
or try to replicate a problem on it, because it is cumulatively, fully patched.
What it also has is a user interface called the PeopleSoft Update Manager, that allows you to effectively go in and select
which of the changes that we've delivered, cumulatively, since the release was made generally available,
that you haven't taken, that you want.
For example, you can choose to take one bug fix that we've created, or one legislative update, or one feature.
You can decide you want to get completely current on a particular product. You can decide you want just the priority one fixes
across a set of products. And you can do this iteratively. What will happen is then we do the dependency calculation that says:
If you want this one change -- here are the other two or three changes that it requires that you didn't know about, you didn't select,
and now, it gives you the ability to take a change package that is tailored, based on what you want.
And it eliminates the time dependency. Because these are always cumulative, if you haven't applied maintenance in six months
you can just download the most recent version of this, and go about your job of deciding which things you want to change.
There's no 'catching up.' The system is always caught up for you.
With 9.2, this PeopleSoft Update Manager is the way we deliver all of our maintenance. There are no more bundles.
There are no more maintenance packs for PeopleSoft applications as of PeopleSoft 9.2. On the 9.2 version and beyond.
This is going to significantly reduce the cost and effort associated with staying current on a given release.
It will allow us to provide more value to our customers, because we're delivering changes in a form you can now use.
Because of the PeopleSoft Update Manager, we're now able to do all
of our developement on a single codeline. And the reason we're able to do that where we weren't before,
is because now we can deliver a lot of change onto that codeline and we don't require customers to take all that change.
The way it works, is we're going to deliver PeopleSoft Update Images about every ten weeks.
These are what I talked about on the PUM slide - the files you download and get the PeopleSoft Update Manager up and running.
These updates are going to include not just maintenance, but new functionality.
In fact, all the new functionality that we're building onto PeopleSoft right now is being built in the most current version of our product,
9.2, instead of some yet-to-be-released version.
As a customer, you can select any point in time to take some of those changes. You can wait six months after they come out,
you can get them right when they come out. And you always take the most recent, shipped, PeopleSoft Update image.
That's cumulative, so everything will be in there. What'll happen is then after we continue to build for a while, we will likely release a next version.
but the idea for the next version is that we put almost nothing in it.
And the idea is that we create the delta between where we end on 9.2, and what we ship with 9.3 is very, very small.
So that then the upgrade from 9.2 to 9.3 becomes very small.
And then after we ship 9.3, we start our development effort on that active codeline, delivering new capabilities
over the next three, four, five years, maybe even, on an active 9.3 codeline
that has our customers - without working on the next release.
This makes that upgrade much, much smaller, much less expensive, and you don't need to do the upgrade to get to the new functionality
as long as you're on a release that is our active release.
This will allow you to continuously receive new functionality on the release. I f you move to 9.2 now, you're going to get
another couple of years of us investing on that codeline. So new functionality that we come out with is going to come out on the version
that you're already on. And PUM will allow you to selectively take that inb a very cost-effective manner.
The benefits of both the PeopleSoft Update Manager maintenance as well as the new release model, will allow you to get
the new functionality that we come out with -- without upgrading.
It'll allow you to take only the changes you want -- based on what you have.
And it allows you to do that iteratively -- so it's not a once-and-done thing.
You can make that decision at any point in time- and change your mind.
If you didn't want to take something one day, and the next day you do -- you can make that change.
You determine when you take changes -- we've broken the time dependency, now.
So if you want to do this once every six months, you can do that.
And then, importantly, we allow you to retain the strategic customizations that you have. It works the same way it works with everything else
What does this look like in terms of our plan? PeopleSoft 9.2 came out in early 2013.
We don't have an exact date for the next major release, but it's probably going to be in 2016 - 2017, sometime there.
It doesn't matter as much, because our focus is entirely on PeopleSoft 9.2 and delivering new functionality PeopleSoft 9.2.
We will deliver that generally a couple of times a year, in an image.
Some new functionality may come out more frequently than that, but we'll deliver
major updates one or times a year across most of the product pillars.
Again, you don't need to take it when we deliver it -- you can take it anytime after we deliver it.
So this will allow you to get new functionality on a regular basis.
And that's some of the changes we're making -- more in store. Stay tuned.