The 7 Dwarfs of ERP Implementation #3: Doc.

Modern ERP systems usually have some means of enhancing or tailoring the functionality delivered to the users. These are often via ‘client accessible’ tools, referred to as customization or configuration, rather than needing back-office supplier bespoke, although a mixture of these is often available.

Local customization or configuration offers great advantages in terms of delivering, and controlling the delivery, of functional enhancements. Often, the customer can undergo training in these tools, such that they can carry out this ‘doctoring’, contribute to, and provide ongoing support. For some ERP products, third party products and/or tailoring is possible.

Such doctoring provides a great advantage for the implementation, opening up functional tuning and new functionality provision through some flavor of technical or semi-technical resource. However, it’s fair to say, I’ve never seen a ‘techie’ that looks like Doc. So, where are the trip-wires ?

a) Over-exuberance.

Put together users who are like kids in a sweetshop, with an overly enthusiastic techie, and what do you get ? A bloated, poorly documented, badly controlled mass of local developments. There’s risk here in reliance on the local support, particularly if they move on. There’s cost implications, albeit local rather than external, but both immediate and long term. Inevitably, there are project timescales implications. There will be upgrade implications too – proving the local configurations mesh with enhanced or changed standard functionality.

Overly exuberant doctoring of the solution may take you away from the original scope or design criteria.

But don’t throw the baby out with the bath water either. If you have some great tools, and some real needs, provide for them. Just manage them properly. That’ll give the users the key functionality without creating a maintenance nightmare.

b) Technical Hurdles to delivery.

“We cannot progress as we are waiting for the changes we need to be authorized.”

“I cannot sign off my area as we are waiting for delivery of the final configuration.”

Practical statements and a call for more resources, or a means of passing on responsibility for slippage ? These may be genuine mission critical requirements, or an overly-embellished list of nice to haves that will put drag on your project. Worst case, the politics of avoiding ownership.

Naive check box ticking project management won’t help you with this, but an experienced project manager ( some would say already bruised by a similar experience ) will. They will be looking ahead to see what potential problems lie ahead, and taking measures to mitigate the risks or bypass them.

Technical Deliverables.

Remember that technical deliverables are a great enabler, but a poor project driver. They are not a panacea if you’ve chosen the wrong solution, a cure for poor project management, or a soothing balm for dissatisfied users.

Manage the local developments properly, and they’ll add real value to your system solution. Be pragmatic about which are go live critical, and which can be delivered in a later phase. Review the later phase items, hone the targets, and deliver these too.

Doc’s a great asset – but use his skills economically and wisely.