Enterprise Product Management

Centralized vs. Federated – is there a right answer?

Catherine Michel — Mon, 19 Oct 2009 16:43:00 GMT

After a brief hiatus, I’m back to blogging! And having just spent the last couple of months deep in the bowels of a CSP advising on their product data architecture, I’m more passionate than ever about what needs cleaning up around the Telco product landscape.

So carrying on from my previous blog’s notion that sorting out the data challenge (PDM) of products takes supremacy over the process (PLM) challenge, let’s talk about the question that inevitably arises for managing the data...centralized or federated???

Where centralized asserts a common view and predominant master over all (or most) product data, federated supports a common view but is still slave to multiple masters.

On first telling, federated is the concept with which many people are most comfortable. On the surface it means less disruption to existing architectures and processes, whilst still achieving the single view of the product. Contrast that with centralized, which involves consolidation of data, changes in the direction and integration of data and changes to operations. With those optics, who would choose anything but federated?

Well, the answer lies deeper than glossy architecture. It is somewhere in the effect that the approach should have on the ability to manage data and the cost and time of doing so.

The reason federated seems so undisruptive is because it is undisruptive. It provides very little basis for change. A lot of work still needs to be done to create that single view, but everything else remains the same. Federated still requires multiple points of entry when creating or updating products / prices. Federated does not rationalize the view of products into something logical with which both the business and IT can relate and work together. Federated does not shift the organization into thinking in holistic product terms, rather than the traditional rate plan or network capability terms. Little change in this case does mean little benefit.

Centralized, on the other hand, gives the organization the opportunity to consolidate products into a standard, comprehensive and very useable view that is focused on component reuse and service enablement. Centralized gives the organization the ability to make changes in one place and disseminate those changes in an automated, error-resilient fashion. Unfortunately, one of the myths about centralized is that it would require major changes to existing systems and the repopulation of data. In fact, if done properly, the changes are limited to the new catalog and to the integration. Finally, and most importantly, centralized asserts real control over the thousands of pieces of data that sit dispersed across the BSS/OSS. This type of control effects real change in the organization and ties together the operations from the best possible perspective – getting the right products out to suit customers’ desires and needs in less time and at lower cost.

So, yes, there is definitely a right answer to the question of Centralized vs Federated.

PDM vs PLM: 4G implications

Catherine Michel — Tue, 18 Aug 2009 23:28:00 GMT

At this stage, it is worth defining some of the key components of true Enterprise Product Management (EPM) – Product Data Management and Product Lifecycle Management. This stage-setting is particularly relevant as the industry embarks upon yet another generation of network technology and all that it promises... 4G!

The expectations of 4G are similarly large to 3G, but without all the hype. While 3G promised a whole new world of wireless services to great fanfare, it took its time in materializing and eventually under-delivered; in contrast, 4G is expected to actually deliver on its promises of ubiquitous services at even higher speeds in a much shorter timeframe.

Which means the pressure is on for CSPs to define and exploit the capabilities they will introduce with 4G.

The question of what and how they introduce these new capabilities is the definition behind and difference between Product Data Management (PDM) and Product Lifecycle Management (PLM).

PDM is the creation and management of the data specifications that define the capabilities from a systems and network perspective. So all the pieces of data that define how the 4G services will function in the BSS/OSS, within the SDP and on the network. The PDM emphasis with 4G will be on system and network definitions for the high levels of service and speeds of delivery.

PLM is the process through which the capabilities are defined and the version managed through their lifecycles. So the steps the CSP will take to eventually deliver and then manage the 4G services. The PLM emphasis with 4G will be on how quickly the 4G services will be operationalized into the CSP’s infrastructure.

In my humble opinion, whilst PLM is important to 4G, I actually see PDM as the critical function. I say this for a couple of reasons. Whilst PLM is a pretty messy prospect for most CSPs today, they tend to at least have well-defined paper based processes and handovers that allow them to successfully run a product development project. Sure, every CSP could do with a capability to manage the PLM workflow and the projects themselves, but the real bottleneck lies with PDM. Inevitably, every product development project falters when it comes to defining the system and network specifications for new capabilities / services. It takes way too long for cross-system analysis and data definition. And because data definition is what ultimately operationalizes the services, this activity is really what is at the heart of delivering a new product development project.

So with 4G, CSPs have a real opportunity to address their PDM challenges at the root. Introducing a product and service information MDM / catalog, which is what a PDM solution is, should be one of the key infrastructure decisions taken as part of the 4G capex. This decision will serve both the short and long game: short term it will provide the 4G product development project with a central data design specification to deliver the systems requirements; long term it will provide the CSP with a centralized and rationalized master of their 4G, 5G, 10G, etc capabilities that can be more proficiently (i.e., better, more innovative products to market) and master efficiently (i.e., faster and cheaper products to market) managed.

Which side are you on?

Catherine Michel — Sat, 01 Aug 2009 09:24:00 GMT

It sometimes seems unnatural as a CTO to be hawking the wares of what is otherwise a Marketing concern. But whilst instinctively clutching to the "build it and they will come" theory, I cannot ignore the "give them what they want" notion.

You may be asking yourselves right about now "why do I care about this prattle"?

Because it is the intersection of these views that lie at the heart of the future of the CSP industry.

(For those die hard EPM fans, I will revisit just what EPM comprises in future blogs; but for now I want to spend just a little more time on why we care about it in the first place!)

So let's break it down.

In the "build it and they will come" camp, traditional service providers have spent decades investing in the network. Over time, they have discovered how to introduce all sorts of clever capabilities (i.e., services) on top of the network infrastructure. Development of capabilities has largely been driven by inventive minds (and a few accidents) discovering new technologies and new ways of using it.

Nothing wrong so far...

Along comes the boom of content. More and more capabilities (i.e., application services) being developed outside the confines of the telco's own SDLC, but still exploiting the power of the network.

Still looking good...

Then the "give them what they want" guys show up. In response to competitive and cost pressures, someone has the responsibility of exploiting all the brilliant development work done to date in order to retain customers and drive up ARPU.

Wait for it...

So they have a look into their portfolio to see what options they have.

Um, portfolio? What portfolio?...And POW!

The "give them what they want" guys discover they don't know what they have to give because there is no portfolio. And therein lays the fundamental problem. It is almost impossible to get a complete inventory of what is available because it does not exist. Sure, you can query the billing system and get a view of the existing service plans and promotions; you can query the CRM system and get a view of the offers currently up for sale; you can query the network inventory and provisioning systems to get a view of what services are available in the network.

But there is nothing you can query and, more importantly, use to manage all the elements at your disposal (including that 3^rd party content) to assemble or reassemble and launch a product in your portfolio.

And this is where I come back to my CTO roots. There are millions of pieces of data spread across the B/OSS that only when assembled together in a rational, componentized fashion do they become a portfolio. Today, the lack of such a capability is not a business stopper. But it is a business crippler. And increasingly so as the number and nature and source of services continue to increase. You cannot control or exploit what you cannot see.

So which side are you on - "build it and they will come" or "give them what they want"?

In the spirit of love, peace and harmony, I hope the answer is both!

Yes We Can, to borrow a battle cry

Catherine Michel — Thu, 09 Jul 2009 23:09:00 GMT

Whilst preaching to the choir can be quite reassuring, it is hardly world-changing. So I have spent many years using whatever platform available to convert non-believers in the CSP industry to embrace the concepts, practices and solutions of Enterprise Product Management. Along the way I have encountered my fair share of sceptics and, in some cases, complete disregard...

...but, those who know me know I am a hard person to ignore.

So welcome one and all to the inaugural issue of my TM Forum blog – my latest venue for encouraging what was once the unthinkable: turning this industry into a “product-centric” one.

Throughout my postings, I promise to practice uncharacteristic restraint, by publishing only once every other week. However, in each issue I will unreservedly call it as I see it. Honesty is always the best policy. And so is brevity; so my last promise is to keep it short.

I will get started by calling attention to the fact that the CSP industry is experiencing an identity crisis. And that this crisis is rooted in the fact that CSPs struggle with the notion of what “products” they sell. Indeed CSPs sell a lot of things. But articulating it is another matter: one is usually met with quizzical looks or inconclusive answers when asking “what do you sell” or “how many products do you have”. The best answer usually amounts to pricing plans; hardly an appealing foundation upon which to devise and operate a business strategy.

And as content has exploded onto the market, access to which circumvents the traditional hold CSPs once had on customer contact, the traditional CSP needs to regroup and ask itself what business they are really in. The answers can vary – full service, retail centric provider; intelligent conduit reseller; dumb pipe; a combination of the above. But getting to that answer and devising the correct product portfolio accordingly is the key to CSPs focusing on the right end customer.

This is not just marketing fluff. The existing lack of clarity bleeds over into a costly operational approach to managing the business. If products are what we sell to the customer, why is it CSPs usually ignore efforts to manage products explicitly, thus hiding the cost of poor product management? Money is poured into “caring for the customer”, billing the customer, managing the network. Very little direct investment is made in managing the product set. The result is quite frankly band-aid solutions that lead to rickety, one-dimensional excuses for product catalogs; hard coded processes for product and service fulfilment; preoccupation with shiny toys in the network.

No single person is to blame - this is a result of how CSPs have developed and evolved over time. And with so many brilliant people in this industry we have the wherewithal and intelligence to solve this problem. And this is where my blog journey begins...