Since the hypothetical Solid American Brass (SAB) is a start-up, the people there don't have the communal memory characteristic of larger, older, organizations. Instead, the key players have to rely on personal experience with other companies; and while that works well for many issues, particularly those involving finance and manufacturing, it is generally inadequate in areas, like customer order expediting, contract sales, and warranty support, where the details are everything.
Most importantly, at least for our purpose in using this company as a kind of clothes horse to try out IT infrastructure ideas or assumptions on, senior management's collective industry experience does not translate meaningfully to the clerical level on the financial and resourcing side of the ERP/SCM process.
Notice in saying this that I'm defining the ERP/SCM process as covering everything needed to record, track, produce for, and ship a customer order - including the HR and fixed asset management components underlying that process. Thus senior managers may know that some customers will wait for the day a custom order is promised to ship to upgrade the order - but that doesn't mean the person who gets the call will have any idea how to deal with it at the detail level of accounting for 60 custom stainless steel bolts being replaced with teflon coated anodized nickel core bolts.
This missing corporate knowledge base has consequences for IT. Erik Engbrecht is going to talk about some of those next week in a guest column devoted to identifying opportunities to achieve a competitive advantage and implementing information systems to exploit them - but the important thing for today is simply that any organization's IT support requirements are defined in terms of its experience - and SAB doesn't have any.
That rules out custom development as an option and sets up two bad choices: an expensive but comprehensive package like Oracle or SAP versus a patchwork of licensed speciality applications like those from Microsoft's Navision and Great Plains acquisitions.
Of these two, I'd argue that the right strategy is to recognise that you don't get competitive advantage from the other guy's software and therefore to choose one of the remaining global ERP/SCM packages now, but quietly set the pieces in place to later replace it with a 100% custom package.
The main reason for this is that using one of the big commercial packages enables SAB to capture much of the business experience embedded in them. Basically, use of a comprehensive package first increases the likelihood that a function SAB needs will be there when SAB's people discover the need for it; and, second, guarantees that the absence of a function SAB's people think they needs prompts them re-consider the business process leading to that perceived requirement.
Thus both Oracle's and SAP's customer billing functions envisage many scenario's that will never arise at SAB; but include a few, like those allowing the call center operator to properly account for that last minute bolt change, that effectively import somebody else's applicable experience to build customer service capacity at SAB.
There are, in addition, two less important reasons:
Notice, however, that this is a very expensive strategy: we're talking the better part of a million dollar up front difference in the systems commitment when we compare going with this big package strategy against just implementing a handful of reasonably capable small systems solutions.
The question management is going to want answered, therefore, is to what extent this is worthwhile. How good, really, are the reasons cited when compared against a million bucks, some effort in getting a couple of smaller packaged solutions to work together, and the enforced use of a data warehouse for business intelligence and integration?