If you visit OmPrompt in the UK you can stay in the nearby dreamy, historic, and beautiful town of Oxford. Photo by Tejvan Pettinger, CC license.

What if you want to make sure all of the data on a customer’s order is correct before it is processed in your systems?  Or if you want to stop orders that you can’t fill based on time constraints?  Many firms at first apply humans to these tasks (customer service), but what if you process 55,000 orders per year?  There must be some way to automate this screening process, right?

There are at least three ways to handle this problem with software.

The first is to modify your ERP system, to incorporate the rules you will apply to every order that is received.  Not only will the ERP system apply the rules and identify exceptions but alert you to those orders that must be stopped and changed before proceeding through the order cycle.

This is certainly a viable option, but you’ll find yourself pouring lots of money into it, with no end in sight, because as soon as you successfully incorporate a set of order checks, the business will come up with a new set of checks based on a new logistics or pricing strategy.  Most ERP systems are not built with user-configurable parameters; changes require programming by expensive resources.

The second is to build some type of middleware filter.  This is a custom application that every order would pass through before entering your ERP system.  The middleware would catch and hold up non-compliant orders.  A lot of firms adopt this route, because it is so much less expensive and much more flexible that tearing into the guts of an expensive ERP system.  And there is no shortage of eager programmers, within company IT departments, who want to build such a tool, in the language they know best on the computing platform they know best.

This second option is better than the first, but barely.  The second option makes you dependent on the genius that builds and maintains that middleware tool, and that is almost as bad as being dependent on an ABAP (SAP code) programmer.  And there will be instances where no matter how brilliant your middleware architect, certain business requirements will be beyond the capabilities of him/her and/or the software they have created.

The third option is to outsource your order capture, partially or entirely, to a firm that has the systems agile enough to handle the ever changing order filters your business may want to apply.  The advantage of these firms is that they serve as adapters: the incoming order is converted to a standard computer script where all of your rules can be applied; the script is then converted to the digital code (such as EDI) needed by your ERP system.

One firm that does this is UK-based OmPrompt, which specializes in automating business processes for large firms all around the world.  Their services are based on transaction volume and are very inexpensive relative to software modifications or building your own system.

I favor outsourcing the job not so much because someone else can do it better (although that is true) but because you cannot predict what is coming down the road in terms of new business requirements.  You need an open system, an infinitely-adjustable capability, if that is possible.  And firms that make their living on being adaptable to requirements like yours will always have more value to offer.