Order Orchestration in Next

Generation Hybrid BSS/OSS:

Dream or Future Reality?
 © 2008, 2014 CGI Group INC. 3

Abstract
In the quest for maximum customer retention, Communications Service Providers (CSPs) are facing
the need to support an avalanche of new, heterogeneous products and services such as voice,
data, entertainment, content, and location-based services, packaged in bundles and provisioned
by both the CSPs and their partners. IP technology preferences are crystallizing: Some CSPs have
announced plans to migrate to IMS; others are content with supporting SIP or peer-to-peer IP
offerings. As there is little indication of a single unified approach, the next generation hybrid BSS/
OSS may exist not only in the interim period, during which some providers migrate to their desired
state, but for a long time to come.

Consequently, providers will face a new challenge: supporting order orchestration in a hybrid BSS/
OSS, with a significant increase in the complexity of ordering, potentially increasing order fallout
and costs. Successful order management and provisioning are key to the introduction of new
products and services and increased competitiveness. What options do providers have? This article
examines the ramifications of the next generation hybrid BSS/OSS on order orchestration and
possible ways to address them.

1. INTRODUCTION AND BACKGROUND

A recent Associated Press article informed readers of the departure of a president and co-founder
of a well-known US carrier in an article titled “President Departure Surprises.” It stated, “Provider’s
problems have stemmed from its recent acquisitions of at least seven companies and being able to
integrate provisioning which encompasses the transaction from a sales order to service activation”.
[italics added].

This article focuses on the following four areas of eTOM Level 3 processes, that is, after the order is
accepted into the CRM system. Figure 1 and Figure 2 represent Order Orchestration in eTOM-Level 3.

Figure 1. eTOM Representation of the Discussed Domain

4 © 2008, 2014 CGI Group INC.

Order Handling

Determine Customer Issue Customer Track & Manage Complete Customer

Order Feasibility Orders Customer Order Order
Handling

Authorize Credit Report Customer Close Customer

Order Handling Order

Figure 2. Level 3 Processes

Order orchestration has been a challenge for some time for many CSPs. Its significance and impact
has increased with the introduction of IP-based products and services, as well as triple and quadruple
play. CSPs are seeing significant erosion of PSTN lines and adoption of IP-based products and
services. With the PSTN line and voice revenue decrease as well as the messaging revenue decrease,
it is a race to replace lost voice revenue with a variety of data-based products, e.g. cloud offerings or
IoT (Internet of Things). In turn, more heterogeneous offerings and a wider variety of products increase
order orchestration complexity. Achieving convergence by an upgrade to the next generation OSS/
BSS can be compared to opening doors in a tunnel—CRM, rating and billing, provisioning, network
management, etc. Order orchestration is one of such doors—a key element of a provider’s success.
 © 2008, 2014 CGI Group INC. 5

2. BEST KEPT SECRET?

2.1 Order Fallout in the Past
Order fallout, defined as unplanned manual touch—a technician having to execute a manual task
which was not planned—is not a new phenomenon. Order fallout numbers vary with CSP size, type of
business, and supported complexity. CGI has performed order fallout studies for its customers. The
aggregated results have noted order fallout of 5-25% on the front end and 20-55% on the backend.
The front end order fallout costs are between $3-$10, with the average correction time of 4-10 minutes.
It is not unusual to see approximately 10% of a provider’s call center staff dedicated to order correction.

The back-end issues are more complex and, consequently, the costs are higher— close to $1M per
each order fallout percentage. Newly introduced services typically have a higher order fallout, while the
established services are at the low end of the above-noted percentage range. However, this equation is
dynamic and can be compared to cresting waves: what was a new service yesterday with high fallout,
in time, becomes an established service, and the order fallout decreases.

However, the order fallout numbers are but the tip of an iceberg. The bulk of the iceberg includes:

• Losses stemming from decreased customer satisfaction or customer churn

• Sub-optimal (too long) order to cash

• Revenue leakage

• Regulatory fines (for example, if a base service cannot be provisioned in the mandated timeframe)

• Class action lawsuits

Even more significant is the unplanned manual touch. In a sub-optimal order orchestration system
there are many more planned manual touches than should be necessary. However, this does not show
as an order fallout issue.

Due to the above factors, true provider costs of a sub-optimal system are likely significantly higher than
the percentages quoted in the early part of the section.

2.2 Current Order Orchestration Challenges

With IP technology the CSP footprint has increased, resulting in triple and quadruple play product
bundles. The following business drivers impact order orchestration:

• Convergence. Product bundles become more complex than the traditional stovepipe offers.

• On-demand Provisioning. The need to rapidly introduce new products and services.

• Technology. A mix of legacy and IP products in product bundles, as providers migrate to IP. As
different providers are adopting different approaches (peer-to-peer, SDP, IMS), the heterogeneous
nature of their OSS/BSS is increasing and order orchestration needs to support it. IP decreases
the cost of entry and increases competition as any provider can write any application on top of IP.
Some providers (Vonage, Skype) do not own the network and ask customers to bring their own
broadband.
6 © 2008, 2014 CGI Group INC.

• Openness. The walled garden is crumbling. Wireless devices are becoming more open and are
moving toward PCs. The end user will eventually be able to put any device on any network and put
any application on such device.

• Mergers and Acquisitions. Large providers have multiple service activation and provisioning systems.
Mergers and acquisitions as seen in the telecommunications industry make such numbers higher.

• Cost Optimization. With increased competition and ever decreasing voice margins, the focus is on
minimizing costs and order to cash.

These business drivers face the harsh reality of existing environments:

• Most existing legacy OSS/BSS systems have not been built to serve an IP-based world.

• With stovepipes in CSPs’ OSS/BSS it is very hard and often impossible to get a consolidated
customer view. Multiple CRM systems often have disparate representations of the same customer,
thus making convergent order orchestration a huge challenge. Similarly, joint ventures in cable and
wireless provide a significant challenge in terms of a unified customer view, customer “ownership,”
and order orchestration.

• Process coordination across a convergent order across a number of CRM, service activation, and
provisioning systems.

• Limited subject matter expert visibility to order orchestration activities.

• Lack of business logic change control.

• Inability to deal with configuration changes in active orders.

• Lack of visibility to order fallout and its causes.

Triple and quadruple play order orchestration across internal and external organizational boundaries
(partners, JVs) in combination with the above limitations increases order fallout. Contributing to such
fallout is a lack of order validation: 1) “dirty” orders can get into the system through ordering gateways
and human error. Multiple sales channels with multiple customer care systems from the past create
fragmented customer representation and fragmented or incomplete product data. An increased
footprint of triple and quadruple play means order orchestration has to support heterogeneous
activation types on network elements, servers, different product types, and products from the CSP and
partners. A product bundle can contain a number of such heterogeneous services. All of these issues
not only contribute to an increase in order fallout, but also to challenges related to efficient new product
rollout and customer satisfaction.

2.3 Past Approaches

Silo Workflow Systems. The logical extension of stovepipes went to order management. Different
provisioning systems had different embedded business logic. Mostly, CRM systems served a specific
stovepipe and passed the order to the provisioning system, though occasionally a CRM is placed
across silos to support bundled products. Regardless of the CRM placement, order orchestration was
difficult, as the business logic was maintained “too low”, i.e. per line of business or specific product
provisioning “silo”. No cross-order control exists in this paradigm (Figure 3). There are multiple points of
business logic definition, and no cross-silo visibility or order orchestration exists.
 © 2008, 2014 CGI Group INC. 7

Figure 3. Order Orchestration in Legacy—Fragmented Approach with Business Logic Positioned “Too Low”

CRM-based Orchestration. An alternative approach was trying to embed the business logic in CRM
systems. Unfortunately, the CRM systems were also fragmented, and while the business logic was
adequate to handle CRM issues, it was not built to handle order orchestration challenges across
different provisioning systems. Furthermore, similar fragmentation occurred as in silo workflow systems,
with similar impact: business logic fragmentation and the lack of a single point from which to monitor
and control. Such order orchestration business logic was created “too high.” Both approaches were
limited in their flexibility and ability to handle cross-line-of-business provisioning.
8 © 2008, 2014 CGI Group INC.

Figure 4. Order Orchestration in Legacy—Fragmented Approach with Business Logic Positioned “Too High”

Order Orchestration Positioning. As order orchestration issues became better understood,

providers started implementing in the optimal place from the convergence prospective. However,
optimal positioning does not guarantee an optimal result, as this depends on the functionality of
such order orchestration solution. This will be discussed in detail in the following sections.
 © 2008, 2014 CGI Group INC. 9

Figure 5. Optimal Positioning of Order Orchestration Business Logic

3. FUTURE ORDER ORCHESTRATION CHALLENGES

AND POSSIBLE WAYS TO SOLVE THEM
The basic issues in future order orchestration remain unchanged: IP products and services still remain
to be qualified and installed, and customers need to be billed and equipment shipped. However,
beyond that the higher complexity of next generation orders needs to be supported:

• Hybrid services—legacy, IP, CSP, partner

• Significant increase in service offerings, including heterogeneous activations on network elements,

servers, and mobile commerce

• Increase in on-demand order orchestration as a result of self service

• Move from static to dynamic (from subscribe to a subscribe-to-preferred-services thus creating

one’s own bundle)

• Increase in partnerships

• Increase in network and device openness

In summary, the trend is toward an explosion in volume and order management complexity.
10 © 2008, 2014 CGI Group INC.

3.1 Impact on Order Orchestration

The ultimate convergence, openness and flexibility goals impact order orchestration. As a result of
these goals, order orchestration no longer consists of static business logic with sequential execution of
steps. In this highly dynamic paradigm, real-time changes may be caused by business logic execution,
external systems, customer input, and partners. Thus the complexity can be represented as a network
of decision nodes, reacting in real-time to order-impacting state changes in the OSS/BSS. Some
decision nodes get executed, while others get bypassed. Thus, execution of the same order may result
in different decision nodes executed and bypassed with the decision path being selected in real-time.
Figure 6 provides a look at order orchestration impacts.

The challenge is significant: transforming order orchestration from a business issue to a competitive
advantage, all while providers are migrating to IP, upgrading their OSS/BSS, consolidating systems,
and at the same time trying to cut costs. Such a transition needs to be done smoothly and without the
customer noticing. It is almost as challenging as building a new plane in the air from both new parts
as well as parts of existing planes in flight and migrating the customers to the new aircraft without their
having noticed anything but the improvements.

Network
Partner
Partner Portal
Portal
Inventory
CRM
CRM
CRM

Service A Workforce
Partner
Partner Portal
Portal
Management

Self
Self Care
Care Portal
Portal

Provisioning
Partner
Partner Portal
Portal
Provisioning

Partner
PartnerPortal
Partner Portal
Portal Partner
Service B Partner
Partner Portal
Partner
Portal
Provisioning
Provisioning
Partner
Partner Portal
Portal
Provisioning
Provisioning

Service C..n
Order 1..n

Network
Billing
Partner
Partner Portal
Portal Partner
Partner Portal SDPPortal
Partner
PartnerPortal
Activation
Partner Portal
Portal

Figure 6. Next Generation Order Orchestration Impact—Decision Nodes

 © 2008, 2014 CGI Group INC. 11

3.2 Different Approaches

Two approaches are examined: centralized and decentralized.

Centralized. In this approach the new system encompasses the functionality of all existing service
activation and provisioning systems supporting legacy and all forms of IP. It provides the ultimate
consolidation of order orchestration as shown in Figure 7 below. What are the issues with this
approach? At first glance it is consistent with the OSS/BSS consolidation. After all, providers are
trying to decrease the number of CRM systems, rating and billing systems, and so forth to decrease
costs and increase efficiency, ideally to a single system. However, significant cracks appear in this
approach upon further examination: First, one has to believe that a dominant provider able to solve this
will emerge and keep this monolithic solution current and competitive. That is a tall order. Even in the
previous order management environment, large Tier 1 providers had between 20-30 different service
activation and provisioning systems, and this was prior to the IP complexity. How will this be achieved
given the significant increase in complexity? Even if such a provider emerged, migrating all service
activation and provisioning systems to one solution is a high effort. It does not support the “best in
class” strategy and puts a provider in a high risk situation, totally dependent on one vendor. Therefore,
this approach is neither likely, nor practical.

Figure 7. Intelligent Order Orchestration—Centralized View

Decentralized—Intelligent Orchestration Layer. This approach, Figure 8, acknowledges the

increasingly heterogeneous and dynamic nature of order orchestration and capitalizes on it. New
IP products get introduced to the market, and legacy is gradually retired. Market experimentation is
key—some IP products succeed, others will also get retired, and new products from the CSP and
partners get introduced in this continuous cycle of innovation.

Figure 8. Intelligent Order Orchestration—Decentralized View

12 © 2008, 2014 CGI Group INC.

There are many requirements to fulfill to make this approach successful:

• It needs to be BU driven. BUs rather than programmers create business logic. This ensures fast
time to market and puts the creativity where it belongs—in the CSP business experts’ hands.
However, this makes the implementation challenge larger, as the Intelligent Orchestration Layer (IOL)
not only needs to handle an unprecedented level of complexity, but provide an easy way for a BU to
handle it.

• Data reactive. Order data is not static, and there may be a variety of potential service
configurations. The order orchestration system needs to be capable of reacting to changes to
this data initiated by customers or interaction initiating in interfacing systems. The real number of
systems is significantly higher than depicted in the above figure.

• Data needs to be validated continuously. When entering IOL, if it is not valid, it needs to be
either automatically corrected or rejected. Since it is assumed that the associated data may change,
the validation should continue throughout the order orchestration process.

• The problem to be solved is non-linear and the IOL needs to address it.

• There is a significant number of orders flowing through the system, many of them convergent, each
containing multiple decision nodes. The IOL needs to support easy to understand, drill down
dashboards and reports. Such dashboards and reports identify issues including the root problem
and report on automatic correction. The CSP can then decide whether to tolerate, fix, or retire the
offending systems causing order fallout.

• Automated order correction. The increase in volume and complexity makes this feature essential.
The IOL needs to monitor all orders and automatically perform corrective action. In the event a
corrective action requires a manual intervention, the IOL monitors these through cascading alarms.
A task may be assigned to an individual or a group. If it is not done during the required period, an
alarm cascades to a different individual/group. Using the combination of automated error correction
and cascading alarms ensures no orders are left hanging.

• The IOL must be state aware. This ensures efficient use of resources and swift recovery.

• The IOL needs to be open, SOA, and NGOSS compliant. However, given the IOL needs to handle
both legacy and modern systems, it needs to have an open access layer through which to easily
interface older solutions which do not comply with modern standards.

CRM consolidation is in progress in most carriers with different customer care systems. However,
not all such carriers have finished this transformation. For those with multiple CRMs there may be
a different client representation of the same client in different CRMs, which then gets in the way of
convergent provisioning. The IOL can handle this in two possible ways:

1. Provide a customer consolidation layer. Such layer extracts the necessary information from different
CRM systems and after the extract provides a consolidated customer view for the purpose of
convergent order orchestration. In this option, a persistent view of the consolidated customer data
is created.

2. On demand view created in real-time and without the persistent database option. The IOL queries
the appropriate CRM databases, creating a temporary customer view for the purpose of executing
the convergent order.
 © 2008, 2014 CGI Group INC. 13

The IOL handles hybrid convergent provisioning. However, it provides yet another function for brand-
new technologies coming to the market, for example, SDP. There are many SDP providers, and it is
often a challenge for a CSP to choose one who is not only most appropriate today, but who will be the
leader in future. Yet, given the breakneck pace of competition, the CSP may not wish to stop, rewrite,
and retire an SDP provider in 2-3 years’ time if such provider is no longer competitive. The IOL treats
such brand-new technologies as yet another black box. In other words, the CSP can add another SDP
in this example without stopping to rewrite and retire the SDP provider whom they wish to retire. The
IOL takes a convergent order and decomposes it. Consequently, it knows which SDP services in a
convergent bundle to route to the outdated product, and which need to go to the new SDP black box
during the ordering process. The CSP can then decide when or whether to replace the outdated black
box. The IOL thus provides a fast way for the CSP to introduce new technologies and products to the
market, further increasing its competitiveness.

Figure 6 shows the convergent order management and the consequent decision node complexity. The
IOL handles “n” different convergent orders at any time. Each order may consist of different products
and services—a through z. Thus, the complexity in the next generation order orchestration goes
beyond static modeling. Each decision node in each service may have multiple outcomes and, as
such, impact multiple decision nodes. Similarly, a state impact of an external system may be on one or
more decision nodes. This illustrates why static modeling through traditional business logic no longer
works—the complexity is too high. Consequently, abstracting the business logic for the BU needs to
be done in a way so that it may be modeled by a BU with no programming skills to define the decisions
and decision relationships, as shown in Figure 9. Decisions represent any business logic with multiple
possible outcome (validations, course of action, error procedures, for example). The BU focuses on
what information is required for a decision and the decision outcome. The IOL insulates the BU from
the complexity of static modeling as it, rather than the BU, understands a cross-decision, cross-order,
cross-system relationship and reacts to the changes appropriately. The decision nodes are not joined
in a flow-like manner, that is, there are no statically modeled process dependencies. Rather, some of
these may be conditions which are continuously evaluated until the order is completed.

Figure 9. Decision Modeling

14 © 2008, 2014 CGI Group INC.

The IOL provides intelligence which has not existed in the OSS/BSS before. It is thus slotted to the
OSS/BSS without replacing existing systems. It utilizes existing system bus, SOA, web services, or
NGOSS type interfaces or works on point to point interfaces. It does not assume knowledge of the
surrounding systems; rather it treats them as black boxes. This gives the CSP the ultimate flexibility: It
can decide whether to introduce it gradually, to solve the largest current problems, or as a big bang
approach.

3.3 Simple “Complex” Example

To illustrate different steps, let us consider an example.

A decision network in Figure 10 is being executed for an order containing service orders a-n with the
first two service orders shown in detail when an external system triggers a change, in our example
the provisioning system in Figure 10, marked by a red arrow. The state snapshot of the IOL at that
point is as illustrated in Figure 10. Such a change could be due to many changes. In this example, the
customer has ordered broadband from a telecom provider and decides to add IPTV. As part of the
order flow, the provisioning system has determined the broadband bandwidth is insufficient for IPTV
and consequently the service needs to be moved to a different DSLAM.

Network
Partner
Partner Portal
Portal
Inventory
CRM
CRM
CRM

Service A Workforce
Partner
Partner Portal
Portal
Management

Self
Self Care
Care Portal
Portal

Provisioning
Partner
Partner Portal
Portal
Provisioning

Partner
PartnerPortal
Partner Portal
Portal Partner
Service B Partner
Partner Portal
Partner
Portal
Provisioning
Provisioning
Partner
Partner Portal
Portal
Provisioning
Provisioning

Service C..n
Order 1..n

Network
Billing
Partner
Partner Portal
Portal Partner
Partner Portal SDPPortal
Partner
PartnerPortal
Activation
Partner Portal
Portal

Figure 10. External Change

 © 2008, 2014 CGI Group INC. 15

As a result of the provisioning system, the IOL determines which decision has been impacted and all of
the dependent decisions based on it. Figure 11 illustrates these impacted decision nodes, which are
marked in red. In our example such dependencies are both within a service order (for example, within
Service Order A) and across service orders (the arrows from service order B to A). The relationship
between decision nodes in service orders A and B have not been statically modeled. Rather, the
output of service order A drove service order B. Since decisions in service order B were influenced by
the relationship between service order A and B, the IOL has the capability to automatically re-evaluate
these decisions also. This is key: in the next generation of order orchestration there will be large
quantities of orders and services, some complex, others simple. It will not be possible to know that
orchestration decision for service XYZ now impacts decision for order ABC. No rollback occurs at this
point in time, as in this phase the IOL realizes the impact of the change and re-evaluates the decisions.

Network
Partner
Partner Portal
Portal
Inventory
CRM
CRM
CRM

Service A Workforce
Partner
Partner Portal
Portal
Management

Self
Self Care
Care Portal
Portal

Provisioning
Partner
Partner Portal
Portal
Provisioning

Partner
PartnerPortal
Partner Portal
Portal Partner
Service B Partner
Partner Portal
Partner
Portal
Provisioning
Provisioning
Partner
Partner Portal
Portal
Provisioning
Provisioning

Service C..n
Order 1..n

Network
Billing
Partner
Partner Portal
Portal Partner
Partner Portal SDPPortal
Partner
PartnerPortal
Activation
Partner Portal
Portal

Figure 11. Evaluation of Dependent Executed Decision Nodes

 16 © 2008, 2014 CGI Group INC.

Figure 12 illustrates the consequences of previous decisions undone and the new decision path
created.

Network
Partner
Partner Portal
Portal
Inventory
CRM
CRM
CRM

Service A Workforce
Partner
Partner Portal
Portal
Management

Self
Self Care
Care Portal
Portal

Provisioning
Partner
Partner Portal
Portal
Provisioning

Partner
PartnerPortal
Partner Portal
Portal Partner
Service B Partner
Partner Portal
Partner
Portal
Provisioning
Provisioning
Partner
Partner Portal
Portal
Provisioning
Provisioning

Service C..n
Order 1..n

Network
Billing
Partner
Partner Portal
Portal Partner
Partner Portal SDPPortal
Partner
PartnerPortal
Activation
Partner Portal
Portal

Figure 12. Undoing Previous Decisions

Figure 12 illustrates the re-evaluation process in its entirety. Three cases exist:

1. Some decisions are re-evaluated and still take the same way as before (blue and green circles with
purple lines).

2. New decision nodes were executed and are shown as new paths (purple circles).
3. Previously taken decisions are no longer taken and are shown in red lines and grey-red circles.

In other words, the intelligent orchestration layer re-navigates through the orchestration decision
network based on the latest real-time situation.

The results of the decisions no longer taken (grey red) need to be rolled back. Examples are the
cancellation message to external system and cleanup of inventory.

The results of new decisions are then applied (purple), for example a different transaction message, an
alternative process path. Rollbacks are done at this point where the decision path is different from the
one chosen originally. No action is taken for decisions where they were re-evaluated and remain the
same.
 © 2008, 2014 CGI Group INC. 17

How is this approach different than those of the past?

• It is more than exception handling.

• Support is provided for undo activities to clean up system transactions for in-progress orders
when the configuration data is changed or orders are cancelled prior to completion

• Comprehensive capabilities exist to address order errors including

• Automatic error correction

• User notifications of errors

• Escalation processes when problems are not addressed

• Effective distribution of error correction activities

• It is more than just workflow.

• The underlying service configuration data must be used to drive orchestration processes

• The solution must allow processes to adjust if the configuration data changes

• The solution significantly reduces order fallout by validating and correcting order data prior to
accepting the order

• Support is provided real-time status, and effective dashboard / reporting tools to measure
process effectiveness and determine the root cause of fallout

• Superior convergence is supported.

• A consolidated view of the customer data significantly reduces the fallout caused by multiple
sales channel portals / CRM applications

• Ability is provided to define cross service and product dependencies and exclusion rules,
including mid-process dependencies

• Ability is provided to define coordinated activities that are required once per customer, such
as order truck rolls and shipping
18 © 2008, 2014 CGI Group INC.

CONCLUSION
CGI has implemented the IOL described above for a Tier 1 customer in North America. The CSP
used the solution in their new product offering family “World over IP” (WoIP), including the optional
Centralized Customer View illustrated in Figure 8, which created a unified customer view by importing
customer data from nine different customer care systems. The total number of external systems the
IOL interfaced to was 29. The minimum provisioning time decrease among the World over IP family
of products was 58%, the maximum 99%. The average improvement in provisioning times across all
WoIP products was 79.37%.

Successful order orchestration is key to the introduction of new products and services, increased
competitiveness and, in some cases, an operator’s survival. The pace of change over the next
two to three years is likely to be unprecedented. Figure 5 showed the optimal position of an order
orchestration system. However, this is not enough. Such a system needs to be able to handle much
more complex orders dynamically, enable BUs to create the business logic necessary to handle such
complexity and insulate them as much as possible from the significantly increased complexities of next
generation order orchestration.

Charles Darwin said: “It’s not the strongest of the species that survive, nor the most intelligent;
it is the one that is the most adaptable to change.” Telecommunications is changing and the
CSPs must do the same to compete. We can easily substitute “species” with “CSPs.” Efficient next
generation order orchestration will stay a dream for those who take no action. On the other hand, the
prize is there for CSPs who realize the challenge. The Intelligent Order Orchestration Layer can give
them the best of both worlds—ability to provide convergent (legacy, current, and next generation)
services quickly and efficiently, while at the same time minimizing costs and time to market.

AUTHOR

Rene Sotola - Vice President, Global Communications Sector, Mobility & IoT
Rene Sotola is the industry lead for the Global Communications Sector and practice lead for
Mobility & IoT (Internet of Things). He is visionary with international senior-level management,
consulting and product development lifecycle expertise in telecommunications and high tech,
a frequent speaker at national and international conferences and the author of numerous
whitepapers.

FOR MORE INFORMATION

For more information about this whitepaper, please contact us at: [email protected]
To learn more about CGI services for Communications
Visit: www.cgi.com/en/communications
E: [email protected]

cgi.com
With 68,000 professionals operating in 400 offices across 40 countries, CGI
fosters local accountability for client success while bringing global delivery
capabilities to clients’ front doors. Founded in 1976, CGI applies a disciplined
delivery approach that has achieved an industry-leading track record of
on-time, on-budget projects. Our high-quality business consulting, systems
integration and outsourcing services help clients leverage current investments
while adopting new technology and business strategies that achieve top and
bottom line results. As a demonstration of our commitment, our average client
satisfaction score for the past 10 years has measured consistently higher than
9 out of 10.

© 2014 CGI GROUP INC.

All rights reserved. This document is protected by international copyright law and may not be reprinted,
reproduced, copied or utilised in whole or in part by any means including electronic, mechanical, or
other means without the prior written consent of CGI. The project referenced in this brochure was
delivered by CGI.

Whilst reasonable care has been taken by CGI to ensure the information contained herein is reason-
ably accurate, CGI shall not, under any circumstances be liable for any loss or damage (direct or
consequential) suffered by any party as a result of the contents of this publication or the reliance of
any party thereon or any inaccuracy or omission therein. The information in this document is therefore
provided on an “as is” basis without warranty and is subject to change without further notice and
cannot be construed as a commitment by CGI.