Business Process

Framework (eTOM)
For The Information and Communications Services Industry

Addendum J:
Application Note: Joining the Business Process Framework
through to Process Flows

GB921 Addendum J
TM Forum Approved Version 11.3

May, 2012

TM Forum 2012

 Business Process Framework – Joining the Business Process Framework through to Process Flows

Notice

This material, including documents, code and models, has been through review cycles;
however, due to the inherent complexity in the design and implementation of software and
systems, no liability is accepted for any errors or omissions or for consequences of any use
made of this material.
Under no circumstances will the TM Forum be liable for direct or indirect damages or any costs
or losses resulting from the use of this specification. The risk of designing and implementing
products in accordance with this specification is borne solely by the user of this specification.
This material bears the copyright of TM Forum and its use by members and non-members of
TM Forum is governed by all of the terms and conditions of the Intellectual Property Rights
Policy of the TM Forum (http://www.tmforum.org/Bylaws/1094/home.html) and may involve a
claim of patent rights by one or more TM Forum members or by non-members of TM Forum.

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

GB921 Addendum J, Version 11.3 © TM Forum 2012 Page 2 of 27

 Business Process Framework – Joining the Business Process Framework through to Process Flows

Table of Contents
Notice...................................................................................................................................................................2
Table of Contents ..............................................................................................................................................2
List of Figures ....................................................................................................................................................4
Executive Summary ..........................................................................................................................................5
Introduction ........................................................................................................................................................6
1. End-to-End Business Streams ....................................................................................................................7
1.1. Terminology......................................................................................................................................7
1.2. Modeling Principles for End-to-End Business Flows .....................................................................8
1.3. Customer Centric End-to-End Business Streams....................................................................... 10
1.4. Network End-to-End Business Streams ..................................................................................... 11
2. Context specific End-to-End Business Flows ....................................................................................... 13
2.1. Definition of End-to-End Process Scenarios ............................................................................... 13
2.2. Context of End-to-End Scenarios ................................................................................................ 13
3. Modeling of End-to-End Scenarios .......................................................................................................... 15
3.1. Definition of Process Ownership of End-to-End Business Streams .......................................... 15
3.2. Analysis of As-Is-Status, Prioritization and Scoping ................................................................... 16
3.3. Mapping of eTOM with End-to-End Business Flow .................................................................... 17
3.4. Decomposition of Process Groupings and Definition of Business Flow .................................... 18
4. Implementation of End-to-End Scenarios .............................................................................................. 20
4.1. Phases of process implementation .............................................................................................. 20
4.2. Manual process implementation .................................................................................................. 20
4.3. Process implementation by automation....................................................................................... 21
5. Appendix – Example for “Lead-to-Cash” ............................................................................................... 23
5.1. Lead to Cash End to End ............................................................................................................. 23
5.2. Flow Diagrams .............................................................................................................................. 24
6. Administrative Appendix ........................................................................................................................... 25
6.1. About this document ..................................................................................................................... 26
6.2. Document History ......................................................................................................................... 26
6.2.1. Version History ...................................................................................................................... 26
6.2.2. Release History ..................................................................................................................... 26
6.3. Acknowledgments......................................................................................................................... 27

GB921 Addendum J, Version 11.3 © TM Forum 2012 Page 3 of 27

 Business Process Framework – Joining the Business Process Framework through to Process Flows

List of Figures

Figure 1: Customer-to-Customer Business Streams and Business Flow (example) 8

Figure 2: A Process View on customer-centric processes 9
Figure 3: Customer Centric End-to-End Business Streams 11
Figure 4: Network area End-to-End Business Streams 12
Figure 5: Four steps of modeling End-to-End Scenarios 15
Figure 6: Definition of targeted status 17
Figure 7: Usage of reference processes for mapping of process groupings on level 2
(exemplarily) 18
Figure 8: Vendor selection for implementation of automated processes 22
Figure 9: Partial End-End Level 2 Process Flow for Lead to Cash 25
Figure 10: Level 3 Process Flow for Validation to Activation 25

GB921 Addendum J, Version 11.3 © TM Forum 2012 Page 4 of 27

 Business Process Framework – Joining the Business Process Framework through to Process Flows

Executive Summary
In a previous release of the Business Process Framework (Release 9.0), TM Forum
addressed the issue of missing reference process flows by introduction of a new
GB921E document “End-to-End Business Flows”, which shows recommended eTOM
process scenarios that address high-priority end-to-end business issues. GB921E
document gives a proposal on how to develop the core Customer Centric and
Network process flows which are compliant with eTOM Level 1 – 3. Based on this
methodology and on the proposed core Customer Centric and Network process
scenarios, the present document shows how these pre-defined end-to-end business
flows can be used by a company in order to develop its own end-to-end process
flows, which are adapted to its business needs.

This document is an Application Note, aiming to document an approach based on

industry experience that can be used by a company in order to develop its own end-
to-end process flows, which are adapted to its business needs.

Note that, as an Application Note, this material should not be read as normative – i.e.
a single standardised approach – but rather as a representative mechanism that
provides a useful base for others to build on. Other approaches, with different
organizational structures which may lead to other process flows, are also possible. It
is the goal of work like this to assist convergence for the industry, but not to impose a
single approach, where there are other variations and alternatives that make sense.

GB921 Addendum J, Version 11.3 © TM Forum 2012 Page 5 of 27

 Business Process Framework – Joining the Business Process Framework through to Process Flows

Introduction
In recent years the Business Process Framework (also known as eTOM) has been
accepted and deployed by many companies around the world in the Information,
Communications and Entertainment industries. On the other hand, there are
numerous enterprises which are yet to understand the advantages of an industry-
wide standard process architecture for both business and functional processes, and
to make use of the Business Process Framework in order to improve their
organizational performance. In many cases, the missing knowledge of the eTOM
based process modeling methodology and lack of eTOM-compliant reference
process flows comprise the main hurdles for the implementation of eTOM within the
organization.

In a previous release of the Business Process Framework (Release 9.0), TM Forum

addressed the issue of missing reference process flows by introduction of a new
GB921E document “End-to-End Business Flows”, which shows recommended eTOM
process scenarios that address high-priority end-to-end business issues. GB921E
document gives a proposal on how to develop the core Customer Centric and
Network process flows which are compliant with eTOM Level 1 – 3. Based on this
methodology and on the proposed core Customer Centric and Network process
scenarios, the present document shows how these pre-defined end-to-end business
flows can be used by a company in order to develop its own end-to-end process
flows, which are adapted to its business needs.

This document is an Application Note, aiming to document an approach based on

industry experience that can be used by a company in order to develop its own end-
to-end process flows, which are adapted to its business needs.

Note that, as an Application Note, this material should not be read as normative – i.e.
a single standardised approach – but rather as a representative mechanism that
provides a useful base for others to build on. Other approaches, with different
organizational structures which may lead to other process flows, are also possible. It
is the goal of work like this to assist convergence for the industry, but not to impose a
single approach, where there are other variations and alternatives that make sense.

GB921 Addendum J, Version 11.3 © TM Forum 2012 Page 6 of 27

 Business Process Framework – Joining the Business Process Framework through to Process Flows

1. End-to-End Business Streams

Many companies visualize their business with the help of end-to-end business
streams, whose name often contains the starting and the end point of the process
flow, e.g., “Order-to-payment”, “Termination-to-conformation” etc. The term “end-to-
end” in this context means that a process is considered in a holistic way, starting by
the trigger of the process (e.g. customer request) and ending with the ultimate output
of the process (e.g. offer to the customer).

Usually, the end-to-end process flows represent a selective “footprint” across the
Business Process Framework, meaning that they are related to a specific context
only. They are examples of the possible connections between process elements and
they represent only one possible scenario of an end-to-end business process. In
order to cover a process fully a set of different scenarios of a business process is
required.

1.1. Terminology

In many documents and studies related to process management several names and
terms for end-to-end processes are used - “value streams”, “solution sets”, and “end-
to-end scenarios” are just a few of them. According to the terminology of TM Forum
this document uses the following terms and definitions:

1. End-to-End Business Stream: End-to-end business stream is the term for

company’s core processes on level 1, which often include the starting and the
ending point of the process. An end-to-end business stream does not include
sub-processes and activities required to accomplish its goals. Examples for end-
to-end business streams are Order-to-Payment, Trouble Ticket-to-Solution,
Service Lifecycle Management, etc. (see chapters 1.3 and 1.4 for further
examples).

2. End-to-End Process Flow: End-to-end process flow includes all sub-processes

and activities and the sequence required to accomplish the goals of the process.

3. End-to-End Business Flow: End-to-End business flow is a specific case of an

end-to-end process flow, which includes all activities and the sequence required
to accomplish the goals of an end-to-end business stream, e.g. of Order-to-
Payment (Figure 1). In order to reflect the fact that eTOM does not mandate a
single way the process elements should be organized or sequenced to create
End-to-end processes, in this document the term “End-to-End Scenario” will be
used synonymously.

GB921 Addendum J, Version 11.3 © TM Forum 2012 Page 7 of 27

 Business Process Framework – Joining the Business Process Framework through to Process Flows

Figure 1: Customer-to-Customer Business Streams and Business Flow (example)

1.2. Modeling Principles for End-to-End

Business Flows

In order to make use of the whole potential of the end-to-end business flows and to
ensure the holistic approach of their development, the following important modeling
principles should be applied:

1. Model high-level and generic: It is crucial to develop high level end-to-end

business flows which are valid for all kinds of products and customers and cover
all possible use cases in order to increase process standardization in the
organization and thereby improve company efficiency and performance. In
addition, this approach allows re-using process blocks for different business
streams: e.g. the sub-processes “Billing”, which is defined in the business stream
“Order-to-Payment”, can also be used for the business streams “Usage-to-
Payment” and “Problem-to-Solution” (e.g. for billing of extraordinary efforts).

2. Develop top-down: It is important to start business flow development with

scoping of its content and identification of relevant eTOM process groupings.
After definition of process groupings further decomposition of the functionalities,
e.g. on level 3, can be done.

3. Design IT- and organization-independent: End-to-end business flows should

(ideally) be designed independently from company’s organizational structure or IT
systems in order to keep focused on core activities and to ensure business
continuity and sustainability.

4. Focus on core business activities: The chosen set of end-to-end business

streams should concentrate on the company’s core business activities according
to company’s targets and strategic direction. For most telco operators, Customer
Service and Network Operations might be areas with a very high priority for the
end-to-end business flows development. In addition, it is crucial to select a
manageable number (e.g. 3-8) of end-to-end business streams with the biggest

GB921 Addendum J, Version 11.3 © TM Forum 2012 Page 8 of 27

 Business Process Framework – Joining the Business Process Framework through to Process Flows

impact on company’s performance. Otherwise there is a risk of ending up with

focusing on everything and nothing.

5. Think end-to-end: Defined business flows must be really end-to-end, meaning

that they are triggered by a specific customer related or market related demand
and result in a final output meeting this demand.

6. Design future-oriented: Design of the selected process flows should not only
reflect the current process status in the company, but rather imply flexibility for
future changes. In addition, the design of eTOM compliant business flows is an
excellent opportunity to critically assess current process performance and to
implement process improvements.

In the recently published release of the Business Process Framework Suite (Release
9.0) TM Forum introduces a new GB921E document “End-to-End Business Flows”, in
which all business processes of a service provider are divided into core business
processes and support processes. The core business processes can be organized
into four process areas/domains: Customer Centric processes, Customer domain,
Product domain and Network domain (Figure 2). In addition, this document gives
clear recommendations on how to develop the core Customer Centric and Network
end-to-end business flows compliant with eTOM and proposes a set of generic end-
to-end scenarios for Customer Centric and Network domains.
Processes
Control

Corporate Mgmt & Human Resources Finance &

Business Excellence Management Risk Management

Customer Domain Product & Services Domain

Core Business
Processes

Customer Centric Processes

Network Domain
Processes
Support

IT Management Procurement External Relations

Figure 2: A Process View on customer-centric processes

These can be seen to represent process domains arranged as end-end business

streams which show a focus across the Service Provider for the area of business

GB921 Addendum J, Version 11.3 © TM Forum 2012 Page 9 of 27

 Business Process Framework – Joining the Business Process Framework through to Process Flows

activity concerned. Note that the use of the terms “process domains” and “end-end
business streams” here is just intended to explain this broad business context and is
not a new element of structure or terminology within the core Business process
Framework.

This kind of view can be considered as a customized extension to the standardised

Business Process Framework structure, which may be useful for some areas of
application. This does not preclude other such extensions and customized views,
where these are found useful also. In particular, note that the structure shown in
Figure 1 and subsequent figures is not a “different” process model, since this is not
proposed as a different process hierarchy. The process hierarchy is still that of the
Business Process Framework, and no changes to the decomposition structure in the
Business Process Framework are being introduced here. Instead, the structure
shown can be thought of as a view of what happens inside a company’s organization,
when the process elements from the Business Process Framework are allocated to
departments and business units. The view on the left in Figure 1, which is then shown
also in Figure 2, can be considered as such an organizational view, and not in any
sense in conflict with the decomposition hierarchy of the Business Process
Framework, since this organizational view makes direct use of the process elements
from the Business Process Framework. The concepts here are discussed at some
length in Addendum G “Guide to Applying the Business Process Framework”, and
the approach above is in line with this.

1.3. Customer Centric End-to-End

Business Streams

A total of seven Customer Centric end-to-end business streams represent the

customer view and interaction with a telecommunication company. These processes
start with the customer initiating the contact and end with the fulfillment of his/her
request. End-to-end business flows, which are developed from Customer Centric
business streams, include activities such as handling information requests, new sale,
billing and invoice generation or problem and complaint handling. Proposed set of
generic Customer Centric processes includes following end-to-end business streams:
1. Request-to-answer: This process is comprised of activities relevant to managing
customer requests across all communication channels (customer interfaces).
2. Order-to-payment: This process deals with all activities which convert the
customer request or an accepted offer into a ‘Ready for use’ product.
3. Usage-to-payment: This process deals with all activities related to the handling
of the product/service usage.
4. Request-to-change: This process deals with all activities which convert the
customer‘s change request into a ‘Ready for use’ product.
5. Termination-to-confirmation: This process deals with all activities related to the
execution of customer‘s termination request.
6. Problem-to-solution: This process deals with a technical complaint (problem as
unplanned interruption to a product service or reduction in its quality) initiated by

GB921 Addendum J, Version 11.3 © TM Forum 2012 Page 10 of 27

 Business Process Framework – Joining the Business Process Framework through to Process Flows

the customer, analyzes it to identify the source of the issue, initiates resolution,
monitors progress and closes the trouble ticket.
7. Complaint-to-solution: This process deals with a complaint (a customer inquiry
in which the customer is not pleased with a product or the handling speed of an
inquiry problem) initiated by the customer, analyzes it to identify the source of the
issue, initiates resolution, monitors progress and closes the trouble ticket.

Customer Product & Services

Request-to-answer
Order-to-payment
Usage-to-payment
Request-to-change
customer customer
Termination-to-confirmation
Problem-to-solution
Complaint-to-solution

Network

Figure 3: Customer Centric End-to-End Business Streams

1.4. Network End-to-End Business

Streams

This consists of six Network End-to-End Business Streams, which represent the
network operations’ view and interaction within the telecommunications company.
Network business flows, which are developed from the proposed business streams,
include activities such as order handling, trouble ticket management, billing, capacity
management, and service lifecycle management. The end-to-end business streams
in the Network area are:
1. Production Order-to-acceptance: This process manages the provisioning and
termination process, starting from the feasibility check and ending with the
activation of services and resources.
2. Trouble Ticket-to-solution: This process is either triggered internally through a
service or resource alarm, or externally, through a trouble ticket generated based
on a complaint of a customer.
3. Activation-to-Usage Data: This process focuses on the enabling of usage, the
collection of usage records and the monitoring of performance criteria.

GB921 Addendum J, Version 11.3 © TM Forum 2012 Page 11 of 27

 Business Process Framework – Joining the Business Process Framework through to Process Flows

4. Capacity Management: This process aims to ensure the timely and cost-efficient
provisioning of the accurate capacity of services and components.
5. Service Lifecycle Management: This process defines, plans, designs and
implements all services in order to support the introduction, operations and
retirement of market products.
6. Resource Lifecycle Management: This process defines, plans, designs and
implements all resources in order to support the introduction, operations and
retirement of market products.

Figure 4: Network area End-to-End Business Streams

GB921 Addendum J, Version 11.3 © TM Forum 2012 Page 12 of 27

 Business Process Framework – Joining the Business Process Framework through to Process Flows

2. Context specific End-to-End Business Flows

As already described above, the end-to-end business flows on level 3 proposed by
TM Forum for the Customer Centric and Network areas can only be seen as
examples of how a business stream can be decomposed and put in a sequence on a
more detailed level. The content of these business flows may be relevant in specific
cases only. Following this thought, the full process coverage may require several
such process scenarios with a different context.

2.1. Definition of End-to-End Process

Scenarios

Generally, one of the principles of process modeling is standardization: the designed

process flows should be generic and valid for all kinds of products and customers and
cover all possible use cases. Certain process standardization increases the efficiency
and the flexibility of the company by providing a common basis for the whole
organization. This is especially valid for the end-to-end business streams, which
define on a high level a company’s main activities in order to achieve its business
goals. Last but not least, usage of standardized process blocks can significantly
reduce the effort of modeling new business processes.

Unfortunately, in real life it is not always possible to define process flows that are valid
throughout the whole business setup. In many cases, companies have to deal with
complex organizational structures and patchwork of IT systems or internal politics
make the implementation of standard and consistent processes almost impossible.
Therefore, in many cases there is a need to specify business streams by
development of several process scenarios, which cover all use cases of one single
end-to-end business stream.

The end-to-end business flows in Customer Centric and Network areas, which are
proposed by TM Forum, represent only one possible process scenario as a reference
flow. In order to implement these scenarios some adaptation to specific needs and
context of the company might be required. Therefore, in the initial phase of modeling
specific business flows it is important to understand the context of the modeled
scenario and to ensure commitment of process owners. In subsequent phases, the
analysis of as-is processes, mapping of relevant process groupings, process
decomposition and modeling of specific end-to-end business flows can be done.

2.2. Context of End-to-End Scenarios

In order to be able to model scenarios of an end-to-end business stream it is first

important to understand how the context of these scenarios can influence the result of

GB921 Addendum J, Version 11.3 © TM Forum 2012 Page 13 of 27

 Business Process Framework – Joining the Business Process Framework through to Process Flows

the modeling. Depending on the context, process scenarios can vary with regards to
used process groupings, their sequence, and/or their interconnection to each other.
Although other factors are also imaginable, some possible factors influencing the
context of a process scenario are presented in the following list:

1. Product and service portfolio: In some cases a differentiation of process

scenarios with regards to different products and services is required. For
example, the Order-to-Payment process for a fixed line product might contain to
some extent different processes on level 3 than the same process for a mobile
service.

2. Customer segmentation: Many providers of telecommunication services

practice segmentation of their customers, e.g. with regards to customer’s
revenues. The segments are usually served with different kinds of products, at a
different price and with a different level of service; therefore, several processes or
process scenarios might be required.

3. Process trigger / starting business event: Different scenarios of an end-to-end

business flow might be developed depending on the trigger or business event,
which initiates the process. A process of handling a technical problem reported by
a customer in most cases requires additional processes on level 3 (e.g. Manage
Contact, Validate Customer Satisfaction, Close Customer Problem Report)
compared to the same process which is triggered by internal control systems.

4. Process execution time / urgency: Another possible reason for specification of

additional end-to-end scenarios is the expected execution time of the process or
the urgency of the required activity. In some cases the process flow might reflect
the need of a “fast track” in order to stay flexible for unexpected and urgent
business events.

As already mentioned above, these are only a few possible factors that can initiate
the necessity of modeling different scenarios of an end-to-end business flow. It is
important to emphasize that the standardization of process flows is the ultimate
target. If any specification of the end-to-end business flow must be done, then it
should be developed on a higher level of detail. In most cases, eTOM level 3 is
appropriate; however, in other cases, specification on level 2 is also possible.

GB921 Addendum J, Version 11.3 © TM Forum 2012 Page 14 of 27

 Business Process Framework – Joining the Business Process Framework through to Process Flows

3. Modeling of End-to-End Scenarios

The modeling of End-to-End Scenarios with help of reference business flows can be
accomplished in four steps:

1. Definition of Process Ownership of End-to-End Business Streams

2. Analysis of As-Is-Status / Prioritization and Scoping

3. Mapping of eTOM with End-to-End Business Flow

4. Decomposition of Process Groupings and Definition of Business Flow

Figure 5: Four steps of modeling End-to-End Scenarios

3.1. Definition of Process Ownership of

End-to-End Business Streams

Before starting the actual modeling of the business flows the first step should be the
definition and involvement of process owners for considered business streams. A
process owner is responsible for a single business process and mainly deals with the
following tasks:

 Definition of detailed processes up to operational level

 Planning and execution of processes within daily business

 Escalation of process related issues

 Coordination with cross-functional interfaces

 Identification and implementation of process optimization potentials

GB921 Addendum J, Version 11.3 © TM Forum 2012 Page 15 of 27

 Business Process Framework – Joining the Business Process Framework through to Process Flows

In the context of modeling a new business flow it is important to keep in mind that
usually the end-to-end business flows are not defined from scratch, but rather build
on some already existing process parts and/or sub-processes. And usually the
responsible persons for these sub-processes are defined or, at least can be identified
in the current organization.

On the other hand, implementation of a new end-to-end business flow in the

organization also requires the definition of the owner of the new end-to-end
processes. But the definition of the process owners is not possible before having
conducted an analysis of as-is status of processes. At the same time, an in-depth
analysis of the current process landscape is not possible without involvement of
process owners. This dilemma can be solved by using the eTOM reference process
flows, which can represent a reference process model. By mapping company’s
organization to these processes it is much easier to find out units responsible for
process execution and to define process owners.

The involvement of parties responsible for current processes and of the new owners
of the end-to-end business flow is essential in order to make the modeling successful.
This approach allows taking into account current organizational setup, operational
restrictions and known process related problems and pain points. On the other hand,
the involvement of the future process owner from the very beginning of process
modeling ensures high buy-in on an operational level, sustainability of modeling
results for implementation and high commitment to the modeled business flow.

3.2. Analysis of As-Is-Status,

Prioritization and Scoping

As already mentioned, in most organizations business processes already exist in one

or another way, but they differentiate strongly with regards to maturity level of
business process management and their compliance with eTOM standards.
Nevertheless, the existing processes usually build the basis for the new business
scenarios or at least they are partially incorporated in the newly modeled processes.
Therefore, it is important to analyze the existing process landscape of the
organization before starting modeling the new business flows. The goal of this
analysis should be the establishment of a baseline with regards to the as-is-status of
process management, including existing process documentation, process modeling
tools, KPIs, gaps and pain points.

After having analyzed the as-is-situation and established a baseline, it is required to

prioritize and scope activities with regards to business flow modeling. The
prioritization and scoping should define the goals, which are supposed to be achieved
by modeling new business flows. In addition, this phase should give answers to
following questions:

 Which processes should be modeled?

 Which process architecture standards should be used (e.g. eTOM)?

GB921 Addendum J, Version 11.3 © TM Forum 2012 Page 16 of 27

 Business Process Framework – Joining the Business Process Framework through to Process Flows

 How should detailed process flows be modeled (e.g. eTOM level 4)?

 Which modeling tools should be used?

 What additional information should be included in business flow description (e.g.

RACI, KPIs, business rules, etc.)?

Prioritization and scoping of process modeling activities allow the determination of the
spread between the targeted status of process maturity and the as-is-situation and
identification of process management activities that need to be done in order to reach
the targeted status (Figure 6). These activities can also be influenced by such factors
as availability of human resources, availability of process modeling skills, quality of
existing process documentation, available time and desired quality of modeled
business flows.

Figure 6: Definition of targeted status

3.3. Mapping of eTOM with End-to-End

Business Flow

Generally, the end-to-end business flows recommended by TM Forum can be

considered as reference process flows, which represent an example or scenario of
possible organization and sequence of process elements. Therefore, these business
flows can be used as an initial basis for modeling the adjusted company’s
requirements process scenarios.

In the first step of actual modeling of the business flow it is essential to identify the
starting business event(s) and the resulting event(s) that should be covered. E.g. the
reference business flow Order-to-Payment proposes “Offer accepted” as the starting
event and “Invoice received by customer” and “Product ready for use” as resulting
events. The modeler of the business flow should check if the proposed starting and

GB921 Addendum J, Version 11.3 © TM Forum 2012 Page 17 of 27

 Business Process Framework – Joining the Business Process Framework through to Process Flows

resulting events match with the goal and the boundaries of the to-be-process and
adjust them if needed.

The next step is to locate the eTOM processes on level 2 that might best cover the
required functions of the business flow. Usually, it requires some time and effort to
identify the relevant eTOM areas (SIP, Operations or Enterprise Mgmt.), process
groupings on level 1 (e.g. Customer Relationship Management) and involved process
elements on level 2 (e.g. L2 CRM Support and Readiness, L2 Selling, etc.). With help
of the reference business flows, which already give clear guidance regarding the
involved eTOM domains and process groupings, this effort can be reduced
significantly. Depending on the requirements and goals of the business scenario the
developer can then use the same groupings as the reference business flow, eliminate
unnecessary process elements and/or include additional ones (Figure 7).

Figure 7: Usage of reference processes for mapping of process groupings on level 2

(exemplarily)

3.4. Decomposition of Process

Groupings and Definition of
Business Flow

In this step the identified process groupings on level 2 are decomposed into a more
fine grained view on level 3 according to eTOM. The reference business flow can
again be used as the basis for choosing the relevant process steps on level 3. In
addition, depending on functional requirements and goals of the modeled process,
the identification of additional and/or redundant L3 process steps must be performed.

After identification of all relevant process steps on level 3 the actual business flow can
be created by arranging the identified process steps into a logical order. The

GB921 Addendum J, Version 11.3 © TM Forum 2012 Page 18 of 27

 Business Process Framework – Joining the Business Process Framework through to Process Flows

reference business flow can serve as an example for such order, but it represents
only one possible sequence.

The definition of the business flow on level 3 is quite an iterative procedure: Arranging
process steps in a sequence can reveal gaps and redundancies in the process flow.
Therefore, sometimes it might be necessary to go back to previous steps and re-
assess the identified process elements on level 3 or even process groupings on level
2.

The result of the described steps of business flow modeling is an eTOM-compliant

end-to-end scenario on level 3, which can be further decomposed and specified for
the operational needs on levels 4 and 5.

GB921 Addendum J, Version 11.3 © TM Forum 2012 Page 19 of 27

 Business Process Framework – Joining the Business Process Framework through to Process Flows

4. Implementation of End-to-End Scenarios

The definition and modeling of eTOM-compliant processes is just one part of process
reengineering activities in a company. Processes, which exist on paper only, can not
improve company’s performance and efficiency. In order to do so these processes
must be implemented and used in the organization and IT systems. Therefore, a
short introduction into process implementation is described next.

4.1. Phases of process implementation

Usually, process implementation project can be executed in four steps, with some of
them being completed before or in parallel with the actual process modeling:

1. Mobilization: Identification of key stakeholder and organizational multiplier;

commitment of key stakeholders (partially done in the first step of process
modeling).

2. Integration: Integration of identified key stakeholders in process design related

activities (done during the process modeling).

3. Movement: Nomination, empowerment and mobilization of process owners;

increase of users’ self steering and control.

4. Embedding: Actual process implementation; independent and sustainable

usage of changed Business Processes.

As we can see the process design activities and implementation of new processes
are closely interconnected and are responsible for success of each other. The
process embedding itself could either be manual or through automation.

4.2. Manual process implementation

The manual process implementation mainly includes all activities that are aimed at
informing and coaching all employees which are affected by the new process. Main
activities in this area are:

1. Development of a training concept as per organizational requirements

2. Development and management of an overall training plan as a change

management tool

GB921 Addendum J, Version 11.3 © TM Forum 2012 Page 20 of 27

 Business Process Framework – Joining the Business Process Framework through to Process Flows

3. Development of training documentation

4. Conducting of process workshops and trainings with process owners, performers

and other stakeholders

5. Validation of business rules

6. Agreement on templates to be used

7. Sign-off of business rules & templates

4.3. Process implementation by

automation

The process implementation by automation applies to processes, which are heavily

supported by IT systems. The target of such implementation is to run some process
steps or even whole processes with few or completely without manual labor. Usually,
the automation of business processes in a company requires enhancement of
existing IT systems or even IT landscape. In many cases companies can not perform
such major changes in the IT systems with their own resources and need support of
external IT vendors. In doing so, the key objective is to find a suitable partner who is
capable of implementing all functional and inter-functional processes where IT-
changes and/or updates are required. The approach of selection a suitable IT vendor
is divided into four phases:

1. Specification of IT requirements: In this phase all process steps to be

automated are defined and IT requirements for process automation are derived
and prioritized. Furthermore, it is necessary to map the identified requirements to
existing IT landscape and to identify system gaps for targeted process
automation.

2. Vendor screening: Potential IT vendors to implement derived IT requirements

are analysed and a short list is created and aligned with all stakeholders.

3. RFP development: In this step a request-for-proposal document is developed,

which addresses all identified requirements. The created RFP is then sent to the
identified vendors from the short list.

4. Vendor selection for implementation: This phase includes the review of

collected responses from the vendors and vendor evaluation. Based on the
results of the evaluation the vendor for IT implementation is selected.

GB921 Addendum J, Version 11.3 © TM Forum 2012 Page 21 of 27

 Business Process Framework – Joining the Business Process Framework through to Process Flows

Figure 8: Vendor selection for implementation of automated processes

Following this approach the main task of company’s process and IT experts is the
overall management and steering of the vendor during the implementation and
ensuring the availability of all relevant stakeholders.

GB921 Addendum J, Version 11.3 © TM Forum 2012 Page 22 of 27

 Business Process Framework – Joining the Business Process Framework through to Process Flows

5. Appendix – Example for “Lead-to-Cash”

The intended focus of this section is an illustrative example of the described methodology. In this
case the focus is on the major business activities for an enterprise and how these can be
supported. This will be translated into a business view of activities and flows that represent how an
enterprise or set of enterprises interworking in a value chain, handles this scenario. While it is
recognized that there may be variation in detail for how companies may handle each scenario, the
objective is to agree a common baseline, from which tailored amendments can be made.

It follows an illustrative description of the Lead-to-Cash process from an end-to-end perspective as

well as from a more detailed flow and activity view.

5.1. Lead to Cash End to End

The end-end view of this scenario can be visualized at different levels of detail, according to the
required breadth of view and granularity. It is anticipated that lower levels of detail (in terms of the
Business Process Framework, using Level 3 or even Level 4 process elements) will be most
relevant for a working view. However, a higher level end-end view may also be helpful, to support
an overview of the scenario.

The end-end view is provided as a Level 2 view of the scenario, in line with user guidance in
development for the Business Process Framework, which illustrates the “footprint” of the scenario
on the Framework. This is then elaborated into a Level 2 process flow. These are set out below.

The overall scenario for Lead to Cash can include a number of aspects, including exceptions that
arise in particular circumstances. However, the view provided here is focused on a mainstream or
“sunny day” situation where only the major branch of activity is represented. Note that this can be
expanded with further study to add other branches, but the expectation is that the view here is not
invalidated by such expansion, and the scenario illustrated will remain a valid representation of the
situation addressed.

Scenario Constraints

1. Only the mainstream (“sunny day”) activities are considered

2. Customer enquiry is for a valid product
3. Customer is a valid customer, and is credit-worthy etc for the required product
4. Required product is “off the shelf” and is available for that customer/location
5. No special network build is required
6. All necessary resources etc are in place for this supply
7. No field work is required (automatic/remote configuration only is needed)
8. No third party (i.e. supplier/partner) involvement is required to deliver and manage the
required product with this customer/location

Note: later iterations of this scenario may relax some of these constraints and address a wider set
of circumstances

GB921 Addendum J, Version 11.3 © TM Forum 2012 Page 23 of 27

 Business Process Framework – Joining the Business Process Framework through to Process Flows

Figure 8: End-End Scenario Footprint for Lead to Cash

5.2. Flow Diagrams

The Level 2 flow diagram (see Figure 9) provides an overview of the Lead 2 cash activities, and is
shown using level 2 process elements from the Business Process Framework. Individual process
flows addressing phases within the overall Lead 2 Cash scenario are provided later, and use
lower-level process elements.

Note that the notation used here provides a “condensed” view of the process interactions, for
simplicity and visibility. This can be developed into a BPMN process flow diagram (not included at
this point).

For simplicity, the billing aspects of the end-end flow are not addressed at this point in this
example,

GB921 Addendum J, Version 11.3 © TM Forum 2012 Page 24 of 27

 Business Process Framework – Joining the Business Process Framework through to Process Flows

Figure 9: Partial End-End Level 2 Process Flow for Lead to Cash

A number of Level 3 flow diagrams can then be developed addressing stages in the overall Lead 2
cash activities. Figure 10 shows an example focused on the Validation to Activation stage.

This phase of the Lead 2 Cash scenario focuses on activities between receipt of a confirmed
customer order through to product activation with the customer.

Figure 10: Level 3 Process Flow for Validation to Activation

GB921 Addendum J, Version 11.3 © TM Forum 2012 Page 25 of 27

 Business Process Framework – Joining the Business Process Framework through to Process Flows

6. Administrative Appendix
This Appendix provides additional background material about the TM Forum and this
document.

6.1. About this document

This document is an Application Note, aiming to document an approach based on

industry experience that can be used by a company and adapted to its business
needs.

6.2. Document History

6.2.1. Version History

Version Number Date Modified Modified by: Description of

changes
- Sep 2011 Georg Vitt & Christian Final draft
Dietze, Detecon
11.1 Sep 2011 Mike Kelly Tidying for
publication
11.2 Oct 2011 Alicja Kawecki Inserted list of figures,
minor cosmetic
corrections prior to
web posting and ME
11.3 May 2012 Alicja Kawecki Updated to reflect TM
Forum Approved
status

6.2.2. Release History

Release Number Date Modified Modified by: Description of

changes
11.1 Sep 2011 Mike Kelly Tidying for
publication

GB921 Addendum J, Version 11.3 © TM Forum 2012 Page 26 of 27

 Business Process Framework – Joining the Business Process Framework through to Process Flows

6.3. Acknowledgments

This document was prepared by the members of the TM Forum Business Process
Framework (eTOM) team.

However, special thanks to Georg Vitt, Christian Dietze and colleagues at Detecon,
who provided the source material and acted as editors for the document as it evolved.
Their support in progressing this to successful conclusion is much appreciated.

GB921 Addendum J, Version 11.3 © TM Forum 2012 Page 27 of 27