Packaged vs custom
To avoid reinventing the wheel, a common practice is to adopt packaged applications instead of developing custom, ad-hoc software. This makes sense in most cases, but in other cases, their drawbacks shall be seriously considered.
 |
The plug and play fallacyDo not expect packaged applications so much plug-and-play as they promise. They can be stable and largely adopted, but introducing them in your organization can imply in a considerable effort, whose order of magnitude leverages sometimes the development effort. Extending or integrating a packaged application can be even worse. An accepted rule of thumb says that whenever 20% or more of an application shall be changed the better alternative is to rewrite it all. |
 |
Data pollutionPackages applications shall serve different needs. Thus they carry information and features that are useless to your specific organization. That pollution makes usage difficult or ineffective. The extreme situation is storing specific information, not provided by the package, in some unused data field. |
 |
Strategic differentiationIf you and your competitors use the same package, it will be harder to apply differentiation. Business policies and strategies shall be supported by application software. Introducing dynamic rules to face global competition will be someway restricted to whatever the packaged application offers. |
When package is your best choice
Nevertheless there are many situations where packaged applications are an excellent choice. This is especially true if you have limited expertise in the field, so you will adopt both the software and the business process. It is also true if the packaged application is highly integrated (ERP, CRM) thus requiring little interfacing to other applications.
For all other cases FG&A can provide custom component-based solutions that will exactly fit your specific needs, with many advantages.