7
M.G. Currie & Company 1 The Four Basic Rules of Enterprise Software By Michael Currie

The Four Basic Rules of Enterprise Software

Embed Size (px)

DESCRIPTION

 

Citation preview

Page 1: The Four Basic Rules of Enterprise Software

M.G. Currie & Company

1

The Four Basic Rules of Enterprise Software By Michael Currie

Page 2: The Four Basic Rules of Enterprise Software

The Four Basic Rules of Enterprise Software 2

You’ve heard the statistic – 70% of enterprise software1 projects fail. How can that be? If results are so dismal, is technology really driving productivity gains in industry today? How does this business stay in business? The alarming statistic obscures something more important; most organizations relying on enterprise software aren’t getting their money’s worth. It’s a real issue in business today because information management is a drain on resources and companies can’t afford time or money wasted on under performing systems. Is applying technology properly an art or a science? Hard to say, but organizations getting value from enterprise software treat it the same way as any other investment - it has to be aligned with the business and provide measurable payback. The technical minutia doesn’t distract them from the underlying purpose for the investment, and they execute expediently. There’s a sense of ownership that survives the initial rollout and with time the system becomes ubiquitous, as useful and unobtrusive as a telephone. There’s no magic bullet that guarantees success with enterprise software, but a certain management approach, a specific set of priorities, seems to pay off. I call these attributes the Four Basic Rules.

1. Software Isn’t Strategy Enterprise software is often promoted as delivering strategic advantage, as the basis for change and the means to transform a business. But software isn’t strategy - while it can automate processes, boosting efficiency and productivity, it is not a substitute for conceptual thinking, business planning, or managing an organization to produce results. Companies court disaster if they try to implement without it being part of a larger initiative to improve the business. I don’t blame software vendors for creating the aura of strategic advantage around their products, it’s great positioning; unfortunately it isn’t true. Management differentiates successful firms from their competitors, profoundly so when making technology investments. There was a wonderful study done by McKinsey2 a few years ago for the European Commission. The EC worried that the productivity gap between Europe and America was due to lack of investment in technology by European companies and they wanted to understand the effects. McKinsey studied a large sample of companies in Europe and ranked their level of technology investment relative to total factor productivity gains over an eight-year period. Then they compared this ranking to a number of variables, the most interesting of which was an objective measure of “management practices”. The

1 Top categories of enterprise software include Enterprise Resource Planning (ERP), Enterprise Asset Management (EAM), Customer Relationship Management (CRM), Materials Requirements Planning (MRP), Human Resource Management (HRM), and Supply Chain Management (SCM) systems 2 “When IT lifts productivity,” Stephen Dorgan/John Dowdy, The McKinsey Quarterly, 2004 Number 4

Page 3: The Four Basic Rules of Enterprise Software

The Four Basic Rules of Enterprise Software 3

results were telling. Companies with low levels of both technology investment and management capability showed 0% improvement in productivity. Those with high levels of technology investment but with meager management capability gained only 2%. Well-managed companies with low technology investment levels still showed 8% productivity improvement while well-managed companies who invested heavily in technology showed a whopping 20% gain in total factor productivity. It’s management, stupid. Software as a strategy usually fails, but in support of one it has a good chance of success. Taking time to understand how the company makes money, and which business processes are critical, will determine the priorities for selecting and implementing a new system. It’s also very common for organizations to leverage an enterprise software project to standardize and simplify the way it does business, to get everybody on the same page. In those cases the software itself isn’t strategic, but the process of aligning people to it is. The approach that says, “We need to improve, software may help”, works better than, “We can only improve if we buy new software”.

2. You Can Show Them the Money There is no return on investment in enterprise software, or so it would seem. Direct savings from streamlined business processes might allow companies to benefit from fewer errors, less staff, and reduced duplication, but these advantages are usually so small compared to the cost of today’s implementations that it’s very difficult to build a compelling business case based on these gains alone. So is that it, don’t buy these systems? Of course not, well-applied enterprise software is a lot more than just a transactional infrastructure, and sophisticated companies understand the strategic implication of leveraging information systems to full advantage. The trick is the advantages may be indirect, sometimes too oblique for most people to understand. But they can be of great value to the firm. During the sales cycle vendors may embellish their dry efficiency arguments with claims of extraordinary secondary gains. They’re on the right track, but they don’t have the deep understanding of your business necessary to accurately determine such indirect benefits and, after all, they’re trying to sell you something. Indirect benefits are usually cause-and-effect; something about the new system that enables a step change in the way a process is managed. A good example was a marine transportation company I encountered several years ago - they made a large investment in an Enterprise Asset Management (EAM) system that allowed planners to automate preventive maintenance activity and integrate it to inventory and financials. This lead to savings in stock levels and improved maintenance efficiency, but the real payback came from something unexpected – it turned out that marine survey and insurance authorities accepted date-stamped digital images associated to historic work records, a function supported by the EAM. This meant that the company could avoid costly invasive equipment inspections

Page 4: The Four Basic Rules of Enterprise Software

The Four Basic Rules of Enterprise Software 4

and enjoy significant insurance rate relief. The savings amounted to hundreds of thousands of dollars annually and helped make the EAM investment a winner. Indirect benefits include such things as increased sales as a result of enhanced production scheduling due to ERP/MRP, or avoiding staff turnover costs because HRM software supports better employee training and development. There are many examples of measurable benefits flowing indirectly from enterprise software; they often dwarf direct benefits but they require more management input. Indirect benefits are, by nature, difficult to estimate, but they are real and should be included in the justification for the project. That justification will withstand scrutiny only if all the likely financial impacts are included, they are represented reasonably, and the impact shown not just departmentally but rolled up to the full organization P&L. Enterprise software investments do pay off, but it’s important to expose them to the same due diligence as any other investment and to understand that other things in the company may have to change in order to fully realize their potential.

3. A Simple Plan, Violently Executed, Will Defeat a Perfect Plan Every Time

General Patton’s famous quote about defeating Rommel is also a good strategy for an enterprise software implementation. While implementations aren’t exactly military campaigns, to succeed you need a plan with well-defined objectives and, like battle, the keys to success are leadership and execution. Leadership manifests itself first by communicating why the change is being made, and how. While this is not an article on corporate communication, let me just say that successful communicators usually have something relevant to say and they tell the truth; brevity is a useful byproduct. Leadership also means ensuring the project gets the resources it requires and delegating real responsibility to the individuals running it - especially the project manager, the most important individual leader by far. The project manager makes the day-to-day decisions about people and technology, manages to a strict schedule, understands interdependencies, and navigates the gauntlet of third parties, nervous users, and internal snipers. The role has to be filled by a competent insider, someone who can handle responsibility and authority. Every successful project I’ve seen had one, every unsuccessful project didn’t. With leadership in place, what comes next is execution. It’s fair to say that organizations with a general history of successful projects tend to do well at implementing enterprise software; they have a culture that expects results. Unfortunately many companies don’t perform so well at executing large, discreet projects, and a few are so mired in the status quo that overcoming it is a significant challenge. Affecting change requires a means to circumvent the mentality that infects inert cultures – a simple plan, with clear objectives and timelines, is the best way to achieve a result.

Page 5: The Four Basic Rules of Enterprise Software

The Four Basic Rules of Enterprise Software 5

There will almost certainly be an elaborate project plan that includes various technical and business streams that converge to a live system. That’s fine, but it’s critically important that the plan accurately reflects the business objectives for the project (milestones should be based on progress to these objectives rather than purely technical targets), be staffed appropriately, and scheduled on a tight timeline. Expedience, doing the things that need to get done to achieve a result, and timeliness go hand in hand. Don’t let a project meander on for years; most enterprise software implementations can be completed within 12 months, even the largest should be finished within 2 years. Never let a deadline pass. The goal for any software implementation is to offer utility to users and visibility for managers who need reliable information to make decisions. Set the bar to these achievable levels, perfection can come later. Many successful implementations are actually executed in two distinct phases; a large primary phase that targets basic initial system configuration and user acceptance, and a smaller secondary phase that embraces more complicated features that may be useful in the future.

4. It’s Never Over At the end of an enterprise software implementation there’s a usually a collective sigh of relief. The vendors and consultants leave, the system is handed over to a new administrator, and everybody gets back to their regular job. It’s done, phew. Except it’s not. It’s really just the beginning because if the investment had any legs in the first place management will want to see results ASAP. Not only that but a year later many organizations are left asking, “How did it go so horribly wrong?” Whether the initial implementation is considered a triumph or not, neglect will punish even the best-delivered systems. Ongoing success depends on three things - acceptance, data, and relationships. Acceptance can be difficult to achieve right away; users are understandably skeptical about a change that many may see as having been foisted on them, and most have been burned by transient projects that had a flavor-of-the-month feel only to be forgotten with time. The key to acceptance is to acknowledge that the system is a continuum, an environment that will evolve and improve based on users’ input. The best organizations formalize this process by creating an expert user group immediately after go-live and giving it teeth (a.k.a. “budget”). The group meets regularly and, if there’s one distinguishing feature about the ones that work, it’s that expert users are the ones informing the system administrators how to improve the system, not the other way around. Data sneaks up on people. Most projects require a significant conversion effort that takes data from the old system and transforms it to work in the new one, but a lot often gets lost in the translation. It’s also true that many organizations neglect their data for so

Page 6: The Four Basic Rules of Enterprise Software

The Four Basic Rules of Enterprise Software 6

long that virtually no amount of effort will improve what amounts to data gridlock. Companies need to continuously develop and cleanse their data, both to support the new system and to ensure that future upgrades can rely on data integrity from the outset. Many “failed” enterprise system projects are really data quagmires in disguise. Finally, the vendor relationship greatly influences the long-term success of enterprise software. It can take a bit of fortitude because the sales/implementation cycle can be very draining, but it’s worth the effort in order to stay current with new system developments and to benefit from the community of users that exists for all major enterprise software products. Most vendors do a pretty good job of organizing conferences and advisory panels, providing numerous opportunities to interact privately with companies in the same region or industry and to participate in determining priorities for future versions of the system. This saves time and resources because it’s better to be at the forefront of any system development, and if you’re encountering a problem that’s already been solved it’s the quickest way to access the solution. It just makes sense to get along with your suppliers, and it doesn’t take a lot of effort to maintain a constructive relationship with a software vendor and its user community. Conclusion Can you distill something as complex as enterprise software down to just Four Basic Rules? Any aspect of business that fails as consistently as enterprise software cries out for clarity and direction, and these rules serve well as guiding principles. It’s not acceptable for enterprise software to fail to deliver a financial return. To get one, companies have to ensure that business imperatives drive investment and execution decisions, and they need to consider it a long-term commitment. In the end software is nothing special; it’s management that counts.

Page 7: The Four Basic Rules of Enterprise Software

The Four Basic Rules of Enterprise Software 7

Copyright © 2006 M.G. Currie & Company. All rights reserved. The information contained in this document is proprietary to M.G. Currie & Company. No part of this document may be reproduced, stored in a retrieval system, translated, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without prior written permission from M.G. Currie & Company.