Implementation Guide › Planning and Design › Design › Contract Modeling (Contract Manager) › How the Modeling Process Works

How the Modeling Process Works

During the Modeling process all Metrics that need to be configured in the system must be defined together with their related entities, based on the Contract under consideration and the reporting requirements.

Before or during this stage it is good practice to decide upon a naming standard to use for the Metric names so that the system looks neat and tidy and is easy to navigate. Also consider the description of the Metric that can be used within the Objective Statement section of the Metric.

The contract analysis process includes the following steps:

1. Identifying the contractual objectives.

   For each objective, identify:

   • A suitable name (keep in mind any naming standards)
   • Target (optional)
   • Tracking period
   • Measurement Unit
   • Service Component
   • Service Domain
   • Domain Category (and measurement unit)
   • Timeslot (when: 24 x 7, business hours only?)
   • Calculation outline (what variables are needed and how is the service level calculated)

   Note: Some of those may not be clear from the first pass through, but can be sorted out later when refining the service catalog.

2. Identifying, from the Contract, any financial objectives and determining for each financial objective:
   • Is it a penalty, incentive, or cost objective?
   • What are the conditions that trigger it?
   • For which Service Component(s) does it occur?
   • Service Domain
   • Domain Category (the unit here may be a currency or cost amount or a percentage of payment, and so on)

Once all the objectives have been noted and defined, it is recommended to review the complete list of Metrics and try to optimize/normalize the catalog.

During this step it is important to make sure that each of the Service Components, Service Domains, and Domain Categories are defined sensibly and that they can form a clear and concise catalog of what is offered throughout the system. This includes ALL of the Metrics and Contracts in the system. This ensures building a very strong service catalog within the system to enable future growth of the system.

Service Domains and Domain Categories should NOT be defined down to a very low granular level. They should be descriptive but at a higher level than the metric.

For example, if you have the three following Metrics:

• % of outage reports delivered on time
• % of exception reports delivered on time
• % of management reports delivered on time

The best category all three Metrics would probably fall under is the service domain of Performance and the domain category of % Reports delivered on Time. The Domain Category should not mention the type of reports. These three Metrics would likely have the same calculation method and use the same business logic (with the exception of maybe a single parameter to distinguish between the different report types).

Suitable Service Domains and Domain Categories can be taken from the ITIL (Information Technology Infrastructure Library) standard. These are only suggested examples, however, and each particular organization may have their own defined standards for these. Refer to Appendix A - Sample Service Domains and Domain Categories for some suggested service domains and domain categories.

Note: It may be useful at this point to hold a meeting with all key stakeholders, in order to get the buy-in from each of them that the chosen catalog supports their current and future needs.

Further examples that demonstrate important points are presented in the appendices. In these examples, a single Contract objective is described along with its modeling. When modeling actual situations, it is necessary to be cognizant of all of the objectives so that the Catalog Entities represent all the objectives in a broader and all encompassing fashion.

Once the process of identifying all Metrics and their related entities is complete, the Contract Manager has a matrix that describes all of the Metrics as shown in the following diagram.

Additional issues to be considered in the Modeling process are described in the following sections.