Skip to main content

Business-Provider Maturity Model

In today’s business climate it is imperative that the IT Service Provider not only understand what the business strategy is, but be able to initiate and deliver services that not only support it, but help to shape it.  This can be successfully accomplished by ensuring that the service portfolio remain aligned to the business needs.  Over time these requirements and demand for services change and mature.  The Business / Provider Relationship is integral in keeping the demand and supply of these services and capabilities appropriately and continuously aligned.  One of the tools engaged for this task is the “Business-Provider Maturity Model”.

The Business-Provider Maturity Model is a way to help surface and understand the growth in maturity of business demand for Provider services and capabilities, and a Provider organization’s maturity of supply capabilities needed to both satisfy and shape that demand. Many maturity assessments are very IT centric assessing the ability of the Service Provider to satisfy demand from the business. The key difference here is that we also need to understand the businesses ability in being able to exploit the IT Service Providers capabilities to enhance the business strategy. It is a means of driving dialog about business demand and Provider maturity and how these elements continue to mature and grow. The model can be used for the entire enterprise or for a particular business unit or Provider capability.

In its simplest form, the model is an S-shaped learning curve—the business learning to exploit technology and the Provider organization learning to become efficient and effective in delivering services and, especially as maturity increases, shaping business demand.  Business executives find the model’s simplicity appealing. They can easily interpret the concepts behind business demand maturity and are able to use the model to analyze how their demand maturity is evolving over time. This enables them to engage in meaningful dialogue with Provider leadership about the business implications of both demand and supply maturity.  In most cases a basic three level model is utilized, however the number of levels is arbitrary. In some cases a 5-level model can be engaged, which can be useful because it represents a finer-grained approach.

To the left of the S-curve are the characteristics of business demand at each of 3 the levels. To the right are the corresponding goals of Provider supply.  It is important to understand this is a developmental model.  That means it is cumulative.  The demand at lower levels never goes away, the business always wants the lights kept on.  A Service Provider that fails to supply against this demand will lack credibility and the capability to move up the maturity curve.  As business demand matures to Level 2, Level 1 demand does not go away, it becomes a fundamental expectation.

Level 1 business demand is typically generated from functional and geographic silos which means it is often fragmented. This can be frustrating for the Service Provider, who are able to look across the enterprise and see many opportunities for cross functional processes and collaboration, but are often unable to communicate these concepts.

Level 1 demand is to provide basic services and solutions while ensuring stabilized operations and support, with an overarching goal of reducing the costs of doing business.

Level 2 demand, which continues to include Level 1 demand, focuses on enabling business partnerships, enterprise integration and consolidation of management information. Level 2 supply is focused on establishing common infrastructure and management information enterprise solutions. Level 2 supply also focuses on building credibility, improved service/ solution delivery, with attention to portfolio management, service management and getting faster at delivering solutions.


Level 3 demand, which now includes Level 1, 2 and 3 demand, addresses strategic and technology capabilities, which enable the convergence of business and IT capabilities which in turn enable business growth and innovation. It tends to be much more externally focused than Level 1 and 2, interested in business intelligence, rapid experimentation and collaboration with other business units, customers and suppliers.


Comments

Popular posts from this blog

What is the difference between Process Owner, Process Manager and Process Practitioner?

I was recently asked to clarify the roles of the Process Owner, Process Manager and Process Practitioner and wanted to share this with you.

Roles and Responsibilities:
Process Owner – this individual is “Accountable” for the process. They are the goto person and represent this process across the entire organization. They will ensure that the process is clearly defined, designed and documented. They will ensure that the process has a set of Policies for governance.Example: The process owner for Incident management will ensure that all of the activities to Identify, Record, Categorize, Investigate, … all the way to closing the incident are defined and documented with clearly defined roles, responsibilities, handoffs, and deliverables. An example of a policy in could be… “All Incidents must be logged”. Policies are rules that govern the process. Process Owner ensures that all Process activities, (what to do), Procedures (details on how to perform the activity) and the policies (r…

How Does ITIL Help in the Management of the SDLC?

I was recently asked how ITIL helps in the management of the SDLC (Software Development Lifecycle).  Simply put... SDLC is a Lifecycle approach to produce the software or the "product".  ITIL is a Lifecycle approach that focuses on the "service".
I’ll start by reviewing both SDLC and ITIL Lifecycles and then summarize:
SDLC  -  The intent of an SDLC process is to help produce a product that is cost-efficient, effective and of high quality. Once an application is created, the SDLC maps the proper deployment of the software into the live environment. The SDLC methodology usually contains the following stages: Analysis (requirements and design), construction, testing, release and maintenance.  The focus here is on the Software.  Most organizations will use an Agile or Waterfall approach to implement the software through the Software Development Lifecycle.
ITIL  -  is a best practice for IT service management (ITSM) that focuses on aligning IT services with the needs …

Incidents when a Defect is Involved

Question: We currently track defects in a separate system than our ticket management system. With that said, my question is does anyone have suggestions and/or best practices on how to handle incidents when a defect is involved? Should the incident be closed since the defect is being worked on in another defect tracking system if it is noted in the incident ticket? I am considering creating an incident statuses of 'closed-unresolved' so the incident can still be reported on in our ticket management system but know it is being worked on/tracked in the defect system. With defects, it is possible that we may never work on them because they are very low priority and the impact is low to the user. However, in some cases a defect is being worked on. Should we create a problem ticket instead?
Thanks, René W.

Answer: RenĂ©. In ITIL, the activity you are describing is handled by the Problem Management process. ITIL does not use the term “defect” but it does use the term “known error” to…