“I’d like to get your thoughts on how to execute an OSS transformation program. As the OSS (or the OctopOSS as you put it) is made up of Fulfillment, Assurance and Inventory as major pillars / building blocks, it would be quite a big task implementing all these all at once.
Should the program start with certain pillars first before others? Any dependencies that need to be accounted for?”
This is a brilliant question asked by a reader. Mikey has been kind enough to let me share the response with you in this blog entry.
It sure can be a big task implementing all these things at once. Not only is there the technical challenges, but there is also the organisational change that is often an even bigger challenge! (you can read more about that at http://passionateaboutoss.com/oss-implementations/oss-change-management/)
But back to the question…
Every situation is different, so there’s no one-size-fits-all answer (eg one organisation may have a business imperative to get inventory locked down and reconciling to prevent revenue leakage, another may have an OSS vendor that delivers all of these as part of core products [but it will still need lots of work to get it functioning as you need it], etc).
But all things being equal, I would tend to take the following approach:
- As mentioned in the change management link above, you want to build momentum as quickly as possible and get the teams seeing visible progress as quickly as possible. I tend to do this by getting a base-level sand-pit environment set up to get people familiar with the product as it helps them see the future benefits as well as getting their head around what’s needed for the project and how it can be customised to suit the customer’s organisation
- Again to build momentum, and to follow the “smallest executable steps” approach, I tend to try to get a base level of assurance up and running first. For example, most alarm management tools support SNMP traps through compiling MIBs, so it can often be quite quick to get raw alarms into your alarm management system from your live network. That gets quick wins and excitement from the customer team. You can make all your refinements (eg alarm suppression, fault workflows, augmentation, etc) done later on
- Next quick win is collecting raw data for performance management, particularly if you have SNMP or XML-based performance counters available from your network. Just like alarm management, if you can get raw data into your performance manager, you’re showing exciting progress. Refinements such as thresholds, threshold crossing alarms, etc can be done later.
- Inventory and fulfilment are often much more complex, although basic services like IN (Intelligent network) services such as calling card provisioning can be relatively easy because resource checking is simpler or not required. But as a rule of thumb, most service / fulfilment functionality will rely on an accurate understanding of the inventory / resources that they will use. So, that means I’d normally tackle inventory before fulfilment
- There are two ways of tackling inventory – via data creation / migration or via discovery (or a combination of both I guess). I tend to prefer taking the discovery path because that’s going to be your long-term solution anyway (most likely) so you might as well build that rather than going with a temporary load first
- Then comes fulfilment, but noting that you’ve probably actually started the fulfilment planning stage much earlier… because you will need to understand the organisation, business unit structure, business processes / workflows, products, approvals, life-cycles, work orders / activities and so forth. This usually takes a significant effort to map into a new OSS. Fulfilment also tends to have the most complex automated provisioning unless the NMS / EMS / NEs that you’re writing to have advanced error checking and error handling functionality.
There are many different dependencies, but again these are dependent on the tools, people and processes in each different situation. For example, some OSS are very data-driven, which means they need a lot of reference data loaded and cross-referenced before the system will function. But on the up-side, these systems also have a lot more cross-referencing which makes the analytics on them more powerful. Others are less dependent on data, making the inventory migration phase easier, but I don’t find them as insightful (or much harder to gather insights from).
I’d also strongly suggest doing a risk analysis (http://passionateaboutoss.com/tools/oss-risk-register/).
Oh, and by the way, I always starting by mapping out a WBS first so that I can get a big-picture view of all the pieces of the project that I need to consider (http://passionateaboutoss.com/tools/planning-a-project/)Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email