Wednesday, February 06, 2008
IT's own system of record - ERP4IT
Related article: EnterpriseResource Planning for IT
ERP4IT is a term used to define a broad-scale integrated management system of IT automation system that enables IT to manage itself. There exist solutions that provide pivotal insights into financials and customers (with ERP and CRM packages) but there is none that delivers an integrated system of record, by which IT (and the CIO) can gain holistic insight into the value, cost and quality of IT services. IT’s own internal systems and processes are often so fragmented, inefficient, and redundant, that there is a strong need to build an ERP system for IT.
D -- data types and document types
All services delivered to the business by its IT department.
O -- Organizational transactions and processes
Following are some of the organizational processes that can be automated: Operation, support and maintenance (functional); supporting IT processes (eg. Asset and change management); element management (technical); enterprise architecture.
C -- Context (types of products and services, industry, geography, regulatory considerations).
Out of the major resource areas in an organization, only information (i.e., IT) lacks comprehensively integrated vendor solutions like ERP and CRM. ERP4IT aims to bridge this gap.
The problem is so complex that a common framework is required to seek data about the data and process to manage the processing.
U -- User types and special user requirements
The users include all IT personnel in an organization. Further, the CIO of a company stands to benefit strongly from this approach of having an ERP system for IT.
M -- Models, patterns, standards that apply or that are needed.
The Software Portfolio Management Facility, a draft specification by the Object Management Group (OMG) has with great relevance to the ERP for IT problem. However, these specs have taken a backseat in the OMG’s approval process, overshadowed by the current Unified Modeling Language (UML) revisions. Further, there are competing efforts by the Distributed Management Task Force, the Business Process Modeling Language [BPML] effort, and more academic work around ontologies. A standard for IT service management is U.K.’s Information Technology Infrastructure Library (ITIL).
E -- Enterprises and ecosystems (trading communities, standards bodies, other standards that help scope the case study).
Standards in this area are being chartered out by several bodies like the Object Management Group (OMG), the Distributed Management Task Force and
N -- The needs (business case) driving the enterprise(s).
IT needs a comprehensive system for IT management, governance and security within an organization. Despite its success building solutions for capabilities such as finance, supply chain, and human resources, IT’s own internal systems and processes often are fragmented, inefficient, and redundant.
Desire for more effective outsourcing in particular is driving the call for ERP4IT. However, no vendor currently offers a comprehensively integrated ERP suite for IT, and this provides an opening for standards-based approaches.
T -- Technology constraints and opportunities.
Managing IT is hard. This is because:
- the concept of information as a resource is relatively new- it is difficult to metamodel the IT problem domain.
- technical challenges such as establishing workable information models for the problem domain .
- IT budgets emphasize hardware and often aren’t directly tied to high-visibility, business-sponsored projects.
Another thing to be cautious about is to avoid making the mistakes that ERP has made in the past.
It would be also interesting to relate ERP4IT to "Enterprise Architecture", which is a comprehensive picture that captures from business to applications, information and technology assets altogether, so that it enables to align the business and IT goal. EA is also one of efforts to improve the ability of IT per se.
You did a good job applying the DOCUMENT checklist, except perhaps for the D, where you might have speculated about what kind of document type would be needed to describe IT services in a general enough way to enable service measurement and management. What's intriguing is whether this information would be added to the document types that carry out the business of IT or would be separate from it - i can imagine it going either way.
This is a domain that seeks data about the data and processes. Some of the services and data areas that are rendered to IT, for IT or by IT would include a convergence of the following:
~ Enterprise architecture - which would include high-level functional and process modeling, data management at the higher level, IT financials, platform strategy (e.g., technologies, vendors, standards), program management etc.
(Luke, you are right. EA for IT is of high significance. However, it is a subset of the problem domain that ERP4IT tries to address.)
~ Technical element management: including the specialized skills required for IT infrastructure areas like network, database and ETL administration.
~ Software and systems development: includes primary tasks that are the focus of IT like custom-built solutions; package solutions and tools used to deliver such software.
~ Supporting IT process: includes secondary processes like asset, change, configuration management which support IT in its main tasks.
~ IT audit/discovery: includes data profiling, application mining, program understanding/reverse engineering.
~ Operations, support, and maintenance: includes functionally oriented areas having existing software solutions in silos.
At a finer level of granularity, the metamodel for these could include the following: system, component, party(individual/team), process, event, interface, data element, data store, document, artifact/deliverable etc.
Yes Bob, it would be interesting to see where exactly these pieces are put in. Further, establishing a generic workable information model is one of the major challenges for this niche area. For example, to create an integration metadata, concerned about the end-to-end semantics of how business processes are supported between 2 heterogeneous systems would be much harder than say, creating a regular data-dictionary.