Increasing service

innovation in the B2C and

B2B customer segments:

Specialized BSS/OSS silos

or a unified architecture?

15 May 2012

Mark H. Mortensen (Principal Analyst)

Ref: RX963

Commissioned by Comarch

Ref: RX963 .

Table of Contents

1 Executive summary 1

2 Introduction: Unified architecture across B2B and B2C or specialized silos? 1

3 Both business and consumer are major revenue contributors 2

4 B2C and B2B operational differences 3

5 The opportunity-to-cash processes for B2C and B2B operations – differences in

challenges 6

6 Supporting B2C and B2B operations with the same systems 10 a. Technical considerations 11

b. Business considerations 11

c. Organizational considerations 12

d. Future considerations 12

e. Bringing it all together 12

7 Conclusions: How much sharing? Just enough, but not too much 13

About the Author 15

About Analysys Mason 15

Copyright © 2012. The information contained herein is the property of Analysys Mason Limited and is provided on condition that it will not be reproduced, copied, lent or disclosed, directly or indirectly, nor used for any purpose other than that for which it was specifically furnished. Analysys Mason Limited | 818 Connecticut Avenue NW, Suite 300, Washington DC 20006, USA Tel: (202) 331 3080 | Fax (202) 331 3083 | washington@analysysmason.com | www.analysysmason.com

| 1

Ref: RX963 .

1 Executive summary

Business-to-consumer (B2C) and business-to-business (B2B) present different challenges to

communications service providers (CPSs). Many of the services are the same in both domains, but

there are also marked differences between the operations in each one of them. These, in turn, have

led to differences between the BSSs and OSSs that support them. New software technologies and

faster hardware are opening the possibility of using the same OSS and BSS systems for both B2B and

B2C operations, creating a truly universal BSS/OSS architecture. But what is the best path for a CSP

to take?

2 Introduction: Unified architecture across B2B and B2C or specialized silos?

One of the most difficult high-level decisions about OSS architectures is how large a domain should a

single OSS, or pre-configured set of OSSs, support? The answer to this question often determines the

success or failure of an OSS project. If the architects choose too small a domain, they provide

excellent focus and a doable-sized project, but may not provide enough benefits to warrant introducing

another technical solution in the architecture. If the architects choose too large a domain, they set the

stage for a long duration, difficult-to-implement project. In addition, the larger the domain, the more

difficult it is for an OSS to support the specific features required by all parts of the domain.

In this report, prepared at the behest of Comarch, Analysys Mason investigates the pros and cons of

OSS architectures that transcend two large domains: Business-to-Consumer (B2C) and Business-to-

Business (B2B) operations, with a special focus on the opportunity-to-cash function.

At one end of the spectrum, systems that support B2B and B2C could be separate, different systems,

driven by the technical, operations, and organizational differences – a vertical OSS architectural

approach. At the other end of the spectrum is the purely horizontal approach – a set of systems that

attempt to fully support both B2C and B2B operations (see Figure 1).

Figure 1: Unified BSS/OSS architecture versus specialized silos – Which is best?

[Reference: Analysys Mason, 2012]

| 2

Ref: RX963 .

Section 3 of this document shows that the importance of the consumer and business sectors is similar

to Communications Service Providers (CSPs).

Section 4 focuses on the differences in the operational characteristics of B2C and B2B operations

and investigates the differences between the B2B sub-segments – Small-office-Home-office (SOHO)

at one end, with major business accounts at the other end, with small, medium, and large businesses

(but non-major accounts) in the middle. It also describes the operational models used by the majority

of CSPs today.

Section 5 presents a deeper dive into today’s differences between B2B and B2C opportunity-to-cash

operational needs and speculates on their future directions as CSPs enter new businesses and

explore new business models. It also describes the operations architecture to support opportunity-to-

cash processes in mobile and fixed line environments.

Section 6 presents the pros and cons of the unified architecture across B2B and B2C versus a silo

approach, calling out the technical, business, and managerial issues that must be considered.

Section 7 summarizes the conclusions of the study and presents some specific recommendations.

3 Both business and consumer are major revenue contributors

Before embarking on an OSS architecture discussion, it is best to review where the money comes

from. Certainly the majority of customers of most communications service providers are consumers –

but how many business customers are there, and how much do they contribute to the revenue?

Numbers of customers rapidly decrease with size of the business

The number of consumers far outweighs the number of businesses, which drop quickly in number as

they get larger1.

Smaller CSPs get the majority of their revenue from individual consumers (B2C)2. Larger CSPs derive

more of their revenues from business services. Although the majority of the customers of these large

Tier 1 CSPs are consumers, only 25-30% of their revenue comes from that segment.

1 The definitions of small, medium, and large businesses vary considerably amongst operators. In the EU, the definition of

“small and medium enterprise” (SME) varies from those with less than 100 to 255 employees. In the US, it is typically capped at 500 employees. Small office/home office (SOHO) is generally agreed to be businesses of less than 10 employees.

2 There are exceptions, small CSPs who cater only to B2B, usually focusing on the small to medium business segment.

| 3

Ref: RX963 .

4 B2C and B2B operational differences

B2B operations differ from B2C operations in that there are fewer customers, but the services are

more complex, as shown in Figure 2. However, business customers themselves are broken into a

number of different areas, with the complexity of the services increasing with size of the business.

Figure 2: Customer classifications, with approximate revenues, according to scale and complexity

[Reference: Analysys Mason, 2012]

Most CSPs break the operations (and often supporting BSSs and OSSs) into two major groups:

• Custom operations supporting the major accounts, usually the top 50 to several hundred

accounts, provided with specialized handling. These accounts are each given their own CSP

contact numbers3, dedicated or semi-dedicated operations personnel, and their own,

customized procedures. A major account manager might meet the customer once a month to

go over the performance of the CSP with regards to meeting the installation due dates and

other Service Level Agreements (SLAs).

• Mass operations are used on the rest of the accounts, using extremely standardized

procedures, backed up by substantial automation to reduce costs. In many cases, the CSPs

establish a separate organization and operations support structure for the larger business

(non-major) and medium accounts – sometimes even the small business accounts. But the

processes are much the same as those supporting the consumer accounts – with different

3 “Hello, Dow Chemical Operations Center” might be a typical greeting for Dow Chemical employees calling that number.

Complexity of the Services

Consumer

SoHoSmall

Business

MediumBusiness

LargeBusiness

MajoraccountsHundreds

Thousands

Tens ofThousands

Millions

Num

ber

of C

usto

mer

s

Low Medium High

| 4

Ref: RX963 .

service bundles and costs.4 Operations efficacy is measured in bulk, on the basis of “Key

Performance Indicators” (KPIs). These are usually measured on weekly, monthly, and yearly

bases.

Figure 3: Characteristics of operations for consumer and business segments

[Reference: Analysys Mason, 2012]

Mass operations Custom operations

Large scale Moderate scale

Standard services Customized services per customer

Simple to moderately complex services Complex to very complex services

Transactions have a limited number of steps, complete in minutes to days.

Transactions take a long time to complete, with many steps, complete in days to months.

Few services per customer Many services per customer

Customized service bundles Unique service bundles

Standardized operations Customized operations

Overall KPIs, measured after-the-fact Per-customer SLAs, measured on an on-going basis

Figure 4: Differences between mass and custom operations [Source: Analysys Mason, 2012]

4 Verizon Business is an example of such an operation.

Complexity of the Services

Consumer

SoHoSmall

Business

MediumBusiness

LargeBusiness

Majoraccounts

Low Medium High

{{Major

Accounts:Top 50-250

{BusinessAccounts

ConsumerAccounts

Custom Operations

Mass BusinessOperations

Mass ConsumerOperations

| 5

Ref: RX963 .

The main differences between B2B and B2C operations include:

Operations scale

With up to tens of millions of B2C customers, opportunity-to-cash systems must be capable of many

thousands of transactions per day, versus hundreds per day for B2B operations processes. Also, there

are many more human system users that must be supported. This requires systems with strong,

optimized database structures and a good client/server architecture. Modern J2EE architectures often

require substantial tuning to achieve this scale, as do the databases to support the reports required.

Complexity of services

Whereas most B2C operations deal with standardized, relatively simple services, B2B operations must

deal with much more complex services and operations. This requires the systems involved to be much

richer in supporting IT personnel in creating new processes, reports, and tracking mechanisms and in

administering those already created. A VPN, for example, may contain several thousand network parts

and many thousand more parameters that must be set in hundreds of network elements.

Long persistence transactions

The transactions involved in B2B opportunity-to-cash processes can also have a persistence time

several orders of magnitude larger than the simpler, B2C transactions. This requires BSSs and OSSs

to have better software memory management, functionality to make changes to the services “in flight”

(as the customers’ needs and desires change during the long transaction cycle), and greater “looking

ahead” to ensure that the right resources will be available when needed. This last item inevitably leads

to an issue of making pending-on-pending changes. Services are promised on a date, assuming that

the resources will be available, sometimes requiring resource additions to the network. If these

additions are not completed on time, then the effect on pending transactions must be identified and

contingencies set. If there are a number of such interdependent transactions, then nth-level pending

on pending can rear its ugly head. Such systems are not unknown, but are much more difficult to

develop and manage.

Service bundles

B2B opportunity-to-cash transactions may have hundreds or thousands of parts, requiring interfaces to

a number of different systems and databases and large working storage for process management.

Operations processes

Optimizing a system for large, long-lasting transactions (B2B) is directly in opposition to optimizing a

system for a large number of smaller, shorter transactions (B2C). Compromises will, inevitably, have

to be made, if the systems support both.

| 6

Ref: RX963 .

Measuring and reporting operational effectiveness

Systems supporting mass (B2C) operations must be able to provide KPI reports on weekly, monthly,

and yearly basis, after the fact. Systems supporting custom operations must be able to do that, but

also provide SLA reports on a per-customer basis not only after the fact, but during the processes.

Projections on potential problem areas are also required for custom operations.

5 The opportunity-to-cash processes for B2C and B2B operations – differences in challenges

The overall opportunity-to-cash process involves both customer care and service fulfillment personnel

and systems, as shown in Figure 5.

Customer-facing systems vs. network-facing systems

Within the opportunity-to-cash process, there are network-facing systems (mostly the OSS and NMS

systems) and customer-facing systems (mostly the BSS systems).

Network-facing systems tend to be specialized in the network technology or a specific service – they

design and assign a single, or several, technologies. New ones are often implemented when a new

major technology is brought into the network – recent examples are IP/MPLS systems or those

optimized for fulfilling simple services that are provided by service delivery platforms (SDPs) such as

voice mail, video-on-demand, etc. Typically, a CSP has a set of a half-dozen or more of these legacy

systems dedicated to different services. A common strategy to reduce the number of these

systems is to put in a new, modern service fulfillment system for a new service and then, in a

phased transformation, expand its scope into other services. Projects spanning three years,

broken into a half-dozen phases, are fairly typical. But these usually still leave a number of stacks in

place – since many legacy systems are not worth replacing.

Customer-facing systems look to support the needs of customers. The definition of a “customer” is

getting more complex, since typically an account is not just an address (wireline) or a single telephone

number (mobile), but a set of these spanning families or businesses. These systems are more

influenced by the scale and complexity of the operations – differing greatly in requirements between

mass and custom operations, as described later in this document.

| 7

Ref: RX963 .

Figure 5: Customer-facing vs. network-facing systems in the opportunity- to- cash process

[Reference: Analysys Mason, 2012]

A typical opportunity-to-cash / service fulfillment information flow proceeds as follows:

• CSP personnel working with the customers, or customers themselves using self-service

systems, match the customer needs to the available, or customized, offerings. The

offerings for mass B2C or B2B operations increasingly become customized packages of

standard services, based on customer segmentation, micro-segmentation, social network

information. Customized operations also include direct consultation with the customer. These

are turned into orders and validated, via a combination of automated systems for standard

services or manual or semi-manual operations for custom offerings.

• The orders from CRM, self-service or subscriber management systems are passed to

customer order orchestration systems that decompose complex, multi-product orders and

orchestrate the overall order. These systems must be able to handle large numbers of

simultaneous orders and be easy to administer and configure for new standard services as

well as personalized service bundles. The usual technique for accomplishing this is to use a

catalog-driven approach, where standardized process fragments connected to the service

resources are assembled dynamically to create the overall customer order orchestration

process.

Customercare

Servicefulfilment

Consumer SOHOMedium &

Large BusinessLarge Major Accounts

Operations Segmentation

Consumer & Business Business Only

Voice Data Video SaaS Other VPN PL IaaS SaaS IT M2M

Service/Technology

Cus

tom

er-

faci

ngsy

stem

s

Net

wor

k-fa

cing

syst

ems

| 8

Ref: RX963 .

• Sub-orders are passed to multiple service fulfillment technology stacks for further

decomposition, management, design and assign, and activation.5 Some sub-orders go

to the systems of partner CSPs or third-party vendors.

• Activation systems are directly interfaced with customer order orchestration (or OM)

systems when a simple activation is required, such as many services provided by service

delivery platforms (SDPs), sometimes called the “service layer.”

• The BSS and OSS components each need data about the products and services required

to fulfill the orders. This is stored in a single, or multiple product catalogs, federated or

manually synchronized.

• Sub-orders are passed to the various service fulfillment “technology stacks,” where the sub-

orders are managed, designed, have available equipment or network capacity

assigned, and activated.

Figure 6: Modern service fulfillment information flow

[Source: Analysys Mason, 2012]

5 Modern order management, inventory and activation systems often service more than one technology, but there are usually

multiple stacks.

| 9

Ref: RX963 .

These operations are extremely standardized and automated to a large extent to keep operational

costs low and throughput high. However, they must be capable of adapting to the new generation of

offers that are increasingly personalized.

Custom B2B opportunity-to-cash operations

Custom B2B operations are designed for meeting specialized needs, providing maximum operations

flexibility and deal with long-term persistence of an order. Much of the process looks the same as in

the case of B2C operations, but with some important differences outlined below.

Figure 7: Modern custom order flow

[Source: Analysys Mason, 2012]

In B2B operations, before an order is taken, the CSP sales and engineering organizations get

involved with the customer to:

• Design and cost out a preliminary version of the service.

• Determine if additional network capacity or equipment is needed to fulfill the service and

initiate the appropriate procedures.

• Negotiate due dates with the customer.

• Confirm the order with the customer and reserve the network resources and end user or

premises devices (if needed).

| 10

Ref: RX963 .

After the order is validated, it follows the same basic process as in B2C, mass operations, except

for the need to:

• Reserve network capacity and assignable equipment and IP addresses for the order.

• Potentially, initiate a project to add network capacity to selected sites.

• Direct a craftsperson to perform manual or semi-manual procedures on an NMS to provision

those services or devices for which there are no automated provisioning available.

• Make changes to the design at the customer’s request, even after implementation has begun.

Very likely, the order will change between the long time it is initiated and the time it is fulfilled,

requiring a process, either manual or automated, for handling these in-flight changes. This

requires backing out parts of the order that are no longer needed and adding new parts to the

order, the order management process, and the tracking system.

• Activate and configure certain equipment that is not interfaced to an activation system. In this

case, manual work is performed using an interface to the network management or element

management system that comes from the network equipment manufacturer (NEM). VPNs are

often configured using this technique.

• Test the overall service prior to delivery.

• Track the implementation, reviewing critical dates to implementing on time and scheduling

and performing mitigation actions if not on schedule.

These operations are less standardized and less automated than the mass operations. This is a

potential barrier for cost reduction.

Mobile vs. fixed network operations

Today, in the mobile domain there are often few differences between a consumer account and a

business account – the latter simply has more users in the account. In these cases, the CSP’s

operations personnel is not much involved in the enterprise’s operations – the enterprise’s Telecoms

or IT department handles much of the customer-facing work while the CSP treats them basically like a

mobile virtual network operator (MVNO).

The service fulfillment “stacks” do not exist in this case since services do not need to be designed in

an engineering sense, just assigned and activated. If a customer’s account contains both mobile and

fixed network services, then a unified customer care system is an operational requirement.

6 Supporting B2C and B2B operations with the same systems

Given these differences and similarities – what are the main considerations behind the decision of how

much sharing of systems should there be in a CSP’s BSS and OSS architecture?

| 11

Ref: RX963 .

a. Technical considerations

We have seen that most of the network-facing systems care little about who is the customer,

specializing in the network technologies. These can be consolidated via a phased transformation

project to provide a unified architecture, up to a point.

The customer-facing systems considerations fall mostly on the order orchestration and order

management components, along with the product and service catalog(s). These have been

implemented mostly on the mass (consumer and business) operations side, where speed and

efficiency are needed. They need the ability to adapt quickly to personalized, complex order bundles

and new standard services. To be used for the custom operations side requires the ability to have very

large, long-lived operations processes that can be easily configured for the particular order for the

particular customer.

We also found that the reporting functions are significantly different, with mass operations focusing on

KPIs measured mostly after-the-fact and custom operations focusing on SLAs, managed on an on-

going basis.

b. Business considerations

In a green field situation, implementing a single, unified OSS and BSS architecture would bring the

greatest benefits. Large vendors provide such solutions, with increasingly pre-configured systems that

are pre-loaded with many services, current operational processes, and reporting structures.

But most CSPs find themselves with a large legacy system footprint, often with systems that do not

meet modern software standards nor can be ‘stretched’ into new areas. Thus, systems that are

targeted for replacement by a more unified architecture are often are those that:

• Cannot easily adapt to the new TeleManagement Forum SID data standards.

• Are not easily integrated, having no service-oriented architecture (SOA) interfaces available,

nor easily added.

• Cannot easily adapt to the high rate of new service innovation coming from the SDP service

layer, thereby becoming the critical path item for new service introduction.

• Are not flexible enough to deal with the increasingly sophisticated personalization of service

bundles aimed at individual accounts.

• Are home-grown or bespoke systems whose high maintenance costs justify system

replacement.

While most operators stay away from disturbing:

• Large legacy systems that have a very large number of interfaces to many systems that would

be very expensive to reverse engineer and re-implement on a new system.

| 12

Ref: RX963 .

• Systems that focus on older, waning services such as TDM private lines or frame relay

service. These are usually best to leave alone, allowing them to fade away with the services

they support.

c. Organizational considerations

We have seen that the operational characteristics of consumer, SOHO, small and medium business

operations are similar. These can use the same systems for the most part. However, if the systems

must support organizations from two different operations groups far apart managerially, the

problem becomes a management, not a technical problem. Budgeting and decision-making about the

priority of features on the systems selected would have to be coordinated between, or among, the

operations groups supported, requiring a high-level managerial mandate to do so.

d. Future considerations

The next generation of opportunity-to-cash processes will be faced with growing challenges in several

areas that will alter the landscape:

• Increasing personalization of offers and (more flexible) services will make the B2C needs

more closely resemble the small to medium business market, requiring more flexibility, but the

same high level of automation

• New cloud-based software as a service (SaaS) offerings will increase the complexity of

small and medium business offerings and operations

• The need for greater speed, accuracy, and control of large business services will drive

the requirement for more automation – but requiring a high degree of easy-to-implement

operations customization

• Self-service by all customers will drive the need for instant service availability for all but the

most customized services

• The new generation of machine to machine (M2M) services, especially for mobile CSPs,

will require unprecedented operations scalability for fulfillment processes for business

customers.

These all together mean that the areas that now require the most automation will also need more

customization, while the areas that currently require customization will require increasing automation.

Thus, the needs of the two disparate areas will become more similar over time, lessening the benefits

of silo-based operations, and operations systems, architectures.

e. Bringing it all together

Systems that seek to support both mass (B2C) and custom (B2B) operations face managerial,

business and technical challenges. These systems have to be capable of handling both complexity

| 13

Ref: RX963 .

and scale and be flexible enough to adapt the constantly-changing services of modern CSPs. Figure 8

below shows three architectural options for system sharing, with their pros and cons.

System architecture Positive Negative

Single system with shared database

and hardware platform

• Lowest Total Cost of Ownership

(TCO)

• Integrated product catalogue

• Standardization of common

processes

• May increase innovation velocity,

as features are immediately

available to all shared areas.

• Requires shared budget and

priorities across organizational

boundaries

• Technical compromises between

high-volume, small, short-lived

processes and low-volume, large,

long-lived processes.

• Legacy systems for some

functions are already in place.

Same system with separate instances

and separate databases

• Can be tuned to the different

needs

• Separate or federated product

catalogues

• Fits the organizational structure,

making priority setting and

budgeting easier.

• Higher TCO

• Cost of federating catalogues or

operational complexities of

separate catalogues.

• Development and performance

costs of multiple interfaces to

many of the same systems

• Processes, even when performing

the same function, will inevitably

become different.

Different systems • Can be optimized for the

operations the systems support

• Highest TCO

• Most complex architecture

Figure 8: System architecture options when considering sharing a system across boundaries – pros and cons

[Source: Analysys Mason, 2012]

7 Conclusions: How much sharing? Just enough, but not too much

“How much should B2C and B2B operations be supported by the same BSSs and OSSs?” turns out

not to be quite the right question. Rather, the dividing line comes between mass operations, with large

scale and simpler transactions and custom operations, with smaller scale, more complex transactions.

In general, using the same system, or stack of systems, across the boundaries of mass consumer,

mass business, and customized business operations may lead to the most standardization and the

lowest total cost of ownership. However, the options for sharing the systems depend upon both

managerial, business and technical considerations. Best current practices have shown:

• Some specialized systems support the special needs of major accounts and must be

dedicated to them. These mostly are related to the needs of custom network designs and

service configurations for the major account customers.

| 14

Ref: RX963 .

• Network-facing service fulfillment systems which focus on the technology and services

that need to be provisioned are agnostic to the characteristics of the customer using them and

can most easily be shared. A phased transformation approach has been shown to provide

reasonable return on investment, but it is unlikely to be optimal to continue the process to

provide a single, unified, provision-everything stack.

• If a customer account has both mobile and fixed services in them, then a unified CRM

architecture is a requirement. However, the rest of the operations can remain separate – or

be unified, as long as an overall architecture, including a unified orchestration and product

catalogue layer is implemented.

• Customer-facing systems can be shared across all of the boundaries, but only if they

adequately meet the opposing requirements of operations scale, transaction complexity, and

administrative flexibility.

• Changes in offerings and service complexity will make the two areas more similar in the

future, increasing the benefits of shared solutions, but putting on the software systems the

difficult simultaneous requirements of scalability and flexibility.

| 15

© Analysys Mason Limited 2012 About Analysys Mason

About the Author

Dr. Mark H. Mortensen (Principal Analyst) is the lead analyst for Analysys Mason’s Customer Care and

Service Fulfillment research programs, which are part of the Telecoms Software research stream. His

recent interest areas include customer self-care, automation of fulfillment processes, and data and

software architecture for agile, real-time systems. The first 20 years of Mark’s career were spent at Bell

Laboratories, where he distinguished himself by starting software products for new markets and network

technologies and architecting the interaction of BSS/OSSs with the underlying network hardware. Mark

was Chief Scientist of Management Systems at Bell Labs, and has also been president of his own OSS

strategy consulting company, CMO at the inventory specialist Granite Systems, VP of Product Strategy at

Telcordia Technologies, and SVP of Marketing at a network planning software vendor. Mark holds an

MPhil and a PhD in physics from Yale University and has received two AT&T Architecture awards for

innovative software solutions. He is also an adjunct professor at UMass Lowell in the Manning School of

Business, specializing in business strategy.

About Analysys Mason

The only constant is change. What worked yesterday won’t necessarily work today. That’s why we look

beyond the obvious, seeing things from a client’s perspective so that a truly effective solution is delivered

every time. A key part of this is our international perspective. Business never sleeps, and with offices

spanning six time zones, neither does Analysys Mason.

Telecoms, media and technology (TMT) are our world; we live and breathe TMT. This total

immersion in our subject underpins and informs everything we do, from the strength and

reliability of our market analysis, to improving business performance for clients in more than 100

countries around the world.

At the core of our approach is a simple, but enormously powerful idea: applied intelligence. By harnessing

our collective brainpower we can solve real-world problems and deliver tangible benefits for our

customers. As a Japanese proverb says, ‘all of us are smarter than any of us’.

We’re passionate about what we do, with the focus and determination to take on and solve the toughest

problems to help our clients. We’ll rise to the challenge and enjoy it. In fact when it comes to problem

solving, there’s a real sense of ‘the tougher the better’.

It’s this unique combination of our applied intelligence, effective problem solving and the ability to look

closer and see further that makes Analysys Mason special.