Frameworx How-To Guide

Business Process Framework

(eTOM)
User Guidelines for the Business Process Framework

Business Process Framework

GB921 Addendum U
Release 15.0.1
December 2015

Latest Update: Frameworx Release 15 TM Forum Approved

Suitable for Conformance
Version 15.0.2 IPR Mode: RAND

© TM Forum 2015. All Rights Reserved.

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

Notice

Copyright © TM Forum 2015. 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, provided
that the above copyright notice and this section are included on all such copies and derivative
works. However, this document itself may not be modified in any way, including by removing the
copyright notice or references to TM FORUM, except as needed for the purpose of developing
any document or deliverable produced by a TM FORUM Collaboration Project Team (in which
case the rules applicable to copyrights, as set forth in the TM FORUM IPR Policy, must be
followed) 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 or
its successors or assigns.

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

TM FORUM invites any TM FORUM Member or any other party that believes it has patent
claims that would necessarily be infringed by implementations of this TM Forum Standards Final
Deliverable, to notify the TM FORUM Team Administrator and provide an indication of its
willingness to grant patent licenses to such patent claims in a manner consistent with the IPR
Mode of the TM FORUM Collaboration Project Team that produced this deliverable.

The TM FORUM invites any party to contact the TM FORUM Team Administrator if it is aware of
a claim of ownership of any patent claims that would necessarily be infringed by
implementations of this TM FORUM Standards Final Deliverable by a patent holder that is not
willing to provide a license to such patent claims in a manner consistent with the IPR Mode of
the TM FORUM Collaboration Project Team that produced this TM FORUM Standards Final
Deliverable. TM FORUM may include such claims on its website, but disclaims any obligation to
do so.

TM FORUM takes no position regarding the validity or scope of any intellectual property or other
rights that might be claimed to pertain to the implementation or use of the technology described
in this TM FORUM Standards Final Deliverable or the extent to which any license under such
rights might or might not be available; neither does it represent that it has made any effort to
identify any such rights. Information on TM FORUM's procedures with respect to rights in any
document or deliverable produced by a TM FORUM Collaboration Project Team can be found
on the TM FORUM website. Copies of claims of rights made available for publication and any
assurances of licenses to be made available, or the result of an attempt made to obtain a

TM Forum 2015. All Rights Reserved. Page 2 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

general license or permission for the use of such proprietary rights by implementers or users of
this TM FORUM Standards Final Deliverable, can be obtained from the TM FORUM Team
Administrator. TM FORUM makes no representation that any information or list of intellectual
property rights will at any time be complete, or that any claims in such list are, in fact, Essential
Claims.

Direct inquiries to the TM Forum office:

240 Headquarters Plaza,

East Tower – 10th Floor,
Morristown, NJ 07960 USA
Tel No. +1 973 944 5100
Fax No. +1 973 944 5110
TM Forum Web Page: www.tmforum.org

TM Forum 2015. All Rights Reserved. Page 3 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

Table of Contents

Notice.................................................................................................................................................................. 2
Table of Contents ............................................................................................................................................. 4
Table of Figures ................................................................................................................................................ 6
Executive Summary ......................................................................................................................................... 7
1. Introduction.................................................................................................................................................... 8
1.1 Audience .............................................................................................................................................. 8
1.2 Plan of document................................................................................................................................. 8
1.3 Principles and Guidelines.................................................................................................................... 9
2. Principles and positions of the Business Process Framework model .............................................. 10
2.1 Introduction ........................................................................................................................................ 10
2.2 A note on the status of the Business Process Framework documentation.................................... 10
2.3 Nature of the Business Process Framework model ........................................................................ 10
2.4 Process model types ......................................................................................................................... 11
Activity-based process modeling ....................................................................................................... 11
Communication-based Process Modeling ........................................................................................ 12
Artifact-based Process Modeling ....................................................................................................... 12
Hybrid approach to Process Modeling............................................................................................... 12
2.5 Characteristics of a Business Process ............................................................................................. 12
2.6 Decomposition ................................................................................................................................... 13
2.7 Traceability......................................................................................................................................... 14
2.8 Process dependency through information ....................................................................................... 14
2.9 Grouping / organization within the Business Process Framework ................................................. 15
2.10 Flows ................................................................................................................................................ 15
2.11Dynamic aspects of Process Modeling ........................................................................................... 16
2.12 Naming conventions........................................................................................................................ 17
2.13 Layer References and Responsibilities .......................................................................................... 17
2.14 Data Responsibility.......................................................................................................................... 18
3. Process Patterns......................................................................................................................................... 19
3.1 Introduction ........................................................................................................................................ 19
3.2 Level 3 patterns ................................................................................................................................. 19
Example 1 – Problem Reports and their resolution .......................................................................... 19
Example 2 – Strategic view and Business Plan ................................................................................ 20
Example 3 – Order Lifecycle .............................................................................................................. 20
Example 4 – Product Lifecycle ........................................................................................................... 20
3.3 Level 4 Patterns ................................................................................................................................. 21
4. Organizational Context for the Business Process Framework ........................................................... 22
4.1 Introduction ........................................................................................................................................ 22
4.2 Use of the Business Process Framework within an organization................................................... 22
Level 0 – Business Activities .............................................................................................................. 23
Level 1 – Process Groupings ............................................................................................................. 23
Level 2 –Core Processes ................................................................................................................... 24
Level 3 – Business Process Flows .................................................................................................... 24
Level 4 – Operational Process Flows ................................................................................................ 24

TM Forum 2015. All Rights Reserved. Page 4 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

Level 5 – Detailed Process Flows ......................................................................................................25

4.3 The Business Process Framework and the Process Hierarchy ......................................................25
.5 Guidance for extending and using the Business Process Framework..............................................26
5.1 Process Hierarchy: Decomposition Principles ..................................................................................26
5.2 Process Hierarchy: Implementation Principles .................................................................................27
5.3 Process Hierarchy: Hierarchies ........................................................................................................28
5.4 Process Hierarchy: Process View .....................................................................................................29
6. Decomposition Guidelines.........................................................................................................................30
6.1 Consistency of Inputs and Outputs ...................................................................................................31
6.2 Additional Decomposition Guidelines ...............................................................................................32
6.3 Information Framework Related Guidelines .....................................................................................34
6.4 Semantic Analysis ..............................................................................................................................35
7. Audit Checklist .............................................................................................................................................46
8. Outstanding issues .....................................................................................................................................48
9. Administrative Appendix ............................................................................................................................49
8.1 Acknowledgements ............................................................................................................................49
8.2 Document History...............................................................................................................................49
8.2.1 Version History ...........................................................................................................................49
8.2.2 Release History ..........................................................................................................................50

TM Forum 2015. All Rights Reserved. Page 5 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

Table of Figures

Fig. 1 Process Hierarchy 23

Fig. 2 Process Hierarchy and analysis focus for Levels 26
Fig. 3 Process Hierarchy Implementation 27
Fig. 4 Process Hierarchy hierarchies 28
Fig. 5 Process Hierarchy: Processes and Resources 29
Fig. 6 Consistency of Inputs and Outputs 32
Fig. 7 Isolate Customer Problem Decomposition 37
Fig. 8 Manage Workforce Decomposition 38
Fig. 9 Manage Workforce Staff Decomposition 39
Fig. 10 Manage Workforce Process Decomposition 39
Fig. 11 Problem Handling L4 Processes 43
Fig. 12 Resource Provisioning L4 Processes 44
Fig. 13 Resource Trouble Management L4 Processes 45

TM Forum 2015. All Rights Reserved. Page 6 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

Executive Summary

This document is an Application Note attached to The Business Process Framework

(GB921). It is intended to provide users of the Business Process Framework (eTOM)
with guidelines and information to assist them in applying the Business Process
Framework within their businesses.

At this stage, this document is a work in progress, but is being released as is to

provide information where available, to invite comments and suggestions for further
development, and to attract interest and support for the ongoing work on adding to
the content.

This release addresses one area of, and audience for, guidelines, that concerned
with Practitioners and Process Architects using the Business Process Framework. It
is hoped that other aspects and audiences will also be addressed in future releases.

15.0.1 Release notice

PLEASE NOTE:

Because of the introduction of domains and additional structural changes to the Business
Process Framework, significant amendments to diagrams and text has commenced. It is
expected to be completed in subsequent releases. The interim state may cause
inconsistences in this and other Frameworx documents. Specifically there are known diagram
depictions, term conflicts, and numbering issues that are being addressed.

TM Forum 2015. All Rights Reserved. Page 7 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

1. Introduction

This document explains the design decisions of the Business Process Framework
and sets out the principles for its application and extension in the form of Guidelines.
These Guidelines are of use in two particular cases. First, for the practitioner or
process architect who wants to apply the Business Process Framework in a
consistent way to specific situations. Second, for assurance of auditing and
traceability, in order to produce repeatable application of the Business Process
Framework within an organization and to demonstrate this externally for audit
purposes.

It also provides a basis for contributors to the Business Process Framework and the
evaluation of contributions by the Business Process Framework team. Note that the
concepts in this document have emerged throughout the development lifecycle of the
Business Process Framework itself, and as a consequence, historical design
decisions that are embedded within the Business Process Framework may deviate
from the recommended practice herein that is intended to guide ongoing users of the
Framework. The intent is to converge the practice here with the Business Process
Framework as it is developed further, but users should recognize that this will be an
evolving situation.

It is intended that the guidance in this document will be augmented through user
experience and feedback. A list of outstanding issues is included.

1.1 Audience

The intended audience for the Guidelines is practitioners, process architects, and
process auditors. The material here is advanced material - it is not introductory (as
that information is available elsewhere in the Business Process Framework set).

1.2 Plan of document

The document is set out as follows:

 The principles and positions of the Business Process Framework model
 Process patterns
 Relationship of the Business Process Framework to Frameworx and the
Frameworx elements

TM Forum 2015. All Rights Reserved. Page 8 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

 Business Process Framework and an organization’s own processes

 Guidance for extending and using the Business Process Framework
 Audit checklist

1.3 Principles and Guidelines

The Principles are shown in the following format. Optionally, a Best Practice
Guideline is indicated where a recommendation is made about the way in which the
Business Process Framework should be applied. Requirements for auditing purposes
are also shown in this format.

Principle Business Process Framework.nn

Business Process Framework is ...

TM Forum 2015. All Rights Reserved. Page 9 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

2. Principles and positions of the Business Process

Framework model

2.1 Introduction

This section sets out to position the Business Process Framework as a process
framework and to make explicit the modeling and design choices which have been
followed in its development.

2.2 A note on the status of the

Business Process Framework
documentation

The Business Process Framework consists of both normative and non-normative

material. The normative material is the Standard; the non-normative material is
included for information and guidance. In general, GB921, with its Annexes and
Addenda is normative material; Appendices and Application Notes are non-
normative. Thus, the Process Descriptions in Addendum D, Process Flow Examples
in Addendum F, and public B2B processes in Addendum B are all part of the
Standard; Application Note C on the Public B2B Business Operations Map is non-
normative. Other TMF documents, such as GB939 (Business Services Examples),
which include Business Process Framework material, are non-normative.

There is, however, an important distinction between the Process Elements (PEs),
presented in Addendum D, and the Process Flows, presented in Addendum F. Both
are normative, i.e. part of the Standard, but the Process Elements are comprehensive
in scope while the Process Flows are examples.

2.3 Nature of the Business Process

Framework model

The Business Process Framework is a set of Process Elements, which are organized
into a hierarchical framework. The Process Elements are activity-based and the
Business Process Framework is thus an activity-based process decomposition
model.

TM Forum 2015. All Rights Reserved. Page 10 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

Principle Business Process Framework.01

Business Process Framework is an activity-based process decomposition model.

The Process Elements in the Business Process Framework are intended as an

exhaustive list; they are comprehensive in scope. It is the intent that all business
activities in the Enterprise can be supported by (i.e. are able to fit within) the Business
Process Framework Process Elements. Each Process Element has a detailed
description that can include the purpose, inputs, outputs, interfaces, high level
information requirements and business rules.

Principle Business Process Framework.02

Business Process Framework Process Elements are comprehensive for a Service
Provider.

Note:

The Business Process Framework is a process model, not a state model. It contains
processes, not states. For example, it contains processes for the processes of Order
Handling but does not model the different states of an Order.

2.4 Process model types

In general, there are 3 approaches to the modeling of business processes. It is also

possible to use a hybrid of these approaches. The general approaches are:
 activity-based process modeling
 communication-based process modeling
 artifact-based process modeling

Activity-based process modeling

Here the overall process is decomposed into tasks that are ordered based on the
dependencies among them. The fundamental entity of a business process for the
Activity-based approach is the unit of work and a business process is considered to
be a succession of activities, or units of work, following a specific control flow.

Definition: Activity

An activity represents a unit of work performed by a party or system. Activities

transform inputs into outputs and are associated with triggers and outcomes (pre and
post conditions).

Principle Business Process Framework.03

TM Forum 2015. All Rights Reserved. Page 11 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

A Business Process Framework Process Element is a succession of activities with a

control flow.

Communication-based Process Modeling

In this approach, an action in a process flow is represented by the communication

between a consumer and a provider). In the communication-based approach the
communication is the message. So a business process can be expressed as an
exchange of messages, or transaction, between two or more roles and every state
change within a company can be associated with the processing of a message.

Artifact-based Process Modeling

In the artifact-based approach objects, or artifacts, are created, modified and used
during the process and thus the model is based on work products and their paths
through a series of workflow activities.

Hybrid approach to Process Modeling

The hybrid approach uses a combination of these general approaches to produce a

set of models for an organization’s processes. Typical models might be based on an
information flow model (from the communication-based approach), a capabilities
model (from the artifact-based approach) and a process-model (activity-based
approach).

2.5 Characteristics of a Business

Process

In general, a Business Process will have the following characteristics:

 It has a goal
 It has specific inputs
 It has specific outputs
 It transforms inputs into outputs
 It uses resources
 It has a number of activities that are performed in some order
 It creates value of some kind for the customer. The customer may be
internal or external.

In addition:

TM Forum 2015. All Rights Reserved. Page 12 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

 It may affect more than one organizational unit - “Horizontal organizational

impact”
 Its effects on information entities can be analyzed via CRUD (Create / Read
/ Update / Delete)
 It may have a responsibility model for the roles associated with the process,
expressable as RACI Characteristics (Responsible / Accountable /
Consulted / Informed)

For a Business Process Framework Process Element:

 Goal is stated.
 Inputs may be defined.
 Outputs may be defined.
 Resources consumed may be defined.
 Activities may be specified within description
 Value should be stated.
 Effect on organizational use may be stated
 CRUD analysis may be available
 RACI analysis may be available

Principle Business Process Framework.04

(Best Practice): a Business Process Framework Process Element has a goal, value
proposition, inputs, outputs. It consists of activities and uses resources. It has a CRUD
and RACI model.

2.6 Decomposition

Definition: Decomposition

Decomposition is the breaking-down of a process into simpler activities.

The Business Process Framework is a decomposition model from a notional Level 0

through to Level 3, and beyond (some Level 4 process elements are now defined and
are being incorporated). Additionally, many individual users are developing lower-
level decompositions that extend the Business Process Framework beyond the
industry-agreed level (and in due course these may feedback to extend the level of
industry agreement). In order to keep the Business Process Framework to a level
which is generally useful it is not intended to decompose the Business Process
Framework (i.e. as managed through the TM Forum) indefinitely. It is asserted that
the further a decomposition is taken, the more difficult it is to prove the uniqueness of
lower level processes. However, the level at which it becomes unproductive to extend

TM Forum 2015. All Rights Reserved. Page 13 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

further is not yet clear, and so decomposition continues to proceed in line with the
industry’s priorities and available effort.

Note:

The relationship and mapping of these Business Process Framework Levels to an

organization’s own processes and procedures is addressed in a later section
“Organizational Context for the Business Process Framework”.

Principle Business Process Framework.05

The Business Process Framework is decomposed from notional Level 0 to more granular
levels – Levels 1, 2 and 3 (and some of level 4) are addressed so far. An agreed end-
point (i.e. a level below which decomposition does not proceed) is not yet defined.

Principle Business Process Framework.06

It is not the purpose of the Business Process Framework to address the detailed
processes and procedures of an enterprise.

Principle Business Process Framework.07

Enterprise Management is generally decomposed to Level 2 only (but specific areas that
represent particular priorities have been decomposed further).

2.7 Traceability

Because the Business Process Framework is a decomposition model, the lower

levels of the decomposition can be traced back to the higher levels.

Principle Business Process Framework.08

The goals, inputs, outputs, and activities of decomposed Process Elements at a lower
level are consistent with the higher level Process Element. In particular, the input of the
first lower level Process Element is the same as the input of the higher level PE; the
output from the last lower level PE is the same as the output of the higher level PE; the
detailed goals of the lower level Process Elements taken together should match the goal
of the higher level PE; the activities of the lower level Process Elements taken together
should match the activity of the higher level PE.

2.8 Process dependency through

information

Business processes do not exist in isolation. Processes require information from

other processes, and they in turn provide information to other processes.
Dependencies (or associations) between processes occur when an activity requires
information from another activity. Process dependencies are related to the entities
and attributes required by the business area. The importance of analyzing and

TM Forum 2015. All Rights Reserved. Page 14 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

modeling dependencies is to provide further understanding of the interaction between

processes and data.

Note:

An exercise is underway to identify the Information Framework (SID) ABEs

(Aggregate Business Entities) which are associated with Business Process
Framework Process Elements.

Principle Business Process Framework.09

(Best Practice): each Business Process Framework Process Element should identify its
associated Information Framework ABEs.

2.9 Grouping / organization within

the Business Process Framework

The Business Process Framework is a classification or taxonomy of Process

Elements. At Level 0 the elements are classified into Operations, SIP and Enterprise
Management. Lower Levels are formed by decomposition with each Process
Element occurring once only.

Principle Business Process Framework.10

A particular Process Element will occur only once in the Business Process Framework;
there is no replication.

2.10 Flows

There are three fundamental flows which exist in any company, namely the information
flow, the material flow and the control flow.
 The information flow concerns the flow of data or information e.g. the
information on an order as it is progressed; these can also be message
flows.
 The material flow concerns the actual physical items e.g. the items which
constitute the order.
 The control flow (or workflow) defines the logic of business processes i.e.
the enterprise behavior in terms of a sequence or order in which enterprise
activities must be performed to achieve business objectives.

The definition of the Business Process Framework Process Elements themselves

does not address these types of flow. However the Business Process Framework
does include in Addendum F sample process flows and depictions of process
interaction in swimlanes. These are examples of control flow.

TM Forum 2015. All Rights Reserved. Page 15 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

Principle Business Process Framework.11

Process flow examples in Business Process Framework are control flows, defining the sequence in
which activities are performed.

Note:

Traceability also applies to swimlanes in Business Process Framework process

flows. (See Principle Business Process Framework.08)

Principle Business Process Framework.12

The swimlanes in a process flow are consistent within themselves and with respect to lower level
decompositions.

2.11Dynamic aspects of Process

Modeling

The Business Process Framework Process Elements and example process flows are a
process view of the enterprise behavior, based on sequences of activity. However, there
are also dynamic aspects pertaining to the processes and their interaction. These are
considered below.
 Temporal aspects
 There may be time-based requirements in the triggering of processes,
triggering frequencies and possible delays between process steps.
Process step durations (minimum, maximum, average durations) can
also be indicated
 Co-operative activities
 In practice, it is common that two or more activities of two different
processes must work co-operatively, e.g. to exchange messages or
objects. Methods include message passing and patterns.
 Process communication
 In the case where processes must communicate, this means that
some activities of one process must interact with activities of other
processes. The previous mechanisms for co-operative activities can
be used.
 Process synchronization
 Process synchronization can happen in three different forms: (1)
synchronization by events, (2) synchronization by messages and (3)
synchronization by object flows.
 Exception handling mechanisms
 Process models often only model the ideal structure of a business
process. Real-world situations mostly consist of dealing with
exceptions. Exceptions can either be predictable or unpredictable.

TM Forum 2015. All Rights Reserved. Page 16 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

Principle Business Process Framework.13

Business Process Framework models success scenarios. Error conditions are not in
scope.

Principle Business Process Framework.14

Dynamic aspects of process modeling are outside the scope of the Business Process
Framework.

2.12 Naming conventions

The preferred convention for naming Level 3 Process Elements is <Verb Noun> e.g.
“Configure & Activate Resource”, “Determine pre-order feasibility”, “Close Problem”.
This is also the preferred convention for naming Process Elements at lower levels of
decomposition (i.e. Level 4 and below)

The preferred convention for naming events is <Noun Verb> e.g. “Work Orders
Executed”, “Resource Allocation & Configuration Done”.

Note: Level 1 and Level 2 Process Names have not in the past used the convention
above. Renaming existing Level 1 and Level 2 process elements is seen as
unnecessarily disruptive and so the existing form (typicallly, <Noun> e.g. “Supplier /
Partner Relationship Management”, “Order Handling”) has been retained. New or
modified process elements at Level 1 and/or Level 2 should continue to use this
existing convention, so that there is consistency in the naming within a Level

Principle Business Process Framework.15

Terminology and naming conventions are <Noun> for Level 1 & 2 Process Names, <Verb
Noun> for Level 3 Process Names, <Noun Verb> for events
.

2.13 Layer References and

Responsibilities

A layered approach to the handling of responsibilities and information is taken in the

Business Process Framework. Responsibility for association / translation between
layers is generally positioned at the lower layer. For example, the Customer
Relationship Management (CRM) layer manages Customer Problems and the
Service Management & Operations (SM&O) layer manages the Service Problems
that may be associated, but it is the responsibility of the SM&O processes to map
between these Service Problems.

Thus CRM provides the Customer Problem (or some appropriate information from
this) to SM&O, which must then associate the one (or more) Service Problems that
derive from this Customer Problem. Any ongoing interaction between Customer and

TM Forum 2015. All Rights Reserved. Page 17 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

Service layers is therefore in terms of Customer Problems (or information based on

these) and not Service Problems, which are managed wholly within the Service layer.

Principle Business Process Framework.16

Responsibility for association / translation between layers is generally positioned at the
lower layer.

2.14 Data Responsibility

The process which is managing data creation, update etc. has a prime responsibility
for ensuring that the results of data which it is manipulating via the process are
appropriately stored.
Principle Business Process Framework.17
A process has prime responsibility for ensuring that the results of data manipulation are
stored appropriately.

Consequently, the Manage Resource Inventory processes have no processes to

create or update the data elements maintained in the repository.
Principle Business Process Framework.18
The Manage Resource Inventory processes have no processes to create or update the
data elements maintained in the repository.

The only exception to this Principle is the aspect associated with data quality. In the
inventory processes there are processes associated with discovery i.e. looking at
comparing what is maintained in the inventory with what actually exists on the
ground. The results of any inventory differences found would be in the form of some
form of report, which could be used by process quality processes to review and fix
any processes which are leading to bad data in the inventory. Note: there is no need
for any “informing” of the original process as to data change.

TM Forum 2015. All Rights Reserved. Page 18 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

3. Process Patterns

3.1 Introduction

In this section are presented examples of decomposition patterns in the Business

Process Framework. These patterns serve as templates for process modeling in the
particular process area. Patterns are identified at Level 3 for:
 Problem Reports and their resolution
 Strategic view and Business Plan
 Order Lifecycle
 Product Lifecycle
Note:

All Patterns should have associated Use Cases. Use Cases will be added in a later
version of the document.

3.2 Level 3 patterns

Example 1 – Problem Reports and their resolution

Applicable to ASSURANCE: Problem Handling / Service Problem Management /

Resource Trouble Management.

This pattern consists of 4 process steps and 2 continuous processes. The process
steps are:
 “Create”. E.g. Problem Report, Trouble Report, Resource Trouble.
 “Analyze”. Diagnose root cause.
 “Fix”. Correct & Recover through recovery activities.
 “Close”. Problem resolved, close report.

With 2 processes running continuously:

 “Track & Manage recovery activities”

TM Forum 2015. All Rights Reserved. Page 19 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

 “Report”

Pre-condition / Inputs to this pattern are: a reported problem or an alarm or event at

resource or service level.

Post-condition / Output is: resolved problem, restoration of normal operation.

Associated Use Case:

Example 2 – Strategic view and Business Plan

Applicable to STRATEGY & COMMIT: Service Strategy & Planning / Resource

Strategy & Planning / Supply Chain Strategy & Planning

This pattern consists of 6 processes.

 “Research”. Research & analyses, including management of research
gathering.
 “Strategy”. Formulate strategy and business goals
 “Business Plans”
 “Operational support.”
 “Partnership.” (Null step for Supply Chain)
 “Commit.” Gain Enterprise commitment.

Pre-condition / Inputs to this pattern are research, forecasts

Post-condition / Output are committed business plans and strategy.

Associated Use Case:

Example 3 – Order Lifecycle

Customer Orders, Service Orders and Resource Orders through to Closure. “Track
and Manage” and “Reporting” run continuously.

Associated Use Case:

Example 4 – Product Lifecycle

From Research and New Product Development through In Service to Retirement.

Associated Use Case:

TM Forum 2015. All Rights Reserved. Page 20 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

3.3 Level 4 Patterns

Later issues of the document will show how the Pattern approach can be extended to
Level 4. Note that these are guidelines, they do not prescribe or mandate Level 4.

TM Forum 2015. All Rights Reserved. Page 21 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

4. Organizational Context for the Business Process

Framework

4.1 Introduction

This section sets out the enterprise context for process modeling, and the ways in
which the Business Process Framework is applied. This section is not a guide on how
to do process modeling in an organization, rather it sets out a generic framework for
the various types of process (including manual human procedures) within a typical
enterprise and shows how the Business Process Framework can be related to those
organizational processes.

4.2 Use of the Business Process

Framework within an organization

The use of the Business Process Framework by organizations involves the extension
and refinement of the Business Process Framework to meet the specific business,
operational, system and deployment needs of the organization.

This section is based on the following view of how processes are developed and
modeled within organizations, and the relationship of the process models to
organization structures and systems developments.

TM Forum 2015. All Rights Reserved. Page 22 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

What Who (role) How

Level 0
Business Enterprise
Activities Activities Objectives Scorecard

Level 1
Process Process Groupings Ownership
Services
Groupings

Level 2
Core Processes Core Processes Delivery Units Products

Level 3 Contracts
S ystem
is predecessor of

is predecessor of
CS/R3

subsumes
I/F
R/3
SD

subsumes

CS/R3-1 CS/R3-2 CS/R3-3

Business Process Create

Contract
SD
Inquiries
Maintain
Contract
subsumes

SD
Quotations
Close
Contract
SD
S ales Orders

Flows Processes Delivery Teams Systems

Level 4
Operational
Process Flows Sub Processes Roles System Functions

Level 5
Detailed Process Detailed Processes Detailed Roles Transactions
Flows

Fig. 1 Process Hierarchy

PLEASE NOTE: As of release 14.5 of Frameworx it is acceptable for a core process

to decompose to other core process. Thus multi level core processes are being
added to the Business Process Framework.

Level 0 – Business Activities

Identify and model: business objectives, value streams, environmental and fiscal
constraints; develop balanced scorecard and product lines. These are the business
goals that process and systems solutions must deliver.

Level 1 – Process Groupings

Design: product structure, product delivery and support process chains, enterprise-
level data model, organizational structure. Identify business knowledge. This is the
functional structure that delivers your business.

Defines different views of how processes are structured to deliver the Business
Activities at Level 0.

Processes may be structured from:

TM Forum 2015. All Rights Reserved. Page 23 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

 A process execution perspective showing standard end-to-end

processes (e.g. Service Fulfillment)
 A functional perspective (e.g. Enterprise Value Domains).

Level 2 –Core Processes

Identify industry standard reference models; develop: generic processes, process

hierarchy; identify and model business data definitions, system structure; define
business roles. Processes are the key to delivering business objectives.

Recognizable sub-process of End-to-End Processes:

 Normally carried out within a Business Unit or Line of Business
 Defines those activities that deliver competitive advantage to business.
As distinct from supporting processes.
 Normally modeled as Value Chains
Comprised of Tasks that are defined in detail in the Business Process Flows at Level
3.

PLEASE NOTE: As of release 14.5 of Frameworx it is acceptable for a core process

to decompose to other core process. Thus multi level core processes are being
added to the Business Process Framework.

Level 3 – Business Process Flows

Design detailed processes; assign business roles; identify supporting systems, data
flows. Map business data models to systems data models. Consider failure paths;
queues and bottlenecks. The detail is essential to ensure every action adds value to
the business (which means to the customer) or is an essential requirement. Apply
Lean Engineering techniques.

Defines the process flows of the Core Processes defined at Level 2.

 Comprised of Tasks
 Normally defined generically (i.e. not specific to a particular product,
customer, geographical operation, etc.).
 Often will only show the 'Sunny Day' scenario and exclude the detail of
alternative actions, failures and error recovery.
Tasks can be decomposed into more detail if required in Level 4 Operational Process
Flows.

Level 4 – Operational Process Flows

Develop detailed sub-process design; define operational roles; link processes to

written procedures; identify detailed systems, equipment and resource usage.

Defines in more detail the Business Process Flows defined at Level 3.

TM Forum 2015. All Rights Reserved. Page 24 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

Normally specific to an operational environment and will be characterized by the

Application Systems and Organizational Units or Positions that support and execute
them.
 Comprised of Steps
 Normally will include the 'Rainy Day' scenario showing the detail of
alternative actions, failures and error recovery.
Steps can be decomposed into more detail if required in Level F Detailed Process
Flows.

Level 5 – Detailed Process Flows

Deliver the process flow automatically through workflow systems, e-business

solutions and systems development. Link process and data models to systems and
software development environments.

Defines in more detail the Operational Process Flows defined at Level 4.

 Comprised of Operations.
 Specific to an operational environment and will be characterized by the
Application Systems and Organizational Units or Positions that support and
execute them.
 Should include the 'Rainy Day' scenario showing the detail of alternative
actions, failures and error recovery.
 Any further detail required of an Operation will be described in a
Procedure document or Work Instruction.
May be used to generate Workflows or be used a detailed requirements for systems
development.

4.3 The Business Process Framework

and the Process Hierarchy

The TMF Business Process Framework in its analysis has addressed the concerns
shown in Level 0 through to Level 3, and now is moving to address Level 4 in
selected areas.

However the concerns for lower levels than are documented in the Business Process
Framework need to be addressed by an enterprise itself in implementing concrete
detailed processes, roles and transactions.

For such extensions to the Framework by an enterprise, the following section

provides guidance on how an enterprise should execute these analysis steps. The
benefit of these guidelines is that different enterprises will use a similar analysis
approach to applying the Business Process Framework to their own organization.

TM Forum 2015. All Rights Reserved. Page 25 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

5. Guidance for extending and using the Business

Process Framework

Because of the introduction of domains and additional structural changes to the Business Process
Framework, significant amendments to diagrams and text has commenced

5.1 Process Hierarchy:

Decomposition Principles

Meta Model structure,

Six-Level Process Hierarchy Meta Level methodology and modelling
standards
Defines business activities
Process Levels Business Levels

Level 0 Distinguishes operational customer

oriented processes from management
Business Activities and strategic process

Shows groups of related

Level 1 Logical business functions and standard
Process Groupings Levels end-to-end processes (e.g.
Service Streams)
Level 2 Core processes that combine
together to deliver Service
Core Processes Streams and other end-to-end
processes
Level 3 Decomposition of core
processes into detailed
Business Process Flows ‘success model’ business
process flows
Detailed operational
Operations Levels

Level 4 Physical process flows with error

Operational Process Flows conditions and product and
Levels geographical variants
(where required).
Level 5 Further decomposition of
Detailed Process Flows detailed operational where
required

Fig. 2 Process Hierarchy and analysis focus for Levels

This diagram provides a more extended description of the 6 level decomposition

model. It shows the focus of analysis for each of the levels. Note that in practice each
level may have several layers of decomposition to deal with practical issues of

TM Forum 2015. All Rights Reserved. Page 26 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

handling complexity and scale. The test of what is in a Level is the focus of the
analysis.

The Business Process Framework has effectively produced an industry analysis of

the process decompositions down to level 3 that provides both core processes and
example process flows in the form of success models.

5.2 Process Hierarchy: Implementation

Principles

Implementation
Processes vary in complexity, importance and
Level 0 their requirement for detailed modelling.
Business Activities
Procedural documentation that describes manual
Level 1 implementation of a process may be applicable at
any appropriate level from Level D downwards
Process Groupings

Level 2
Enactment of a process through an IT or
Core Processes Workflow System requires more detailed
modelling including error conditions and
Level 3 must be applied at Level E or Level F
Business Process Flows

Level 4 Procedural
Operational Process Flows
Definitions System
(manual) Specific
Level 5 Implementation
Detailed Process Flows
Definitions

Fig. 3 Process Hierarchy Implementation

TM Forum 2015. All Rights Reserved. Page 27 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

5.3 Process Hierarchy:

Hierarchies

Hierarchies

Level 0 Process-related information

Business Activities visualised in a hierarchical manner

Level 1

Roles & Responsibilities

Measurement and KPIs

Process Groupings

Level 2

Business Interfaces

Business Information and

Core Processes

Product Lines
Level 3

Operational Support
Business Process Flows

Data

Systems
Level 4
Operational Process Flows

Level 5
Detailed Process Flows

Fig. 4 Process Hierarchy hierarchies

This diagram shows those attributes and characteristics that have to be in lock step
throughout the decomposition steps.

TM Forum 2015. All Rights Reserved. Page 28 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

5.4 Process Hierarchy: Process View

Process View

Process Levels Business Levels

Level 0 Business
Business Activities Activities

Level 1 Value Domains

End-to-End Service Streams
Process Groupings Business Functions Enabling Streams
Processes Process Service Lines

Level 2
Core Processes Core
processes

Level 3 Tasks
Business Process Flows Processes

Operations Levels
Level 4 Steps
Operational Process Flows Sub Processes Resources

Level 5 Operations

Detailed Process Flows Detailed Processes Detailed Resources

Fig. 5 Process Hierarchy: Processes and Resources

This figure shows a view of how processes are developed through the decomposition
steps.

TM Forum 2015. All Rights Reserved. Page 29 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

6. Decomposition Guidelines

Before providing a set of decomposition guidelines the properties of a process are

provided. Each framework process may have one or more of these properties. As
enterprise specific extensions are made to the framework, these properties should
become part of the overall specification of the added processes.

A process specification consists of

 A stated goal that the process achieves

in terms of a purpose or result from applying the process

 Inputs that may be defined

 Outputs that may be defined

Note that inputs transform to outputs through the process
functionality/behavior

 Resources consumed that may be defined

Note for the Business Process Framework, resources may be defined
through linkages with the Information Framework

 Activities into which the process decomposes that may be defined

These may be embedded in the process description

 A stated or implied value/benefit within the business

May be related to how the process is used within a particular
enterprise

 Create, Read, Update, Delete (CRUD) analysis that may be available

This can link with the Information Framework

 Responsible, Accountable, Consulted, Informed (RACI) analysis that may

be available
Typically, this is related to how processes are mapped into
organizations

 Key Performance / Quality Indicators (KPIs/KQIs)

These characteristics apply to all levels including extensions and should be included
in the definition/description of the process.

TM Forum 2015. All Rights Reserved. Page 30 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

A process transforms inputs into outputs. The activities into which it decomposes are
performed in some order. The value is created for the customer. The customer may
be internal or external.

6.1 Consistency of Inputs and Outputs

The goals, inputs, outputs, and activities of a decomposed process at a lower level
are consistent and should match those of the higher level process, specifically:

 The goals, scope and content of the lower level processes taken together
should match those of the higher level process

 Each input of the higher level process is the same as an input of a lower
level process

 Each output of the higher level process is the same as an output of a

lower level process

 The activities/behavior of the lower level processes taken together should

match that of the higher level process

This ensures the consistency between process extensions to the framework and its
further decomposition. “First” and “last” mean the first and last in a sequence of
process execution. The Problem Handling example previously described illustrates
this.

Customer Problem is input to the L3 process Isolate Customer Problem. It is also

input to the first L4 process, Verify Proper Product Use, into which Isolate Customer
Problem decomposes. The Root Cause of the Customer Problem is output from the
last L4 process, Provide Problem Analysis Completion Notification, It is also output
from Isolate Customer Problem. Note that this does not imply that these are the only
inputs and outputs of the Isolate Customer Problem process or the processes into
which it decomposes. This is particularly true when dealing with higher level
processes, such as L2 processes.

TM Forum 2015. All Rights Reserved. Page 31 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

Customer Problem

Problem Handling
Isolate Customer
Problem
Customer Problem
Root Cause
Root Cause Notification
Notification Provide
Close Customer
Problem
Verify
IsolateProper
Customer
Product
ProblemUse Problem Report
Analysis Completion
Notification

PerformCustomer
Report Product - Track
Identify&Customer
Manage
ProblemDiagnostics
Related Customer Problem
Problem Root Cause

Fig. 6 Consistency of Inputs and Outputs

6.2 Additional Decomposition Guidelines

The Business Process Framework represents a non-redundant decomposition;

therefore, a process is not duplicated within the framework.

Two different conventions are used for naming Business Process Framework
processes. Nouns, often nouns and/or gerunds (a noun form of a verb), such as
Service Management and Operations, Fulfilment, Billing, Problem Handling are used
for L1 and L2 processes. This convention indicates a higher level process that is a
combination of tasks (L3). The <verb noun> convention are used for processes that
represent more discrete processes, such as tasks (L3), steps (L4), and operations
(L5). Note that L3, L4, L5 refer to the levels within a process hierarchy and that there
may be multiple levels of Business Process Framework process that represent a
given process hierarchy level. A bit confusing, but the focus of the Business Process
Framework process must be considered when classifying a Business Process
Framework process within the levels of a process hierarchy.
Association/translation between process layers, horizontal Business Process
Framework processes, is the responsibility of the lower layer. For example, the
interaction from Problem Handling to Service Problem Management is expressed in
terms a Customer Problem Report. It is the responsibility of Service Problem
Management, not Problem Handling, to create the Service Problem Report(s) and
associate the Report(s) to the Customer Problem Report. This in part helps ensure
that the lifecycle of the entity is managed by a single L2 process and is not split
among more than one L2 process.

TM Forum 2015. All Rights Reserved. Page 32 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

The process which manages data creation, update, and so forth has a prime
responsibility for ensuring that the results of data which it is manipulating via the
process are appropriately stored.

When decomposing a process to L3 or to L4, and sometimes below L4, it is helpful to

think of the next level of decomposition in terms which represents “life cycle”
decomposition. Life cycle decomposition is a technique to use when identifying
processes that move an object/entity through its life of interest to the business. L3/L4
processes, each of which represents the task level within the process decomposition,
naturally focus on a single state in the life cycle of an object/entity. Typical processes
in the decomposition perform “Plan”, “Acquire”, “Use”, “Dispose” tasks. The set of
tasks is typically made up of those that plan to uses an object/entity, which acquires
an object/entity, which uses an object/entity, and which disposes of an entity. Note
that life cycle decomposition is just one of the many techniques described here which
may be used to identify lower level process elements.

The lifecycle often depends on the category of entity. Plan, Acquire, Use, Dispose
processes may take on names specific to the type of entities/objects upon which they
act. Shown below are some examples of the names associated with different
categories of entities.

Tangible oriented entities, such as products, services, and resources may have the
following life cycle related processes:

 Gather/analyze

 Develop

 Deploy

 Assess

 Retire.

Intangible oriented entities, such as strategies and plans may have the following life
cycle related processes:

 Research/analyze

 Formulate/prepare

 Approve/commit

 Assess

 Retire.

Activity oriented entities, such as orders and problems may have the following life
cycle related processes:

 Issue/Create

TM Forum 2015. All Rights Reserved. Page 33 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

 Analyze/diagnose

 Fix, monitor, correct

 Close.

Note that the actual decomposition may only consist of a subset of these types of
activities. There are many examples of this type of decomposition in the framework.

Note also that while products and services are intangible entities, they are typically
realized by in part some type of physical (tangible) resource. The first set of sample
process names represents processes that appear in the Product Lifecycle
Management L1 vertical process grouping; the second set represents processes that
appear in the Strategy & Commit vertical process grouping. The third set represents
processes associated with activity-oriented entities that span Fulfilment and
Assurance.

For example, the decomposition of the L2 Problem Handling includes Create

Customer Problem Report (Acquire), Correct & Recover Customer Problem (Use),
and Close Customer Problem Report (Dispose) represents processes that appear in
the Assurance L1 vertical process grouping. In this example there is no equivalent for
the Plan process.

Below L2, beware “/”, “&”, and their variants in process names, which typically means
process should be split. Although the Business Process Framework does not always
follow the last guideline, processes whose names imply more than one process, such
as Implement, Configure, and Activate Service could be split into three processes at
the next level of decomposition. Processes such as these are often combined at a
given level of decomposition to manage the number of processes that appear at that
level.

6.3 Information Framework Related Guidelines

These guidelines were developed as the Business Process Framework/Information

Framework mapping team defined actions taken by processes on SID entities and as
the team began to identify L4 processes.

An Aggregate Business Entity (ABE) is a group of closely related (cohesive) entities,

such as Customer Problem Report and Service Order. A L2 process manages the life
of a small number of ABEs. For example, Service Configuration & Activation
manages the life of the Service Order and Service ABEs as defined by the published
Business Process Framework/Information Framework L2 to ABE mappings. Problem
Handling manages the life of a Customer Problem Report. The L3 processes focus
on states within the life cycle of an ABE. For example, Issue Service Order focuses
on the creation state; Close Service Order focuses on the completion state. A similar
relationship exists for the L3 processes that define Problem Handling. Lower level
processes deal with managing the states of the entities associated with the L3
processes and no others.

TM Forum 2015. All Rights Reserved. Page 34 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

A process in one domain, such as Customer, Product, Service, does not create
instances of entities in another domain. This guideline follows on from the layers
guideline. For example, Problem Handling does not create instances of Service
Problem Report. Similarly, Order Handling does not create instances of Service
Orders. The two L2 processes reside within the CRM L1 horizontal process and
focus on Market/Sales, Customer and Product domains, while Service Problem
Report and Service Order are Service domain entities.

6.4 Semantic Analysis

In linguistics, semantic analysis is the process of relating syntactic structures, from

the levels of phrases, clauses, sentences and paragraphs to the level of the writing as
a whole, to their language-independent meanings, removing features specific to
particular linguistic and cultural contexts, to the extent that such a project is possible.
The elements of idiom (a fixed distinctive expression whose meaning cannot be
deduced from the combined meanings of its actual words) and figurative speech,
being cultural, must also be converted into relatively invariant meanings.

Semantic analysis is much like sentence diagramming that we all learned at an early
age. The descriptions of L3 processes can be used and analyzed to begin identifying
L4 processes.

This is accomplished by performing semantic analysis on the description of a

process:

 Look for nouns (entities) upon which actions are performed

 Look for verbs that act on nouns (entities)

 Look for phrases that imply actions on nouns (entities).

Caution: Verbs and phrases may represent processes in other areas of the
framework that interact with the processes being identified.

Semantic Analysis should be considered as just another of the many techniques

described in this section that can be used to decompose processes. The techniques
can be viewed as supplemental to the techniques currently in use within an
organization. Often, Semantic Analysis is carried out iteratively with other techniques
and may result in updating the description of a process to which Semantic Analysis
was originally applied. The goal would be that the final decomposition(s) are
consistent with the parent process description(s) from a Semantic Analysis viewpoint.

TM Forum 2015. All Rights Reserved. Page 35 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

For simple L3 processes whose description is brief, such as Close Service

Performance Degradation Report and Audit Data Collection & Distribution,
decomposition to L4 may not be possible. Their descriptions are included here to
illustrate this point.

Close Service Performance Degradation Report - The objective of the Close Service
Performance Degradation Report processes is to close a service performance
degradation report when the service performance has been resolved. These
processes monitor the status of all open service performance degradation reports,
and recognize that a service performance degradation report is ready to be closed
when the status is changed to clear.

Audit Data Collection & Distribution - The Audit Data Collection & Distribution
processes are responsible for auditing the management information & data collection
activities in order to identify possible anomalies such as loss of management
information and/or data in the different collection, processing and distribution steps.

Decomposing From L3 Description Example 1 – Isolate Customer Problem

Isolate Customer Problem is the L3 process being decomposed.

The purpose of the Isolate Customer Problem processes is to identify the root
cause of the customer problem. The responsibilities of these processes include, but
are not limited to:

· Verifying whether the customer is using the purchased product offering

correctly; and

· Performing diagnostics based on the customer provided information to determine

whether the root cause of the customer problem is linked to the underlying services.

The Isolate Customer Problem processes will make the results of the root cause
analysis available to other processes. The Isolate Customer Problem processes will
update open customer problem report, as required during the assessment, and when
the root cause has been identified. The Isolate Customer Problem processes will
notify the Track & Manage Customer Problem processes when the analysis is
complete.

The highlighted text represents the candidate L4 processes using the semantic
analysis guidelines described previously in this section. Not all of the description
resulted in candidate L4 processes. Some were used as part of the description of the
L4s or represent the initiation of flows to other processes. For example, the
notification to Track & Manage Customer Problem is defined using a flow to that
process; updating the open Customer Problem Report is also accomplished by
initiating a flow to Track & Manage Customer Problem.

Note that all the nouns (entities) deal with the Customer Problem ABE and its entities,
such as Root Cause.

TM Forum 2015. All Rights Reserved. Page 36 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

Figure 3.5 - Isolate Customer Problem Decomposition shows the resulting

decomposition diagram for Isolate Customer Problem. Some of the processes
names represent interpretations that were made based on the analysis of the Isolate
Customer Problem description. All of the L4 processes deal with the “isolate” state of
the Customer Problem.

The Provide Problem Analysis Completion Notification implies a flow to another

process, such as Track & Manage Customer Problem L3 or an L4 process within the
Track & Manage decomposition.

Problem Handling
Isolate Customer
Problem

Verify
IsolateProper
Customer PerformCustomer
Report Product - Track & Customer
Identify Manage Provide
Close Customer
Problem
Product
ProblemUse ProblemDiagnostics
Related CustomerRoot
Problem Problem
Cause Problem Completion
Analysis Report
Notification

Fig. 7 Isolate Customer Problem Decomposition

Below are examples of L4 process descriptions. The descriptions of the L4

processes were based on the description of the L3 process. These L4 process
represent the lowest level to which the current Isolate Customer Problem can be
decomposed. Later in this chapter we will discuss how processes can be extended
using this same technique of starting with an extended description of a process.
Other guidelines for extending the framework will also be provided.

 Verify Proper Product Use

Verify that the customer is properly using the product.

 Perform Product-Related Diagnostics

Perform diagnostics based on the customer provided

information to determine whether the root cause of the customer
problem is linked to the underlying services.

 Identify Customer Problem Root Cause

Identify the root cause of the customer problem. Make the

results of the root cause analysis available to other processes.
Update open customer problem report, as required during the
assessment, and when the root cause has been identified.

 Provide Problem Analysis Completion Notification

TM Forum 2015. All Rights Reserved. Page 37 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

 Provide notification of the completion of problem analysis

Decomposing From L3 Description Example 2 – Manage Workforce

Manage Workforce is the L3 process being decomposed. Note that this description is
from the 7.0 release of the Process Framework. The analysis was used to develop
the next level of decomposition and update the descriptions in release 7.5.

The responsibilities of the Manage Workforce processes are twofold - plan, assign,
dispatch and manage the activities of staff (directly or indirectly) employed by, or
operating as part of, the enterprise (i.e. technicians, clerks, managers, etc.), and
monitoring, managing and reporting on the capability of the Manage Workforce
processes. The staff directly managed by these processes include all employees,
contractors and who are paid by the enterprise. The staff indirectly managed by
these processes includes all employees, consultants and contractors paid by third
parties who have commercial arrangements with the enterprise. In the cases where
the third parties own and manage the service and/or resource infrastructure the
Manage Workforce processes are responsible for requesting activities to be
performed rather than directly assigning specific staff. The Manage Workforce
processes also enable reporting and monitoring of assigned activities.

This first part of the description and can be used to identify two L4 processes and a
number of L5 processes before moving on to the remainder of the description. The
L4 processes were based on the statement that the “processes are twofold” in the
first line of the description above, one group of processes that deals with workforce
staff and another group of processes that deal with the workforce processes. The L5
processes were based on the other highlighted text.

The candidate decompositions are shown on the next figures, followed by examples
of L4 and L5 process descriptions.

Manage Workforce Decomposition

Shown here is the L3 process, Manage Workforce, along with its two L4 processes,
Manage Workforce Staff and Manage Workforce Process.

Problem Handling
Isolate Customer
Manage Workforce
Problem

PerformCustomer
Report Product - Track
Identify& Customer
Manage
Manage Workforce
Problem Manage Problem
Customer Workforce
Related Diagnostics Problem Root Cause
Staff Process

Fig. 8 Manage Workforce Decomposition

TM Forum 2015. All Rights Reserved. Page 38 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

Manage Workforce Decomposition

Shown here is the Manage Workforce Staff L4, with its six L5 processes, derived from
the first part of the Manage Workforce L3 process description. Descriptions for these
processes will be derived from the remainder of the Manage Workforce process.

Manage Workforce
Problem Handling
Staff

Plan Workforce
Isolate CustomerStaff Assign Workforce
Report Customer Staff Dispatch
Track & Manage
Workforce Manage
Close Customer
Workforce Staff
Activity
Problem Activity
Problem Staff
Customer Problem Activity
Problem Report

MonitorCustomer
Create Workforce CorrectWorkforce
Report & RecoverStaff
Assigned Activity
Problem Report Activity Problem
Customer

Fig. 9 Manage Workforce Staff Decomposition

Manage Workforce Process Decomposition

Shown here is the Manage Workforce Process L4, with its three L5 processes,
derived from the first part of the Manage Workforce L3 process description.
Descriptions for these processes will be derived from the remainder of the Manage
Workforce process.

Manage Workforce
Problem Handling
Process

MonitorCustomer
Isolate Workforce ManageCustomer
Report Workforce Report&Workforce
Track Manage
Process
Problem Capability Process
Problem Capability Process
CustomerCapability
Problem

Fig. 10 Manage Workforce Process Decomposition

Decomposing From L3 Description

This section contains the remainder of the Manage Workforce L3 process description.
The descriptions of the L5 processes can be based on this part of the description.
The fragment of the description below can be used to derive descriptions for Manage

TM Forum 2015. All Rights Reserved. Page 39 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

Workforce Staff L4 processes. For example, the first, second, and fifth bullets above
will be used to describe the Plan Workforce Staff Activity L5, and the third, fourth, and
sixth will be used to describe the Assign Workforce Staff Activity L5.

In fact, these descriptions can be used to develop L6 processes. For example,

Establish Work Assignment Queue, Establish Staff List, and Forecast Assignable
Staffing Requirement are L6 processes for Plan Workforce Staff Activity; Establish &
Distribute Workforce Assignment, Establish Re-Assignment Capability, and
Determine Work Activity Estimate are L6 process for Assign Workforce Staff Activity.
Brief descriptions can also be derived for these L6 processes from the text.

Note that descriptions may not be derivable for all L4 or L5 processes. For example,
no description could be found for Dispatch Workforce Staff. The description would
have to be developed.

Continuation of description…

Responsibilities of these processes include, but are not limited to:

· Establishing and managing work assignment queues through which requests for
work activities are received from Business Process Framework processes;

· Establishing and managing staff lists, containing details about assignable staff such
as location, skills, availability for assignment etc.;

· Establishing, managing and distributing individuals work assignments to staff

outlining the daily, or other time breadth, work assignments;

· Establishing and managing fast-track and jeopardy re-assignment capabilities to

allow for modification of work assignments as required to meet jeopardy or other high
priority conditions;

· Forecasting assignable staffing requirements on a daily, weekly and longer period

basis, based on historic work volume records, and forecast activity volumes;

· Determining work activity time estimates for all known work activities, based on
actual historic results or on forward estimates, to be used as a parameter for
scheduling work rosters;

· Establishing and managing recall capabilities to allow for out-of-hours staff recall in
the event of unforeseen circumstances;

The remainder of the Manage Workforce L3 process description follows. The

descriptions of the L5 processes will be based this part of the description. This
description can be used to derive descriptions for Manage Workforce Process L4
processes. For example, the first, second, and third bullets above will be used to
describe the Manage Workforce Process Capability L5, and the fourth and fifth will be
used to describe the Monitor Workforce Process Capability L5.

TM Forum 2015. All Rights Reserved. Page 40 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

The descriptions can be also used to develop L6 processes. For example, Manage
Registration & Access Control Process, Establish Workforce Information Transfer,
and Ensure Accuracy of Workforce Management Systems are L6 processes for
Manage Workforce Process Capability; Track & Monitor Workforce Management
System Usage and Identify Workforce Management System Shortfall are L6 process
for Monitor Workforce Process Capability. Brief descriptions can also be derived for
these L6 processes from the text.

Note that descriptions may not be derivable for all L4 or L5 processes. For example,
no description could be found for Report Workforce Process Capability. The
description would have to be developed.

Continuation of description…

-- Managing the registration and access control processes that enable processes to
create, modify, update, delete and/or download scheduling and work assignment data
to and from the workforce management system(s);

· Establishing and managing information transfer between the enterprise workforce

management system(s) and those of external third parties (when the infrastructure is
owned and operated by third parties);

-- Ensuring workforce management system(s) accurately captures and records all

assignment and work scheduling details, through use of automated or manual audits;

· Tracking and monitoring of the usage of, and access to, the workforce management
system(s) and associated costs of the Manage Workforce processes, and reporting
on the findings;

Identifying any technical driven shortcomings of the workforce management

system(s), and providing input to Resource Development & Management processes
to rectify these issues.

L4 Process Description Examples

The descriptions of the L4 processes were based on the description of the L3

process. These L4 and L5 (and possibly L6 as described in the previously)
processes represent the lowest level to which the current Manage Workforce can be
decomposed. Later in this chapter, as mentioned earlier, we will discuss how
processes can be extended using this same technique of starting with an extended
description of a process. Other guidelines for extending the framework will also be
provided.

TM Forum 2015. All Rights Reserved. Page 41 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

 Manage Workforce Staff (L4)

Plan, assign, dispatch and manage the activities of staff (directly or indirectly)
employed by, or operating as part of, the enterprise (i.e. technicians, clerks,
managers, etc.). The staff directly managed by these processes include all
employees, contractors and who are paid by the enterprise. The staff indirectly
managed by these processes includes all employees, consultants and contractors
paid by third parties who have commercial arrangements with the enterprise.

In the cases where the third parties own and manage the service and/or resource
infrastructure the Manage Workforce processes are responsible for requesting

 Plan Workforce Staff Activity (L5)

Establishing and managing work assignment queues through which requests for work
activities are received from Business Process Framework processes. Establishing
and managing staff lists, containing details about assignable staff such as location,
skills, availability for assignment etc. Forecasting assignable staffing requirements on
a daily, weekly and longer period basis, based on historic work volume records, and
forecast activity volumes.

Other L3/L4 Decomposition Examples

This example illustrates the current L3/L4 process decomposition work being
undertaken by the Business Process Framework/Information Framework mapping
team. The example illustrates the work accomplished for the L3 processes for the L2
Problem Handling process. Inputs and outputs were derived from the descriptions
and implied actions on entities contained in the descriptions of the L3 processes.
These, along with semantic analysis, discussed earlier in this chapter, were used to
deduce the candidate L4 processes that will make their way into the framework.

The Inputs and outputs can be used to construct/confirm L3 and L4 process flow
diagrams. This process shows the work done that resulted in the Problem Handling
decompositions.

TM Forum 2015. All Rights Reserved. Page 42 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

L3 Process Name Input Information Output Information Candidate L4

Processes
Create Customer I-1) Customer O-1) Customer Problem
Problem Report Information Report
I-2) Customer/ Process O-2) Customer Problem
Request Report

Isolate Customer I-1) Customer Problem O-1) Product Use Verify Proper Product
Problem Verification Use
I-2) Customer Problem O-2) Product-Related Perform Product-
Diagnostic Results Related Diagnostics
I-3) Customer Problem O-3) Customer Problem Identify Customer
I-4) Problem Related Root Cause Problem Root Cause
Diagnostic Results

I-5) Customer Problem O-4) Customer Problem Provide Customer

I-6) Customer Problem Analysis Completion Problem Analysis
Root Cause Notification Completion
Notification

Report Customer I-1) status of O-1) notifications of any

Problem CustomerProblemRep changes and
ort management reports
O-2) Specialized
Fig. 11 Problem Handling
summaries L4ofProcesses
the
efficiency and
effectiveness of the
overall Problem
Handling process
I-2) Problem, root O-3) Reports on this
cause and activities for information
recovery of normal
operation

TM Forum 2015. All Rights Reserved. Page 43 of 51

 Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

Fig. 12 Resource Provisioning L4 Processes shows similar work accomplished for

Resource Provisioning L3 processes.

L3 Process Name Input Information Output Information Candidate L4 Processes

Allocate & Install I-1) Service Order O-1) ResourceSpecification CheckResourceFeasibility
Resource I-2) LogicalResource

I-3) Resource Order O-2) ResourceSpecification AllocateResource

O-3) ResourceConfig

I-4) ResourceSepcification Nil InstallResource

I-5) Supplier/Partner O-4) ResourceSpecification CheckResourceAvailability

Configure & I-1) Resource Order O-1) ResourceOrder PlanResourceConfigurationAn

Activate Resource dActivation
I-2) ResourceConfig O-2) ResourceSpecification ConfigureResource
I-3) Resource

I-4) ResourceSpecification O-3) ResourceAlarm NotifyPotencialResourceTrou

I-5) ResourceConfig ble

I-6) ResourceSpecification O-4) AdministorResourceData UpdateResourceInventory

I-7) ResourceUsage O-5) Resource
I-8) ResourceConfig

Fig. 12 Resource Provisioning L4 Processes

TM Forum 2015. All Rights Reserved. Page 44 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

Fig. 13 Resource Trouble Management L4 Processes shows the decomposition for

Resource Trouble Management L3 processes.

L3 Process Name Input Information Output Information Candidate L4

Processes
I-1) Resource Alarm Event O-1) Resource Trouble Generate Resource
Record Trouble

1-2) Service Trouble O-2) Resource Trouble ConvertReportTo

I-2) Resource Order ResourceTrouble
Create Resource I-3) Resource Trouble O-2) Resource Trouble Format
EstimateTimeFor
Trouble I-4) ResourceRestoration RestoringResource
Time
Localize Resource I-1)Resource Trouble O-1) Resource Trouble Verify Resource
Trouble I-2) Current Resource O-2) Resource Configuration
Configuration Configuration Verification
I-3) ResourceFacingService
Configuration
I-4) Resource Trouble O-3) Resource Trouble PerformSpecific
I-5) Resource Configuration O-4) Resource Trouble Resource Trouble
Verification Root Cause Analysis Diagnostics
I-6)Resource Trouble
Diagnostics Specifications
I-7) Resource Trouble
Diagnostics Methodology
Template(New)

I-8) Resource Trouble O-5) Resource Trouble Perform Specific

I-9) Resource Trouble Test O-6) Resource Trouble Resource Trouble Tests
Specifications Test Results (Created)
I-10)Resource Trouble Root O-7) Resource Trouble
Cause Analysis Root Cause Analysis

Fig. 13 Resource Trouble Management L4 Processes

TM Forum 2015. All Rights Reserved. Page 45 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

7. Audit Checklist

This section contains a checklist of the Business Process Framework principles for its
use and application within an organization.

Principle
Business The Business Process Framework is an activity-based process
Process decomposition model
Framework
.01
Business The Business Process Framework Process Elements are
Process comprehensive for a Service Provider
Framework
.02
Business A Business Process Framework Process Element is a succession
Process of activities with a control flow
Framework
.03
Business (Best Practice): a Business Process Framework Process Element
Process has a goal, value proposition, inputs, outputs. It consists of
Framework activities and uses resources. It has a CRUD and RACI model.
.04
Business The Business Process Framework is decomposed from notional
Process Level 0 to more granular levels – Levels 1, 2 and 3 (and some of
Framework level 4) are addressed so far. An agreed end-point (i.e. a level
.05 below which decomposition does not proceed) is not yet defined.

Business It is not the purpose of the Business Process Framework to

Process address the detailed processes and procedures of an enterprise
Framework
.06
Business Enterprise Management is generally decomposed to Level 2 only
Process (but specific areas that represent particular priorities have been
Framework decomposed further).
.07

Business The goals, inputs, outputs, and activities of decomposed Process

Process Elements at a lower level are consistent with the higher level
Framework Process Element. In particular, the input of the first lower level
.08 Process Element is the same as the input of the higher level PE;
the output from the last lower level PE is the same as the output of
the higher level PE; the goals of the lower level Process Elements
taken together should match the goal of the higher level PE; the
activities of the lower level Process Elements taken together

TM Forum 2015. All Rights Reserved. Page 46 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

should match the activity of the higher level PE.

Business (Best Practice): each Business Process Framework Process

Process Element should identify its associated Information Framework
Framework ABEs
.09
Business A particular Process Element will occur only once in the Business
Process Process Framework; there is no replication
Framework
.10
Business Process flows in the Business Process Framework are control
Process flows, defining the sequence or order in which activities are
Framework performed.
.11
Business The swimlanes in a process flow are consistent within themselves
Process and with respect to lower level decompositions.
Framework
.12
Business The Business Process Framework models success scenarios.
Process Error conditions are not in scope.
Framework
.13
Business Dynamic aspects of process modeling are outside the scope of the
Process Business Process Framework.
Framework
.14
Business Terminology and naming conventions are <Noun> for Level 1 & 2
Process Process Names, <Verb Noun> for Level 3 Process Names, <Noun Verb>
Framework. for events.
15
Business Responsibility for association / translation between layers is generally
Process positioned at the lower layer.
Framework.
16
Business A process has prime responsibility for ensuring that the results of data
Process manipulation are stored appropriately.
Framework.
17
Business The Manage Resource Inventory processes have no processes to create
Process or update the data elements maintained in the repository.
Framework.
18

TM Forum 2015. All Rights Reserved. Page 47 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

8. Outstanding issues

 Not reconciled with Domain Structure!

 Implications of the Horizontals and Verticals structure. Principles arising.
 Traceability at lower levels. E.g. For a Level 6 it should also be clear which
of the Level 6 go back to which Level 3 (because they could go to several).
 Process dependencies and Process associations. E.g. The ABE and
contract work.
 Section on status of the Business Process Framework documentation.
Check that flow examples are normative. Can examples be normative?
 Section on Hybrid approach to Process Modeling. Is it of benefit to discuss
these distinctions when some not relevant to the Business Process
Framework?
 Section on Decomposition. Say more about decomposition and
uniqueness.
 Section on Flows. More explanation required for consistency of swimlanes.
 Use Cases for Patterns.
 Detail on the relationship of the Business Process Framework to
Frameworx.

TM Forum 2015. All Rights Reserved. Page 48 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

9. Administrative Appendix

9.1 Acknowledgements

This release of the Business Process Framework is the result of the combined efforts
of a large group of individuals from companies all over the world. Most noteworthy is
the participation of numerous service providers. The knowledge and commitment in
providing contributions and participating in discussions are greatly appreciated.
Contributors over the program leading to previous Business Process
Framework/eTOM releases were acknowledged in those documents

The team looks forward to continued input and involvement for ongoing work on the
Business Process Framework. Thank you for making this the acknowledged, best
framework for Telecom and Information Services business processes.

See main document (GB921 Concepts and Principles) for other acknowledgements.

9.2 Document History

9.2.1 Version History

Version Number Date Modified Modified by: Description of

changes
0.21 November 2006 Philip Willliams Document launch
1.0 December 2006 Mike Kelly Formatting for first
issue of document
1.1. February 2007 Tina O’Sullivan Updates from AC
1.2 June 2009 Alicja Kawecki Minor updates to
reflect TM Forum
Approved status
1.2 June 2009 Alicja Kawecki Minor updates to
reflect TM Forum
Approved status
1.3 Jan 2010 Mike Kelly (with some Small terminology
updates by Ken changes to use
Dilbeck) “Business Process
Framework” and to
update diagrams,
Also, small textual

TM Forum 2015. All Rights Reserved. Page 49 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

clarifications;
incorporation of
member review
comments
1.4 March 2010 Alicja Kawecki Minor cosmetic
updates for web
posting
1.5 April 2011 Alicja Kawecki Updated to reflect TM
Forum Approved
status
1.6 September 2012 John Reilly Added decomposition
guidelines chapter
1.7 October 2012 Alicja Kawecki Corrected notice,
minor cosmetic
corrections prior to
web posting and
Member Evaluation
1.8 July 2013 Alicja Kawecki Updated to reflect TM
Forum Approved
status
1.8.1 November 2014 Alicja Kawecki Applied rebranding,
corrected Notice
1.8.2 March 2015 Alicja Kawecki Updated cover,
header, footer and
Notice to reflect TM
Forum Approved
status
15.0.0 May 2015 Avi Talmor Notes on domain
addition
15.0.1 May 2015 Alicja Kawecki Updated cover, Notice
15.0.2 16 December 2015 Alicja Kawecki Updated cover,
header and Notice to
reflect TM Forum
Approved status

9.2.2 Release History

Release Number Date Modified Modified by: Description of changes

Release 7.0 December 2006 Mike Kelly Formatting for first
issue of document
8.1 Jan 2010 Mike Kelly (with some Small terminology
updates by Ken changes to use
Dilbeck) “Business Process
Framework” and to
update diagrams;
Also, small textual
clarifications;
incorporation of
member review
comments
12.0 September 2012 John Reilly Added decomposition
guidelines chapter
14.5.0 November 2014 Avi Talmor Added note regarding

TM Forum 2015. All Rights Reserved. Page 50 of 51

Addendum U – User Guidelines for the Business Process Framework
Business Process Framework (eTOM) R15.0.1

change to core
processes
decomposition
15.0 May 2015 Avi Talmor Notes on domain
addition

TM Forum 2015. All Rights Reserved. Page 51 of 51