Integration for integration's sake is not the best approach – instead, says Phil Nicholls, consider how much value can be gained from linking systems and functionality
The challenge of IT integration, reckons Phil Nicholls, is best posed by a single, deceptively simple question. In short: for a typical manufacturer with a typical ERP system, how much integration is too much integration?
"Integrating legacy and third party best-of-breed systems to an ERP system is rarely an enormous technical challenge," notes Nicholls, the managing director of Emerge IT, an experienced and fast-growing ERP software development and integration company. "The real question is a more strategic one: when does it make sense to integrate these systems with your ERP backbone – and when doesn't it? Too little integration is certainly sub-optimal, but too much integration can be overkill."
Coming from a business such as Emerge – which might be regarded as only too happy to help customers spend money achieving high levels of integration – such candour is refreshing. But Nicholls is emphatic. Particularly in the present straitened economic climate, he asserts, the wise business spends only what it needs on integration, and no more.
Yet if Nicholls' assertion that integration is an issue best viewed strategically, on a case-by-case basis, the arguments underpinning that view turn out to be both varied and multi-layered. It's not that integration itself is a bad thing, he explains, it's more that the full context isn't always properly thought through.
"Start with what you're trying to achieve," he urges. "Then ask if integration adds value. If it does – fine. But if it doesn't, then there's an opportunity to save money, and reduce risk."
A commonsense respect for sensitive information, for instance, dictates that some external systems – and the data residing on them – are probably best left largely decoupled from the network. Payroll systems, for instance, should managed by the finance department, with access closely guarded. Valuable intellectual property, too, should be kept apart from the mainstream.
"Do you really want your IT manager – and his or her staff – knowing the details of directors' salaries and bonuses?" asks Nicholls. "Finance functions have a good track record of keeping such information confidential, so why risk compromising it? Likewise, think about sensitive product development or product formulation data: just because it's possible to share it around the organisation, doesn't mean that it's always wise to do so, irrespective of password protection and access rights."
Similarly, says Nicholls, there is often functionality that it simply makes no sense to integrate with an ERP system, or for which to provide any more than 'one way', simple integration.
"Take route planning," he argues. "If a manufacturer has a fleet of vehicles – either delivery vehicles, or service vehicles making maintenance calls – then it makes sense to schedule their movements. But the scheduling doesn't have to be visible to the ERP system: all that's really required is the details of which deliveries or service calls need to be made."
Likewise, Nicholls is keen to stress that attempting to shoehorn too much functionality into an ERP system can create a beast which is simply too unwieldy for the needs of the business. And doubly so, when that business is relatively small, with an ethos of running lean.
"There are things that people do better than computers, or at least do just as well as computers," he points out. "Particularly when it comes to smaller businesses, the rigidity of process that systems impose can simply get in the way, and add cost and complexity. 'Best-in-class' processes are all very well, but 'best in class' doesn't mean that they come without cost, or administrative overhead."
Finite or infinite
And the example he chooses is intriguing. Emerge itself, points out Nicholls, offers Priority, an ERP system aimed squarely at the needs of manufacturing businesses. As such, Priority provides customers with two options when it comes to manufacturing: conventional 'infinite capacity' MRP I, and true finite capacity scheduling.
Equally, he adds, customers may choose to take advantage of the opportunity offered by a new ERP system to bolt on a third party finite capacity scheduling solution from one of the specialist vendors providing such capabilities. Indeed, he notes, mention finite capacity planning during a presentation, and manufacturing directors typically aren't slow to see its potential within the business.
"Our view is that delivering finite capacity scheduling is straightforward, whether it's a third party application or our own offering," says Nicholls. "But the question that's rarely asked is, 'do you really want it?'. Because once you've got finite capacity planning, you're automatically locking in a lot of associated expense and overhead."
Detailed shopfloor data capture is usually required, for instance, to update the scheduler as to which jobs have been completed, which are part-way complete, and which are awaiting commencement. Planners are usually required to manage and monitor the schedules. Schedules will make assumptions about raw material availability and set-up sequences that may prove difficult to adhere to in practice. And unless regularly updated, schedules themselves may fail to keep in touch with reality on the factory floor.
"If finite capacity scheduling is genuinely critical for the business, then it's an overhead worth carrying," argues Nicholls. "But surprisingly often, that isn't the case: commonsense rules, rough cut capacity planning, and basic MRP I will deliver a comparable performance, without the overhead. Put like that, a lot of our customers see the sense in staying lean, and not bringing into being a planning department that they don't currently have."
Mobile device integration, too, is another area where Nicholls counsels caution. As a vendor he stresses, Emerge will provide integration to suit customer requirements. That said, he warns, 'out of the box' integration to date has tended to revolve around Windows Mobile devices, especially where robustness is a requirement, and in hostile environments such as engineering service call support, and sales representative support.
"Consumer-centric devices generally don't have the required level of robustness, and you have to carefully think through the issue of wireless signal availability, as well – a customer's office is one thing, and a customer's factory floor another," notes Nicholls. "That said, consumer-centric smartphones and tablets from vendors such as Apple are gaining traction in sales situations."
In the end, sums up Nicholls, integration with third-party solutions – whether legacy or more modern ones, meeting an as yet unfulfilled requirement – is a question of judgment.
"50% of our customers have asked us for some sort of customisation," he notes. "Customisation in itself shouldn't be unwelcome: there's a saying in the ERP world that today's customisation is tomorrow's new module. But not every customisation is relevant for every business – and that's the point at which you ask, 'is it valid to provide this specific customisation through integration with the core system?'."
Indeed, Emerge IT's view of ERP, he adds, is of a three-layer hierarchy. First, a core system that meets the needs of all customers; secondly, additional optional models that are still part of the 'standard' system; and then, thirdly, customer-specific developments and integrations.
"That way, customers who don't want or need advanced features don't have to pay for them, and those who do want them can have them," he concludes. "At the end of the day, you have to ask, 'do you take the software to the business, or the business to the software?'. The answer is often somewhere in the middle, but that doesn't mean that you reach that point without careful thought."