Over the years in OSS, I’ve spent a lot of my time helping companies create their OSS / BSS strategies and roadmaps. Sometimes clients come from the buy side (eg carriers, utilities, enterprise), other times clients come from the sell side (eg vendors, integrators). There’s one factor that seems to be most commonly raised by these clients, and it comes from both sides.
What is that one factor? Well, we’ll come back to what that factor is a little later, but let’s cover some background first.
OSS / BSS covers a fairly broad estate of functionality:
Even if only covering a simplified version of this map, very few suppliers can provide coverage of the entire estate. That infers two things:
- Integrations; and
If you’re from the buy-side, you need to manage both to build a full-function OSS/BSS suite. If you’re from the sell-side, you’re either forced into dealing with both (reactive) or sometimes you can choose to develop those to bring a more complete offering to market (proactive).
You will have noticed that both are double-ended. Integrations bring two applications / functions together. Relationships bring two organisations together.
This two-ended concept means there’s always a “far-side” that’s outside your control. It’s in our nature to worry about what’s outside our control. We tend to want to put controls around what we can’t control. Not only that, but it’s incumbent on us as organisation planners to put mitigation strategies in place.
Which brings us back to the one factor that is raised by clients on most occasions – substitution – how do we minimise our exposure to lock-in with an OSS product / service partner/s if our partnership deteriorates?
Well, here are some thoughts:
- Design your own architecture with product / partner substitution in mind (and regularly review your substitution plan because products are always evolving)
- Develop multiple integrations so that you always have active equivalency. This is easier for sell-side “reactives” because their different customers will have different products to integrate to (eg an OSS vendor that is able to integrate with four different ITSM tools because they have different customers with each of those variants)
- Enhance your own offerings so that you no longer require the partnership, but can do it yourself
- Invest in your partnerships to ensure they don’t deteriorate. This is the OSS marriage analogy where ongoing mutual benefits encourage the relationship to continue.