Doing it right: lessons from the coalface

Every enterprise system implementation (ERP or similar) is different. It has to be: every manufacturing organisation is different – and not just in terms of its industry, markets, scope and operations, but its size, investment history, culture (its people, departments and their style), business and working practices and its customers. It’s certainly not just about IT – although the success or failure of its former system implementations and the degree and nature of integration are also major influencing factors. But that accepted, there are nevertheless some common threads, common costly mistakes and poor and best practice, albeit somewhat context-sensitive. The following is a distillation of lessons learned from a range of manufacturers, as voiced by their IT and production managers and directors, who’ve been there, done it and got the battle-scarred tee shirt. We also provide supporting statistics from market researcher Benchmark, which recently completed a customer satisfaction survey across manufacturing industry users – and which helps to point the finger at what are still the most difficult areas. Bob Toseland, head of IT at Rolls-Royce Airlines business (which provides large fan engines and services from Derby, Bristol, Indianapolis and Berlin), has strong views about implementing ERP systems. He says that where many users fall down is in not determining the business strategy first and then sorting out what processes they need to support it – they simply rely on the existing business processes – yet it’s an absolutely critical first step in getting to a successful conclusion. “Only by doing significant change will you see a real return on investment. The alternative is simply to embed the waste, dig it in rather than weed it out,” he says. And with the strategy work done, “you can define you process requirements and then you’ve got a half reasonable chance of getting a requirements statement, which leads you to an RFQ for the vendors.” But while he is far from being a lone voice, others say it’s just not feasible to go this far. Bill Britton, IT executive for the customer division of Smiths Industries Aerospace, for example, says: “I think that’s quite a difficult thing to do. Yes, there’s a huge opportunity to improve business efficiency by revisiting all of it as part of business process re-engineering [but] unless there’s a directive from the top – that it will happen and that we’ll allow time – then it won’t work. Even if targets can be set and metrics put in place it’s very difficult: very often the users are still being asked to deliver yesterday’s outputs, which is an obvious contradiction.” So, a caveat. You should do it – but you will hit problems that have as much to do with management conviction as budgets. And time is another serious factor. Not only do you need to get the system in as fast as possible to minimise project costs and the time to return on investment, but as Neil Salf, group IT manager for advanced materials maker Porvair, says, if you take too long you risk losing commitment. He, for one, recommends designing, or staging projects to run over a maximum of six months, “otherwise everyone loses focus”. And Dave Leaming, production control manager at Dowty Aerospace, which did its Frontstep implementation in six months, agrees. He says that having such a short time frame facing you transforms attitudes. “At the time we were saying ‘it can’t be done’ [but] with hindsight the time focused our minds. We created training panels and set up sessions so that people learnt from each other … and we managed. I’d say ‘yes’ to six months if we had to do it again.” But while Toseland empathises with the six months idea, he fears its workability. “ERP implementations are by their nature big, and I’m not sure you can do this and still make it meaningful,” he says. His point: when you’re talking about very highly integrated systems going into what should be becoming more integrated manufacturing firms, you’re likely to end up limiting yourself. He cites putting in core SAP modules: “You’ve got to do it across the whole business; if you don’t you’ll have to somehow de-latch parts of it and then work around. It doesn’t make sense.” His advice: “Certainly you should bear in mind time minimisation, and absolutely use accelerated methodologies where you can but the project deliverables need to come first.” There is another factor though: change – it happens to companies, and the longer you take the more likely this is to be a problem. As Graham Leake, systems director with airline seats and structures manufacturer Britax Aerospace, says, the real world happens to you and “you can’t tell it to go away till you’ve put your ERP system in.” And that can create it’s own problems – at the very least delay and rework, at worst blame and accusations of failed systems. You can’t stop change Formerly manufacturing director at Britax, Leake was project director for the firm’s major Baan implementation which, after almost four years, is still going on. “In our case … since we signed the contract with Baan in 1997, the business changed from a £25 million turnover single company in Camberley to three separate companies on multiple sites with a combined turnover of £130/140 million!” It’s excellent for business but it doesn’t help your project timescales, costs, buy-in, or grey hair. Life is inevitably about compromises. So the lesson has to be that there is always a middle course, but be aware of the consequences of, on the one hand, passing up the opportunity new ERP brings in terms of improvement and, on the other, failure to get that implemented fast enough. Next is selection: and it’s another tricky one. Everyone I speak to laments the hit-and-miss nature of finding the right partner for what is generally one of the biggest systems undertakings most firms will ever take on. Porvair’s Salf makes a couple of useful initial points. He says that for groups with several different styles of manufacturing, a mix of site size and staffing (multi-role or departmentalised), different markets and few common suppliers or customers – as is the case for Porvair – imposition of systems at a corporate level cannot be justified. “It’s nothing more than dogma.” But he also observes: “For SMEs to evaluate all the systems available is a major task.” If any opportunity for a collective approach isn’t taken, serious effort will be duplicated and precious resource wasted. Salf’s answer to the problem he faced was to steer a strategic course, and get a group project going with representatives from finance, manufacturing and so on from all group companies. This resulted in a Porvair group statement of overall requirements and, after some massaging by the then Price Waterhouse consultancy, issuance of an RFQ to SAP, Baan, Fourth Shift (now part of ArmisSoft), QAD (then in the form of BDM Largotim) and Symix (now Frontstep). Now, Frontstep’s Syteline is Porvair’s preference: when a new system is required at any of its companies, if it’s not going to be Syteline the management simply needs to justify its decision. “The required approach is one of showing payback without jeopardising future extension,” he says. Back on the hit-and-miss, Rolls-Royce’s Toseland recommends the usual – look within your industry community, sister companies, the ERP-specific user groups, exhibitions and conferences and the web. You can go to the Online Shortlist search-and-select facilities on www.mcsolutions.co.uk. Beyond this, he says there are quantitative and qualitative assessments, “but I think also there’s a third consideration: how much clout they’ve got. “At Rolls-Royce we are big enough to influence SAP, but if you’re a 30 or 40 man outfit down the road you’d have no clout. And clout is very important – it’s your control over your roadmap.” And there’s a fourth point: “people and inter-personal relationships are very important.” All that said, however, he believes there’s no better way of progressing than talking through the RFQ with your shortlist “and assessing the level of interest”. Then it’s back to the scoring, weighted averages and the rest. Standard or custom The advice is universal. Smiths Industries’ Britton speaks for everyone: “Don’t bespoke. There’s always a tendency to think there’s something peculiar about the way you do things, but the only thing that’s peculiar is past practice. It’s only history that drives things a bit differently – and manufacturers generally believe that their way is the best way.” Generally, he says, you’ll find functionality in any of the modern ERP system to do everything at least as well, if not better. And if you do bespoke, stand by for costly times ahead when it comes to help desk support and service pack upgrades and the rest. As Ann Johnstone, IT manager at Centura Foods (formerly RHM Foods) and a Geac System 21 user, says, “We’re going through an upgrade now and it’s much easier because we’re on standard product. We’d learnt from our [earlier] BPCS experience: it was so heavily modified that upgrade was just not a possibility.” Kevin Hall, development manager with Herman Miller, the $2 billion turnover office furniture manufacturer, and another Frontstep user, endorses the view. “We changed many of the processes significantly to work the way Symix worked.” And the result was excellent improvements: in his case, massively reduced receiving times (from arrival of materials on site to availability on the system), improved visibility of work in progress and customer orders throughout manufacturing, and greater flexibility and speed of production. And Hall claims “much better control of stock turns and stock accuracy – and ownership of real time stock accuracy by the storemen.” Training and education When it comes to training and education the common cry, wherever you go, is “I wish we had done more … if only we hadn’t cut budget … we should have allowed more time.” Toseland is emphatic: “Training: the word does it an injustice. What you’re really talking about is change management, and collaborative change at that. It’s vital, especially with ERP because of the significant process change it involves. You have to get to everyone from the keyboard doers to the management, and change their behaviour, because if they stick with their old processes, then the doers won’t have the reinforcement to go with the system – then you get workarounds and system avoidance.” How do you ensure that doesn’t happen? “You have to start right at the beginning of the programme. Senior people have to publicly buy into it. If you don’t get that, then you’ve lost it right at that point. You won’t get the benefit.” Beyond that, Toseland recommends regular bulletins for everyone involved, with feedback mechanisms, getting more detailed as the project gets closer to delivery. That way, he says, you have a good chance of successful go-live, because everybody knows the impact of the system on everybody else. “For us everybody went through four waves of training, each different in terms of detail, and each with a core message according to the department, but based on a central package, driven by champions who understood the full meaning of the changes. The final phase was transactional on the job, and the trainer had to sign off for competency.” Porvair’s Salf had another way. He sent all key people on Frontstep’s training courses up front, then did a team conference pilot, on Frontstep’s database as an extension of the training course – with roles outside their own remit. Only then did the team consider its “blueprint of requirements” for the individual businesses on an iterative basis with the Frontstep consultants. And the benefit, he says was that everyone then understood the bigger picture and the possibilities. It’s an interesting approach, but as ever there’s a balance to be drawn. Smiths Industries’ Britton took full Oracle training up front. His view: “We spent too much up front and not enough at the back end.” The strategy was ‘train the trainer’, so ‘super users’ (the process or module owners) and the rest, but he says in the end there were too many people needing to know too much. “There should have been more formal training at the end. The lesson is that if you do it too early, either they don’t take it in because it’s too far away, or they forget.” And., of course, then the budget’s gone. Nevertheless, Britax’s Leake rightly emphasises the importance of training and process definition “by the process users themselves, who know the processes better than we can.” In one of his implementations he says this didn’t happen enough: “It meant we got 80% there, but after go-live we had to spend more time than we should on supporting users in handling some of the detail that hadn’t been passed on – so the project plan got extended.” Good point, and the same will happen if users aren’t built up to ‘own’ their processes properly – and the underlying data. Even after data cleaning there are bound to be errors and omissions (the 80—20 rule applies!): failure to ensure this is the users’ responsibility will lead to accusations of the ERP system not working and in the worst case, system avoidance. And if that happens, again you’ve lost it. Leake’s blunt solution: “It’s a difficult one to call, but almost, the people that are going to give you the most grief are the ones you want out of the process and on the project team.” Project creep Another classic difficulty is project creep. Toseland sums it up: “Scope creep is one of the biggest single contributors to cost and time overruns not least because of the chaos it causes. You have to go through and rework work you’ve already done, work to embed that in the programme and reopen deliverables you thought you’d finished. And that means the programme effectively stands still while time continues to pass and resources are consumed.” His advice: “It’s not easy, but you have to have a strong programme manager, strong change management procedures and a good change management culture in place to control it.” Bottom line advice So finally, here’s a few words of advice from our colleagues: if you take anything away with you, take these. Graham Leake says: “All businesses should go through a full risk/opportunity analysis before they embark on an ERP project. Take a long, hard, cold look at your company’s future. Remember, you need your best people to work on the project, but they’re the ones that the business will want back if the opportunities come in. You can’t have them twice.” Kevin Hall: “At changeover, plan for lower volumes because you’ll get them anyway.” And, “Check out the user groups; they’re a good source of information and feedback.” Bob Toseland: “First, if you’re going to undertake an enterprise like this, be absolutely certain your CEO is there with you. And second, manage the cultural change, work it hard: you can never pay it enough attention.” Ann Johnstone: “Understand the business processes before you go anywhere near the software. And don’t modify core software – the benefits don’t just come when you go through version changes, but when you need the help desk – they won’t have to dig through the all the mods before they can help you.” Dave Leaming: “Take great care with initial selection. Be rigorous about personal relationships – that’s what matters more than the rest. And focus.” Manufacturing users’ satisfaction with their packaged enterprise software is in general not good, certainly compared with their views of other purchases, like forklift trucks or whatever. And figures for users’ views of suppliers’ implementation and associated project management skills and training and support are also relatively unimpressive. Nevertheless, our loyalty to our ERP suppliers is greater than that to almost all others – although probably for no other reason than the sheer difficulty of change. These are top line findings of a recent survey by market researcher Benchmark Research. Looking at specific module types across a very wide spread of ERP vendors to an even wider spread of manufacturing industry revealed financials scoring best against expected benefits at 74% (98% is typical with our forklift trucks example). MRP/MPS/scheduling modules come in at 70%, along with warehousing, distribution and logistics, while workflow technology achieved just 68%. Scores against expected benefits for top end advanced planning and scheduling (APS) are 63%, CRM (customer relationship management) 64% and aspects of e-business connection around 66—68% – although Benchmark points out that with the low numbers involved in these latter, those figures could be shaky. Beyond these, the picture is no better when it comes to overall system performance – scores ranging from 59% to 73% for aspects like ease of use and ease of upgrade, to running costs, scaleability and ease of adaptation to changing business needs. Supplier performance figures on specifics like staff competence, quality of service/support, account management and speed of problem resolution are then 55% to 70%. Naturally there are two obvious ways of viewing these results. On the one hand, they’re not all that bad, and comparing against forklift trucks is hardly reasonable anyway in view of the sheer complexity of ERP systems and the ability of people, including the users themselves to screw up – for whatever reason. On the other hand, if you’re only likely to get 60—70% of the benefits you think you will, and those that have done all this say their suppliers and their products only perform at similar figures, you might need to reconsider a few things! Either way, the research sounds a serious note of caution – and is another reason for paying attention to the basics of big project specification, management and execution, and especially the people and culture issues.