“How important is it to synchronize product catalog and service catalog, specifically who needs to master what to fulfill order orchestration and fulfillment processes? Should one be the master over the other? And is it important to have just one Catalog view from an operational perspective?”
Great question(s) from a subscriber named Mikey.
Let’s start with one concept. OSS/BSS usually fail or under-deliver because of complexity so I try to keep everything as simple as possible. Unfortunately the product development teams tend to want to build all sorts of tricky models (eg bundling, promotions, discounts, etc). Since the products are up-stream of everything else, the more complexity you have in the products, the harder it is to contain complexity in down-stream systems such as OSS, CRM, etc.
A similar question is how standardised vs bespoke are the services you offer to your customers? For simplicity, I much prefer that all products should be standardised and they become building blocks that the service catalog can define and roll out time after time. However, some companies have business models that are dependent on delivering bespoke solutions for their customers, so my preferred approach needs to be tweaked in those scenarios.
If you go with the standardised services model, then it makes sense that the product catalog should be master. If you do bespoke solutions, then your service catalog will need the flexibility to accommodate standard building blocks, plus custom variations per order that might not be reflected in the product catalog.
The tricky part is to build these catalogs in such a way that operators will be able to answer customer calls easily. For example, if a CSP runs special promotional pricing for all customers for one product for one month, but also has a customised promotion for one VIP customer for 6 months, your operators will need to be able to identify the specifics for each customer to answer their calls correctly. You can see why I say I wish those pesky product teams wouldn’t be so innovative with their models right?? 🙂
You can also see why product and service catalogs have to be planned in conjunction with CRM, SLA, BSS and OSS tools, where the catalogs usually end up as master (or at least higher-order) over those other downstream systems too.
Now for the question about the single catalog view… This is also an interesting one. Let’s say that you’re trying to orchestrate a service that is a mixture of physical cabling (customer lead-in), transmission (PDH/SDH/DWDM), IP (switches, routers, firewalls), cloud (servers, storage) and perhaps even other domains such as third-party content providers? If your catalog can handle all of these domains and can send provisioning commands (manual or physical) to any domain, then it is possible to have a single catalog and workflow engine.
However, let’s say you have a IP-centric service catalog that can orchestrate services across IP & cloud, but not the transmission domain, nor generate manual work orders for the field work-force doing the cabling. In this case, you need some sort of workflow engine that can sit above more than one catalog, field workforce tool and/or provisioning engine. You can see how your service designs, procedures and available tools can effect the approach you take to the hierarchy of functionality!
Your architectural approach will be driven by the capabilities of the different catalogs, workflows, provisioning / orchestration, etc tools that you have available. What domains do they cover? How do they handle product vs service or do they bundle together and how does that relate to your organisation structure and the responsibilities of each business unit? How do they handle standardisation vs bespoke offerings? How do they handle simple (eg pre-paid) vs complex (eg multi-domain) services and which do you offer? How do they interact with other systems like billing, inventory, etc? How do they handle simple (ie sequential) vs complex (ie decision gate) processes?
There’s less black and white, more grey in the responses to these great questions from Mikey unfortunately!