For better or worse, I think that often the software vendors completely oversell their product, and resist any effort by the customer to really understand whether the fit is a good one. At Intel we got really lucky, in that we had both a management that was insistent on doing 6 months worth of groundwork before making any committment, and a vendor (SAP in that case) that was willing to put up with us in order to make the sale. By the end of those six months, we knew to a very high level of detail what SAP could do for us and, more importantly, what it couldn't do, and had come up with a rough implementation plan that allowed us to go forward with those pieces of the business that were fairly "generic" while leaving unique and non-core systems alone in their existing state. I know SAP weren't happy to hear that we thought their application would only cover 50-60% of our financial applications activity (my area of focus), but the recognized that it was an accurate asessment, given the number of unique processes we had in house.
I have found the same to be true at many other successful companies. And in retrospect it's not surprising either. Sucessful companies are sucessful for a reason, and often the reason is that they do things differently. Doing things differently frequently means that "packaged" applications just don't fit well. Really smart companies recognize where the pacakges do and don't fit, and plan accordingly. Few software vendors are interested in hearing that their "perfect" solution is only perfect for 60-70% of customers, and that more difficult work is necessary for the others.
SAP were pretty shocked in 1996 when we told them that we couldn't possibly use their cost accounting/controlling solutions anywhere at Intel. But it was true. We were in that odd set of "outliers" who things so differently, and for such a good reason, that trying to find a common solution was completely a waste of time. We found a way to do things without using SAP's costing methodology. To the end, SAP were trying to sell us on the fact that we really should just do things "their way" without really understanding our business and why a more accurate cost-control mechanism was central to our being the most efficient and successful company in the field.
I know of the AMAT solution only from outside, from friends who have worked there on both SAP and Oracle. I trace the problem not so much to the fact that the software doesn't work, but to the fact that AMAT does many things differently from most companies, that to a large degree they don't quite understand how unique they are, and that the software vendors tend to gloss over the differences between how the software works and how the company works in an effort to get the sale.
I suspect that AMAT will never be fully happy with Oracle, and possibly not with any packaged software in many areas. 11i may turn out to be better, or may turn out to be worse, but regardless of what it is, it most likely will still not be a complete fit for their business. The decision to go with a packaged solution was largely a political one, not one that was based on a clear evaluation of the alternatives. It should be no great surprise that the software selected would not fully accomplish everything that was desired of it.
As I said before, I give Agilent a lot of credit for not even mentioning the name of the software vendor, though I know it to be Oracle. Most likely the problem resulted from a fairly radical changeover in both systems and operational procedures, not with problems inherent in the new software. Last I checked, Agilent was using relatively antiquated systems and procedures inherited from the HP days, which no longer made sense and were incredibly expensive to continue with. I believe they needed to change them, but also recognize that it would have been a major "shock to the system." I think it's pretty classy of them to take the blame, rather than blaming the software or the consulting partner.
mg |
