Daily Archives: March 10, 2009

The New Delphi of Oracle Sourcing On Demand

Jason Busch had a great post on Oracle’s new Sourcing on Demand offering on Spend Matters yesterday. Although it was a few paragraphs longer than his average post, and included a laundry list of features, it’s worth a read as it has some insightful information that is hard to come by. (Oracle, like a few other large players in this space, are very selective in who they talk to and, as such, solid information is hard to come by on the independent blogs.)

As I have not had the opportunity to demo the product, I’m not going to do a technical review but I am going to highlight two important take-aways from Jason’s post.

  1. The original design of R12 (and MRD), which the new on-demand solution is based on, was written in 2004 and was 3 years in the making before its initial release in 2007.
    This says that while the solution may still be good, don’t expect the latest best-of-breed functionality. It’s not going to be there.
  2. The list pricing is $850 per user per month with a minimum of 20 seats (and a set up fee of $5,000)
    Doing the math, that’s a minimum of 17,000 a month or 204,000 a year. That’s likely (at least) twice what you’ll pay for what I consider to be competitive on-demand best-of-breed sourcing solutions, especially in this market. I’m not saying it’s not worth it, but if it doesn’t “fit” snugly into your current platform, the ROI might not be there. Be sure to do a TCO/TVM assessment before making a decision (and consider bringing in an RFP Expert and Deal Architect to help you out).

Software Acquisition Insider Tips, Part IV

Forego the Escrow (because It’s All About the Data)

You’ll be hard-pressed to cheerily find a vendor who won’t agree to put their code in escrow for you, in case they go bankrupt, and laugh all the way to the bank when they do so. That’s because your average vendor knows that it’s no effort for them and useless for you. Why?

  1. You probably don’t have software developers working for you, and have no ability to do anything with the code.
  2. Even if you do have a couple of developers, who probably spend most of their time doing integration projects and not core development, they’re not going to be able to translate 1,000,000 lines of code — or more — and do anything sensible with it any time soon. It will be months, and maybe years, before they are fluent in the code.
  3. If the software was remotely hosted, it will be a monumental effort to get a local copy compiled, linked, loaded, configured, hooked up, and populated with your data. Monumental. Especially if you need a recent version, because you have no idea how to do this and neither does your team. You could be facing months of downtime before you figure it out, if you ever do.
  4. Even if you half an IT team with a few competent developers, there’s no guarantee that the escrow code-base is going to be up-to-date (many vendors never update the escrow code-base because they know you’ll never check if they do) or that it’s going to contain the documentation you need to make sense of it, if it has any documentation at all!

You’re only safe if you have a stable application installed behind your firewall that your team, or third party system integrator, can maintain or if you’re using an on-demand application that could easily be replaced with one or more competitor products at the drop of a hat.

What you really need is a data availability agreement which allows you to get a complete extract of your data in a neutral format (like XML or CVS) at any time, and guarantees that you will get a complete data extract within 24 hours if the provider stops supporting your product at any time for any reason. That way, you can just switch to a competitive on-demand solution, load up your data, and keep on truckin’.

Is it Software or Service?

Many software products aren’t really software products at all. In other words, there is some incantation that has to be performed by the software vendor, in the form of services, configuration, or other magic, on a regular basis, to keep the software running. In this case, you haven’t bought software, you’ve bought software plus services. What’s even worse is that you’ve single-sourced it. If the vendor goes broke, or can’t deliver, you have no options.

Always ensure that you can procure services from multiple third party vendors, not just from the software vendor. Even better, make sure that whatever magic process the software vendor is performing can be easily transferred to your own staff. If there are special tools that the vendor uses, insist on owning them yourself. If the vendor cannot provide them, or is unwilling to train your personnel to use them, then find another vendor — fast.