- The ERP systems are difficult to tailor to support the organization's processes. Typically, the suppliers of ERP systems build the functions to a group of standards that are used by most industries or most organizations within an industry. If for whatever reason, a) the enterprise that is implementing the ERP does not have a process that uses those standards, then either the enterprise must change its process--unlikely--b) it must attempt to tailor the ERP system to match its process, or c) some combination of the two. Generally, none of the alternatives are particular effective or popular in large organizations with a diverse product mix. The result is that either the initiative fails completely or that the personnel of all of the business lines work much harder and longer (and possibly create "shadow systems") to overcome the limitations imposed by the ERP system.
- The Systems are difficult to update. Frequently, the software supplier implements the next version of a package the equivalent of installing, configuring, and tailoring the original system. The reason is that they have updated the technology, perhaps the functional architecture (design) sufficiently, that any bolt-ons, add-ins, or other tailoring will not work with the new version.
- The Systems are operationally inflexible. That is, they are not agile; able to respond successfully to unexpected challenges and opportunities. Because the tailoring required for an ERP system can be major, the costs and time involved becomes a significant item in the organization's budget. Consequently, the time to change becomes long and the cost of change becomes high. This leads to the problem that IT systems have become an impediment to change rather than an enabler, as studies by Gartner and Forester have shown.
There is an additional benefit to separating the process flows from the Service Components. When the organization's automated business rules change in response to changes in policies and standards (which in turn should be in response to changes in Governance), the System Architect can very quickly evaluate the change by modeling the process and Composite Application to understand the consequences of the change. In the best situation, the System Architect would model all affected applications before any proposed change in policies, standards, or business rules is put into place because this would enable both the Governance and Policy Management teams to understand the consequences and results of the proposed change before those changes become unmanageable negative externalities.
Obviously, this is a significant shift in the organizational culture.