Just to set the record straight for my friend the IT Skeptic:
Not sure I agree with "ERP for IT" either. Paid too many dues back in the day as an ERP architect for Accenture, where I saw the good and the bad of it. Here are some quotes from my book:
Finally, the concept of “Enterprise Resource Planning for Information Technology” or more concisely “IT Resource Planning” (from AMR Research) is a recurring them throughout this book. Other emerging terms are Integrated IT Management (Forrester Research), IT Business Management (Gartner Research), IT Lifecycle Management (IBM) and Systematic Technology Management (DiamondCluster).
An ERP system is an automated solution supporting a major business process or functional area. Most of the concepts we have discussed in this section have some corresponding attempts at automation. Currently, such systems are badly fragmented. Just as Accounts Payable, General Ledger, and Accounts Receivable systems converged into financial ERP systems, these enablement systems for enterprise IT will eventually converge into a centralized capability that might be called “ERP for IT.”
This does not mean that all automated functions of each IT area will be centralized – rather, it means that their touchpoints of shared process and data must be formalized and managed to maximize alignment and minimize redundancy and non value-add work...
ERP is used evocatively and provocatively in this book. Reality check: the reputation of real-world ERP systems is not distinguished. There have been widely publicized failures of implementation and acceptance.
Secondarily, ERP systems have a poor technical reputation; earlier versions traced their lineage back to mainframe, flat-file-based systems with intricate, proprietary, and obscure architectures. Their monolithic architectures have proved inflexible and costly to upgrade. Such a platform would have serious challenges in supporting internal IT business processes, which depend on complex data structures requiring state of the art architectures, and are quite varied in their interactions.
However, it clearly has been an advance to have one system covering Accounts Payable, Accounts Receivable, Payroll, and General Ledger, where previously those systems might well have been separate and joined by inefficient interfaces...
While the “ERP for IT” concept invokes the idea of a single, massively integrated system on a common data repository, this idealistic vision will probably never encompass all the systems functionality described here. There are strong practical reasons to maintain loosely coupled systems; having the same architecture supporting source code control as well as IT financial planning does not make a lot of sense...
Obviously, the concept of an Enterprise Resource Planning (ERP) system provides some challenges of cohesiveness. ERP systems aggregate much diverse functionality, and might be seen as poorly cohesive. However, this functionality is always subdivided into modules, and the modules overall share common data structures, which makes a cohesive framework a logical solution.
Service Oriented Architecture (SOA) in some respects has emerged as a response to the limitations of ERP’s monolithic, shared data approach. However, there are sound technical and practical reasons for centralized data stores; SOA with its implied increase in data replication and heterogeneous system dependencies is inherently harder to achieve.
Trouble is, in many cases ERP is like democracy or capitalism: the worst solution, except for all the others.
