gb935_concepts_&_principles-v7.1.2.docx

8/10/2019 GB935_Concepts_&_Principles-V7.1.2.docx

1/43

TM Forum 2013. All Rights Reserved.

Frameworx Best Practice

Business Metrics Scorecard BMS)

Concepts & Principles

Business Metrics Solution Suite 2.1

GB935

October 2013

Latest Update: Frameworx Release 13.5 Member EvaluationVersion 7.1.2 IPR Mode: RAND


2/43

BMSConcepts & PrinciplesBusiness Metrics Solution Suite 2.1

TM Forum 2013. All Rights Reserved. Page 2 of 43

Notice

Copyright TM Forum 2013. All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative

works that comment on or otherwise explain it or assist in its implementation may be prepared,copied, published, and distributed, in whole or in part, without restriction of any kind, providedthat the above copyright notice and this section are included on all such copies and derivativeworks. However, this document itself may not be modified in any way, including by removing thecopyright notice or references to TM FORUM, except as needed for the purpose of developingany document or deliverable produced by a TM FORUM Collaboration Project Team (in whichcase the rules applicable to copyrights, as set forth in theTM FORUM IPR Policy,must befollowed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by TM FORUM orits successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and TMFORUM DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOTLIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOTINFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OFMERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Direct inquiries to the TM Forum office:

240 Headquarters Plaza,East Tower10thFloor,Morristown, NJ 07960 USATel No. +1 973 944 5100

Fax No. +1 973 944 5110TM Forum Web Page:www.tmforum.org
http://www.tmforum.org/IPRPolicy/11525/home.htmlhttp://www.tmforum.org/IPRPolicy/11525/home.htmlhttp://www.tmforum.org/IPRPolicy/11525/home.htmlhttp://www.tmforum.org/http://www.tmforum.org/http://www.tmforum.org/http://www.tmforum.org/http://www.tmforum.org/IPRPolicy/11525/home.html


3/43



Table of Contents

Notice .................................................................................................................................................... 2

Table of Contents ................................................................................................................................. 3

List of Figures....................................................................................................................................... 4

Executive Summary ............................................................................................................................. 5

1. Introduction ...................................................................................................................................... 61.1. Document Overview ........................................................................................................... 61.2. Industry Benefit ................................................................................................................... 6

2. Business Metric Taxonomy ............................................................................................................ 82.1. Metric Terminology ............................................................................................................. 82.2. Metric Naming................................................................................................................... 102.3. Metric Categories .............................................................................................................. 13

2.3.1. Domain ................................................................................................................... 13

2.3.2. Process Focus ....................................................................................................... 142.3.3. Topic ....................................................................................................................... 14

2.4. Metric Codes..................................................................................................................... 162.5. Metrics and "Meta Processes" .......................................................................................... 18

2.6. Metric Model ..................................................................................................................... 21

2.7. Supporting Taxonomies ................................................................................................... 242.7.1. Business Object Taxonomy ................................................................................... 242.7.2. Business Value Driver Taxonomy .......................................................................... 26

2.8. Metric Counting Rules ...................................................................................................... 28

2.8.1. Service Outages ..................................................................................................... 28

2.8.2. Problem Reports .................................................................................................... 29

2.8.3. Order Acceptance .................................................................................................. 31

3. The Business Metrics Scorecard (BMS) ...................................................................................... 333.1. The Customer Experience Life Cycle ............................................................................... 33

3.2. Structure of the Business Metrics Scorecard ................................................................... 363.3. Navigating the Business Metrics Scorecard ..................................................................... 38

Appendix A: Terms and Abbreviations Used within this Document ........................................... 40

Appendix B: Administrative Information ......................................................................................... 42B.1. Version History ................................................................................................................. 42

B.2. Release History ................................................................................................................ 43B.3. Document Family and Related Documents ..................................................................... 43


4/43



List of Figures

Figure 1 - The Balanced Scorecard 13

Figure 2 - Process Foci 14

Figure 3 - Example of how coding is used for the business metrics 17

Figure 4 - Fulfillment Meta Process 19

Figure 5 - Assurance Meta Process 19

Figure 6 - Billing Meta Process 20

Figure 7 - Customer Management Meta Process 20

Figure 8 - Customer Experience Lifecycle 33

Figure 9 - Business Metrics Scorecard 36

Figure 10 - F-CE-2a Example 38

Figure 11 - B-OE-2c and B-OE-2d Example 39


5/43



Executive Summary

Service providers are striving to achieve business excellence and are increasingly looking to theTM Forum for guidance and understanding: What does business excellence mean? How faraway from business excellence are we? What initiatives should we develop in order to obtain

the benefits of achieving business excellence?

For these purposes the industry requires quantitative as well as qualitative information tosupport its evolution in the increasingly complex market that is developing. Service providersneed measures that will focus attention on aspects of their operation and areas of their businesswhere improvement will bring the most benefit. They also need a way to compare themselveswith their peers and to promote areas in which they are able to offer uniquely superiorperformance.

The TM Forum is addressing this situation with the Business Metrics Scorecard. The objectiveof this team is to create a set of business metrics aimed specifically at business performance atthe service level. These are living metrics developed and maintained by a project team and willevolve over time to continually reflect the interests of the service provider community. This is a

real example of work done for the industry by the industry.Further information on the measures and the benchmarking data associated with them isprovided in other output from this team and TM Forum (see www.tmforum.org or [email protected] more information).
mailto:[email protected]:[email protected]:[email protected]


6/43



1. Introduction

1.1. Document Overview

The GB935 document family describes the TM Forum output related to business metrics. Thedocument family consists of several documents, including a Concepts & Principles document,an addendum A that lists out the business metric specifications, and an addendum thatdescribes the process for contributing new business metrics.

This Concepts & Principles document provides an overview of the business metrics that havebeen developed in collaboration with service providers via the Business Metrics Scorecardteam. This includes definitions of key terms, taxonomy, naming conventions, and how themetrics are structurally composed into a business metrics scorecard.

The Business Metric Specifications Addendum A lists the definitions of the 100+ businessmetrics that are currently active with the BMS team. This includes key attributes like naming,codes, categories, formula, description, units, etc. The Business Metrics Development Guide

Addendum B describes how contributors can submit new metric proposals to the BMS team,and includes the process to follow and the definition detail they should fill out in a provided form.

Additional information concerning each metric and its corresponding benchmarking data isavailable by contacting the business benchmarking team ([email protected]), and/orsubscribing to its reports and services.

1.2. Industry Benefit

The Business Metrics Scorecard group is responsible for the TM Forum Business Metrics usedby digital service providers and suppliers as standard industry business performance metrics.

This includes identification of new metrics requirements, as triggered by the proliferation of newand innovative services and extension of the Balanced Scorecard as needed.

To assist in this goal, the BMS team is motivated by the following key functions:

Standardize the vocabulary and modeling of business metrics

Standardize the definition of specific business metrics, that appear on the BusinessMetrics Scorecard

Build holistic linkages between BMS metrics and other TM Forum standards.

Additionally, the BMS metrics are used as the basis for the TM Forums BusinessBenchmarking Studies, Metrics Conformance testing, and various Benchmarking Services,which leads to additional benefits that include:

Access to relevant benchmarking data, that are:

o Service offering focused

o Assessed against relevant peers
mailto:[email protected]:[email protected]:[email protected]:[email protected]


7/43



Ability to develop investment business cases based on achievable targets to supportimprovement initiatives

Awareness of areas of strength

Means to analyze the inter-relationship between metrics

Access to industry trends.

The benefits will be attained on the basis of analyzed and raw benchmarking data that will beavailable in two forms:

Benchmarking Study Summary Reports

A secure current database that can be queriedthe Business Benchmarking SecureWeb-Portal.


8/43



2. Business Metric Taxonomy

Before we can advance much further with our metrics discussion, we need to state clearly howwe intend to use the various metrics-related terms (like metric, measure, benchmark, etc.).

2.1. Metric Terminology

The business metrics that have been developed and housed in the Business Metrics Scorecardrepresent areas of business operation that are important in assessing business performance,customer satisfaction/loyalty and operational efficiency. Any metric managed by the BMS teamwill be called a business metric. A business metric must:

Be intelligible to anyone familiar with high-level telecom business concepts; i.e. abusiness metric does not require specialist or technical knowledge

Be appropriate to include in a business scorecard, i.e. a set of enterprise-levelperformance indicators of the business

Be part of a select minority of all metrics; i.e. it is not likely that all measurable thingsare business metrics.

According to the US National Institute of Standards and Technology, a measure is for moreconcrete or objective attributes and metric for more abstract, higher-level, or somewhat subjectiveattributes.1A measure is a more general concept than a metric. Any quantity can be measured, but agood business metric also has a clearly understood preferred progression, a numerical directionalitywhich indicates how wed like to see the metric change as the business improves. Preferredprogression can come in many different flavors, like:

The higher, the better (like revenue) The lower, the better (like customer response time) The closer to a specific value, the better (like body temperature) Can be equal to or lower than a value, but must not exceed (like a speed limit) Can be equal to or higher than a specific value, but must not be lower (like bank account

balance).

A metric is more likely to be some sort of comparison between two values, often expressed as aratio, less frequently as a difference. But still, not all metrics need be comparisons. So for example,one can have a metric which is the number of days it takes to go from bill cycle close to bills issued.However, even this simple count does have directionality -- since the shorter this delay, the better.

A metric begins with the thing being measured. The measurandis the "entity quantified by themeasure"2. Important kinds of measurands in the BMS work include:

number of subjects, or more specifically:

o number of things (like # bills)o number of events (like # customer contacts)o number of people (like # customers)

monetary value of subjects

1National Institute of Standards and Technology,http://samate.nist.gov/index.php/Metrics_and_Measures.html

2Structured Metrics Metamodel (SMM), V1.0
http://samate.nist.gov/index.php/Metrics_and_Measures.htmlhttp://samate.nist.gov/index.php/Metrics_and_Measures.htmlhttp://samate.nist.gov/index.php/Metrics_and_Measures.htmlhttp://samate.nist.gov/index.php/Metrics_and_Measures.html


9/43



o monetary value of things (like $ value of bills)o monetary value of processes or capabilities (like $ cost of assurance)

time durationso time durations for work effort (like # hours for all order processing)o time durations between events (like # hours between customer requested date

and customer committed date)

A benchmarkgenerally suggests that a number or set of numbers is available for the metricthat is indicative of either an average or a target for the industry. While the BMS team isresponsible for defining business metrics, the Benchmarking team is responsible for runningbenchmarking studies using these metrics, which generates reports containing benchmarknumbers, both average and 80-percentile values, among others.

A dimensionis a breakdown scheme for a metric. For example, a metric like "Revenue" can bedimensioned by region, by service, by market segment, etc. or indeed by any combination ofthese. Ideally, a dimension should not be part of a metric name, since one can instantiate manymetrics from one metric by running through all combinations of dimensions -- and that just leadsto clutter.

Note that Frameworx business metrics are service offering (SO) agnostic, and as such can bedimensioned by any appropriate service. That means that the same metric (F-CE-2a MeanDuration to Fulfill ) would be used to study service fulfillment time for residential broadband,mobile services, or IP VPNs. Obviously, the data collected would be quite different. Thus, it isgenerally not appropriate, for example, to compare a fulfillment metric for mobile service againsta fulfillment benchmark for DSL service.


10/43



2.2. Metric Naming

A given metric might be expressed in multiple equivalent ways. For example, one could write "Aas a % of B" or "% A of B" or "A/B %". All this variety can lead to the same metric erroneouslyentered multiple times in different namings, or else might make it difficult to find a metric givendifferent namings. So in order to ensure consistency as well as concision in the naming ofmetrics, a set of naming types was used to standardize metrics, detailed below.

What principles guided these metric name types? A good metric name should provide the gist ofthe metric without having to resort to looking up further detail. For example, "# hours to fulfillservice order" is better than "time to fulfill service order" since we do not need to look up theunits. Also, "# hours" is self-explanatory, so we do not need to write "Number of hours". Also,business objects and their states have been standardized as much as possible; so we use"bills" instead of "invoices", for example. Lists of standardize business objects, value drivers,and other expressions are presented later in this chapter.

Some ratios are ratios of the same thing, where some subset based on attribute is in thenumerator. This can be written very compactly. For example "% bills issued electronically"means "% of bills that were issued electronically out of total bills". A percentage of two differentthings in the same units can be written as "% opex, of revenue", where the comma and "of" areused to indicate what the percent is based on. In the most general case, we have two differentthings in a ratio, like cost of fulfillment per employee. Such ratios are generally not written aspercents.

Prose metric names are written in title case. In addition to a Prose Name, a metric also has an"XLS Name". This is driven by the need to have clear formulas for derived metrics. So whileolder formulas exist in Prose Formula form, we have made sure that every formula can also beexpressed an XLS Formula using the XLS Names.XLS Names are written in lowercase usingthe syntax for named ranges in Microsoft Excel3, or in other spreadsheet products that adopt thesame naming conventions.

To summarize, metric naming in BMS FX13 has been driven by several needs:

To keep the name as short as possible. To keep the name meaningful enough so that we reduce the need to reference the more

complete definition in the documentation To keep the structure of the names consistent To keep the terms in the name consistent (see Business Object Taxonomy for BMS

Measurand)

Below are the principle metric naming types used in FX13:

Type 1: Count - Basic

Format: # Example: # Bills Format: # Example: # Bills Issued Note: It is important to follow the metric format exactly. Thus it is "# Bills", not "# of Bills",

not "# Bills Total", not "Number of Bills", etc.

3http://office.microsoft.com/en-ca/excel-help/define-and-use-names-in-formulas-HA102749565.aspx#_Toc312073993


11/43


12/43


13/43



2.3. Metric Categories

The TM Forum Business Metrics have been used by the Business Benchmarking program byover 170 service providers in 65 countries to,

Assess business health, identify problem areas and drive focused improvement

Support business case, budgeting and investment decisions and Track business performance against best-in-class peers based on geography, size

and service offering.

The BMS Business Metrics are based on a scaffold that targets business performance based ona balanced scorecard. The balanced scorecard looks at financial, customer-oriented andprocess oriented measures.

Figure 1 - The Balanced Scorecard

2.3.1. Domain

Comparing performance indicators in each of the 3 areas of the balanced scorecard arerequired for a 360-degree view (Figure 1)

Revenue and Marginfinancial performance indicators such as OpEx as a % ofrevenue or recovered leakage

Customer Experienceindicators from the customer-facing side of the business

Operational Efficiencyindicators around the key operational process areas offulfillment, assurance, billing, and Call Center

The metrics have been developed to be service agnostic and to be applicable across existingand future service offerings. A service change or an addition of a new service will not have animpact on the definition of the metric.


14/43



2.3.2. Process Focus

The Balanced Scorecard is further divided into 5 process focus areas as shown in the figurebelow, namely General, Customer Management, Fulfillment, Assurance and Billing. Thisdelineation helps to concentrate the measure in specific service provider process areas. Metricswith a General process focus address the entire line of business. While metrics in the Domains

of Customer Experience and Operational Efficiency, fall into one of process foci of CustomerManagement, Fulfillment, Assurance, and Billing.

Figure 2 - Process Foci

2.3.3. Topic

In addition to the process detail, topic areas are used to ensure that the metrics are organized ina clear fashion. The topic areas are defined by Balanced Scorecard Domain as;

Revenue And Margin1. Margin/Revenue2. OpEx/CapEx3. OpEx/Revenue4. Revenue Breakdown5. Customer Constancy

Customer Experience1. Preferred Access2. Customer Time Spent


15/43



3. Usability4. Accuracy5. Contact Availability6. Ease of Doing Business7. Pricing Flexibility8. Security

Operational Efficiency1. Unit Cost2. Time3. Rework4. Simplicity5. Process Flexibility& Automation6. Utilization

Each metric has a domain, process focus, and topic. The decomposition of domains accordingto process is applied to Customer Experience and Operational Efficiency. Revenue and Marginmaintains an overall, general view of the service offering, and is not broken down further.

Metrics have been defined for combinations of domain, process focus and topic. The resultanthigh-level scaffold is described further in The Business Metrics Scaffold.

In some cases, it has been appropriate to position the metrics with a lower level of granularity.For this purpose, modifying details have been defined for certain metrics. An example ofmodifying detail is addressing specific customer segments, i.e. Consumer & SME vs. LargeEnterprise & Government. Appendix A contains some of the modifying details (possibleoptions) that are available for selected metrics.


16/43



2.4. Metric Codes

Every BMS metric is associated with a metric code, for example, "CM-CE-2b" is the metric codefor "Average Handle Time". At first glance the metric codes seem complex, but in fact, theycontain useful information about the metric. The code naming leverages the BalancedScorecard refinements described above. A metric is uniquely coded as follows:

- --

Where Process Focus is one of:

General metrics (G)

Customer Management metrics (CM)

Fulfillment metrics (F)

Assurance metrics (A)

Billing Metrics (B)

And Domain is one of:

Revenue and Margin (RM)

Customer Experience (CE)

Operational Efficiency (OE)

And Topic Number is a number representing the topics as covered in the Topics sectionearlier.

As an example lets assume that we are looking at measuring the performance of the order to aprocess for a particular service offering. The order to cash process includes accepting andvalidating the customer order, procuring the service, activating the service, billing for the serviceand receiving payment for the service. Three metrics that are critical to do this are

Mean Duration to Fulfill the Service Orderthis represents the time mean time fromcustomer calling in to and ordering a service until the service is active.

Mean Time from Service Activation to Bill Dispatch Mean Duration form Bill Dispatch to Cash Received

We will look at each in turn starting with Mean Duration to Fulfill the Service Order.

Fulfilling a Service order is part of the Fulfillment process (Process Focus = F).A service requestinitiated by a customer is in the Customer Experience Domain (Domain=CE).The measurement

topic is duration which is time related (Topic = 2) and it happens to be the first measuredeveloped with this combination. The resulting metric name is

- --

F-CE-2a


17/43



The figure below illustrates the metric code structure for F-CE-2a (Mean Duration to FulfillService Order).

Figure 3 - Example of how coding is used for the business metrics

Extended Metric Codes

An additional process for expanding metrics has been created to facilitate this work and assurealignment with the main business performance metrics developed by the Business MetricsDevelopment team. To accommodate increased detail, these expanded metrics have additionalcharacters in their metric codes. For example, the Revenue Assurance metrics link to the mainbusiness performance metrics via the Revenue and Margin Domain and the General ProcessFocus. This means that all RA metrics start with G-RM.

Secondly, to be understandable, expanded metrics need to have a topic identifier that is easilyrecognizable. Thus for Revenue Assurance metrics for example, RA is used instead of a topicidentifier of like 6. Similarly, the expanded metrics have a topic separation themselves. These

are expressed as sub-topics and are indicated with alpha sub-topic identifiers. In the case of theRevenue Assurance, sub-topics include DQ (Data Quality), RL (Revenue Leakage), and PE(Process Efficiency).

Finally, the individual metrics are designated by lower-case alpha characters after the sub-topic,similar to the designations in the main metrics set. Therefore, an example Revenue Assurancemetric would be G-RM-RA-DQa. Since this can be cumbersome, it is permitted to call the metricsimply RA-DQa, with the G-RM- implied. When using the metric outside the specific RA context,the full metric code should be used to avoid confusion.


18/43



2.5. Metrics and "Meta Processes"

To enable apples-to-apples comparisons, several "meta-processes" have been abstracted upa layer from the Business Process Framework. By meta-process we mean a simplifiedsequence of stages for major end-to-end processes. Meta-processes are process overviewsused to establish start and stop points for metrics in the different process foci. There is no meta-process for the General process focus since it applies to the entire business.

The key meta-processes and their stages are listed below (alternate names are shown inparentheses).

Fulfillmento Sellingo Order Handling (Ordering)o Service Configurationo Resource Provisioningo Service Activation (Activation)

Assuranceo Resource Data Collection & Processingo Resource Trouble Detection/Handlingo Service Problem Managemento Customer QoS/SLA Management

Billingo Initiate Billing / Collection (Bill Cycle Close)o Resource Data Collection & Processingo Service Rating & Discountingo Invoicing (Bill Dispatch)o Collection Management

Customer Management (Call Center portion of CRM)o no stages used

The following figures illustrate the sequence of the stages of the TM Forum Business Metricsmeta-processes.


19/43



Figure 4 - Fulfillment Meta Process

Figure 5 - Assurance Meta Process


20/43



Figure 6 - Billing Meta Process

Figure 7 - Customer Management Meta Process


21/43



2.6. Metric Model

Having established the basic terminology for metrics, metric categories, the metric code, andthe metric name, we are now ready to look at the overall metric model, i.e. the kinds of metricattributes we would want in a metric database or inventory. Over the past 6 months, the BMSteam has analyzed many different sets of metrics to come up with a set of fields that shouldcover most needs. Most metric definitions will not have all these fields, at least not at thebeginning -- so whether the metric is mandatory is indicated in parentheses.

Identification Section

1. ID: Metric ID, assigned by team responsible for metric; UUID supersedes this whenavailable (mandatory and unique)

2. Unused: A non-blank value indicates the metric has not been used yet, in any study; "X"indicates a metric has not been reported on, "Y" indicates a measure that is not a part ofany reported-on metric, and "D" indicates the measure is deprecated. (optional)

3. Code: team-specific alphanumeric code; longer form ID, more human friendly than anumber (recommended)

4. Name: actual metric name, that should be fairly descriptive of the metric without furtherdocumentation (mandatory and unique)

5. XLS Name: XLS-friendly name for use in XLS-formulas; the XLS-name must be a validXLS named range (no dashes or spaces, but underscores and periods are ok)(mandatory and centrally managed)

6. Alternate Name: an additional/alternate non-canonical name (or nickname) for themetric, common in the industry (ex: ARPU, Profitability) (optional)

7. Category: high-level categorization within overall TM Forum metric structure: BusinessMetric (domain-significant quantifiable), Measure (interim quantifiable), or other category(mandatory)

8. Fx Domain: one or more of the Frameworx Domains that best houses the metric:Common, Customer, Enterprise, Market_Sales, Product, Resource, Service,Supplier_Partner (ideally mandatory, but for future use)

9. Capability: what business capability is being measured, or more broadly, what businessdomain does the measurand belong to (ideally mandatory, but for future use)

10. Measurand: what business architecture object is being measured, ie. the measurand:process, employee, network resource, etc. (ideally mandatory, but for future use)

11. Topic: standardized topic names, across all metrics teams (to be determined) (ideallymandatory, but for future use)

12. Level: metric level hierarchy (optional)13. Parent: parent metric linkage, if this is a child metric (optional)14. Group: TM Forum group/team that is responsible for the metric definition (mandatory)15. Alternate Category 1: team-specific category 1 (for BMS, this is the "BMS Domain")

(recommended)16. Alternate Category 2: team-specific category 2 (for BMS, this is the "BMS Process")

(recommended)17. Alternate Category 3: team-specific category 3 (for BMS, this is the "BMS Topic")

(recommended)18. Alternate ID: alternate/abbreviated metric ID (for BMS, this is the shorter metric ID for

the RA metrics) (optional)

Definition Section

19. Metric Type: indicates whether direct, ratio, formula, etc. (mandatory)


22/43



20. Prose Formula: prose expression of formula, may not be as precise as the XLS Formula(optional)

21. XLS Formula: precise XLS-compatible formula using XLS named ranges (from XLSName field) (mandatory)

22. Prose Ratio: if Metric Type = Ratio, then this is automatically generated as NumeratorName / Denominator Name (optional)

23. XLS Ratio: if Metric Type = Ratio, then this is automatically generated as Numerator XLSName / Denominator XLSName (mandatory if formula with XLS formula = blank)

24. Numerator Metric ID: if Metric Type = Ratio, then this should be a unique identifier(FxMetric UUID, ID, etc.) for the record in this table that is the Numerator of the ratio(mandatory if formula with XLS formula = blank)

25. Numerator Name: if Metric Type = Ratio, then this should be the Name field associatedwith the Numerator ID, used to automatically generate Prose Ratio (optional and derivedfrom Numerator FxMetric ID)

26. Numerator XLS Name: if Metric Type = Ratio, then this should be the Name fieldassociated with the Numerator ID, used to automatically generate XLS Ratio (optionaland derived from Numerator FxMetric ID)

27. Numerator Includes: items included from numerator; this is obtained from the same table

(optional and derived from Numerator FxMetric ID)28. Numerator Excludes: items excluded from numerator; this is obtained from the same

table (optional and derived from Numerator FxMetric ID)29. Numerator Units: units for numerator; this is obtained from the same table (optional and

derived from Numerator FxMetric ID)30. Denominator Metric ID: if Metric Type = Ratio, then this should be a unique identifier

(FxMetric UUID, ID, etc.) for the record in this table that is the Denominator of the ratio(mandatory if formula with XLS formula = blank)

31. Denominator Name: if Metric Type = Ratio, then this should be the Name fieldassociated with the Numerator ID, used to automatically generate Prose Ratio (optionaland derived from Denominator FxMetric ID)

32. Denominator XLS Name: if Metric Type = Ratio, then this should be the Name field

associated with the Numerator ID, used to automatically generate XLS Ratio (optionaland derived from Denominator FxMetric ID)

33. Denominator Includes: items included from denominator; this is obtained from the sametable (optional and derived from Denominator FxMetric ID)

34. Denominator Excludes: items excluded from denominator; this is obtained from thesame table (optional and derived from Denominator FxMetric ID)

35. Denominator Units: units for denominator; this is obtained from the same table (optionaland derived from Denominator FxMetric ID)

36. Dependent Metrics: list of metrics that use this metric in calculation (optional)

Description Section

37. Description: text description of the metric (recommended)

38. Comments: general remarks about the metric, including how to measure, commonpitfalls, etc. (optional)

39. Includes: business rules for what is included in metric definition (mandatory if formulawith XLS formula = blank)

40. Excludes: business rules for is excluded in metric definition (mandatory if formula withXLS formula = blank)

41. Prose Dimensions: text description of key dimensions to consider (optional)42. XLS Dimensions: XLS-friendly comma-delimited list of cube dimensions (to be

determined) (optional)


23/43


24/43



68. Other Linkages: related actors, stakeholders, capabilities, ecosystem components, etc.(future use)

69. XLS Fields: list of comma-delimited XLS fields extracted from XLS formula, if applicable(future use)

Legacy Section

70. Legacy Name: old metric prose name, for data quality tracking (optional)71. Legacy Prose Formula: old metric prose formula, for data quality tracking (optional)72. Legacy Prose Ratio: old metric prose ratio, for data quality tracking (optional)73. Legacy Numerator FxMetric ID: old metric numerator ID, for data quality tracking

(optional)74. Legacy Numerator Name: old metric numerator name associated with ID, for data quality

tracking (optional)75. Legacy Denominator FxMetric ID: old metric denominator ID, for data quality tracking

(optional)76. Legacy Denominator Name: old metric denominator name associated with ID, for data

quality tracking (optional)77. Legacy Factor: old metric includes and excludes, if measure/factor (optional)

78. Legacy Links: old metric linkages (optional)

2.7. Supporting Taxonomies

As we build and expand the BMS metric model, we encounter fields/attributes that add richness tothe understanding of a metric, like "Measurand", and "Business Value Driver". But to ensure that thevalues entered for these attributes are logical and consistent, we need to build some light, supportingtaxonomies to guide their use. For example, for Business Value Driver, one can imagine all sorts ofprose entered to describe what benefits the metric is related to. By using a supporting model (like theBusiness Value Driver Taxonomy), we ensure that we select from a small set of consistently named

entries that do not overlap, and reduce interpretation as to meaning. Note that all these taxonomiesare still evolving, and we expect further maturing in future releases of the BMS documentation.

2.7.1. Business Object Taxonomy

Many of the BMS metrics are about process, and as such, what we are measuring, themeasurand, is process, or more broadly speaking, an occurrence. Some measurands arepeople or stakeholders (# customers, # FTE), while other are artifacts, tangible or informational(# problem reports, # data records). And of course many are financial in nature ($ cost, $revenue). A list of business architecture domains will help standardize these measurandcategories, which will give us another way to organize, navigate, and analyze metrics.Measurands are substantives, or nouns in our business architecture depictions. Some people

call them business objects.A taxonomy for measurands and other substantives will help limit and control the number ofnouns (and ideally states and behaviors) that are used in the metric definitions. For thisiteration, our focus has been on the substantives only. We are basing the top-level businessarchitecture domains on the work of the OMG (Object Management Group) BASIG (Business

Architecture Special Interest Group) -- who have produced a domain model. The top-levelmeasurand domains are:

Capability


25/43



Stakeholder Money Artifact (a document, information record, or other business object, like a bill, a payment,

a problem report, etc.) Occurrence (an initiative, process, behavior or event, that takes place in time) Resource (a tangible or intangible material used to deliver products/services to

customers)

The list of measurands used in this release of the BMS metrics is as follows:

Capabilityo assuranceo repair (a subset of assurance)o repair and maintenance (a subset of assurance)o billingo channel (may overlap Marketing & Sales and CRM)o collections (a subset of billing)

o customer management (referred to as CRM earlier)o fulfillmento sales (a subset of the Marketing & Sales capability discussed earlier)o SLA management (a subset of assurance)

Stakeholdero customer

Note: The term customer is preferred over user or subscriber. o user

Note: This term is retained for some special uses, such as its use inARPU, where U stands for User.

o employee (NOC FTE) Value

o account receivableso asseto billing chargeo billo capexo collectable debt written offo costo operating incomeo opexo revenueo sales

Artifact

o billo billing suspense fileo data recordo ordero problem reporto service problemo settlement reporto SLAo XDR


26/43



Occurrenceo activationo bill processing faulto billing erroro case of revenue recoveryo customer callo customer contacto customer incidento customer paymento customer requesto customer transactiono failureo fulfillment issueo installationo pricing changeo service outageo SLA violation

Resourceo future infrastructure buildo revenue systemo service

Using this taxonomy, for example, the metric "Average Handle Time" has a measurand of"occurrence.customer_request", since it represents the time to handle a customer request,which is a kind of business occurrence. The list of measurands will help keep the list of nounsused in metrics to a manageable level.

2.7.2. Business Value Driver Taxonomy

A business value driver is a high-level business benefit we are trying to ultimately monitor usinga metric. It is related to the business reason or imperative for wanting the metric in the firstplace.

Benefit Statement

A benefit statement will be written as either "increase" a value we want (like revenue), or decrease an"anti-value" (something we don't want, like cost). If a benefit statement can be written in either way,we will pick the one expressed using the most intuitive wording.

Simple Benefit Statement (Atomic & Derived)

Below are some benefit statements that are relevant to the BMS metrics:

decrease customer risk decrease excessive contacts decrease information loss decrease launch time decrease operating cost decrease problems


27/43



decrease revenue loss decrease process time decrease waiting time decrease time to revenue decrease time to market increase customer satisfaction increase margin increase marketshare increase productivity increase revenue

Atomic Benefits Statements

It should be apparent that these benefits are inter-related. For example, increasing productivity can inconsequence lead to improved customer experience as well as reduced operating costs. Thus, wedistinguish between atomic and derived benefits. Atomic benefit statements are benefit statementsthat represent the most elemental forms of value (or "anti-value" in the case of cost). Atomic benefits

are the benefits that are necessary for a balanced view of performance. While one can try to reduceeverything to money, a mature business understanding appreciates that customer and marketbenefits may not always be easily correlated to financial performance. Here is a running list of BMSbenefit statements to date that we consider to be atomic, grouped by topic.

Revenueo increase revenueo decrease time to revenueo decrease revenue loss

Costo decrease operating costo increase margin

Customer

o increase customer satisfaction Market

o decrease time to marketo increase marketshare

Value Drivers

We define a value driver as an atomic benefit statement, or a sequence of benefit statements thatcausally lead to an atomic benefit. A sequence of benefit statements can be chained using the "->"(leads to) symbol. Below are the benefit statements used as value drivers in the current list of BMSmetrics. Only metrics with a non-blank "Preferred" value (meaning we prefer them to tend higher or

lower), are canonical metrics, and as such will have an associated value driver.

Revenueo increase revenueo decrease revenue losso decrease information loss -> decrease revenue losso decrease process time -> decrease time to revenue

Costo decrease operating cost


28/43



o decrease excessive contacts -> decrease operating costo decrease problems -> decrease operating costo decrease process time -> decrease operating costo increase productivity -> decrease operating costo increase margin

Customero increase customer satisfactiono decrease customer risk -> increase customer satisfactiono decrease excessive contacts -> increase customer satisfactiono decrease problems -> increase customer satisfactiono decrease waiting time -> increase customer satisfactiono increase productivity -> increase customer satisfaction

Marketo decrease launch time -> decrease time to marketo increase marketshare

2.8. Metric Counting Rules

Some metrics require detailed description on how to count their measurands. The following countingrules explain in detail when service outages, problem reports, and order acceptances can becounted.

2.8.1. Service Outages

Terminology

A Scheduled Outage results from a scheduled or planned maintenance, installation, orinitialization. This includes such activities as configuration changes, upgrades, and serviceadditions/changes/cessations. Typical Operations, Administration, and Maintenance (OA&M)

activities that may be counted as scheduled activities include:

cutover (e.g. any service element replacement or absorption) hardware or software growth/extension preventive maintenance routine or scheduled diagnostics data/configuration change software update to add new features software generic upgrade backups (application, configuration or data).

Counting Rules

1) An Outage is an absence of the service contracted with a customer, primarily triggered by oneor more of the following:

the system design, hardware, software, components or other parts of the system scheduled events necessitated by the design of the system support activities performed by an organization including documentation, training,

engineering, ordering, installation, maintenance, technical assistance, software orhardware change actions, etc.


29/43



2) All effects of failures and service degradation resulting from (Operations, Administration andManagement - OA&M) activities are covered. Outages that result because of, or during, OA&Mactivity should be counted in any outage downtime or frequency measurements. Correctiveactions not be counted as a Scheduled Outage activity include:

deferred maintenance, e.g. a deferred repair or restart to clean-up operating errors,

diagnostics to isolate a detected fault, service fault repair, fixing an error or omission in configuration or an omission in a recent configuration

change, temporary fixes in the course of a fix to a fault found as a result of a Problem Report.

3) Outages attributed to (caused by) a customer are counted in both the:

"All Causes" dimensioning, and "Customer Attributable" dimensioning.

4) If stand-alone or redundant capability is available from the organization, but a customer haschosen not to equip the service with the capability, an outage event in the service should beclassified as "Customer Attributable" if the stand-alone or redundant capability would haveprevented the outage condition.

5) When an outage requires the dispatch of a customer's technician to location to complete therestoration of service, the customer is allocated 1.5 hours after notification of the problem to havea technician on-site. Time of on-site arrival in excess of 1.5 hours will be treated as "Customer

Attributable" in the outage duration measure.

Counting Rule Exclusions

1) Outages are counted in a Service Offering only when the failure is within the Service Offeringitself. Outages caused by associated products in the network are excluded, e.g., a failure withinan MPLS service is counted against the MPLS instance that caused the event and excludesattached equipment or applications.

2) Where a customer does not make outage data available to the organization, then thosespecific services deployed by the organization for that customer shall be excluded from theoutage measurements.

3) Outages that occur in test or trial environments or that do not carry live service transactions (ortraffic) shall not be counted.

2.8.2. Problem Reports

Counting Rules

The following general rules shall apply in counting problem reports:

1) Only customer problem reports shall be counted (including those reported on or alarmed onbehalf of the customer).

2) Problem reports where the reported problem cannot be duplicated during subsequentinvestigations shall be counted.

3) Identical problem reports, i.e. multiple reports of the same occurrence of the same problem atthe same location at the same time, shall be counted as one problem report.

4) Duplicate problem reports, i.e. the same fault has occurred either at a different customerlocation or at a different time, shall each be counted as separate problem reports.


30/43


31/43



17) The delivery of temporary or interim fixes or workarounds in response to critical problemreports shall not be counted in this measurement. Subsequent or "follow-up" major or minorproblem reports opened to track the development and delivery of the official fix shall be included.When the official fix activity is tracked against the original critical problem report, then thoseproblem reports shall be treated as major problem reports.

18) With customer approval, the time between the application of a temporary or interim fix andthe commitment date for a permanent fix may be excluded in the fix response time calculation.The customer must agree that the temporary fix meets their needs. Failure to provide anacceptable resolution with a permanent fix by the negotiated commitment date will result in therestoration of all the excluded time.


The problem report count shall exclude:

1) A problem report determined to represent an information request; formal agreement from thecustomer such as a written document or e-mail is not required,

2) A request for a feature by agreement between the organization and customer,

3) A problem report related to use of the product in a manner not defined in the specification ofthe product by agreement between organization and customer,

4) Customer reports of routine events such as: expected maintenance, normal field replaceablereturns, software upgrades, technical assistance unrelated to a service defect, reports of outagesreceived after their occurrence without the request from the customer for investigation, or anyother event where there is no customer expectation of investigation and action by theorganization.

5) Problem reports received from indirect customers unless forwarded by a direct customer.

6) If a Problem Report misses its due date it is not counted again - even if a new due date isnegotiated.

2.8.3. Order Acceptance

Counting Rules

1) Acceptance shall be defined according to purchase order and/or contract terms and conditionsunless notified otherwise by the customer.

2) Due dates and delivery dates are considered to be one 24-hour period, the customer'scalendar day unless a different delivery window has been agreed to in advance with thecustomer.

3) Early order completions or deliveries are considered to have missed the delivery date unlessauthorized by the customer.

4) A service order is considered delivered on the date when service is complete at the job siteand accepted by the customer and is not the date the customer completes their acceptancetesting, unless so specified by contract.

5) The calculation shall include all orders having the commitment date occurring during the monthbeing reported.

6) The commitment date is the date promised to the customer requested for delivery and is notthe date the customer completes their internal acceptance testing, unless so specified bycontract.


32/43



7) Order types can be a line item or service.

8) Line item delivery occurs on the date when actually delivered to the required address.

9) The delivery of a line item order may occur at the organization's facility if the customer providesor specifies a shipper to be used for an order.

10) Compound orders designated by the customer for a single delivery, e.g., "must delivercomplete" orders, shall be treated in aggregate. If one line item is late, then all line items shall becounted as late.

11) Bulk orders, such as blanket purchase orders, shall be considered complete if all itemscommitted to be delivered in the order are delivered within the timeframe specified in the bulkorder agreement, e.g., weekly, monthly, etc. Each scheduled delivery date should be treated as aseparate line item.

12) Installations containing multiple products with a single customer completion date shall beconsidered a single installation.


1) Orders for which the customer requested date is earlier than the date the order is received by

the organization.

2) Software "deliveries" that are not physically shipped or downloaded by the organization to acustomer. This is considered the release of a new software design.

3) Hardware that is part of a service delivery by the organization should not be counted in aseparate delivery measurement.


33/43



3. The Business Metrics Scorecard (BMS)

In December 2009, the TM Forum Business Benchmarking team launched the Business MetricsFramework (BMF), later renamed the Business Metrics Scorecard (BMS). The BMS is both avisual graphic of current TM Forum benchmarks as well as a framework for ongoing metrics

discussions in the telecommunications industry.

3.1. The Customer Experience Life Cycle

To support design of the TM Forum Balanced Scorecard, a Customer Experience Life Cycle(CxLC) model was developed. The CxLC model presents both customer and service providerperspectives on the relationship, and aligns the main touch point categories between the two.The CxLC model is important because it will define the main headings of the CustomerExperience domain in the Balanced Scorecard.

Structurally, the CxLC model consists of seven paired stages, arranged into two horizontal

perspectives of three vertical groups each, as shown in figure 4. Each block is described in thetext following the diagram. For each lower-level block, we also list some key paired verbs thatrepresent the actions of the customer and/or provider.

Figure 8 - Customer Experience Lifecycle

The first group in the CxLC model consists of three stages relating to the customers Buyingexperience, as tied to the service providers Marketing and Selling.

Awareness/Acquisition: This is the stage during which the service provider attempts

to reach a prospective customer and/or the customer becomes aware of the serviceprovider. The provider can position messages which the customer observes andreacts to. The customer can learn about offerings the provider informs the marketabout.

o Key Customer Verbs: Observe, React, Understand

o Key CSP Verbs: Position, Reach, Inform


34/43



Interaction/CRM: Unlike the other stages, interaction can occur at any point in thelifecycle although it is a natural consequence of Awareness/Acquisition. The providerpersuades the customer about their value proposition and engages in furtherdialogue with the customer. Perhaps the customer contacts the providers call center,visits the providers store or goes to the providers website. The provider responds tothe customers queries about products and prices. The customer may request

marketing literature or a demonstration to which the service provider responds.

o Key Customer Verbs: Engage, Contact, Request

o Key CSP Verbs: Persuade, Answer, Respond

Agreement/Fulfillment: This is the stage when the customer and provider enter into acommitment ranging from a simple one-time transaction to a complex multi-yearrelationship. The customer can specify their needs and the provider proposes asolution, whether consumer or enterprise. Here is where the purchase occurs andorders are placed. By the end of this phase the provider has provisioned the offeringand the customer has received the product.

o Key Customer Verbs: Specify, Agree, Receive

o Key CSP Verbs: Propose, Order, Deliver

The second group consists of three stages relating to the customer Using the service, whilethe provider is Operatingit.

Consumption/Operation: This is the stage when the customer is using the purchasedproduct and the provider is operating the service. It also encompasses the scenariowhere things no longer work. This is to say the customer can no longer use theproduct or the provider cannot deliver the service. It also includes terminating theservice.

o Key Customer Verbs: Learn, Use, Conclude

o Key CSP Verbs: Instruct, Render, Cease

Support Need/Assurance: This is the stage when there is a problem with the serviceand the customer reports the problem while the provider resolves it. In the extremecase the customer returns the product and the provider replaces it. This stage alsocovers customer training and education by the provider on how to use the products.

o Key Customer Verbs: Cant Use, Report Problem, Return

o Key CSP Verbs: Cant Render, Resolve Problem, Replace

Payment/Billing: This stage begins with the provider billing the customer by way ofan invoice. The customer verifies the invoice and may make inquiries to which theprovider gives explanations. Ultimately the customer pays the provider or theprovider initiates collections procedures.

o Key Customer Verbs: Verify, Dispute, Pay


35/43



o Key CSP Verbs: Bill, Explain, Collect

The last group consists of two stages that describe what happens after the transaction iscompleted. Will CSP end up Satisfying the customer, who will hopefully end up Advocatingthe CSP or service? Does the customer continue, augment or diminish its relationship with the

provider?

Loyalty/Retention: At this stage the transaction comes to a close and the customermust decide whether to renew the agreement with the provider. The provider is notonly interested in retaining the customer but wants the customer to upgrade theircommitment yielding greater ARPU. If the service provider succeeds in truly inspiringits customers they will advocate the providers services to family and friends.

o Key Customer Verbs: Renew, Enhance, Advocate

o Key CSP Verbs: Retain, Upgrade, Inspire

Disengagement/Attrition: This stage represents the negative version ofLoyalty/Retention. Here the service provider has disappointed or the customer hascomplained. The customer may downgrade their agreement. In the worst case thecustomer leaves the relationship.

o Key Customer Verbs: Complain, Diminish, Leave

o Key CSP Verbs: Disappoint, Downgrade, Lose


36/43



3.2. Structure of the Business Metrics Scorecard

The metrics are held in the Business Metric Scaffold as shown below. As you can see, thestructure of the scaffold reflects the structure of the balanced scorecard shown in Figure 1.Thescorecard is further refined by process foci, and topic as described earlier.

Individual metrics appear in the scaffold cells based on a combination of their domain, focus andtopic. Metric naming codes are used to uniquely identify a metric and are used to quicklydetermine where a metric sits within the scaffold based on this combination as well as referencethe detailed metric descriptions in the Business Performance Measurement System (BPMS).For better viewing the Metric Scaffold can be downloaded from the TM Forum website atwww.tmforum.org.

Figure 9 - Business Metrics Scorecard
http://www.tmforum.org/http://www.tmforum.org/http://www.tmforum.org/


37/43



In order to provide a holistic business-oriented benchmarking and metrics framework, the BMFhas been structured to look like the scorecard first introduced in Basic Structure of theBusiness Metrics. Referring to figure 5, the three largest areas of the BMF model correspond tothe three main domains:

Revenue and Margin (in burgundy, running along the top of model)

Customer Experience (in orange, at the bottom left of model)

Operational Efficiency (in blue, at the bottom right of model)

In the Revenue and Margin domain, the BMF parses out rows based on key groupings ofmetrics: Revenue, Profitability (including Margin and Revenue Assurance), Cost (includingOpEx and CapEx), and Churn.

Both the Customer Experience and Operational Efficiency domains consist of columns thatreference the topics described in Basic Structure of the Business Metrics. Due to the numberof topics, they are grouped in the BMF as consolidated topics for simplicity.

Thus in the Customer Experience domain, the consolidated topics (columns) are Access, Timeand Quality. (The Quality grouping consolidates the topics of Usability, Accuracy andAvailability.) Note that the row names are extracted from the Customer Experience Lifecycle.

In the Operational Efficiency domain, the consolidated topics (columns) are Cost, Time, Qualityand Effectiveness. (The Quality grouping consolidates the topics of Defects and Simplicity, whilethe Effectiveness grouping consolidates the topics of Process Flexibility & Automation, andUtilization.) Most of the row names are extracted from eTOM.

Thus the BMF leverages several important model components to build a holistic view ofbusiness benchmarking:

The overall scorecard structure of the TM Forum Benchmarking metrics anddomains, factoring in process, as well as customer experience, and revenue and

margin The topics used to group metrics in the TM Forum Benchmarking domains,

supporting views by cost, time, quality, etc.

Process categories from eTOM, to ensure we are using standard process namingconventions

Customer experience categories from the CxLC, to leverage a rich view of thecustomer experience.


38/43



3.3. Navigating the Business Metrics Scorecard

Using the earlier example, we can see in the figure below where metric F-CE-2a appears on thescaffold.

Figure 10 - F-CE-2a Example

Using similar logic, the Mean Duration from Service Activation to Bill Dispatch and the MeanDuration from Bill Dispatch to Cash Received, are both part of the Billing process (ProcessFocus = B), they are both part of the service providers internal operational domain (Domain =OE), and as with the Fulfillment measure both are time related (Topic = 2), The resultingmeasure names are B-OE-2c, and B-OE-2d respectively. The last letter is different to indicate aunique measure in the same Process-Domain-Topic tuple.


39/43



Figure 11 - B-OE-2c and B-OE-2d Example

These metrics have been developed and honed over the past 6+ years, and have been used instudies in support of Business Performance around multiple services offerings as well as

Revenue Management studies such as Billing Performance. In a very dynamictelecommunications environment, the base metrics have proven to be resilient. When changesare required, the scaffold provides a structure, and this document outlines a process, that whenfollowed ensures that metrics are

1. Requiredthe metric goal is not satisfied by existing metrics2. Consistent - the metric can be calculated and fits into the scaffold, using existing

terminology and methodology3. Benchmark-ablethe metric has been normalized to accommodate global

benchmarking.4. Standardizedthe metric is reviewed for relevance and measurability by service

providers and adopted into the BPMS and the Business Metrics Scaffold, becoming a

part of the standardized TM Forum Business Metrics.


40/43



Appendix A: Terms and Abbreviations Used within this

Document

Term Definition Possible Options

1 Access Media The interface mechanism between theservice provider and the end-customer

Direct (store front, acct mgr.) reseller/distributor phone web mail

2 Channel The channel to market for the service. Direct (store front, acct mgr.) reseller/distributorcall center web

3 Customer Confirmed

Date

The date that the service provider

confirmed delivery of the service.

4 Customer Density Differentiates between services that aredelivered in a high populous area with highdegree of infrastructure (Urban/Suburban),versus outlying areas with highly distributedcustomer and low degree of infrastructure

Urban/Suburban Rural

5 Customer Request Interaction between a service provider andan end-customer.

Possible types are shown.

Complaint Inquiry Change

6 Customer RequiredDate

The date that the customer requested theservice to be activated by

7 Defect Type Technologyrefers to a network or serviceproblem. Workforcerefers either the SP or3rd party employed workforce. A Systemcause refers to a problem in the OSS/BSSinfrastructure.

customer causedtechnology causedworkforce causedsystem caused (data

mismatch problems) other

8 End-CustomerSegment

Indicator of end-customer segment. Smalland medium business is considered to be

the same segment as consumer

Consumer, Small/MediumBusiness

Large Enterprise,Government

9 Maintenance Type Unplanned maintenance referencesexception based intervention ormaintenance

Planned vs. Unplanned


41/43



Term Definition Possible Options

10 Market Position An indication whether the Service provideris operating as the incumbent or outside the'geography' where they are incumbent.(This metric is valuable to a wirelineoperator that was once the monopoly

carrier. It is best applied to measures thatare applicable to wireline vs. wirelesscarriers)

Incumbent Competitor

11 Payment Timing when the customer is scheduled to pay forservices

Prepaid, Postpaid

12 Request Category Process that the contact is referencing. SeeCustomer Request

Fulfillment Assurance Billing General

13 Service Component Differentiates the Bearer from the

Application. The bearer providesconnectivity only.

Bearer, Data, Content, Retail


42/43



Appendix B: Administrative Information

This appendix provides additional background material about the TM Forum and this document.

B.1. Version History

This section records the changes between this and the previous document version as it is editedby the team concerned. Note: this is an incremental number which does not have to match therelease number.

Version Number Date Modified Modified by: Description of changes

1.1.0 15 June 2005 Mike Kelly First issue of Release 1.0 document

2.1.0 12 June 2006 Alpna Doshi

Paul Winder

First Issue of Release 2

New name of the documentBusinessMetrics Scaffold

3.0.0 5 May 2008 Rudi Jetzelsperger First Issue of Release 3

updated metrics and added RevenueAssurance Metrics

3.0.1 6 June 2009 Robert Bratulic Made minor corrections

5.0.0 18 April 2010 Robert Bratulic New major release, aligned with BMF5.0

6.0.0 8 August 2010 Beryl Graham New major release, aligned with BMS6.0 / Metrics Inventory 6.0.0

6.1.0 31 August 2010 Alicja Kawecki Updated Notice, minor cosmeticcorrections for web posting and ME

6.2.0 19 January 2011 Alicja Kawecki Updated to reflect TM Forum Approvedstatus

7.0 31 March 2013 Robert Bratulic Document has been significantlyrestructured based on GB935, BM1000,and BM1001now all combined intoone GB935 document family of 3documents. Concepts & Principles isthe main document, with 2 addendaone for metric specifications, the otherfor metric development.

7.1 18 Sept 2013 Robert Bratulic Added section 2.8 on Counting Rules(recuperated content from BM1000metrics Excel spreadsheet); a few typoscorrected.

7.1.1 8 Oct 2013 Alicja Kawecki Updated cover, header & footer; minorcosmetic fixes

7.1.2 14 Nov 2013 Alicja Kawecki TM Forum name change in Notice


43/43


B.2. Release History

This section records the changes between this and the previous official document release.

Release Number Date Modified Modified by: Description of changes

1.0 15 June 2005 Mike Kelly First release of document

2.0 12 June 2006 Alpna Doshi Second Release of document

3.0 14 April 2008 Rudi Jetzelsperger Third Release of document

4.0 16 June 2009 Robert Bratulic Fourth Release of document

5.0 18 April 2010 Robert Bratulic Fifth Release of document, including firstreferences to BMF model

6.0 01 August 2010 Beryl Graham Sixth Release of document aligned withBMS 6.0 / Metrics Inventory 6.0.0

7.0 31 March 2013 Robert Bratulic Document has been significantlyrestructured based on GB935, BM1000,and BM1001now all combined intoone GB935 document family of 3documents. Concepts & Principles is themain document, with 2 addendaonefor metric specifications, the other formetric development.

B.3. Document Family and Related Documents

Document Name Revision/Date

TM Forum GB935: Concepts & Principles V7.1.1 / Oct 2013

TM Forum GB935-A: Addendum A: Business Metric Specifications V7.0 / Apr 2013

TM Forum GB935-B: Addendum B: Business Metric Development Guide V7.0 / Apr 2013

TM Forum Business Metrics Poster V7.0 / Apr 2013