Archive for April 2006
Liquidation Sales
Over the years central Procurement departments have been responsible for a lot of stuff. If memory serves, up to 45% of firms in some surveys have Procurement lead disposal sales. So I have a basic question for my readers: why? Is Procurement really a natural for *selling* as well as buying?
There was a time when Sourcing solutions weren't even considered complete unless they supported a forward- as well as a reverse auction. But of course it was ludicrous for most sales – because sellers naturally go to where their market is. And whatever you're disposing of, chances are "the market" is NOT in your sourcing tool!
DoveBid or eBay seem like two of the most logical choices for disposal sales. And of course there are a ton of eBay liquidation specialists to choose from.
Please share your stories on this topic. A friend of mine who ran Procurement at a mid-sized high-tech company once told me their disposal sales were more like garage sales – a few signs would go up around the neighborhood & the receiving dock would be open for the day with people coming by to make offers on lots of "stuff" (office furniture, excess inventory, etc). Can you beat that?
Shameless plug for Doug Hudgeon
Doug is a Procurement consultant in AUS. I'm enjoying his latest posts. I thought he did a wonderful job exploring & giving a real world (and fun) example of Procurement's long tail here. And I've thoroughly enjoyed his exploration of vendor relations, especially his latest post on contract management & fairness. Good work Doug!
Ariba Quarterly Report
Jason Busch over at spendmatters has the objective analysis. Here is where you’ll find the rant… Btw, the 2nd comment on jason’s blog by ‘Dan’ is pretty insightful too.
I was stumped by Ariba’s quarterly numbers. They are certainly out of excuses for not growing the top line. I’ve definitely heard enough of how great the transition to SaaS is going while revenues limp along. Oracle, SAP, and many of the little guys in Procurement are growing license (let alone total revenue) at an impressive clip in Procurement – and yet the self-proclaimed leader is shrinking.
But I shouldn’t have been surprised. The problem is straightforward imho. Ariba saturated the Fortune500 with hugely expensive software back in the .com boom. These big firms were stuck with massive annual support bills, and over the years they’ve switched off Ariba and onto something else – and justified the migration on the reduction in support payments alone.
Ariba isn’t accumulating any at-risk contracts like that anymore, but it’s just taking a long time for the overhang to work itself off.
Now this Ariba view is sans-FreeMarkets, which was struggling with it’s own “renewals” problem. I remember thinking they sold to Ariba at just the right time – before their revenues began sagging as buying organizations opted for more self-service.
So I am awaiting some stronger numbers from Ariba – they certainly have a great vision and some really useful technology for customers. Maybe next quarter.
Procurement System: Build or Buy?
With all the latest technology advances, you might be wondering whether a packaged Procurement solution is any better than a homegrown, tailored system.
It’s a very good question. And to be honest, I’ve been wondering the same thing.
The first step in determining the answer is to look at your business requirements. Some aspects of Procurement seem simple on the surface, yet can prove surprisingly complicated.
For the sake of specificity, why don’t we narrow down our discussion to a particular area within the Procurement domain – after all, there are systems for tactical buyers, Sourcing tools for strategic commodity experts, portals for suppliers, self-service buying tools for users, and lots of additional toolsets for dedicated problems, from linear price performance to category sourcing optimization.
So, let’s take a supplier portal. What if you have a basic Purchasing system but are wondering if you should build out a capability for suppliers to log in to interact with their data 24×7 and deflect calls, inquiries, etc from your tactical buyers.
Whether to build or buy depends on what you want your supply base to be doing. Many firms make it a point to offer prospective supplier registration – a simple mechanism for alerting the buying organization of a new supplier’s presence in the market. But whether to build or buy may depend on how you choose to work with the data afterwards. How do you propose a prospective supplier who registers be promoted to your true supplier master? Can it be manual because of its rarety? If so, the process & data collection can be stand-alone and the piece of work really is very simple. With new tools a simple registration flow would likely take less than 2 person weeks to build.
Okay, let’s assume prospective registration is a good fit – now how about dealing with existing suppliers – how do they log in, maintain their password, check their Purchase Orders, and perhaps submit Invoicing information?
Again, newer technology makes build-up of these functions a snap – salted MD5 login encryption is available as a plug-in to many technology infrastructures. It’s like having the best available login security “for free”. As for showing data, that’s a breeze to – as long as your requirements are not real-time from your source systems. But when it comes to initiating transactions, you have some work to do. You must figure out a number of exception cases if you can’t perform the transaction at the same time in you back-end system & your homegrown supplier portal. The more “digital divides” you have, the more likely hidden costs will creep into your homegrown solution (and turn it into a quick & dirty solution).
Does that make homegrown start to sound like a problem? Remember, you have other options. If you use Oracle Advanced Procurement, iSupplier Portal provides some good transactional functionality & is architected right on top of your central e-Business Suite database. Of course, if you don’t have a centralized system, it doesn’t fit at all.
Also, you could go SaaS and use the new-age VAN’s out there like Ariba or Perfect Commerce. If the price is right, passing your supplier portal problem to them may make some sense.
But for many of you, it’s quite possible a homegrown solution just broad enough in scope to hit your top requirements may be just what the doctor ordered.
I’ve received a few build vs. buy questions over the last month – and I find them enjoyable. So, feel free to send me your question & situation. I’ll be happy to provide my advice on where some of your tougher areas might be.
Good luck!
Oracle Advanced Procurement: Graduating Class
Quite a few members of my former team are pushing hard to get R12 of Oracle Advanced Procurement out the door. I have no doubt they are doing a great job.
But quite a few others have gotten the start-up bug, mostly in the consumer space. And some have moved on to "cool" endeavors at other established firms. I've decided to label the group who has left: The Advanced Procurement "Graduating Class". Here's the honor roll:
Jeff Mellen, Joe Wong, Sam Hsiung, Srini Panguluri – YouOS startup
Jang Kim – Moblastic.com startup
Jacky Cheung – Mobitv.com startup
Sudhir Rao – Purisma startup
Angus Huang – Aplix (established company in cool space)
Damon May – Fred Hutchinson Cancer Research Center (what an amazing job)
Now, some of my former hot shots are MIA. Drop me a line at drstephe at gmail dot com and let me know what you're up to. I'll update the honor roll accordingly ;)
It's a joy to see these former Advanced Procurement development rockstars spread their wings. The ones pursuing start-ups are each going after pure innovation & creativity and are pursuing large prospective markets. It's great stuff. For the readers who have time check out some of their websites & demo their stuff.
And here's a promise to the "Graduating Class": I won't be just a lazy bones blogger forever!
drs
For Jason: JDEdwards Operational Sourcing
Jason asked I comment on the release of a tightly integrated Operational Sourcing package for JDEdwards. The short version is – yes, I think it was a good idea. And yes, I think it puts light pressure on Sourcing point solutions. But perhaps not too much pressure – you see, I think JDEdwards is probably going to expand the size of the market and get customers using Sourcing who otherwise wouldn’t have bothered.
Let me first give a nod to the folks from JDEdwards.
I liked the people I met from JDEdwards post the Peoplesoft acquisition. They were down to earth and tended to focus more on product capabilities and less on “technology for technology’s sake”. My kind of people. Good folks.
In any event, when Peoplesoft acquired JDEdwards, (this is what I heard from others btw, so no more news stories referencing me please!) they didn’t quite know what to do with the company. Should JDEdwards be their mid-market solution, or should they sell it to verticals like Home Building and Discrete Manufacturing? It was a tough call because while the majority of JDEdwards customers were smaller, a good chunk of revenue came from bigger companies. Peoplesoft waffled, JDEdwards revenues shrank, etc.
One of the questionable things Peoplesoft did (to show how great the “integration” of the 2 companies was going) was build links between systems. Never mind demand was tepid.
So Peoplesoft SRM, which certainly had a bucket of features JDEdwards didn’t, became a showcase “integration” to JDE. I’m not sure if a single customer ever bought & went live on the combined offering, but it was there. The problem was, Peoplesoft SRM was built for a totally different type of customer.
IMHO, Peoplesoft was a collection of highly functional, best-of-breed applications optimized for big companies who could afford to spend a bunch of money in IT to rig them up to legacy systems & build a composite system. They were high-end. Meanwhile, JDEdwards customers installed the system as quickly as possible, and had that single system do as much as possible – hopefully everything their business needed. They then promptly locked it away in some closet. The joke goes: A JDEdwards customer’s idea of maintaining their application was “dusting”. Perhaps every 3-4 years they’d consider upgrading if you weren’t a pain in the behind about it.
So even though building JDEdwards Operational Sourcing meant introducing redundant functionality by replicating some of the basic sourcing capabilities also present in Peoplesoft and Oracle products, it was absolutely in line with what customers wanted & where that market was. It was just good common sense.
Now this won’t hurt Sourcing point solutions tremendously. It becomes more like the McDonald’s line “do you want fries with that?” Sell JDE, salesman xyz says “do you want Operational Sourcing with that?” – great! So my guess is it expands the size of the sourcing market more than it takes away business from the smaller players.
As for the debate around best-of-breed Sourcing vs. Sourcing tied into your operational and transactional systems, I defer weighing in for now. I certainly sponsored/authored/architected Oracle’s highly integrated approach to their flagship Advanced Procurement product line. But I’ve had a little less Oracle cool-aid lately and am getting close to forming a more objective opinion.
Lessons from Transparent Punch-out Project
One of the projects I learned the most from at Oracle was Transparent Punch-out. Of course, for as long as I can remember we had this vision of keeping content under the supplier's control & on their website but being able to ensure a consistent user experience for self-service requisitioners. For many years this just sat on the shelf, until one day Vijay Pawar and a few crack engineers on his team did an advanced prototype that actually worked and performed. We were able to do a distributed & parallel XML query to multiple content sources, get the responses, aggregate them & display them all within a second or two. We immediately submitted a patent on the idea, and scheduled it for the 1st available release.
Next, we invited a bunch of distributor suppliers to Redwood Shores to get their feedback. We told them "look, no more catalog syndication". We send you a query, you respond with the results. It's all real-time, with search governors in place to ensure speed. How do you think they reacted? "Boo!", "Hiss!", "NEVER!"
We had failed to position the "why" – and suppliers, hungry to differentiate to their customer base, just weren't buying. Sure, there were a couple ready to compete on price alone with good back-end systems who were ready to play ball. But 1 company estimated it would cost them $900,000 to adapt their systems. Pah! I'll adapt their systems for that and then hang out in the French Riviera for a few months to recoup. The bottom line was, if suppliers view a technology change as moving them closer to a commodity they will passively & actively resist.
Transparent Punchout may yet prove compelling – in fact, it has been pushed forward a lot further in the UK than in the US. Time will tell.
But lesson learned – technology that bring capabilities to buyers at the expense of sellers will go nowhere fast.
Targeting Your Supplier Programs
Most companies I’ve worked with over the years put their suppliers in 3 buckets:
A) Strategic
B) Important
C) “Who Dat” (aka Shop)
It’s unfortunate many Procurement organizations are daunted by the size of their supply base when designing supply programs. A simple query reveals the steep “relationship drop off” between the masses & those who you really value.
There are several ways to judge value – the most obvious being dollar volume and transaction volume. Add to that a weighting for “direct” vs. “indirect” and you’re almost there. All you need do is add a sprinkling of suppliers whose innovation helps shape your business. And you should know those suppliers by name.
Voila, for most firms we’ve just reduced the supply base from 10-20,000 to a few hundred tops.
And my advice is to aggressively invest on improving your electronic and human interactions with these few hundred strategic firms. For the rest, it’s up to you. It all comes down to real efficiency. If you can reduce cost through automation (truly reduce costs, not just push costs to exception management) then by all means do so.
With a manageable number like a few hundred, go ahead and scorecard. Take subjective surveys. Plan face-to-face visits. Invest in strengthening relationships and securing your supplier’s best ideas.
Improving the speed and “connectedness” of the supplier’s organization with your own can really help. Most types of communication with your top suppliers “is goodness”, the point is to increase it.
Do you have more than 3 buckets, or a completely different distribution of strategic suppliers? Or perhaps other measures to determine who to spend time on? By all means, share them!
Software Development Practices Must Change
I think it might have been my former boss John Wookey who said “Software development is a lot like making sausage. The less known about the process, the better.” How true! And I know John is committed to improving practices at Oracle. But let’s face it: software development at big ERP companies is inefficient. And looking at Microsoft’s woes with Vista it’s obviously not just big ERP firms that have trouble.
So how do these firms build software? Surprisingly, practices haven’t really changed for decades. The state of the art is still classic waterfall-based milestones where thousands of resources are supposed to hit “Design Complete” or “Code Complete” all on the same day. I’ll risk getting flame mail & go ahead and state the obvious: it’s stupid. Delays are built into the model. In my experience human error, communication mistakes, and scope increases were the 3 most frequent causes of schedule delays, and they certainly weren’t the result of incompetent resources. Instead, they were the result of a system so inefficient it seems ripe for revolution. Southwest Airlines, efficiency zealots that they are, would go berserk if they saw it!
I still recall the original target for Oracle’s 10th installment of 11i was very early in 2004, perhaps January. January turned to March, March turned to June, and eventually 11i10 came out in November of 2004. Customers affectionately renamed the release from 11i10 to “11iWHEN?!”
In Procurement, 11i10 was a very big release. I had introduced 2 new products – Procurement Contracts and Services Procurement. We had interested customers demo’ing product in January. But by November I had lost most of their attention, as well as that of Oracle’s direct sales force.
Of course, post-11i10 launch Oracle acquired Peoplesoft & there were a lot of management changes. Heck, now Oracle has also acquired Siebel. But through all this change 1 thing has remained the same: the delays. Now R12 of Oracle e-Business Suite (on which development began in 2004!) is even further off schedule than 11i10 ever was. I hear the latest target for the release is November. Sound familiar?
Just to make my point, consider this: I was still at Oracle, and still heading up Procurement applications development when R12 scope was determined. I selected features from an impressive candidates list and did my best to maximize Oracle’s chances of growing share in the market. I oversaw functional design efforts and early advanced prototyping. And yet even though I left the group in January of 2005 (to head up CRM for a “New York minute” prior to the Siebel acquisition), my organization’s ideas won’t be tested in the market until 3 years after they were envisioned. And by the way, the organization is led by just as much talent and capability as it ever was.
Why, I could probably start-up a new enterprise applications business and deliver v1 product before Oracle even released my prior work. Sort of a mind-bending thought, I know, but true.
By the way, you could always predict the projects that were going to cause a schedule delay. They were either painted with a big red “I’m going to be so-o-o late” sign (e.g. let’s rewrite the Account Generator) -or- they were cross-product and cross-organization efforts. Whenever teams with differing priorities had to come together to get work done there was the possibility of miscommunication, differences in points of view on prioritization, and, to sum it up, risk.
Okay, now I’ll go ahead and say what you’re expecting: THERE IS A BETTER WAY. A former direct report of mine and all-around smart guy Seth Stafford once came up with an idea called “the chute.” Here’s how he envisioned it: you’d have your copious amounts of resources all working on their important efforts. And at any given time you’d select 1 key project or initiative to be in “the chute”. The attention of the entire company would be drawn to the project at that time. Of course it would have to pass rigorous inspection criteria to qualify for “the chute”. Any issues encountered while adding the project to the existing body of work (in this case the eBusiness Suite) would be Priority 1 for the entire group. The project would have a very short, fixed time period to get through the chute and to release.
What’s great about Seth’s idea is it is a fundamentally different approach than today’s “we need to test all this stuff together” mentality. Combining thousands of destabilizing elements into a new build & then trying to isolate problems and iron out difficulties is challenging work. But Seth’s idea poses perhaps a bigger challenge to traditional enterprise applications vendors – it requires a brand new approach to how many layers of stratified and often intransigent organizations operate.
I’m in favor of software development practices that empower individual groups to move fast and yet still ensure the high intrinsic quality customers deserve. I believe there’s an opportunity to foster chaos-based development while upholding processes meant to ensure standardization and high quality.
As always, I encourage your thoughts. If you’re a Procurement manager, do you really care about innovation in software development, or are slow, lumbering 2-3 year releases with incremental innovation good enough. After all, aren’t policy enforcement challenges and other, more political issues, really your key areas of concern? If you’re in IT, how fast can you reasonably adopt change anyway? Doesn’t a release every 24 months free you up for business-sponsored project work? And is the only way to uptake software faster through SaaS? And finally, if you’re in software development yourself, what’s worked for you?
Half Moon Bay Turning Into Shangri-la
On Saturday around 8pm there was a landslide just off Highway 92 out here in lovely Half Moon Bay. It took out a fiber optic cable I had very much been taking for granted. Said cable carried regular wired phone, broadband internet, and even wireless phone communications.
Combine it with another landslide which has forced a months-long road closure of Highway 1 at Devil’s Slide, and we are just a few natural disasters away from becoming a fantasy or lore or a myth.
Thankfully, due to the hard work of AT&T repair crews up until midnight last night, we are back on the grid and wired to serve!