Many companies struggle with implementing large software packages, from SAP to Oracle to Salesforce.com. Conventional wisdom advocates insuring that your business requirements are well-documented, and the any effort is tied to a business case with a well-vetted ROI prediction. Further, the package implementation should be regarded as part of a larger organizational change effort (not just implementing some technology), but there is one wrinkle many organizations miss with package software.
With these types of systems, you’re not buying software so much as you’re buying “canned” business processes. Many organizations get caught up in flashy screens or meeting a laundry list of features, and end up buying a package whose canned processes have little or no relation to their business. This scenario turns the project from a quick implementation to what essentially amounts to a custom development effort.
To get the maximum benefit from packaged software (lower cost of implementation and support) make sure your business dovetails nicely with the package’s canned processes, or seek to adopt as many of them as possible or you’ll end up buying a new development environment rather than a business software package.
Thank you for so eloquently summarizing what I have tried to explain on more occasions than I care to remember.
Glad to help! I guess if his wasn’t such a prevalent problem the big ERP implementation companies would have a lot more time on their hands!