Ice-cream dream?

"Don't go down the bespoke route with core ERP software unless you absolutely have to," advises Mark Goodwin, group IT director at automotive thermoplastic extrusions manufacturer Coba International. "But equally, don't let the software drive your business," he adds. How can this IFS Applications ERP user offer such apparently contradictory advice? Quite simply, because those two statements are no longer at odds: ERP has evolved to the point where you can 'go vanilla' (stick with standard core software) yet still run the business your way without being constrained. Or, to continue the confectionery metaphor, you can now have your cake and eat it. Why does this matter? It's all about sustainability, time to value, flexibility, cost and support. Implementing an off-the-shelf ERP system means that, when the time comes to upgrade to the next version – for whatever reason (and there are many) – you'll be practically flicking a switch, not scratching your head and wondering how you're going to get all that bespoke code to migrate. Or where the money is going to come from. Just as important, well before that you should have found yourself ready for go-live much faster – with tried, tested and proven software – than if you had engaged consultants and/or your own IT team to do the programming for those 'special' processes. So, with vanilla ERP systems, sustainability and quick wins are straight away in the bag. And it's much the same with business flexibility: most of today's out-of-the-box ERP software is highly configurable to meet the needs of evolving businesses. It has to be, because ERP software vendors need to appeal to businesses in a broad cross-section of manufacturing types and industries that, guess what, must themselves respond to change. By their very nature these systems encapsulate hundreds of man-years of experience achieved on real projects with real manufacturers – and the mere fact of maturity means there's not much that hasn't been done before and generalised for others. Finally, cost and support are inextricably interlinked. Essentially, if you stick with Mr Whippy, you're on safe ground and you should find what you get is to your liking. If you don't, then you're in uncharted territory – and anyone who's been there will warn you of the potential for unpalatable consequences. Further, as an increasing number of pundits are now observing, it may be thrilling for those that get off on firefighting, but what's the point when so much about most businesses is, at heart, so similar? It may sound trite, but essentially we all buy stuff, make and/or assemble and then sell it. The trick is doing that more efficiently and better, faster, cheaper than the next man. So, with such persuasive arguments, why hasn't everyone long since gone the vanilla route? Well, there are three principal reasons. First, there's no denying that, until recently, most vendors' ERP frameworks weren't flexible enough, so there were always aspects that just couldn't be covered satisfactorily. Secondly, manufacturers couldn't quite bring themselves to believe that software vendors might know business processes better than them. And third, those two together have conspired to perpetuate a vicious circle of denial – not so much among IT managers but their counterparts in manufacturing and business operations – that ERP might be that good. The message, however, is that ERP has changed and, although the methodologies may be different, most modern software is impressively capable and configurable. Hence the comments from people such as Coba's Goodwin, but also plenty of others – such as Steve Ching, IT manager at electronics manufacturing services specialist Hansatech, and Malcolm Garbett, IT manager at encoders and digital readouts manufacturer Newall. As Ching puts it: "When I worked on IBM System/36, I would never have envisaged being self-sufficient, in terms of managing change. But this time around, by sticking with vanilla Epicor we haven't used a single day of consultancy in the last two years... How we configure the system is really down to the imagination of our people and I'm constantly amazed at what they're doing – both on the factory floor and in the business." And Garbett, who implemented Exel's Efacs ERP just last year, adds: "When our people talked about needing to change this or that, I made the point that when they got Microsoft Office nobody said we don't quite like the way Word works for Newall. Why is modern ERP any different? ERP technology has improved massively, so don't go bespoke: there's no need." So much for the testimony, but how did these manufacturers make staying vanilla work for them? Coba's Goodwin states that, although vanilla ERP was a strategic decision, the company also set out to configure the system "to work the way we work" unless processes within IFS Applications were better. "The beauty of IFS is that you can use its utilities to configure procedures that sit alongside the application. We use nothing more sophisticated than Microsoft Visual Basic and .Net to rebuild screens or add processes without touching the code," he explains. "For instance, certain product needs to go through quality control before being booked into stock. So we've created sub-processes and screens for the operators that prompt the checks, pull data from IFS and then allow passed items to be logged to an operator and booked in IFS." And it's much the same for goods picking from the warehouse, where Coba uses Motorola Symbol RF devices that call and return data to the IFS 'pick' process, yet run bespoke procedures and screens for the pickers. Goodwin makes the point that in the automotive industry this kind of flexibility is essential, particularly around logistics and production – and that, without modern ERP, would be very expensive to maintain. "Customers are very demanding: we have to adhere to their standards but also accommodate change – say, providing ASNs on goods despatch but also dropping extra information into their systems. In the past [and still today] a lot of manufacturers would be forced to pay their software vendors for modifications, which was a costly headache but also had implications for upgrades. My team just creates what's required in a Visual Studio environment, using standard utilities to call IFS which runs the processes. "We don't modify any code: we just create routines, tweak them when necessary and remove them when they're redundant," Goodwin continues. "You can think of it as IFS letting us do our own thing while still retaining the controls. But also, when it comes to upgrade time, we only have to look at our sub-processes. It's a two-second job to supply information and we're back in business." It's a similar story at Hansatech, the significant variance being the method of custom configuration. However, Ching explains that his organisation's near obsession with vanilla ERP stems from an expensive software rollercoaster that saw it migrate from green screen to IFS Applications in 2008, but with heavy modifications, and then on to Epicor ERP just 12 months later, following an MBO. "With IFS, we spent the usual three months looking at configuration and change requirements, and then another three months doing the implementation. Then, when it came to the MBO we reviewed the system and found we'd spent a lot of time building what we thought would be a flexible tool that precisely matched our needs – but that actually only did the original jobs well." Unfortunately, the world – as it does – had moved on and the new Hansatech needed a more flexible system. "We looked at transferring over what we had built," says Ching. "But, because we now wanted a vanilla system [for the cost and flexibility benefits], it would have cost more than buying Epicor from scratch – mostly because of the price of premium support. Taking vanilla Epicor and using their tools to customise the configuration meant the system would pay for itself within three years." Hansatech turned off the 'old' system and learnt from the experience. "It was a tough decision for the management team, not least because it meant we would have to cope with another system implementation. But we needed a multi-mode ERP system to handle the complexity of our fast moving build-to-order and build-to-stock mix – and something we could change and manage ourselves. So we went vanilla Epicor for all business basics, from raising purchase orders to running MRP. But then we used the system functionality to add a layer of personalisation – not customisation – that enables us to work differently for different customers, projects and people." Ching gives the example of some customers working from project numbers, while others want purchase orders. It's about configuring the ERP projects module to respond accordingly, in terms of procedures and screens – and being able to react to different requirements fast. "With standard Epicor, if a customer needs it, when we raise a purchase order above a threshold, the system emails the contracts manager. Then again, when we're setting up a new part, the system drives rules to make sure the data is correct. If goods need a quality check, because they're safety critical, Epicor forces them through QA. And you can do all that at the part number level or wherever, with post- and pre-process tractions and alerts." Additionally, Ching refers to user-definable tables, an Epicor method of enabling additional fields, such as parts records or inspection data, which can then be married up with the rest of the system. "For example, our test procedures generate data from the factory that ERP doesn't recognise. So we use the tables utility to integrate that information. We also use them to merge data types, so that users can work in terms of what matters to them – circuit references, part numbers or components. It's just mapping, so there's no additional maintenance cost and no risk when it comes to upgrades." Interestingly, however, our Hansatech man also says that staying with the vanilla system delivered excellence in terms of business operations – and to a level that he openly concedes was not at first obvious. "We made the decision not to replicate the existing business, because we wanted to build on the best practice processes and documentation of the new system. But, as a result, we also found that some of our earlier problems disappeared – and the workarounds with them – essentially because we were using the system properly." Ching cites materials demand visibility, making the obvious point that production managers need to know about component shortages ahead of job release, which Hansatech used to handle via a system of alerts. "Epicor tracks and controls materials directly from our suppliers. If we had specified the system to match the way we used to work, we would have spent money getting these alerts, only to find we didn't need them." But the last word goes to Newall's Garbett, who had the benefit, with hindsight, of preparing for his company's Exel Efacs ERP implementation twice – once abortively just before the economic turndown in 2008, and then again during the recovery of 2010. He explains that, with a new system requirement identified before the crash, he ran a SWOT analysis, partly to help with the choice of ERP vendor and partly to determine the implementation method. "For a company like ours, which has no spare resource, any implementation has to work right first time. We can't afford to get it wrong," he reasons. However, whereas in 2008 that study led Newall to the conclusion that phase one should faithfully replicate functionality from the old system, to minimise business risk, when it came to 2010, the decision was very different. "To reduce any possible disruption, we aimed to keep each area of the company running Efacs as vanilla as possible and to follow Exel's lead in achieving this," he recalls. And Garbett was ruthless with that decision, now claiming that less than 1% of the ERP implementation involved bespoke work (mostly financials related to US trading and some engineering change management, both since supported under maintenance by Exel). "We're now looking at moving up to the next release [MR28] – so we don't fall behind on upgrades and because the new CRM module looks useful. It's already on our test server, and the one thing I've checked is that small amount of bespoke code. In fact, it just needed one adjustment – copying a file from one folder to another. But that's the point: even if we had a large IT team, I would still stick with vanilla wherever possible. The system works well across everything we do – and we can continue to benefit as it develops, without the fear of costly and time consuming migration and test work."