| Service Definition | What's Typical: Almost no Services are clearly defined. Requests and responses are handled without standard procedures. Different people in the enterprise use the terms "Service," "service request," and "incident" to mean different things.
What To Improve: Adopt a written, one-paragraph definition of "Service" that every person in the enterprise can reference. List the Services the enterprise currently delivers, even without formal documentation. State the differences between a Service, a service request, and an incident in writing.
What To Avoid: Key Takeaway: At Crawl tier, Service Definition requires a written statement of what a Service is. The enterprise cannot benefit from a system that enforces definitions until it has a definition to enforce. | What's Typical: Written definitions exist for most Services and are referenced when new Services are proposed. Each defined Service has a name, a brief description, and a named owner. The distinction between Services, requests, and incidents is applied consistently for most Services but not for all.
What To Improve: Adopt the IF4IT Single Service Definition Pattern as the standard for every Service. Introduce semantic identifiers so that a Service's identity remains stable when its name, owner, or Portfolio placement changes. Conduct a definition-quality audit against the enterprise schema and prioritize gaps.
What To Avoid: Do not attempt Run-tier attribute coverage on a subset of Services while other Services remain undefined. Do not tie the Service definition to the Ticketing System's data model — the two are separate concerns.
Key Takeaway: At Walk tier, adopting a standard definition pattern converts inconsistent Service records into a governable enterprise inventory. Complete coverage of all Services is more important than complete attributes on some Services. | What's Typical: Every Service has a complete definition following an enterprise-wide schema. Definitions are governed through defined review cycles, change management processes, and versioning. Semantic identifiers are used throughout the enterprise, so Service reclassification, ownership changes, and Portfolio moves do not disrupt downstream references.
What To Improve: Introduce cross-domain relationship attributes that connect Services to Applications, Capabilities, Vendors, Data Types, and Value Streams. Automate consistency checks between Service definitions and downstream artifacts so that inconsistencies are detected by the system, not by users. Introduce federated Service definition authorship — domain teams author their own Services and central governance validates conformance to the schema.
What To Avoid: Do not add attributes to the schema that no one populates or uses. Do not treat definitions as unchanging documents. A definition without a scheduled review will differ from operational reality within a short period of time.
Key Takeaway: At Run tier, Service definitions require ongoing governance. Without scheduled review cycles, definitions will differ from operational reality over time, even when they were accurate at the time of authoring. |
| Service Ownership | What's Typical: Because Services are not clearly defined, ownership of individual Services also does not exist. The Help Desk Manager is typically the person responsible for all Service delivery by default. Ownership questions arise only when a Service fails and no individual has clear responsibility for resolving the failure.
What To Improve: Assign a named Service Owner to every Service, even if the assignment is provisional. Publish ownership assignments so that any person in the enterprise can find out who owns any Service. Establish a defined process for transferring ownership when an owner leaves the role.
What To Avoid: Key Takeaway: At Crawl tier, no Services are individually owned because no Services are individually defined. The Help Desk Manager becomes the default owner of all Service delivery, which means no Service has an owner with specific accountability. | What's Typical: Every Service has a named Service Owner with documented responsibility for the Service's definition, quality, and lifecycle. Ownership assignments are reviewed on a defined schedule, typically once per year. The distinction between Service Owner and Service Manager is understood and applied throughout the enterprise.
What To Improve: Introduce Portfolio Owner accountability for each domain-level Service Portfolio. Define the competencies required for Service Owner roles. Establish Service Owner review boards that assess ownership currency, coverage, and effectiveness.
What To Avoid: Key Takeaway: At Walk tier, named Service Ownership replaces default assignment to the Help Desk Manager. The maturity change is from "who resolves the failure" to "who has decision authority over the Service." | What's Typical: Service Ownership is governed as an enterprise discipline with defined roles, required competencies, decision authority, and review cycles at every Portfolio level. Ownership roles include Service Owners, Portfolio Owners, and enterprise-scoped governance owners. Ownership currency (whether owners are still assigned, still in role, and still active) is measured and reported.
What To Improve: Introduce cross-domain ownership coordination for Services that span multiple domains. Integrate Service Ownership into enterprise talent management, including competency development, succession planning, and internal mobility. Automate ownership-currency reporting so that inactive or missing ownership is detected by the system.
What To Avoid: Do not delegate ownership to organizational levels that lack authority to make definition or lifecycle decisions about the Service. Do not allow ownership assignments to be determined by organizational politics rather than by required competencies.
Key Takeaway: At Run tier, Service Ownership must include the authority to make definition, lifecycle, and change decisions. An owner without decision authority cannot govern the Service. |
| Service Expectations | What's Typical: Expectations exist only at the ticket-response level: how quickly the Help Desk responds and how quickly tickets are closed, aggregated across all requests. Because Services are not clearly defined, there is nothing at the Service level for expectations to attach to. Service Owners do not exist, so no one is responsible for setting Service-level expectations.
What To Improve: Document response-time expectations in a single place, even if only at the Help Desk level. Publish Help Desk operating hours, contact channels, and typical response times. State explicitly that "no documented expectation" does not mean "any outcome is acceptable."
What To Avoid: Do not create Service Level Agreements (SLAs) that the enterprise cannot meet, even if industry benchmarks recommend them. Do not set expectations for which the enterprise has no measurement mechanism.
Key Takeaway: At Crawl tier, expectations exist only at the ticket-response level, not at the Service level. Service-level expectations cannot exist until Services are defined. | What's Typical: Some Services have their own indicators, objectives, and agreements set by their Service Owner. Other Services still fall back to the general ticket-response expectations of the Help Desk. Expectation-setting is uneven across the enterprise, determined by which Services have defined owners and complete definitions.
What To Improve: For every Service with a named owner, establish Service-level indicators, objectives, and agreements. Differentiate expectations by Service criticality or by consumer segment. Measure achievement against expectations on a defined schedule and publish the results.
What To Avoid: Key Takeaway: At Walk tier, expectation coverage is uneven across Services. Advancing means bringing every owned Service into a defined indicators-objectives-agreements framework. | What's Typical: Setting indicators, objectives, and agreements is required for every Service. Expectations are established as part of the Service definition. A Service without expectations is not considered fully defined. Different consumer segments (internal employees, external customers, partners) may have different agreements for the same Service.
What To Improve: Introduce predictive expectations that account for current fulfillment load and historical patterns. Differentiate agreements by consumer segment. Use expectation data as input to capacity planning before capacity limits are reached.
What To Avoid: Key Takeaway: At Run tier, a Service without defined expectations is considered incomplete. Setting indicators, objectives, and agreements is part of what makes a Service a governable artifact. |
| Service Portfolios | What's Typical: Because Services are not defined, no Service Portfolios exist. Leadership communication may reference the term "Portfolio," but no operational structure supports it. No individual has assigned accountability for the coverage, health, or strategic direction of any group of Services.
What To Improve: Introduce a two-level Portfolio grouping: an enterprise-level root and a small number of domain-scoped child Portfolios. Assign every Service in the Services Inventory to a domain Portfolio. Do not introduce sub-Portfolios or deeper hierarchy at this tier.
What To Avoid: Do not design a detailed Portfolio hierarchy before the flat Services Inventory is complete. Do not conflate Portfolios (which are governance groupings) with Service lifecycle states (which describe Service maturity over time). These are separate dimensions.
Key Takeaway: At Crawl tier, Portfolios cannot precede Services. Creating Portfolios without underlying defined Services produces empty containers that add governance overhead without governance value. | What's Typical: Domain-scoped Service Portfolios exist and are named (for example, HR Services, Finance Services, IT Services), and each has a named Portfolio Owner. A two-level grouping — an enterprise-level root plus domain Portfolios — is used for governance decisions. Sub-Portfolios may exist for domains that are large enough to require them, though these sub-Portfolios may not be formally documented.
What To Improve: Formalize sub-Portfolios in the Services Inventory schema so that every Service's placement is explicit at every level of the hierarchy. Introduce Portfolio-level attributes such as coverage completeness, ownership currency, and lifecycle-state distribution. Begin cross-Portfolio coordination for Services that span multiple domains.
What To Avoid: Do not create a Portfolio for Services that do not fit into other Portfolios. This produces a Portfolio without governance meaning. Do not allow a single Service to be assigned to multiple domain Portfolios at the same time.
Key Takeaway: At Walk tier, two levels of Portfolio hierarchy with named Portfolio Owners converts a flat list of Services into a governable structure. Deeper hierarchy is added only when the number of Services in a domain requires it. | What's Typical: The Service Portfolio hierarchy is a governed structure with defined depth, Portfolio Owner accountability at every node, and defined criteria for creating, splitting, merging, or retiring Portfolios. Every Service is placed at the appropriate level of granularity in the hierarchy. The enterprise Service Portfolio is used as an instrument of strategic planning and capital allocation.
What To Improve: Introduce Portfolio-level review cycles that assess Portfolio coverage, Service redundancy across Portfolios, and strategic alignment. Give Portfolio Owners defined authority to add, retire, or reassign Services within their Portfolios. Automate Portfolio-level reporting on coverage, ownership currency, lifecycle distribution, and cost.
What To Avoid: Do not allow Portfolio structure to reflect internal organizational politics rather than Service groupings. Do not add hierarchy depth beyond what governance requires. Flatter Portfolio structures are preferable when they are workable.
Key Takeaway: At Run tier, Portfolios are governance instruments, not classification schemes. Each Portfolio node includes budget authority, ownership accountability, and responsibility for Service rationalization. |
| Services Inventory | What's Typical: No formal Services Inventory exists. The list of Services the enterprise delivers is held in individual memory, or distributed across intranet pages, spreadsheets, and ticket-history queries. Coverage gaps and duplicated Services exist but are not visible until a request cannot be routed or two teams discover they are delivering the same Service.
What To Improve: Create a single shared inventory that lists every Service the enterprise delivers, even if the inventory entries are incomplete. Assign one person to maintain the inventory and reconcile it against actual ticket flow on a monthly schedule. Populate a minimum attribute set for each Service: semantic identifier, name, brief description, and named owner.
What To Avoid: Do not purchase enterprise ITSM tooling to solve the inventory problem before the enterprise has demonstrated the discipline to maintain the inventory manually. Do not populate detailed attribute coverage on a few Services while other Services remain unlisted.
Key Takeaway: At Crawl tier, inventory coverage is the priority, not inventory depth. A shared spreadsheet listing every Service produces more governance value than a detailed record of only a few Services. | What's Typical: The Services Inventory exists as a governed artifact with defined ownership and a defined update schedule. Every entry has minimum attributes: semantic identifier, name, description, owner, and lifecycle state. The inventory is used for governance decisions but is not fully integrated with downstream operational tools.
What To Improve: Adopt the IF4IT Services Inventory and Attributes schema. Populate the full Crawl attribute set for every Service before adding Walk-tier attributes to any subset of Services. Establish an inventory owner distinct from the individual Service Owners. Begin integrating the inventory with the Service Catalog and the Ticketing System so that operational Services reference the inventory record.
What To Avoid: Do not distribute inventory ownership across departments without a shared schema and shared governance. Do not conflate the Services Inventory with the Service Catalog. The two are separate artifacts with different purposes.
Key Takeaway: At Walk tier, the Services Inventory is the source of truth for Service identity in the enterprise. The maturity is the discipline of maintaining it, not the tool that stores it. | What's Typical: The Services Inventory is a governed enterprise artifact with schema versioning, data-quality metrics, integration with downstream operational tools, and cross-references to Applications, Capabilities, and Vendors. Every Service in the enterprise is registered in the inventory before it is published or made operationally available. The inventory is used as a source of truth by Enterprise Architecture, APM, TPM, compliance, and Service Management operations.
What To Improve: Automate reconciliation between the inventory and operational sources so that unregistered Services are detected by the system. Introduce cross-inventory relationship attributes so that the Services Inventory participates in the Enterprise Model graph. Make the inventory available as an API resource for downstream systems.
What To Avoid: Do not allow domain-owned inventories that duplicate the enterprise Services Inventory with different or conflicting data. Do not treat inventory coverage as a one-time achievement. Without ongoing maintenance, inventory data will differ from operational reality within a few years.
Key Takeaway: At Run tier, the Services Inventory is the connection point between Services and the rest of the Enterprise Model. Without the inventory, downstream governance constructs cannot reference Services consistently. |
| Service Catalog Architecture | What's Typical: Because Services are not clearly defined, there is limited use of a Service Catalog. Requesters submit requests by contacting a person through email, phone, chat, or in person, and the Help Desk processes the request directly. The number of requesters and providers is small enough that individuals know which Services are available without needing a Catalog.
What To Improve: Publish a written list of available Services on an intranet page that describes what each Service is and how to request it. Establish a process for updating the list whenever a Service changes. Do not invest in a formal Catalog application at this tier. The goal is discoverability, not sophistication.
What To Avoid: Do not purchase an enterprise Service Catalog product at this tier. The product will not resolve the discipline problem. Do not attempt to build a Catalog façade before publishing a discoverability list. The façade requires content that the list creates.
Key Takeaway: At Crawl tier, the Service Catalog is a written list, not a software system. Discoverability of available Services must precede investment in Catalog technology. | What's Typical: A single-façade Service Catalog exists, typically as one enterprise portal that publishes Services and provides request initiation channels. The Catalog is the primary intake point for service requests, though the Service Desk also supports direct channels. The Catalog and the Ticketing System are integrated so that Catalog requests generate tickets.
What To Improve: Publish every Service in the Services Inventory through the Catalog façade. Include Business Service Catalog and Technical Service Catalog views of the same underlying Service definitions. Introduce a defined taxonomy for Catalog navigation, structured to match the Service Portfolio hierarchy. Establish a formal Catalog Manager role responsible for Catalog content quality, taxonomy governance, and content refresh scheduling.
What To Avoid: Key Takeaway: At Walk tier, a single well-governed façade is the correct Catalog architecture. Deploying multiple façades before Run-tier governance exists produces uncoordinated duplication that the enterprise cannot manage. | What's Typical: A governed multi-façade Catalog architecture is in place, typically with domain-specific portals that each publish a domain Service Portfolio. All façades draw from the same enterprise Services Inventory, are supported by the same Service Desk, and integrate with the same Ticketing System. Façade autonomy exists in the presentation layer (visual design, language, branding) but not in the governance layer (Service registration, ownership, lifecycle, and routing are enterprise-governed).
What To Improve: Introduce cross-façade Service reuse when the same underlying Service is required by multiple audiences. Automate façade content freshness by pulling Service definitions from the Inventory rather than maintaining façade content separately. Extend Catalog architecture to include external-facing façades for partners, vendors, or external customers when appropriate.
What To Avoid: Do not allow domain façades to develop their own fulfillment infrastructure. Fulfillment infrastructure must be shared across façades. Do not allow façade owners to add Services that are not registered in the enterprise Services Inventory.
Key Takeaway: At Run tier, multi-façade Catalog architecture succeeds when façades share governance and share back-end fulfillment. Uncoordinated back-end duplication is the primary failure mode, not the existence of multiple façades. |
| Service Desk (a.k.a. Help Desk) | What's Typical: The Service Desk exists in the informal form of a Help Desk that receives all requests and has not been organized into a Service Desk that supports specifically defined Services with specifically assigned Service Providers. Typically one or two people handle all requests as part of a broader role. The Help Desk staff and the fulfillment workforce are the same people. The two functions have not been separated.
What To Improve: Assign the name "Service Desk" to the function, even if only one person staffs it. Establish basic ticket-handling procedures: every request generates a ticket, and every ticket reaches a defined closure state. Define at least one escalation path for issues that exceed the primary staff's authority to resolve.
What To Avoid: Do not equate the term "Service Desk" with a specific software product. The Service Desk is a function, not software. Do not treat the Service Desk role as a career step that leads nowhere.
Key Takeaway: At Crawl tier, the Service Desk staff and the fulfillment workforce are the same people. The maturity change is naming the Service Desk function distinctly from the individuals who staff it. | What's Typical: The Service Desk is a formally named function with defined staff, defined operating hours, and defined ticket-handling procedures. A Service Manager role exists with responsibility for operational performance and Service Level Agreement achievement. Ticket routing follows defined rules, and specialized Service Groups are beginning to handle tickets that the Service Desk routes to them.
What To Improve: Introduce tiered ticket handling (Level 1, Level 2, Level 3) with defined criteria for escalating between tiers. Publish Service Desk performance metrics regularly to leadership and to Service consumers. Establish a discipline of documenting resolutions for recurring ticket types in a shared knowledge base.
What To Avoid: Do not allow the Service Desk to become the required channel for Services that Service consumers could resolve through Catalog self-service. Do not measure Service Desk performance only by the number of tickets closed.
Key Takeaway: At Walk tier, the Service Desk becomes a governed function when its intake, routing, escalation, and knowledge processes follow defined procedures rather than individual practice. | What's Typical: The Service Desk is a professionally staffed function with defined career paths, formal certifications, and dedicated management. A single Service Desk supports multiple Catalog façades across all domains. Domain-specific expertise sits in specialist Service Groups that operate behind the Service Desk. The Service Desk performs intake, triage, and coordination. Specialist Service Groups perform fulfillment.
What To Improve: Introduce AI-augmented Service Desk operations for automated triage, resolution suggestions, and escalation prediction, with defined governance over AI recommendations. Integrate Service Desk operations with Enterprise Model data so that Service Providers see complete context on every ticket. Extend the Service Desk model to support external partners and vendors under the same operational discipline.
What To Avoid: Do not split the Service Desk into domain-specific desks with separate operational infrastructure. Do not allow AI augmentation to make decisions or take actions without governance review. AI recommendations must be traceable and validated.
Key Takeaway: At Run tier, the Service Desk performs intake and orchestration. Fulfillment work is performed by specialist Service Groups that operate behind the desk. The Service Desk's function is coordination, not resolution. |
| Service Providers / Service Groups | What's Typical: One group of people delivers all Services. Individuals have broad but shallow skill coverage. Few or no people are formally assigned to specific Services. Ticket routing is based on individual knowledge rather than group-level assignment. Requesters and dispatchers know that specific individuals handle specific types of work.
What To Improve: Name Service Groups explicitly, even if a Group consists of one or two people. Document each Group's Services delivered, staff, contact channels, and coverage hours. Route tickets to Service Groups rather than to individuals.
What To Avoid: Do not create Service Groups that consist of one person without a documented backup. A single-person Group without a backup is a single point of failure. Do not rely on individual knowledge as a substitute for documented Group procedures.
Key Takeaway: At Crawl tier, the Service Desk function and the Service Groups are the same people. Treating them as separate constructs at this tier misrepresents the enterprise's actual organization. | What's Typical: Service Groups are formally named, staffed with multiple Service Providers, and used as the primary routing target for tickets. Each Group has a named Service Manager responsible for operational performance. Cross-training exists within Groups so that Service delivery continues when individuals are absent.
What To Improve: Publish Service Group coverage hours, staffing levels, and current capacity. Introduce formal Group performance metrics: SLA achievement, first-contact resolution rate, staff utilization, and consumer satisfaction. Establish coordination procedures for Services that require handoffs between multiple Groups.
What To Avoid: Do not allow Groups to continue delivering Services that fall outside the Group's stated competencies because the Group has done so historically. Do not measure Groups only by the number of tickets they close.
Key Takeaway: At Walk tier, named Service Groups with named Service Managers replace individual-knowledge routing. The maturity change is from "who has the knowledge to handle this" to "which Group is accountable for this Service." | What's Typical: Service Groups are governed as enterprise-level organizational units with defined charters, required competencies, staffing models, and performance metrics. Coordination between Groups happens through defined governance structures: change advisory boards, incident management processes, and Service coordination councils. Service Provider career paths and Group knowledge management are governed as enterprise disciplines.
What To Improve: Introduce Group models that allow local autonomy while requiring shared enterprise operational discipline. Automate Group capacity forecasting and workload balancing so that leadership can address capacity gaps before they cause delivery failures. Integrate Service Provider skills information with Group charters and Service definitions.
What To Avoid: Do not allow Groups to develop their own separate governance, tooling, or metrics that are not aligned with enterprise standards. Do not allow Service Provider career progression to end at senior levels within a single Group.
Key Takeaway: At Run tier, Service Groups operate with local autonomy under shared enterprise governance. Two conditions reverse Run-tier maturity: Groups that develop independent governance, and Service Provider career paths that end within a single Group. |
| Service Request Management System (a.k.a. Ticketing System) | What's Typical: The system captures tickets with basic attributes: requester, timestamp, description, assigned person, and status. Ticket classification is limited, typically one "Type" field with generic values. The system supports basic status tracking (Open, In Progress, Closed) with limited or no enforcement of a defined workflow. Reporting is limited to counts of tickets by Type and by assigned person.
What To Improve: Introduce a defined set of ticket categories that match the enterprise's actual request patterns. Define minimum required fields on every ticket to improve the quality of downstream reporting. Establish and enforce consistent naming and values for Type, Category, and Status fields.
What To Avoid: Do not purchase enterprise ITSM tooling before basic ticket-handling procedures are established. Do not receive tickets through multiple systems (email, spreadsheet, chat, forms). Consolidating intake matters more than adding tool features.
Key Takeaway: At Crawl tier, the request management system is used for data capture, not workflow enforcement. The enterprise must establish consistent ticket capture before adopting more sophisticated tools. | What's Typical: The system supports defined workflows, categorization aligned to Services, status-based routing, and role-based assignment to Service Groups. Notifications reach requesters and Service Providers when ticket status changes. The system produces operational reports beyond ticket counts: SLA achievement rates, resolution time distributions, and backlog levels by Group.
What To Improve: Align the ticket data model to the Services Inventory so that tickets reference registered Services by semantic identifier. Introduce workflow automation for routine ticket categories to reduce manual routing work. Extend reporting to include SLA achievement, first-contact resolution rate, and consumer satisfaction.
What To Avoid: Key Takeaway: At Walk tier, aligning the ticket data model to the Services Inventory converts a work-tracking tool into a system that supports Service governance. | What's Typical: The system is a request-management platform with automated capture, processing, and update capabilities. Notifications reach Service stakeholders through multiple channels, with content adjusted for the recipient's role. Incident management is fully integrated. The same system handles requests, incidents, and the coordination between them. The system integrates with the Enterprise Model so that tickets automatically include context on affected Services, related Applications, and upstream dependencies.
What To Improve: Introduce AI-augmented ticket triage, categorization, and resolution suggestions under defined governance. Extend integration with the Enterprise Model so that tickets automatically include Service, Application, Capability, and Vendor context. Extend the system to support external consumer segments (partners, vendors, external customers) under the same governance procedures.
What To Avoid: Do not allow AI-augmented actions to execute without human review when they affect high-risk Services. Do not use system sophistication to compensate for missing discipline in Service Definition, Service Ownership, or Service Measurement.
Key Takeaway: At Run tier, the request management system connects Services, incidents, and the Enterprise Model in operations. Its value at this tier is the depth of its integration with other systems, not the number of features it provides. |
| Service Reusability | What's Typical: Reusability is not part of operational vocabulary. Fulfillment happens through individual choices. The same task may be performed differently by different Providers on different days. Providers do not systematically check whether a similar problem has been solved elsewhere before building a new solution.
What To Improve: Introduce the term "reusability" as an operational concept, even before Services are defined enough to be reused. Identify and document one or two obvious reuse candidates, such as shared runbooks or common intake templates. Establish the practice of asking "have we solved this before?" before building a new solution.
What To Avoid: Do not attempt to formalize reusability discipline before Services are defined. Reusability requires Services that can be reused. Do not purchase a "reuse platform" at this tier. Reusability at Crawl is a practice, not a tool.
Key Takeaway: At Crawl tier, reusability discovery precedes automation. Before the enterprise can automate what is done repeatedly, it must first notice what is done repeatedly. | What's Typical: Some Services are recognized as reusable in principle, but actual reuse depends on individuals remembering that reusable Services exist. Duplicated fulfillment work across domains is common but is not measured. The compositional model (Services that invoke other Services) is not formalized. Cross-Service invocation happens through manual coordination.
What To Improve: Change from reuse that depends on individual memory to reuse designed into new Services. Build new fulfillment logic with reuse as an explicit design requirement. Establish a shared library of reusable Service components: approval workflows, provisioning steps, notification templates. Measure duplication cost so that the enterprise can identify what reuse would save.
What To Avoid: Do not force reuse when domain-specific requirements genuinely require separate implementations. Forced reuse of an inappropriate Service produces worse outcomes than deliberate duplication. Do not penalize teams for building new solutions when the reusable alternative is undocumented or difficult to find.
Key Takeaway: At Walk tier, reuse depends on individual memory rather than design intent. The maturity change is making reuse a design requirement for new Services rather than a discovery about existing ones. | What's Typical: Reusability is a documented design principle applied to every new Service. Services are built with defined interfaces (input parameters, published behavior, and defined Service Level Agreements) so they can be invoked as components of other Services. Workflow Orchestration platforms connect reusable Services into larger Services, both within a single domain and across multiple domains. Reuse metrics — Services reused across domains, cost avoided through reuse — are tracked and reported.
What To Improve: Formalize Service composition. Build new Services as workflows that invoke other Services through defined interfaces. Introduce cross-domain reuse governance so that domain teams do not independently build Services that already exist elsewhere. Publish reuse metrics as one of the standard measurements of Service Management performance.
What To Avoid: Do not measure reuse as a target for its own sake. Reuse that no one adopts does not produce value regardless of its design. Do not require reuse governance approval for routine decisions when the review overhead exceeds the cost of duplicating the Service.
Key Takeaway: At Run tier, reusability is pursued as a strategic goal to reduce redundancy, reduce waste, and increase quality of delivery through consistency. No other trait produces these three outcomes together. |
| Service Automation | What's Typical: Automation is minimal or does not exist. Any automation that exists is individual scripts written by practitioners for their own convenience. Scripts are not shared, governed, or documented. The enterprise cannot answer the question "what is automated in our Service Management practice?" from available records.
What To Improve: Identify the three to five Services with the highest ticket volume and the most repetitive fulfillment steps as automation candidates. Build simple automation for those Services using scripts or workflow tools. The goal is to reduce manual work, not to achieve autonomous fulfillment. Document any automation that runs in production: what it does, who owns it, and how to disable it.
What To Avoid: Do not purchase an enterprise automation platform at this tier. The platform requires operational discipline that the enterprise does not yet have. Do not allow automation to be built and deployed without governance. Automation without governance fails without producing visible error signals, and it operates at higher speed than manual work, so failures affect more users before they are noticed.
Key Takeaway: At Crawl tier, automation exists only as individual scripts that solve individual problems. The maturity change is treating automation as an enterprise concern rather than a personal one. | What's Typical: Automation exists for a defined set of Services, typically high-volume and low-complexity Services, with documented ownership and operational governance. A lightweight automation platform is in use, with a specific owner. Automation reduces manual work measurably but is implemented per-team rather than on shared enterprise infrastructure.
What To Improve: Consolidate per-team automation onto shared enterprise infrastructure so that fulfillment logic built once can be reused across multiple Services and domains. Establish a formal automation governance policy that defines what may be automated, what requires human review, and how automation is monitored. Extend automation to include approvals and provisioning workflows, not only fulfillment steps.
What To Avoid: Do not allow automation ownership to be spread across multiple platforms with overlapping capabilities. Do not automate Services whose underlying definitions and processes are not stable. Automating an unstable process reproduces the instability at higher speed.
Key Takeaway: At Walk tier, automation produces greater return when it runs on shared enterprise infrastructure rather than on per-team infrastructure. Reusability and automation reinforce each other when both operate at the enterprise level. | What's Typical: Automation is an enterprise-level capability with shared platforms, governed authoring, defined operational monitoring, and integration with the Enterprise Model. Fulfillment automation is decoupled from Catalog façades so that the same automation logic serves multiple façades without duplication. Automation covers fulfillment, approvals, notifications, monitoring integration, incident detection, and self-service resolution.
What To Improve: Introduce AI-augmented automation for triage, resolution suggestions, and escalation prediction. Define governance boundaries for what AI may recommend and what AI may execute autonomously. Integrate automation actions with the Enterprise Model so that every automation action is traceable to the affected Services, Applications, and processes. Extend automation governance to include the full lifecycle: authoring, testing, deployment, monitoring, deprecation, and retirement.
What To Avoid: Do not allow AI-augmented automation to execute autonomously against high-risk Services without human review of the action. Do not measure automation success only by the percentage of tickets automated. Coverage without quality does not produce value.
Key Takeaway: At Run tier, automation produces the return that reusability makes possible. AI augmentation increases automation's reach but requires governance to prevent failures that do not produce visible error signals. |
| Service Measurements & Reporting | What's Typical: Formal measurement and reporting are minimal or absent. Where measurement exists, it operates at the Ticket Type level (password reset, VPN issue, printer problem) rather than at the Service level, because defined Services do not exist to aggregate against. Help Desk managers may analyze Ticket Type patterns informally, even without a defined reporting schedule.
What To Improve: Formalize Ticket Type tracking and reporting. Convert informal pattern analysis into a monthly review document. Use Ticket Type analysis as input to Service Definition. Recurring high-volume Ticket Types are candidates to be defined as distinct Services with dedicated staffing. Focus measurement on outcomes that the enterprise can act on.
What To Avoid: Do not purchase dashboarding tools before defining what to measure. Do not implement Service-level metrics or SLA achievement reporting before Services are defined. Measurement built on missing Service definitions produces misleading numbers.
Key Takeaway: At Crawl tier, Ticket Type analysis identifies which Services should be defined. Measurement is not downstream of Service Definition at this tier — measurement provides the input that Service Definition requires. | What's Typical: Regular operational reports are produced weekly or monthly. SLA achievement is measured; consumer satisfaction is measured through sampling. Reports reach Service Desk leadership but do not reach executives or Service Owners directly.
What To Improve: Introduce leading indicators that predict outcomes, in addition to lagging indicators that describe past outcomes. Distribute reports to stakeholders beyond the Service Desk, including Service Owners and executives. Connect measurement outputs to a documented Service improvement backlog, so that measurement leads to action.
What To Avoid: Do not report metrics that indicate activity without indicating outcomes (for example, raw ticket volume growth without context). Do not produce reports that are not consumed by their intended audience.
Key Takeaway: At Walk tier, measurement without reporting produces unused data, and reporting without action produces documentation that does not affect Service delivery. Both cycles must connect to produce value. | What's Typical: Measurement covers operational, financial, satisfaction, and business-outcome dimensions. Reports are produced for multiple audiences: Service Desk leadership, Service Owners, executives, and Service consumers. Measurement and reporting are integrated into governance cycles rather than produced as standalone artifacts.
What To Improve: Introduce predictive analytics that use operational measurement data as input. Integrate Service Management reporting with Enterprise Model reporting. Automate report distribution and track report consumption so that leadership knows which reports are being used.
What To Avoid: Do not measure so many outcomes that measurement itself consumes more resources than the improvements it enables. Do not treat quantitative measurements as sufficient without qualitative validation from Service consumers and Service Providers.
Key Takeaway: At Run tier, measurement produces value when reports lead to decisions. Reports that no one reads and dashboards that no one monitors indicate that measurement has become a procedural activity without governance impact. |
| Service Culture | What's Typical: The enterprise is largely unaware of the twelve structural traits of Service Management as distinct disciplines. Service delivery is treated as reactive work that responds to problems as they occur, not as a discipline that prevents them. Service Management is not recognized as a body of practice worth investing in. The Help Desk is the destination for problems that other teams cannot or will not handle.
What To Improve: Introduce the vocabulary of Service Management as a discipline that includes distinct traits. Recognize successful Service delivery visibly at the enterprise level so that Service Management is understood to be work that matters. Establish that Service Management is an enterprise concern, not administrative work performed by IT.
What To Avoid: Do not declare that the enterprise has a Service culture through communications activities without corresponding changes to how Service delivery is treated. Do not use the Help Desk as the destination for problems that other teams have failed to resolve.
Key Takeaway: At Crawl tier, the enterprise does not recognize Service Management as a discipline. Service Culture determines whether the enterprise begins to engage with the twelve structural traits or continues to react only when Service delivery fails. | What's Typical: The enterprise recognizes the twelve structural traits of Service Management as distinct disciplines. Service delivery is treated as a professional discipline with defined roles and career paths. The enterprise addresses trait maturity when problems surface, but does not continuously monitor or manage the traits. Leadership references Service Management in operational strategy discussions.
What To Improve: Include Service Management competencies in performance reviews for roles that participate in Service delivery. Have leadership consume Service Management reports on a defined schedule and reference the reports in operational decisions. Recognize successful cross-functional Service coordination when it occurs. Introduce reassessment of trait maturity on a defined schedule, not only when problems occur.
What To Avoid: Key Takeaway: At Walk tier, the enterprise recognizes Service Management as a discipline but engages with it responsively. The maturity change is moving from responsive engagement to scheduled, continuous engagement with the twelve structural traits. | What's Typical: The enterprise keeps all thirteen traits of Service Management continuously in focus. Service delivery is treated as an enterprise discipline that is actively managed and improved, not one that is corrected when it fails. Executive sponsorship for Service Management is visible. Service Providers have defined career paths. Cross-domain Service coordination is a normal expectation rather than an exception. The enterprise reassesses trait maturity on a defined schedule and invests in advancement even when the current tier is delivering acceptable results.
What To Improve: Introduce cross-organizational rotation programs to distribute Service orientation across the enterprise. Include Service Management outcomes in executive-level performance measurement. Support Service Management publications and external presentations by enterprise staff so that the discipline is treated as a source of enterprise expertise. Extend continuous improvement to the maturity assessment process itself, so that reassessment methods advance as the enterprise's practice advances.
What To Avoid: Do not allow Run-tier maturity to become an operational routine that no longer receives leadership attention. Do not conflate process maturity with cultural maturity. The two can advance independently, and each requires its own investment. Do not treat completing the maturity progression as an endpoint. Culture is what sustains the discipline of continuous improvement across all traits.
Key Takeaway: At Run tier, Service Culture keeps the enterprise engaged with all thirteen traits as living disciplines that are actively managed and improved. This engagement is what sustains structural maturity over time; without it, structural investments reduce to procedural activity that produces no governance value. |