Salesforce

Industries
Communications –
Catalog-Centered Design

by Michelle Emanuel
Salesforce Industries Global Practice Director
 Table of
Contents
2. Introduction 3 Structuring an EPC with
Salesforce Industries 19
An Overview of BSS/OSS 5
Object Types 19
The Foundations of a CSP’s
Digital Transformation 6 Inheritance 20

Selecting an EPC Framework 8 Products 23

Commercial Catalogs 8 Decomposition

& Orchestration 24
Technical Catalogs 8
Summary 26
Considerations for a
Catalog-Driven Approach 11 Works Cited 26

Modeling an EPC Using the Author Biography 27

TM Forum Framework 14
Certifications 27

Table of
Figures
Figure 1: Relationship of BSS Figure 6: Vlocity View of TM
and OSS 5 Forum Layers 18

Figure 2: As-Is-To-Be 11 Figure 7: Basic Object Types 20

Figure 3: Simple Product, CFS, Figure 8: Object Type Inheritance 20

RFS and Resource Spec. 12
Figure 9: Inheritance “IS-A” 22
Figure 4: Simplified Model 13
Figure 10: Product Offerings 23
Figure 5: Simplified Information Framework
(SID) 16
3. Introduction

D efining and maintaining a product catalog is a daunting challenge. Product managers

and others with similar roles must be able to introduce products quickly and
efficiently. Just as products are introduced, they also must be removed, and product
managers need the ability to sunset or make products no longer available with the same
ease. What this all means is that modeling and creating a catalog must be done in such a
way that maintaining and scaling it will be user-friendly and cost effective.

This document presents an overview of how Salesforce Industries Communications can

enable communications service providers (CSPs) to develop and support an Enterprise
Product Catalog (EPC). An EPC is a unified solution for managing a CSP’s communications
products, tariffs (pricing), rental charges, bundles, and network services. There are many
factors in modeling and implementing a product catalog; this eBook presents one point of
view on how to approach this task. It includes modeling an EPC using industry standards
and stresses the importance of having an overall plan for the catalog’s design. It is not
meant to be a comprehensive “how-to” document and should be read with this in mind.

Often a CSP’s introduction of an EPC is done during a digital transformation, which is the
launch of digital technology into all areas of a business, fundamentally changing how the
CSP operates and delivers value to customers. It’s also a cultural change that requires
organizations to continually challenge the status quo, experiment with what they can do,
and get comfortable with failure. Not all decisions will result in success, but all decisions
will result in a learning experience and provide valuable information to move forward.

The events that precipitate a CSP’s decision to invest in a transformation are generally due
to either:

» The CSP reaching their capacity with the legacy systems.

» Or some of the systems within their architecture becoming model discontinued

(MD) or sunset.

When a CSP engages in a transformation of its product catalog, it must develop a model
that understands the relationship between products and services, as well as fulfilment
tasks. Before discussing catalog modeling and creation, it’s important to understand the
EPC’s role within an overall digital transformation and the significance of a catalog-driven
architecture.

The Business Benefits of an EPC

 A CSP is in business to sell products and services.
To sell these products and services, they have
4.
to be presented to potential customers, and the
EPC is the mechanism for doing so. Based on
this view, the catalog becomes the center of the
overall transformation as it is where all products
and services will be represented. By developing an
enterprise-wide, centralized EPC using Salesforce
Industries, a business can achieve a series of
benefits:

» Decrease the time to market for new

products, bundles, and offers.
» Develop greater agility with the ability to
quickly respond to marketplace trends with
the right products or services at the right
time, opening greater business opportunities.
» Increase customer satisfaction based on
using new strategies and tech platforms
that enable a greater focus on customer
experience.
» Gain the ability to continue evolving with
ongoing Salesforce Industries innovations
and keep up-to-date with customer
expectations.
» Reduce dependencies on legacy systems as
the EPC is enhanced and further phases of
the transformations are completed.
 An Overview of BSS/OSS
In communications, BSS/OSS refers to the Business Support System and the Operation
Support System, respectively. These two concepts define a line between the operations of
the network and business in the communications system (see Figure 1). The commercial
5. catalog fits into the responsibilities of the BSS and the technical catalog of fit within the
OSS framework.

Service
Assurance

Billing and
Revenue
Management OSS

BSS Service
Fulfillment

Customer Figure 1: Relationship of BSS and OSS

Management

In the communications ecosystem, the BSS provides services to support the end customer,
either through direct channels or applications that provide services to the end customer.
Some of the main functionality provided by the BSS are:

» Product management
» Order capture
» Customer relationship management
» Billing

» Order management, which includes:

 Order decomposition
 Order orchestration
 Order fallout

The OSS examines the operations of the network, provides the capability to provision
products and services, and assesses the health of the overall network. Some of the high-
level functionality that OSS supports includes:

» Network service assurance

» Network operations
» Order fulfillment

The primary focus of this eBook will be on developing an EPC to fit within the CSP’s digital
transformation.
 The Foundations of a CSP’s Digital Transformation
6.
The digital transformation that the CSP undertakes provides a complete product, service
and resource model. The best practice for modeling an EPC is using industry standards,
which for comms is defined by the TM Forum1. A catalog-driven approach can be achieved
through the transformation using these industry standards.

Today’s customers want to make purchases from anywhere, at any time, on any device in
a fast-changing digital economy, so a catalog-driven approach is often needed. During
the transformation, the requirements to implement a catalog design should be achieved
without adding significant costs and by realizing a high level of automation. Hence, catalog
purchases must drive the downstream processes and automate the provisioning of the
customer’s selection, resulting in a positive experience for the customer. In addition to
addressing costs through the building and maintenance of the catalog an effort to address
catalog rationalization should be undertaken.

Catalog rationalization is an exercise in reviewing the products that the CSP currently
supports as well as evaluating the costs and revenue, with respect to each product. There
are several examples of CSPs that have undertaken this activity before starting the digital
transformation and have realized significant reduction as high as 80-90%.

1
TM Forum is the global industry association that drives collaboration and collective problem-solving to maximize the
business success of communication and digital service providers and their ecosystem of suppliers.
7.
 Selecting an
8. EPC Framework

T here are several ways to approach designing an EPC in Salesforce Industries Comms.
A product catalog is a long-term concept; time should be invested to use a framework
and design a structure that will support future needs for scalability and for product
evolution.

Salesforce Industries Comms provides the core components needed to configure,

integrate, maintain, and fulfill the product and service catalog – the EPC. The catalog
contains the commercial and technical elements needed to support the customer’s overall
experience:

Commercial Catalog
The commercial catalog includes the products, services, and attributes the end
customer will purchase. The capabilities allow the designer to identify complex
relationships and dependencies between products and promotions.

Technical Catalog
The technical catalog defines the technical products used in the decomposition
and fulfillment steps. It is a container where a commercial product is further
decomposed and orchestrated.

The decomposition process is responsible for enriching an order with the technical
information required for fulfillment during orchestration. The process will add information
that was not included in the commercial catalog. Once the order is decomposed, it is ready
to progress to orchestration.

Orchestration will arrange the steps for fulfillment to complete an order. The process
of communicating with external systems to provision an order is then directed to the
appropriate entity. Management of all these exchanges with external systems is directed
through this orchestration phase.
9.

Catalog-building capabilities give the architect a wide range

of choices on how to structure the catalog. The challenge
is in determining how to approach the decisions needed to
design the catalog.

Among the business considerations that should be

addressed in the product catalog design are:

» W
 here does the catalog have to be represented or
replicated?

» Where is the source of truth?

» How many products will be included?

» W
 here is the pricing source of truth? How often do
prices change?

» H
 ow are products and services configured, delivered,
tracked, etc.?

» W
 hat systems are involved in the provisioning or
fulfillment of the products and services once they are
purchased?
10.
 Considerations for a Catalog-Driven Approach
The product catalog is where all products consumed by individual consumers and
businesses are made available. The catalog also presents a visualization of product
11. structures and the relationships between the components, first in modeling and second in
the presentation.

When approaching the design and implementation of an EPC, start by understanding the
“as-is” product lifecycle management (PLM), if one is in place. If a PLM is currently not
implemented, it should be part of the design activities. The key is to achieve the modular
services with reduced technical complexity and variation, staying clear of the silos that are
in the process of being removed.

CURRENT FUTURE

Build a working
1
IT and Business relationship
1
relationships
Customer
2
Technology and Experience Focused
2
IT focused
Metrics collected with
Metrics collected 3 the view of the
3 customer experiences
on IT operations

Waterfall methodology Agile/Hybrid

4 4
and DevOps agnostic DevOps supported

Increasing costs Automation and budget

5 5
matched to demand
6 Projects done in silos
Multi-domain architecture
6
with common platform

Figure 2: As-Is-To-Be

Simplicity and reusability are paramount; look for commonalities to improve reusability
across all units to reduce costs and increase quality. Achieving this approach needs to
be methodical not only to build the foundation, but to avoid duplication for the future.
There are two models that Salesforce Industries supports; these are discussed in the
subsequent sections.
 »  lat model: This approach is only concerned with the resource-facing service (RFS)
F
layer and is generally modeled to facilitate integration with fulfillment systems.
Flat modeling typically has less complexity because there are fewer decomposition
relationships and mappings.

»  ierarchical model: This model is comprised of both the customer-facing service

H
(CFS) layer and the RFS layer. The CFS layer confers an abstraction of the RFS layer
12. that is less technical and more understandable from the commercial side.

The CFS are products and services that can be purchased or acquired by the end customer.
The opposite of a CFS is an RFS. The RFS supports the CFS but by itself is not a visible
product or service to the end customer. The RFS is used to “build” the CFS or to fulfill it.

Users of the information framework’s (SID) customer- and resource-facing service (CFS/
RFS) typically consider that one or more RFSs are associated with a CFS, with the former
specifying how it is configured within an enterprise’s resource infrastructure. They also
tend to assume that the association between a CFS specification and one or more resource
specifications themselves defines the types of resources that will be used to support a
CFS.

1
Figure 3: Simple Product,
CFS, RFS and Resource Spec.
PRODUCT
What is ordered

2
CUSTOMER FACING
SERVICE (CFS)
What is configured

3
RESOURCE FACING
SERVICE (RFS)
How it is configured

What it

4
represents
RESOURCE
What is used to configure it
 This can begin with a product such as a virtual private network (VPN), which is a CFS.
However, the end customers may not know that in order to provision their VPN, it may
require the configuration of a border gateway protocol (BGP) to support it. This indicates
13.
that the BGP is a RFS.

How is it
configured
What is

1
ordered
Product
PRODUCT
Configuration

2 SERVICE
Service
Configuration

What it

3
represents
Resource
RESOURCE
Configuration

Figure 4: Simplified Model

 Modeling an EPC Using the
14. TM Forum Framework

T he catalog designer can introduce and effectively manage a portfolio of products that
are relevant to customers, released at the right time at the right price. The cost and the
effort of managing each product and service should also be considered.

The catalog designer can also leverage a standards-based data model, such as a TM Forum
SID-compliant model, which offers modularized, reusable building blocks that enable
product and service associations. Salesforce Industries also provides a componentized
mechanism to achieve a reusable approach within an aggressive time to market.

For comms, it is recommended that the framework of the TM Forum be used, which defines
three levels:

» eTOM: This is the Business Process Framework, an operating model for CSPs. The
model describes the service providers’ required business processes, and it defines
key elements and how they should interact.

»  SID: The Information Framework (SID) is a critical component of the Open Digital
Framework; it provides standard definitions for all the information that flows through
the enterprise and between service providers and their business partners. Within
Salesforce Industries, the SID represents the catalog structure.

»  TAM: The Application Framework (TAM) is a subcomponent of the Open Digital

Framework from the TM Forum, providing a common language and a means of
identification for buyers and suppliers across all software application areas. It
provides a migration path from legacy IT systems and processes to modular, cloud-
native software. The framework comprises tools, code, knowledge, and standards.
 The intent is to modernize the process to achieve
the updated objectives. The components allow the
15. consolidation of a single, unified catalog with up-front,
role-based access and back-end system interoperability.
Using the TM Forum’s modeling framework will provide
the following benefits:

»  Reduce integration costs by adopting standards-

based information models and using them in
applications and interfaces.

»  Save hundreds of design hours by starting with

a mature framework and entities developed and
vetted by subject-matter experts.

»  Speed time to market by using well-understood

integration interfaces based on the Information
Framework, eliminating the need for data
translation between systems.

»  Avoid wasting development time debating the

structure internally with partners or vendors by
adopting a widely proven, industry-accepted, rich,
and extensible information model.
 Figure 5: Simplified Information Framework (SID)

Market/Sales
Market Strategy & Plan Marketing Campaign Contact/Lead/Prospect

Market Segment Competitor Sales Statistic Sales Channel

16.
Product
Strategic Product
Product Portfolio Plan Product Performance

Product Specification Product Offering Product Usage Statistic

Customer
Customer Customer Order Customer Problem Applied Customer Customer Bill Collection
Billing Rate

Customer Interaction Customer Statistic Customer SLA Customer Bill Customer Bill Inquiry

Service
Service Service Strategy
Service Applications Service Performance and Plan

Service Specification Service Configuration Service Usage Service Trouble Service Test

Resource
Resource Resource Topology Resource Performance Resource Trouble

Resource Strategy
Resource Specification Resource Configuration and Plan Resource Usage Resource Test

Supplier / Partner S/P Performance S/P Bill

Supplier/Partner S/P Interaction S/P Order S/P Problem S/P Bill Inquiry

S/P Plan S/P Product S/P SLA S/P Statistic S/P Payment

Enterprise Common Business Business Interaction

Party Location
Under Construction
Agreement Policy

The black ovals in Figure 5, Simplified Information Framework (SID2), indicate the:

» Product specification: The details of a product.

» Product offering: A product available to clients for purchase that includes pricing
information.
» Service specification: The details of a CFS.
» Resource specification: The resources needed to implement the CFS.

2
This version of the SID framework is not complete; it is used here because it is simplified and easier to understand.
17.
 Using these specifications for the product, service, and resource, an object type supporting
a hierarchical catalog model can be created. Object types are presented in detail in a later
section. The other definitions, found in the SID, can be used to further define entities within
the catalog. Those are outside the scope of this document.

The catalog, using the structure outlined in Figure 5, is generally divided into two parts:

»  A Commercial catalog is visible to the customers and contains:

18.
 Products

 Services

»  Technical catalog:

 Commercial products are decomposed.

 Then the decomposed products are orchestrated for provisioning.

The following diagram is taken from the Salesforce Industries documentation but serves as
a good representation of the commercial and the technical catalogs.

Salesforce Industries EPC = SID/TM Forum Model

Internet Spec
Attributes:
Product Spec Layer • Product Name: Internet Spec
• Commercial Code:...
• SLA:...

CFSS Layer
Customer Facing Service Spec
Base Internet
• Target Customer (new): Wholesale, Retail
• Protection Type: “Unprotected Circuit”
• Protected Circuit: “Partially Protected Circuit”
• Capacity: 1.5 Mbps, 2 Mbps, 34 Mbps

RFSS Layer TXEquipment SubMatineCable SDHAccessPort Trunk

Attributes Attributes Attributes Attributes
Resource Facing Service Spec

PRS/LRS Layer RFSS_Backbone RFSS_POP RFSS_LocalLoop

Attributes Attributes Attributes
Physical/Logical Resource Spec

Figure 6: Vlocity View of TM Forum Layers

The product spec, CFSS layer, and RFSS layer represent the framework from the TM
Forum and are being used to model the entire commercial and technical catalog. The PRS/
LRS layer shown is the layer that orchestration interacts with to configure and provision
various products and services.
 Structuring an EPC with
19. Salesforce Industries

F or the past several releases, Salesforce Industries has moved to supporting Lightning
Web Components (LWC), which are used by Salesforce Industries product designers,
whereas the legacy product console continues to use the Angular framework. The classic
console is still supported but will not be discussed any further.

The Vlocity Product Designer provides a unified user experience to manage EPC
elements in a single contextual interface. It is a web-based application for managing a
Salesforce Industries EPC that gives both business and IT users access to all the product
management capabilities needed.

Object Types
An object type is a reusable entity that defines properties such as fields, attributes, and
layouts for all product instances. It’s like a Salesforce record type but has additional
capabilities. It can be used to group products with similar characteristics and ensure
consistent behavior and application of rules.

Conversely, a Salesforce record type has the ability to create processes, picklist values,
and page layouts assigned to different users. It can be created to differentiate regular
sales deals from professional services’ engagements, offering different picklist values for
each.
 Figure 7 defines the base set of object types using the SID-defined framework. After
defining the first level in the hierarchy, inheritance can be used to enable further product
definition.

20.

Root
Based EPC
Object
Types

SID
Based Product Resource
Object Product Specification Specification Offering
Types Specification (CFS) (RFS)

Figure 7: Basic Object Types

Inheritance
The object types defined in the previous section will inherit from the definition, or the
entity above. From the object type, you can create a child object type and assign it specific
attributes. Any product linked to the object type will automatically inherit the attributes
from the parent object type, as well as any attributes of the child object type.

Root
Based EPC
Object
Types

SID
Based Product Resource
Object Product
Specification Specification Offering
Types Specification
(CFS) (RFS)

Product
Object Tablets Phones
Types

Figure 8: Object Type Inheritance

21. In Salesforce Industries, object types are designed as an “is-a” inheritance, meaning you
can create relationships between abstractions, where one object type is a subtype of
another object type. The primary type of object relationship used in building a catalog is
an “is-a,” which is fully based on inheritance. An example of this type of relationship would
be an apple is a fruit, a car is a vehicle, etc. Inheritance is one directional. For example, a
house is a building, but a building is not a house.

In terms of products that are common within an EPC, an iPad is a tablet, or an iPhone Max
is a phone. As stated above, these are single directional because an iPad is a tablet, but a
tablet is not an iPad.

This is where we see the value of inheritance. Often the children will have common
characteristics; hence, they can inherit from the parent object type.

It’s important to follow certain guidelines when creating object types:

»  Each object type can have only a single layout. There is only a single definition of
how attributes and fields will appear. Attributes are not all shared with all object
types and fields are common across all object types.
»  Within the layout management facets are pages (groupings) with corresponding
links that appear in the left navigation menu. Layout elements, such as fields
or custom uniform resource identifier (URI)-based elements, are grouped into
sections. These facets are defined when an object type is created.
»  An object subtype inherits the layout via deep copy, but any subsequent changes
to the object supertype’s layout are not replicated down the hierarchy after initial
creation. You can add or delete fields for each object type without altering the
layout with the addition of any fields on the parent object type. This allows for
variation in the inheritance line.
22.
Root
Based EPC
Object
Types

SID
Based Product Resource
Object Product Specification Specification Offering
Types Specification (CFS) (RFS)

Product
Object Tablets Phones
Types

Product
iPad Samsung
Specification
Galaxy

Figure 9: Inheritance “IS-A”

The product specification is a record in the product object. It is created from an object
type and inherits all fields, attributes, and layouts defined for the associated object
type. As shown above, an object type has a many-to-one relationship with the product
specifications. An example of this is a product specification where an iPad can have
multiple types or versions of iPads.
 Products
23. Once the product specifications are defined, they are then associated with prices,
promotions, and context rules to create offers or commercial products that customers can
purchase.

Root
Based EPC
Object
Types

SID
Based Product Resource
Object Product Specification Specification Offering
Types Specification (CFS) (RFS)

Product
Object Tablets Phones
Types

Product
iPad Samsung
Specification
Galaxy

Product
Offerings iPad Pro iPad Mini

Figure 10: Product Offerings

 Decomposition & Orchestration

24. In the decomposition and orchestration activities, order management (OM) uses the TM
Forum framework to provide guidance. The TM Forum defines the two main areas of OM as
follows:

»  Commercial order management (COM)

»  Service order management (SOM)

Salesforce Industries covers both COM and SOM in compliance with the TM Forum. Often a
CSP will use Salesforce Industries to implement both COM and SOM; however, at times only
COM may be implemented.

Throughout this document, the theme has been a catalog-driven approach. As a result, the
clarity between COM and SOM may not always be apparent. If SOM is addressed outside
Salesforce Industries, it is important to identify the services in the decomposition process.
As this is not a document focusing on OM, additional details are left to the reader to
investigate.

The goal of the OM is to take the products and services purchased by a customer and make
them operationally available for the customer. The OM application should allow for a gradual
approach to the ecosystem transformation without the need for a costly, risky paradigm
shift. It must also be able to communicate with all fulfillment systems in the stack.

As each order is received, order decomposition uses the catalog to enrich the commercial
order with the technical attributes needed for fulfillment. Following the order
decomposition, checks of the subscriber inventory will ensure the appropriate fulfillment
actions are taken based on the service a customer already has. Finally, order decomposition
generates a series of suborders, or fulfillment requests, that include the fulfillment tasks.

Once order decomposition takes place, the next phase is the order orchestration process.
During this activity the catalog will dynamically generate fulfillment actions based on the
order context. It will enforce any dependencies in the fulfillment actions, establish and
maintain connections to the fulfillment systems, and apply the correct logic to handle
connections. Finally, it interacts with external fulfillment systems such as inventory, billing,
and provisioning to exchange the data needed for fulfillment.
25.
26.
Summary

A s stated in the beginning, this eBook is not a “how to define a product catalog”
manual; it is meant to provide guidance to start the journey and suggestions on
initial areas of focus.

Salesforce Industries supports the tools to model an EPC; this allows customers of the
CSP to view various products and services. When customers have all the data they need,
they can make decisions and buy products more efficiently. Whereas the Salesforce
platform provides general-purpose CRM capabilities, Salesforce Industries takes it to
the next level and provides industry-specific capabilities. It is this industry-specific
functionality that will accelerate time to market and generally improve the overall
customer experience.

Works Cited
» Forum, TM. tmforum. https://www.tmforum.org/

»  locity Salesforce. “Vlocity Success Center.” Vlocity Enterprise Product Catalog (EPC).
V
https://docs.vlocity.com/en/Product-Definition-in-Vlocity-Enterprise-Product-Catalog--
EPC-.html
 Author Biography
Michelle Emanuel
Ms. Emanuel has more than 40 years of experience delivering
complex solutions for strategic clients, with an extensive background
in Salesforce Architecture, project, customer, and risk management,
and technical innovation. She has a master’s degree in both
business and computer engineering.

Certifications
»  Salesforce certified Administrator »  Salesforce certified Lightning Field Services
»  Salesforce certified Advanced Administrator »  Vlocity Certified Communications
» S
 alesforce certified App Builder Developer II Case Study
» S
 alesforce certified Service Cloud Consultant » S
 alesforce OmniStudio Consultant
» S
 alesforce certified Sales Cloud Consultant » S
 alesforce OmniStudio Developer
» S
 alesforce certified Platform Developer I » S
 alesforce Industries CPQ Developer
» S
 alesforce certified Lifecycle and » V
 locity Order Management Certified
Deployment Designer » P
 MP Certified
» S
 alesforce certified Integration Architect » L
 ean Six Sigma Yellow Belt Certified
Designer » L
 ean Six Sigma Green Belt Course work
» S
 alesforce certified Community Cloud completed
Consultant » L
 ean Six Sigma Black Belt Course work
completed

Wipro Limited (NYSE: WIT, BSE: 507685, NSE: WIPRO) is a leading global information technology,
consulting and business process services company. We harness the power of cognitive
computing, hyper-automation, robotics, cloud, analytics and emerging technologies to help our
clients adapt to the digital world and make them successful. A company recognized globally for
its comprehensive portfolio of services, strong commitment to sustainability and good corporate
citizenship, we have over 190,000 dedicated employees servicing clients across six continents.

Together, we discover ideas and connect the dots to build a better and a bold new future.