Posts filed under 'Enterprise Software'
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:
- 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.
- They issue a list of requirements to potential software vendors …
- … who all agree that their software is capable of meeting those requirements.
- The business then identifies a consulting partner to manage the implementation.
- Implementation of the software begins with everyone in high spirits.
- Then everybody realises that the business processes are a lot more complex than had been assumed in step 1.
- 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.
- More money is thrown at the project.
- 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.)
- 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.
- The system is declared “live” to great fanfare from the project team, and indifference from the people who are supposed to be using it.
- 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.
- 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.
- 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.
- …….. 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
Software wants to be free
Over time the value of software trends towards zero.
In operating systems we’ve already seen mass supplanting of Unix with Microsoft and now with Linux.
In the procurement space SAP to Ariba to Coupa marks a clear trend. OK, so Coupa isn’t completely free but if they really are providing people to support your setup on their system in the quoted prices – then the software element of the deal is pretty close to free. (With thanks to the doctor for the Coupa story).
Then in the sourcing space, Whyabe is already offering software for free.
Of course things are never as simple as they seem:
- Free versions of software tend to have less bells and whistles than the chargeable versions.
- There are always lots of revenue opportunities for software companies outside of selling just the software itself.
But overall the direction of software pricing is only going to go one way.
1 comment October 22, 2007
Keeping up with supply chain technologies and trends
This is a section title in Are You the Weakest Link in Your Company’s Supply Chain? (subscription required), an article in HBR Sept 07. The article attempts to raise the profile of Supply Chain Management amongst CEOs by arguing that, when done right, SCM is a source of competitive advantage.
They give a range of pointers on how to do Supply Chain Management right, for example:
- Ensuring that supply chain leadership has real supply chain expertise,
- Adding supply chain insight into business planning,
- Balancing short term and long term views,
- Taking advantage of modern technology.
On the subject of technology the authors argue that whilst good implementations of technology can make a positive contribution to supply chain management, many companies make unwise investments in technology. Therefore:
A CEO who understands new technologies can play the important devil’s advocate role by challenging the business case for technology adoption. Most firms that have bought leading-edge supply chain systems acknowledge that they use only a fraction of the software’s functionality and an even smaller fraction of the promised capability. An attentive CEO can lend authority to the change-management process, helping to foster user buy-in and making certain that proper vendor support, adequate training, and other resources are in place.
Moreover, CEOs who fully appreciate the challenges of deploying complex and costly systems can help their companies avoid classic missteps. The CEO of an industrial equipment manufacturer admitted that her company into one such classic trap: “we spent $18 million getting an ERP package up and running in our company, and all we did was bring more modern technology to bear on supply chain processes that are 40 years out of date. I expected this technology to bring supply chain costs down dramatically, and nothing has changed. My mistake was expecting technology to solve a process challenge.”
I love this quote and couldn’t agree more with the sentiment. But I suspect that readers might go away underestimating the significance of change management issues when implementing new software. Users are very likely to resist the imposition of new supply chain technologies. Encouraging buy in and user adoption takes a lot of attention from the top. A lot. For your software implementation to succeed, at least with the kinds of software package around today, you will need plenty of leadership attention and energy to overcome user resistance.
Add comment October 15, 2007
The Future of eSourcing – Less is More
Anyone remember SAP circa 1998? The way SAP integrated everything was great. Except it was completely unusable. Then along came Ariba’s e-procurement system and it’s whizzy interface. Here was a system that would address SAP’s legendary user-unfriendliness, and drive adoption of improved purchasing processes through organisations. Guess what? While Ariba did solve some of SAP’s problems it raised plenty of new ones: how to ensure catalogs could be easily searchable and contained relevant items; how to ensure users understood what they had to buy through the Ariba platform and what they had to buy through different processes, etc.
A common theme throughout is that software systems, however intuitive they are to their designers and builders, are rarely intuitive enough to their end users. Aside from a small number of glowing successes, many corporations find themselves achieving less than what they expected when implementing new e-sourcing systems. As European Leaders In Procurement put it in July 2007: E-systems gather dust. (http://www.europeanleaders.net/magazines/procurement-magazine-jul-2007/procurement-news/e-systems-gather-dust/).
The relentless consumerisation of business technology is a great opportunity to change all this. I’m not talking about a Web 2.0 phenomenon – the blurring of boundaries between consumer tools and business tools has been going on since Instant Messaging, if not before. However, it is consumer Web 2.0 sites that are now pointing the way to the future of enterprise sourcing software. For example, two web sites that excite and inspire me the most are ones like www.ecourier.co.uk and www.zopa.com. They are easy, friendly and the user can see where the value is. Consumers are not interested in “downstream process improvements” – they are interested in whether a particular tool is good for them now. This is not to say that consumer tools are unsophisticated. Zopa, certainly, needs to do a lot of fancy footwork behind the scenes when it matches borrowers with lenders.
For sure, the e-sourcing industry has come a tremendous way in the past decade but in all honesty e-sourcing is still in a comparatively early adopter phase globally. In order to really reach mass adoption of our tools, and to transform the effectiveness of enterprises, e-sourcing tools need to take far more cues from consumer-friendly sites and, dare I say it, less cues from IT departments’ integration requirements. Imagine that: users demanding e-sourcing tools because they are fun and helpful rather than using them because the boss says so. A brave new world indeed.
Add comment October 2, 2007
eSourcing Software Adoption Challenges – a cynic’s view
I recall the implementation of a purchasing module of an ERP system from a past life. The intention had been for individual requisitioners to enter their requisitions directly into the ERP system. But the software was too cumbersome for end-user requisitioners, so they continued filling out their requisitions on paper and the organisation then assigned “super-requisitioners” to enter those requisitions onto the system.
Measuring such a project against “number of users” would show a failure. But change the metric to “number of reqs online” and you might have a success on your hands. Albeit at the cost of the super-requisitioners to do the typing for you. And hope no one asks about why you are using a super-expensive ERP system to store your requisitions when you could have got your super-requisitioners to type them into Excel. Still, you have a good metric of project success that you can put on your resume which is the most important thing, right?
This is an eProcurement example, I know.
eSourcing is very similar. Often companies start off with a plan to roll out extensive adoption of new RFX functionality. The roll-out then stalls for all the usual reasons. Changing the success metrics is usually an easy way of pulling the wool over the business’s eyes and might confuse them enough not to challenge you about the value of enterprise sourcing software if the bulk of the process continues to take place offline.
Add comment August 22, 2007
eSourcing Software Adoption Challenges – an Optimist’s view
OK, you’ve invested in a license for a new eSourcing system. You love it, your team loves it and the CPO has given it her blessing. Even the CEO turned out at the launch and came to the pilot reverse auction you did and was very excited by the results.
But 6 months later and you’re struggling to keep momentum going. You’ve only managed one more reverse auction, only a handful of staff are actually using the new system with most still happily using Excel for everything. Where to go from here?
In the simplest of terms, people take to new technology (applies to pretty much everything) either when:
- It is fun and/or makes their lives easier (Nintendo is an example of the first, washing machines are an example of the second).
- It is mandated from above and their job/career/compensation depends upon it (Enterprise Software in general usually falls into this area).
Most eSourcing systems are not really easier for the individual buyer who is perfectly happy with Excel and Email. The people who benefit most from eSourcing systems tend to be managers who achieve better visibility and control.
Therefore the top-down approach is the one generally taken. The trouble with the top-down approach is that it requires dedicated attention from the top to continue ramming the new way of doing things down people’s throats until they give up resisting. Or Change Management as it’s sometimes called. Most organisations drastically underestimate the need for this.
What can you do about this?
- Review your implementation plan. Your implementation plan needs to go well beyond the initial customisation, training and pilot stage, through to how it will be rolled out across the organisation. Ensure functional heads are bought in as early as possible, understand the benefits of the system, are bought into the plan and consider it their system, not just yours. This point is often mentioned, but rarely acted upon because it is hard to do. I know it’s hard and time-consuming, but if you don’t do it you will struggle to reach the adoption levels you want.
- Ensure that you genuinely understand the issues that real staff members are facing, as opposed to what their managers claim are the issues. If you can demonstrate your system addressing these specific issues, or even make the software fun to use, then you will need less top-down attention.
- Don’t lose track of your objectives. Too many software implementations forget the original objective behind the system and get bogged down in indefinite debates with functional heads about requirements whose cost, in a sober analysis, would outweigh their benefits.
- Be prepared to fail. If those resisters are resisting your software then maybe they have a point. They are probably smart guys, after all. Sometimes, taking their objections seriously and adjusting your approach to adoption and roll-out (whilst continually ensuring you have agreement on the objectives in 3) can help in the long run.
Some more cynical comments on the subject tomorrow …
Add comment August 21, 2007
Product Development Lessons from Proctor & Gamble
Just been reading another article in the current issue of The Economist about Procter & Gamble’s approach to product development, entitled “Will she, won’t she?”.
Some quotes
[M]any people at P&G do not use the word “consumer”. Nor might they ask if a “customer” or “shopper” would buy a putative product. They are more like to ask: “Would ’she’ buy it?” … Women have long accounted for four fifths of P&G’s customers.
and
Staff from [P&G's] Consumer and Market Knowledge division tour the world and spend entire days with women to observe how they shop, clean, eat, apply their make-up or put nappies on their babies. They try to understand how a woman reacts in the first three to seven seconds after she sees an item in a shop (the “First Moment of Truth”, in P&G speak) and when she tries it at home (the “Second Moment of Truth”).
Some insights for those building enterprise software and esourcing software systems:
1. Be clear on who you are targeting. Certainly avoid generic terms like ”user”. A particular challenge for enterprise software developers is that the person buying the system (could well be a Purchasing Director or CFO, for example) is often far removed from the people who actually get saddled with the software. Which one is the real target? Probably both. Most enterprise systems I’ve seen are great for one or the other, but struggle at being good for both.
2. Once you’ve worked out who you are targeting get to know how they really operate during The First and Second Moments of Truth, i.e. When they see the demo (they first moment of truth) and When they pilot it for the first time (the second moment of truth). You won’t achieve this by reading analyst reports and case studies. You’ll only achieve this by being on the ground with people as they work with the software.
Add comment August 17, 2007
Software Firm Successful IPO Shock
In a time of sliding stock prices, VMWare’s stellar IPO stands out:
Check
http://www.economist.com/business/displaystory.cfm?story_id=9644619
for the story and
for some more details
Good news for technology companies with viable business models.
Add comment August 16, 2007
There Is Always More Change Management To Do
The Economist on 11 August has a feature on the uptake of roundabouts in the USA.
Apparently roundabouts are safer (less misjudged left-hand turns, or right-hand turns in the UK), cheaper (no traffic lights), more fuel efficient (cars only need to stop if there is traffic coming onto the roundabout).
What has this to do with a blog on e-auctions and enterprise software? Anyone who has attempted to implemented ERP software or eSourcing software will recognise the issues knows that getting users to adopt new technology can be a very long, hard, drawn-out process. It’s heartening to remember that exactly the same change management issues can occur in all kinds of areas – not just software. According to The Economist:
In Deepest Washington state, trouper Dusty Pierpont stands in front of a roundabout trying to persuade motorists to like them. Washington started building roundabouts in 1997. By 2001 there were 17; now there are over 100, according to Brian Walsh of the state’s transport department. But trooper Pierpont is still needed to soothe those first-time (or even tenth-time) nerves.
Sound familiar?
Add comment August 16, 2007
