Posts filed under 'e-sourcing software'

Gartner Magic Quadrant for Sourcing Application Suites - A Reaction

See this link on Spend Matters for the story on Gartner’s 2008 Magic Quadrant for Sourcing Software http://www.spendmatters.com/index.cfm/2008/7/15/A-Free-Look-at-a-Gartners-Sourcing-Magic-Quadrant. My comment was a bit too lengthy for a comment on Jason’s post. So here it is, below:

First a disclosure: I lead the product development for TradingPartners. TradingPartners provides eAuction services. Very similar to what FreeMarkets pioneered all those years ago with their “Full Source” offering. We don’t sell software licenses, let alone software suites, so wouldn’t fall into Gartner’s analysis but we are considered competitors with a number of the companies mentioned in the Gartner Sourcing Magic Quadrant report. You can make up your own mind to what degree the comments below are self-serving or not.

I’m not keen on the name of the report. Despite all disclaimers the report is titled “Magic Quadrant” which implies that there is one “magic quadrant” that buyers should look at, i.e. the top right. And when I look at the vendors in the graphic the relative ranking seems fairly arbitrary. Certainly it’s not clear from the report why Quadrem should be better able to execute than BravoSolution.

The best part was the overall 10,000ft view of what is happening in the market. In particular:

  1. The distinction between strategic sourcing and tactical sourcing. “Organizations should expect to eventually deploy two separate sourcing solutions or two configurations of a single solution: one for tactical sourcing (for example, querying a contract fuel vendor for this week’s price per liter) and one for strategic sourcing (such as simultaneously negotiating rental car contracts across multiple vendors for service for the next three years and in 10 countries”.
  2. The summary of the consolidation in the sourcing software space (gone are Freemarkets, B2eMarkets, Frictionless, Mindflow, Procuri, Verticalnet).
  3. The recognition that wrap-around sevices are of paramount importance in strategic sourcing initiatives. “[E]ffectively leveraging different auction/event types for the best results requires a knowledge that can be gained only be using strategic sourcing applications. Furthermore, enabling suppliers to register online and providing customer service to troubleshoot their issues requires a significant effort that a procurement group will not be able to support without advanced planning and incremental staffing”.
  4. The recognition that strategic sourcing tools don’t require ERP integration. “They function nicely as standalone tools, because the trigger to commence a strategic sourcing event is the initiation of a project, and prospective vendors do not need to be in the vendor master unless they win the bid. The output of an event tends to be a contract. The unstructured nature of strategic sourcing lends itself to solutions that are architected as project management and document repository tools”. Here Gartner calls strategic sourcing unstructured. I would prefer to call it BRP (in contrast to ERP).
  5. The recognition that, in reality, buyers are still sticking to Excel rather than fully automating the sourcing process. “Requirements should be specified in the sourcing tool at the line-item level to fully evaluate and document the resulting bids using the application; however, in practice, many companies simply attach the specifications and record the resulting proposals at the header level, and analyze the results offline.”

Some parts of the report I would take with a pinch of salt:

  1. Including forward auctions in the debate. They are a red herring. Sure from a technology point of view they are similar to reverse auctions but in practical business terms they are of little relevance to most buyers.
  2. Cautioning that some suppliers are buggy. Without any meaty supporting arguments I’d assume all software is equally equal in this regard
  3. Come to think of it, a lot of the “strengths/weaknesses” seem cursory. E.g. Ariba is praised because it “offers varying scales of its sourcing product so customers can consume functionality as gradually as desired”. And Ariba is criticised because its “customers tend to use sourcing to solicit bids from local vendors”. 

1 comment July 18, 2008

Blame the users, or the technology?

Hardly a news story but this week’s Supply Management has a news story headline “Councils: most buying goals met“.

One of the goals listed in the article that was not met was the use of e-marketplaces.

Each council was also meant to be using an e-marketplace by 2006, but latest figures show only 22 per cent have met this target.

The traditional response to such a dismal failure to adopt a new technology is: “more change management, please, doctor”. As if the technology users are always to blame for being to blinkered.

But are people always and everywhere scared of new technology? I don’t think so. People are not afraid of adopting new technologies if those technologies are good. Excel. Mobile phones. SMS. Email. Social Networks. Online airline check-in. Google. Online banking. Etc etc. (yes, I am old enough to remember offices before Excel. I spent some time working as an accountant doing 4 column trial balances on paper. That was horrible).

Oh yes iPods. Good technology. Vista. Not as good technology.

You can make your own lists.

To come back to the SM article: if an e-marketplace helps buyers buy stuff better then of course they will use it. But if it is just a pain in the a** to use then they will stick to email and Excel. And don’t talk about nebulous downstream process improvements, puh-lease. People want process improvements now, not some unidentified time in the future.

When a fly keeps banging its head against a pane of glass trying to get out of your house, it’s obvious what the fly needs is a different approach: an open window. The same is true in enterprise software. Software developers: stop bashing your heads on the change management window. Do something to your software so the users don’t need change management to want to use it.

The exciting news is that there are some people who are daring to do the undoable. Thingamy for example has the audacity to be challenging not only the rigid process-driven ERP mindset prevalent in the industry, but also how we do something as basic as accounting. Will they succeed? Who knows. But the more people who take Sig’s lead and try to re-invent enterprise software, the more chance we’ll have of getting those buyers all happily using their e-marketplaces.

 


Add comment May 30, 2008

eAuctions in the news

Always good to see some  (positive) coverage of eAuctions in the trade press. Here’s an article from Purchasing.com about BlueBird’s use of eAuctions. For non-US readers, Blue Bird make those iconic yellow N. American school buses.

Blue Bird procurement uses an e-auction tool to help consolidate the company’s supply base and transform purchasing.

Whose e-Auction tool? TradingPartners’, of course!

 

But you have to read the article carefully to get the full story. On the one hand Purchasing says

In the year since he assumed his current post with the bus manufacturing company, Marshall has used an e-auction tool of Trading Partners in Chicago to negotiate pricing with suppliers of safety supplies, crib supplies, corrugated packaging and office supplies. While the lowest bidder doesn’t necessarily get the contract—quality and delivery are equally important criteria, he says—the tool has helped to reduce costs in some spend categories by 30%.

Read this paragraph and you’d get the impression that Blue Bird bought a license to use a piece of software to run their auctions on.

 

But later on Purchasing says

Marshall, who has more than 30 years experience working in purchasing in the auto industry, views Trading Partners, which has conducted more than 20 e-auction events for Blue Bird, as an extension of his purchasing team and sought its expertise when analyzing the company’s spending. Blue Bird’s database is huge—there are approximately 30,000 part numbers on an average bus.

In other words - it’s the service that Blue Bird has bought into, not just the software.

 

This is an important distinction.

 

If you buy software for your e-auctions (which may well be pretty cheap), then unless you have some pretty dedicated people on board, you will struggle to achieve the adoption levels you hoped for. Strategic Sourcing (and, by extension, Auctions) is a very different beast to processing purchase orders. Strategic Sourcing is much more of a “Barely Repeatable Process”, to use Sig’s phrase than the kinds of “Easily Repeatable Process” that ERP-biased software houses build their software around.

 

So, until some BRP-style software for eAuctions turns up you should consider carefully whether what you really need is the software, or whether what you really need are the results. If it’s results you are after then think seriously about buying the service rather than just buying the software.

 

 


1 comment May 14, 2008

The consumerisation of enterprise (e-sourcing) software, revisted

One data point does not prove an argument but look at Zycus’ recent announcement of their sourcing software, a commented on by Jason Busch:

Zycus iSource – Zycus iSource is an eSourcing module that provides comprehensive RFX processing, objective supplier bid evaluation and multiple negotiation techniques. Zycus has leveraged Web 2.0 technologies including Drag-and-Drop for RFX creation, Interactive graphical analysis, and collaborative workflow to provide end users the simplicity, speed and power that encourage adoption.

“In order to be more broadly adopted, sourcing tools need easier to use functionality for constructing requests, evaluating bids, and archiving the results of events in a searchable fashion,” said Deborah Wilson, Research Director at Gartner Inc.

Good to see people buying into the idea that consumerisation is the future of business technology. Though whether Zycus have simplified the tool sufficiently is an open question at this point :)


2 comments January 31, 2008

Lightweight technologies, e-sourcing and VRM

One of the blogs I read most religiously is Confused of Calcutta (*). For the past aeon or so, JP’s being going on about the uses of Facebook and Twitter in the enterprise. Today’s post brings together a whole bunch of strands that show vividly how small pieces of technology, that on their own are not that intersting, combine to make a whole that is far greater than the sum of its parts. He uses examples from the consumer side of things, but we all know how consumerisation is the future of business technology.

But I digress. To come back to JP’d post. Read it, the storyline is great. I’ll try not to rip off the whole thing, because you have to follow the story to get the point. But here are some extracts:

Something should be scraping what I am doing, capturing it in a way I can choose to share with others. Choose, we must remember that word. And what else? Oh yes, wouldn’t it be nice if I could enrich the information I was sending? Provide more information about the artist or group, maybe YouTube video links, maybe Wikipedia links, maybe Flickr links, maybe even the homepage of the band or group. How about a link to the song itself, so that someone else can sample it, try it out, decide for themselves if they like it? Maybe even a way to search for more information, and the tools to buy the CD or DVD in physical or digital format?

and

It’s worth bearing a few things in mind. First there was the web. Then there was SMS. Without SMS there is no Twitter. Without the web there is no Twitter. Now we’ve had tinyurl for a long time, but it starts coming into its own when we start using something like Twitter. As a result of all this, someone else could build something like FoxyTunes (which looks like Netvibes meeting last.fm), and then building TwittyTunes to connect up with the Twitter world. And then suddenly everything else waltzes in to enrich what we can see and do, ranging from text to audio to video, from search and syndication and conversation to fulfilment.

and

What strikes me is the power manifest here, the power of connecting simple things like SMS and tinyurl and Twitter. Small pieces loosely joined, as David Weinberger said.

There are important applications here in the e-sourcing space. Funnily enough, JP ends the post with some questions about VRM (short questions, long answers). Now, I think he’s talking about VRM from the perspective of how, say, one individual an manage his relationship with the arline he buys tickets from and another person can manage her relationship with the garage she bought her car from. But I’ll address it from the point of view of sourcing in the enterprise space. Here’s a start: The important innovations of tomorrow won’t come from inside Ariba or even Emptoris or Zycus. The innovations will come from small pieces that didn’t even come with a business plan attached, until people (yes, people, in the plural) figured out how you could plug them all together, and then all of a sudden it all seemed so obvious.

Ridiculous? I don’t think so. What about MFGx.com’s recent exhortations to use YouTube more? There’s something emergent here.

(*) - I’ve been a big fan of JP Rangaswami since I first heard his story about how you decomission a mainframe. To paraphrase: If you need to decommission a mainframe and you ask people in the organisation whether they still need it or not they will tell you that, yes, they do sometimes need it. They will tell you that, yes, they do refer to the 50 page printout that lands in their department once a week. So you can’t decommission it. So what you do, is you just turn the damn thing off. And then 6 weeks later tell people that you’ve decomissioned it.


Add comment January 28, 2008

ERP, BRP and e-sourcing

Brilliant post I picked up from Gaping Void. It discusses a company called Thingamy and how Thingamy’s founder contrasts ERP (which in his book equates to “Easily Repeatable Process”) with what Thingamy call BRP (“Barely Repeatable Process”).

When I think back to my old SAP and Ariba days: those are really all about Easily Repeatable Processes. Posting an invoice, posting a purchase order, issuing a sales order. Etc etc. All pretty standard stuff that happens the same way day in and day out.

But when it comes to sourcing, things are rarely as clear cut as posting a purchase order. Sourcing is much more BRP than ERP which is probably why so many of the traditional ERP companies struggle to produce quality e-sourcing software. And why so many companies who have bought e-auction and e-sourcing licenses end up under-using them and/or considering them a poor tool (e.g. see the comments about e-auctions on Supply Excellence and SpendMatter’s third wish for Santa for some examples). And probably why Email and Excel are still de rigeur in most purchasing departments.

Unless Santa does come up with the MacGyver gadget, a new approach will be needed that better addresses the BRP nature of sourcing. And despite the underwhelming response so far to Enterprise 2.0, I’m sure that most, if not all, of the principles that Jeff Nolan lists here are going to play a major part.


1 comment December 21, 2007

Wikis, User-Generated Content and Procurement Communities

I started experimenting with wikis at TradingPartners a little over a year ago. A wiki could help us, we figured, with sharing  up to date category information across a team that is spread all over the globe. (How to best make sure when Joe in the USA ran a sourcing project for castings that he would know that Jane had recently been working on something similar in China, and would be able to benefit from her experience?)

A wiki seemed like a good fit as:

  1. it would be editable by anyone in the business 
  2. it would be accessible to everyone in the business over the web
  3. it would be fun for people to use
  4. the necessary investment would be negligible

So we tried out various wikis and settled on mediawiki. Launched it to the business early 2007 in workshops at which staff excitedly brainstormed ideas of what kinds of information they’d like to see on there…

Then we left it to see how it evolved. Fast forward 9 months and this is what we had:

  • Lots of marketing material - case studies, brochures etc.
  • Some customised user pages with pictures of people, their backgrounds and interests.
  • Standard templates, training materials etc.
  • Some category information. But, interestingly, this had not been put on by auction managers themselves, but by self-appointed editors who were collecting the information and uploading it.

In reality, despite the initial enthusiasm for a site that “anyone could edit” was replaced with the more realistic understanding that in order for it to be of any value, “someone” would have to do the actual editing!

It brings home the fact that in wiki- or forum- style communities, the number of people who contribute information is a fraction of those who consume information. The templates and marketing information all went on because they only relied on a small number of interested editors to make the wiki site definitive. Some people – either those who find this sort of thing interesting, or those whose managers find this stuff interesting, were prepared to update their own user pages. But changing the process of running a sourcing event so that all the relevant information is entered into the wiki repository after the event for the benefit of others in the business? Now that’s a whole different proposition. And it begs a number of questions like: how do you make sure all the relevant information is loaded onto the wiki (and you don’t miss out a crucial piece of information which is blindingly obvious to you but which might not be obvious for other people)? How do you ensure that people who are consuming the information are looking at the right page (paper bought for resale might not be the same as paper bought as an indirect, for example)? Etc, etc.

Extrapolating from this experience has taught me something important about any attempts to build a procurement community online: The procurement world is sufficiently small that you can’t expect a critical mass of people simply to contribute useful information to any one central repository. Iasta’s e-sourcing wiki is an example: 7,500 odd hits so far but check the recent changes page and only a small number of names appear as contributors. Perhaps there’s a generational element, with newer buyers more open and older buyers more reticent. That would be the thrust of articles like this one at Tech Crunch, but I suspect the generational piece will turn out to be just a small element in the overall equation, especially when applied to business information. Seems to me that the best way to share useful information in the procurement space is by inferring it from what people are actually doing, rather than treating it as an activity in its own right. Of course, exactly how to infer auction best practice (for example) from successful auctions people have run rather than via a self-contained documentation exercise is another question in its own right which, I guess, nods towards the Semantic Web – if that ever gets off the ground. More questions than answers, in other words.

A coda: what did we do with our wiki in the end?

Well, we kept it for two things:

  1. Community building by people building their own pages and telling a bit about where they come from and what their experiences are. This is becoming part of the process for all new starters and is quite a neat way to quickly get a feel for who you should be talking to about what.
  2. An intranet-style piece holding standard templates and marketing materials.

Regarding category information: We could have gone down the traditional Enterprise Software Change Management route. This would have gone something like “come on, the eAuction managers aren’t updating their category information. We need to mandate it as part of the process and keep beating them over the head until they accept it”.  Or we could have gone down the Enterprise Software Budget Busting route. This would have been something like “the central repository won’t work without an editor. So let’s hire someone to maintain the wiki and have that person interview, or otherwise, extract information from the eAuction managers as they go about their daily jobs”.

We took a different approach, which I call the Going Back To The Objective approach. We asked “what are we trying to achieve here?”. The answer was: “help eAuction managers keep up to speed with what their colleagues are doing”. Next question: “Is there an easier way to do this that doesn’t make them do extra typing?”. Answer: “How about just letting everyone have query access over our history of sourcing events with some pre-defined reports so people can easily look up who has the most experience in category X and which eAuction managers have auctioned category Y most recently. That way they can just pick up the phone and easily get hold of all the relevant information, plus all that intangible, invaluable stuff you only get through talking to people”. The tool then becomes something to encourage, and facilitate, people to talk to each other. Not an end in itself. Boom. Sometimes the simplest solutions are the best.


4 comments December 20, 2007

e-Sourcing at Royal Mail

Silicon.com has some good detail on how Royal Mail is using e-sourcing.

The SAP application went live in June after a relatively short two-phase implementation of just over three months and is being used [as at 1 November] by more than 100 Royal Mail staff.

Those timescales are pretty good in SAP terms - 3 months to get the system up and running and then getting to 100 users in 4 months. Read on …

The application being used is from SAP’s 2006 acquisition of Frictionless Commerce.

So it’s using the SAP badge but is really a standalone piece of software?

“We are looking to make it more connected with what already exists here in the SAP landscape.”

So the 3 month installation process was to get a basic, hosted e-RFX/e-auction system up and running?

Read the full story at http://www.silicon.com/publicsector/0,3800010403,39168959,00.htm


Add comment November 10, 2007

The consumerisation of enterprise (e-sourcing) software

Hand on heart, what would you say are the most popular e-sourcing technologies amongst buyers? How about:

  • Outlook
  • Google
  • Excel

Sorry Ariba, sorry Emptoris, sorry Procuri, sorry Iasta.

This pattern extends far further than just the world of procurement.

Once I, like many others, used to assume that dragging users by their ears until they saw the light of a new enterprise system was just part of the normal process of deploying a new enterprise software system. They used to call it change management.

But again, like many others, I have been blown away by how fast adoption can kick in for software that is genuinely good and flexible enough that people want to use it.

Imagine enterprise software that didn’t need change management. Imagine users demanding software. Like they do with MS Office, email, Google Maps, etc. Imagine software that doesn’t add new features for the sake of it release after release, but just builds one or two pieces that work well and which people can understand fast.

Now look at Huddle, or Coupa, or 37Signals. These guys are onto something.


2 comments November 2, 2007

How software implementations fail

The doctor’s comment from my last post leads me neatly onto posting about what is broken about today’s models of enterprise software in general (and enterprise e-sourcing software in particular).

Here’s a take on how your average enterprise software deployment fails to meet expectations: 

  1. Someone in “the business” figures that a software tool will help address a particular business objective. After all, they were at an industry conference recently in which a company spoke about the tremendous benefits it achieved by adopting solution XYZ.
     
  2. They issue a list of requirements to potential software vendors …
     
  3. … who all agree that their software is capable of meeting those requirements.
     
  4. The business then identifies a consulting partner to manage the implementation.
     
  5. Implementation of the software begins with everyone in high spirits.
     
  6. Then everybody realises that the business processes are a lot more complex than had been assumed in step 1.
     
  7. To compound this, it turns out that when the software vendor had said their product was capable of meeting the requirements, they neglected to mention that this would only be at considerable customisation costs.
     
  8. More money is thrown at the project.
      
  9. Then the business decides to change the requirements. (Repeat steps 6 to 8 for as long as $$$ and enthusiasm allow. Remember that the consulting partner is charging day rates for this so won’t be overly upset. Or if you thought you had a fixed price agreement now is when the change orders start flying thick and fast.)
     
  10. The project is going nowhere. Exhaustion sets in and finally everybody agrees to implement something approximating the original set of requirements. The software is only just about being used.
     
  11. The system is declared “live” to great fanfare from the project team, and indifference from the people who are supposed to be using it.
     
  12. Just when everyone thinks the project has finished, someone checks back to see how well the software system has delivered against its original objectives. No-one can remember the original objectives.
     
  13. Various options now exist: Scrap the system (or scale back the implementation scope), point fingers, hire more people to operate the new system etc etc. Some or all of these options get played out.
     
  14. Eventually the dust settles. Project sponsor, consulting partner and software vendor all agree that the project was a tremendous success. Press releases, glowing resumes and presentations at industry conferences follow.
     
  15. …….. time to start again with the next customer.

Has Software-as-a-Service / On Demand solved all this? Not necessarily, is the simple answer, you realise, when you speak to some of the people who actually have to use this stuff.


1 comment November 1, 2007

Previous Posts


What

Alan Buxton on e-Sourcing in general and e-Auctions in particular

RSS Subscribe

CTO

Read my technology blog, Golden Pebbles

Technorati

Add to Technorati Favorites

Category Cloud

auction CIO e-auction e-sourcing software Enterprise Software procurement Ramblings reverse auction Software development sourcing

Archives