Business & Technology Nexus

I received a thoughtful request recently to post on how US software vendors (including Oracle) are viewing the India and China markets. Of course all large software vendors have been drawn to India and China as low-cost R&D centers. But it is also true that these very same companies have been investing heavily in a sales presence, although often this hasn't yet translated to significant revenue streams compared to their more mature US and western European markets.

India and China could not be more different, though, when it comes to where to hunt for gold. India, with it's slice of highly educated knowledge workers, is a service industry play. China has that element to it, but the far larger opportunity seems to be providing the Manufacturing industry what they need (which sometimes means catering both to foreign operators as well as their in-country presence).

The short answer is both markets deserve and are getting lots of attention. Both markets also run the risk of becoming another Brazil, where in country software vendors simply take the time to understand and build software that fits local laws more completely. For example, Brazil has a requirement/business practice called 'Nota Fiscal'. It mandates a single document for Shipping Label & Invoice. Physical Receipt and Invoice Receipt are one and the same. At Oracle, we couldn't figure out how to build in support for the Nota Fiscal – it was too expensive (and maybe we weren't smart enough). By not having support for this we gave up on a very large and growing market. SAP and others fared better.

I think the real question the emailer was asking is "do I have a chance of competing in India and China against the big guys". And if you spend your time in country and on-top of local requirements, the answer, surprisingly, may be yes! Good luck!

Google is giving enterprise search another go, this time with OneBox, its followup to the Google search appliance. Check out the datasheet. Also check out the support from Oracle, salesforce.com, etc. in these video clips. (And notice Oracle's example search via OneBox is for requisitions)

The problem Google is attacking is a good one – enterprise systems, including Procurement, tend be okay at recording history. But sharing that transactional history and turning it into knowledge that empowers an organization is another thing entirely.

Now how to do this & enforce the data- and role-based security so present in today's enterprise software is a tough challenge. So, for the moment I'll profess some skepticism on how well this concept might work. Not as much as this SAP guy, mind you, but some at least.

But for very large enterprises with hopelessly fragmented systems maybe this "mashup" of ERP & Google is just what the doctor ordered.

By all means check out Jason's post on the new Federal CPO.

It got me thinking. After all, I've been trying to figure out how to eventually "not be a blogging bum". One of my early ideas was to build public sector-specific software. But it didn't check out. I had already discounted Federal due to $ required to even participate in a sales cycle, so I considered instead States and Municipalities.

I asked experts about the sales process – and of course I drew upon my own sales experiences while at Oracle with both the Federal and State and Local teams. As everyone knows, trees can grow tall during a single sales cycle. But what really soured me on the idea was when one advisor was able to pull out a price sheet on meetings with governors and mayors for California, Oregon, and Washington. Prior to that my idealism kept me too naive to believe stuff like that actually happens. Now with my idealism duly crushed, I just don't see the system changing. But I hope I'm wrong!

Some of you have asked: aren't you at least going to gloat about continuing higher energy and raw materials prices? Okay. Yeah, I guess I will.

I talked you through the 2006 Energy Outlook from the Bush Administration in an earlier post. Turns out, they failed to imagine our current scenario – an inexorable upward climb. Look at the chart and try to put a point at $72 and 2006. Scary.

Of course, all commodities aren't created equal. As more flash memory capacity has come on world markets, Apple reported higher margins than expected due to lower prices paid for flash.

But raw materials will continue to be under pressure as China and India and other emerging markets continue their red-hot growth.

April 21st update: make that $75/barrel. wow!  

Note: I’m still collecting my thoughts on Chapter 4 of the E-Business Suite post thread. Thanks for all your interest and inquiries on that topic. I’ll pick it up again soon! But let’s shift gears and discuss something more practical: techniques for escalating successfully with software vendors.

As usual, I’ll write from my experiences in my former role as a vendor of Procurement applications software.

In that role I had thousands of customers. And over the years I witnessed the full range of complaints, gripe sessions, yell-a-thons, you name it. Let’s face it: enterprise software is complex. It’s going to have problems & some customers will need to escalate with their suppliers to get their issues resolved.

And please, before the comments come rolling in accusing Oracle of low quality, you should know Oracle’s per-customer defect rates for Procurement were very, very low. You can never do enough on the quality front, and certainly I wish we would have done even better. But I’ll stand by the track record of my teams.

But let’s get back to the escalation process. For most issues a vendor’s support organization works just fine. But sometimes it doesn’t. These are some of the conditions that can indicate you need to escalate:

1) You talk to a different support agent every time you call in & you have to “bring them up to speed” for a few hours, only to be transferred to the next geographic center. No discernable progress for days or weeks (or months).

2) The vendor refuses to acknowledge the issue you have is a software defect & you can’t possibly “go live” without it. Or you can’t get a commitment for your issues by your “go live” – weeks are sliding by with no noticeable progress.

3) The patches you are getting from the vendor cause more problems than they fix

These are just a few tell-tale signs. I’m sure I’ve left out a ton. Basically, smart customers escalate when they sense they’ve fallen between the cracks in an erstwhile quite reasonable support effort.

[And here's your magic decoder ring for defect priorities: P1 = we need to work on this right away, P2 = darn, we need to fix this, P3 = we should probably fix this within the next 4 years, P4 = not in your lifetime. (I tend to exaggerate, but I find it interesting how few experienced customers ever log a P3 or a P4).]

So, now you are ready to escalate. But to who?

First, before you send an email to Hasso or Larry you should know larger software companies have small dedicated groups, typically embedded within product development, to communicate with escalated customers. In SAT terms, Support::Army, TheseGroups::Marines. Oracle called the group & the customers within it “Escalated Accounts”. Peoplesoft called it “Lighthouse Accounts”. Kudos to Peoplesoft yet again for turning something negative on its head into a positive.

You want to escalate into this group. They know how to work the system and get you in touch with the people most likely to satisfy your immediate needs. If you have a personal relationship higher, that’s great, by all means use it. What an executive will do first is put you in this program. You’ll know you’re in it when you get daily status reports and have daily conference calls. And before you rush to escalate keep in mind it’s really a lot of work for customers to engage with their software vendors in this way – so think twice before you do it. If you need not, do not – you’ll just end up wasting a lot of time.

The award for worst customer (no it wasn’t Ford! not by a longshot) goes to a former CIO of Carrefour. He was so acidic and caustic on the phone that I always found a way to avoid him. So if the person you most want to talk you is avoiding you at all costs I would argue you might not be on a good path to getting what you want.

But aside from extreme behavior such as this there are other approaches which really don’t usually pay off including: Excel spreadsheets the size of small countries, snooze-worthy 4-hour conference calls, and gargantuan Webex sessions walking through dozens and dozens of flows, to name a few.

So, you’re wondering, “what works”? How do I get my issues fixed fast – and how do I get my enhancements in the base product?

There is no magic formula. But I will tell you what some of the more successful customers did. Oh, and by the way, don’t bother asking “how do you figure out what to put in the next release?” There’s no methodology, even if one is offered to you. It’s a pointless question, and it certainly won’t lead to you getting a different answer on your issues.

Successful escalations require a very knowledgeable escalation person.

They also tend to follow these guidelines:

1) They never, ever, have more than 10 things wrong.

Ideally, pick your 3 top issues and let the rest go through normal channels. After all, it’s an escalation for crying out loud.

2) Communication is outstanding and unemotional.

Don’t assume your supplier understands a word you are saying. Walk her through every step of the process, and stop to make sure you are understanding each other. “Do you agree so far?” is a good thing to say now and again when walking through a complex issue.

3) The customer understands their software vendor’s true motivation.

Know your vendor’s objective is to resolve the issue as quickly as they possibly can, and get back to their primary work. Use that to your advantage & help them understand that fixing your problems will cost them the least amount of time.

Now much of my readership has been on the other side of this relationship. I’m very interested in your comments on what has worked for you!

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.

Oracle, like many companies, operated in all practicality as a loose confederation of entities dispersed by geographic regions. I believe Larry referred to the managing heads in each region as his "feudal lords".

He said more than once that he finally figured out each different Oracle actually did have something in common – their tagline. In the US it was "Oracle, the internet changes everything" or something like that. Everywhere else in the world (according to Larry) it was "Oracle: Larry, you're not the boss of me!"

So Larry started setting up incentives to consolidate systems. He would eventually refer to the Global Instance he envisioned as his "global policy instance" – he was sure without it he would be unable to enforce global practices. But I'm getting ahead of myself.

He started with something simple – Email servers. Truth was, at Oracle email was horribly unreliable. Or at least it seemed that way. I can remember outages that lasted for days. And for a technology company that was just embarrassing. Well, part of the problem was that Oracle had over 100 different email servers. Now there is 1. Oracle saved a ton of money and improved email service with that work alone. It was just common sense applied to a very un-optimized, fly-by-the-seat-of-your-pants empowered Oracle culture.

To incent the regions, Larry offered the global single email instance free to the "feudal lords." They could pay extra for their own, more unreliable email, or they could use the central service for free.

From there, it was on to Applications.

And at Oracle, there was no shortage of work. Any given country in which Oracle operated was likely to have an instance of Financials, an instance for CRM, an instance for HR. So each operating country's ERP & CRM systems weren't integrated, let alone the region's!

Now if you look at a solution like Peoplesoft's, this was anticipated. In fact, it was as good as you could do. Peoplesoft Applications were in separate databases to begin with & could never be engineered to work together. Peoplesoft HR came in 1 database, Financials and SCM came in another database, and Peoplesoft CRM came in a 3rd database.

But with Oracle, you could run all this stuff in a single database: Financials, SCM, Procurement, HR, & CRM. And all of the applications were integrated not via XML or web services or insert-trendy-integration-glue-here, but at the schema level. Now this was true even before Larry got more involved in applications, but he took it to a whole new level.

Oracle proceeded on a Stalin-esque 5-year plan of consolidating instances in all its operating countries and regions, and eventually did get to a Global Single Instance for all ERP & CRM – for about a month. Then Peoplesoft crashed ashore. But fundamentally, Oracle had learned how to absorb disparate business with its instance and business process consolidation work – a skill that would start coming in quite handy as the M & A forces at the executive level won out & Oracle went on its buying rampage. And as always with Larry, there is method behind the madness. But that's for another time.

In the meantime, check out this great Financial Times interview. Page 2 contains Larry's assertions about instance consolidation and business operating practices. Well worth the free sign-up imho. 

- Chapter 3 on its way -

Perhaps a better name for this post would be "what was right about Oracle's E-Business Suite Strategy."

I will tie my opinions into choices I made in the Procurement area & along the way you'll get a good idea of similar choices Oracle made across its ambitious ERP & CRM footprint.

It makes sense to start this story by relaying a snippet of a conversation between Ron Wohl and Larry Ellison. In those days, and likely to this day, Larry would host a weekly meeting on Applications development. Key leadership at Oracle would attend and discuss a variety of topics requiring action.

One interesting feature of these meetings was the waiting. You see, you never knew just when they would start. If the scheduled start time was 2:30pm, the meeting might begin anywhere from 1pm to 6pm. Everyone was on call, ready to go whenever Larry arrived.

If you were in the board room, you could tell Larry was close at hand when his food arrived. Maybe it was a fish sandwich from McDonalds, maybe it was accompanied with a nice fresh root beer float. You see, when you're Larry you can have whatever you want whenever you want. I'm sure it's a strange existence – and tough in it's own way (yes, you say, I'd like to have that kind of tough!)

Now Ron Wohl at the time (and up until shortly after the Peoplesoft acquisition) ran Oracle's Applications Development organization. And make no mistake about it, this meant Ron ran Oracle's Applications business. Ron is an amazing intellect. He is a great leader and remains a fantastic mentor. Ron always seemed to expect people to do great things – and sometimes we did..

But on this day, long ago, Ron and Larry were bantering on the state of the Applications business, and somehow the topic turned to Marketing. Now, as usual, you are getting my best effort at a recollection, not necessarily to be confused with the truth. I hope it's fair.

In any event, Ron told Larry that Applications (ERP & CRM) was a mixed bag of products that were bought by different buying centers within a company and with wildly different value propositions.

Larry: Well, how do you market them then?

Ron: By area – for HR it's "blah", for CRM it's "blah"

Larry: But how do you market the whole thing?

Ron: It's very difficult – there's no central message

Larry: No, no, no. This stuff has to all tie together. We have to brand Applications as a whole – we can't possibly do it area by area.

And just like that, Larry dove into Oracle's Applications business. The press somehow knew about Larry's increased involvement and wrote about it a lot. And it sure was interesting seeing how Larry's perspective evolved over time (or more correctly, my perception of his perspective).

Larry declared right away that what was wrong with Applications (ERP & CRM) was that there were too many different systems & too many different configurations. He could never understand the schizophrenic feedback he'd get: some customers would say quality was great, others would say they were ready to sue.

He theorized the reason for this was that every system was unique. And this uniqueness was driving up support costs, and driving down customer satisfaction. And not only that, most customers were running too many systems, thereby fragmenting their corporate information horribly. Including Oracle.

He started asking questions like "How many employees does Oracle have?" or "How much did we spend worldwide with Dell last year?" And he never could get an immediate answer. It always took awhile. And when he got an answer, it wasn't "as of now." It was always stale.

So he posited that every customer should have a single, global instance of ERP & CRM applications. Oracle would make darn sure that system was engineered to work together – in fact that would be job 1.

Further, Larry posited the system should be vanilla – no customizations. And he'd start with Oracle itself as a testbed.

- Chapter 2 on it's way -

It can be tough staffing your organization with the right kind of people. You want smart, disciplined, well-educated individuals committed to winning while upholding the highest ethical standards.

So how do you get them? And how can you keep them?

Your first choice in evaluating candidates is how to balance direct work experience against a person's capacity for learning quickly and raw growth potential. In product development I always errored on the side of growth potential figuring technology moved so fast a person's capacity to keep pace was more important than their immediate ability to contribute.

Now making this kind of choice might be unwise in Procurement. After all, you are being measured on savings now, not a year or two from now – and so the margin of error for mistakes in judgment due to lack of experience is far smaller. But you might be surprised how quickly a sharp MBA-grad might come up to speed on the markets you care most about.

The Hackett Group has done some benchmarking of Procurement human resource patterns. And while many of the findings are straightforward (e.g. world class firms spend more time on training), one factoid might surprise you: turnover is actually higher at the some of the best companies.

When you're world class, you grow your people quickly in many best practices. As they grow so do their opportunities – both at your firm and via jumping ship. After all, what's the best talent pool for a hungry Procurement group in turnaround mode with the desire to become world-class? Yep, your world-class firm!

So what's to be done? Of course retention programs are 1st priority. But assuming your talented organization will face higher turnover, your systems had better adapt. They must make it easy to collect, aggregate, and convey the body of knowledge your company has built up over the years.

A 1st class knowledge management system can be a great insurance policy to keep your Procurement organization's world-class status.

Service can be very important. I know a few friends who don’t shop at The Home Depot anymore. For them, the superior service they receive from the local Ace Hardware is more important. They are “sourcing for best value” – placing a premium on their time. Which begs an important question – whose efficiency should be maximized in a Procurement implementation? The central buying organization’s -or- the business units they serve?

With that kind of a setup, I’m sure it’s clear I’m a fan of optimizing Procurement “services” for the convenience of business units. And it’s a tough job. The variety of “you’ve got to be kidding me” types of goods and services each business unit calls on Procurement to help with can be daunting.

But with new systems, tactical buyers can be, well, pretty darn strategic. Instead of pushing paper in Bangalore, they can work efficiently with business units in Baltimore, and add value along the way. That’s not a knock on tactical buyers working from India – the talent of the resources in India is truly amazing. But it is a knock on tactical buyers working from India for a largely US-based company. Why? #1 the 12 1/2 hour time difference almost guarantees a day’s delay for each interaction. #2, if you solve #1 by having your tactical buyers work the night shift you are really asking for trouble. And #3, why on Earth do you need 20 people in India to process requisitions – what is the root cause for this kind of labor need? And how could they possibly ever add value in your local markets?

Tactical buyers were “invented” before systems existed. Their job was to literally push paper. If your organization is still pushing paper, albeit in eletronic fasion, you’ve got the wrong system. Paper-pushing, for companies with decent solutions in place (and I know of at least 3 solutions with some market share that don’t qualify!) just doesn’t need to happen anymore. Transaction automation can handle 90+% of the workload.

These lucky companies, with good tools already in place, can take their tactical buyers and use them for value-add with the business. More than figuratively, these buyers are your ambassadors; the service you provide sets the business’ impression for your organization.

So why is “onshoring” Tactical Buyers a Procurement “Long Tail” concept? Well, leading systems and technology are enabling tactical buyers to spend more time on the value add, and less worrying about the electronic paper pushing. As a result, the Procurement organization, for a very reasonable labor cost, can serve up great transaction support across a more and more diverse range of goods and services. Instead of focusing tactical buyer efforts on the “mass market” (in this case aggregating requisitions, fixing them, grouping them, and pushing into Purchase Orders) tactical buyers can spread their wings and grow into some of the most strategic resources you have, serving the “long tail” of specialty categories that really, truly, help a business operate effectively.

Great execution is more than a tactic – it’s how you win. So, while this recommendation is controversial, do consider it. Imagine serving up great tactical buying support for business units through local resources. You’ll spend more on your labor costs than if you offshored the work. But the business may value your work more as well.