B/OSS Strategy_nb

Plus de détails

CRYPTOVERSE2

par Eric Phillips

CM - Chapter 3 - Why organizations change

par Sander van der Kolk

Map IEC/ISO 27001:2013 Annex A - English

par Grandt Grandt

Money

par Samuel Anderson-McCoy

B/OSS Strategic Options

Operating Model

Combination

Vendor-operated

UCSS-Operated

Delivery Model

Fully Outsource to 3PV

Manage Internally with Staff Aug

Fully Outsource to B/OSS Vendor

Hosting Model

Public Cloud

In vendor's data center

On-premises

Goals

Minimize Business Disruptions

As part of normal operations

To implement new capabilities

Ease of integration to other products

Adaptability and Extensibility of the product

To maintain technology lifecycle

Intrusiveness of product upgrades

Cost of product upgrades

Frequency of product upgrades

Faster Speed-to-Market

Enable agility

etc

Next-gen digital business architectures

Lower Cost

Lifecycle costs

Cost to deliver new capabilities

Operational Cost structure

Strategic Leverage

Increase level of transparency and trustworthiness in B/OSS vendor relationship(s)

Increase number of potential vendors for system operation

Increase number of viable alternative solution paths & vendors

Greater ability to challenge costs (see "Lower Cost")

Increase amount of influence on product roadmap

Enable New Business Capabilities

Adaptability of "out-of-the-box" features

Configurability

Openness of APIs

Products and Services

The next business model change like EIP

The next Shared data / Unlimited data / Rollover data

Lead & Prospect Management

LOB-Specific features

B2B & SMB

Prepaid

NW services, VoLTE, 5G and IoT

Personalized Recommendations (consistent across channels)

POS on Tablet

Integrated eCommerce

Technology Stack

Matrix Diversified "Best of Breed"

Cost and complexity surpasses the potential strategic benefts

Custom new product/s to comply with current business processes

Change process to comply with new products

Can't think of even a single carrier that transformed from best of suite to best of breed

Most Amdocs customers - other than those that implemented a full stack

Bell Canada

Tellus

Sprint

Incremental cost, time and complexity in building new business capabilities

Complicates testing

Complicates technical requirements

Accountability challenges

Manage multiple vendors

Reduced operational stability

Significant Development cost

Reoccur costs with any Upgrade

To achieve parity with productize stack

To implement interoperability changes in the Amdocs components that will be part of the new architecture

Other BSS components for which matrix diversity can be considered, but doing so can't be considered as "best of breed" architecture

Roaming Partner Manager

Service integration layer

Data Analytics

User Interfaces (self-care, Retail, call center, IVR)

Mediation (already non Amdocs)

Bill Document Design

Provisioning

Component choices

Enterprise Product Catalog

Ordering

Rating

Billing

CRM

Modify our BSS stackvconsisting of best-in-breed components for (some or all of) the following: CRM, Billing, Rating, Ordering, Product Catalog

Vertically Diversified "Parallel Stack"

Depending on business case: how much are we willing to invest (CAPEX and OPEX) for gaining these strategic benefits

Complicates leverage for billing projects 2+ moves ahead

Produces leverage for next-move billing projects

Incremental headcount to manage an additional stack

Depending how many new stacks

Depending on the operations model of the new stack

Depending on the hosting model of the new stack

Many business processes will be impacted

Custom the new stack/s to comply with current business processes

Change process to comply with the new stack/s

Some business process may need to be adjusted to become in compliance with the new stack/s (in order to reduce customization of the new stack/s)

Examples

Other case studies

TMO

AT&T

High Complexity

Likely 50+ Integration Points with existing 3rd party systems

Commissions

Cash Registery

Network Elements and/or Provisioning GW

SAP

Examples:

Duplicate vs. Shared components

Order Management - Duplicate

Product Catalog - Duplicate

Bill Design - Can be shared

Collections - Duplicate

POS Cash Registry - Must be Shared

Accounting and journaling - Must be Shared

Account Receivables - Duplicate

Rating - Duplicate

Billing Calculation - Duplicate

Provisioning - can be shared

Scope TBD: Provisioning, Customer-Facing UI, Service Integration, etc.

Out of Scope: Inventory, G/L, Commissions, Mediation, etc.

New BSS stack to include: CRM, Order Mgmt, Rating, Billing, Product Catalog, Payments, A/R, Collections, Applicable UIs

Introduce new suite(s) of BSS components to serve other LOB(s)

Leave Amdocs stack in place for core consumer postpaid LOB

Horizontally Diversified "Layered Architecture"

Develop a technology strategy for each business capability (tablet in retail store, Digital, Call Center UI) on a case-by-case basis, but while considering technology re-usability and channel consistency.

Don't proactively replace existing CES UIs

Depending on the technology approach for relevent business capabilities, some process changes may be needed

TOPS Backend

Require Amdocs to expose more / all APIs

Decouple from TOPS by leveraging a Digital technology and implement a unifed UI

Combinations of the above

Retail POS platform

Hybrid: Custom Lighweight UI with minimal embedded headless commerce product capabilities

Headless commerce product (e.g., Elastic path) and custom UI

Custom LightWeight UI based on NodeJS and Angular

eCommerce platform

Build non-Amdocs user interaction channels (UIs, etc.) on top of integration layer

Build non-Amdocs integration layer on top of CES backend components

Keep Amdocs components for core BSS functions (in the "backend" layer)

Fully Unified "Best of Suite"

Transformation Option

At this phase, do not invest further in anlyzing this option

Significant business impact

Huge cost

Has the potential to address many of the strategic goals

Technology

Complete new stack

Re-evaluate and possible re-design many business process to align with the new stack

Huge and lengthily effort to evaluate, and then learn, the new stack

Implement full suite of non-Amdocs B/OSS vendor

Incumbent Option

Recommendations

For every technology capability, evaluate Amdocs solutions vs. alternatives and make selection on a case-by-case basis

Raises the level of our partnership with Amdocs

Enable implementing some new business capabilities (POS on Tablet, Digital Services platform)

Limited ability to address many of our strategic goals

Depending on the technology approach, some process changes of business teams handling specific channels may be needed

Example: ecommerce team will rely on EPC for products, pricing and promotions

Additional Amdocs components to operate

Can include any of the following components:

Other Amdocs OSS components

Amdocs NFV solution

BriteBill

Amdocs Big Data Analytics

Call Center UI

Evolve to CIM to hybrid architecture that is partially based on UXF Widgets

Keep CIM as-is and continue to expand/customize as needed

Tablet solution in Retail Stores

Implement ARIM (based on UXF)

Digital channel

Dependency on TOPS Upgrade is yet TBD (probably feasible with Backporting to 8.1)

Integrated eCommerce - by design

eCommerce solution based on Amdocs Digital Service Layer product (UXF)

Headless - with our own-developed UI

With Amdocs UI

Description

Stay on Amdocs Product Path

Amdocs Retail Solution (POS on Tablet)

Amdocs UI products (fully or partially widgetized)

Amdocs Integration Layer (REST, Headless Widgets)

Keep Amdocs solution as-is

Implications

Strategy

Process

People

No impact

Technical

Do not deliver new BSS capabilities that requires stretching the existing stack

Design solutions to new business capabilities within the bounds of the existing BSS stack