OSS Vendor Selection & Transformation

The hardest choices in life aren’t between what’s right and what’s wrong but between what’s right and what’s best.”
Jamie Ford

Have you already experienced an OSS / BSS transformation? The process of transforming your OSS / BSS is full of potential pitfalls isn’t it? There are soooo many potential risks and issues to think about and overcome.

We’ve been through dozens of OSS / BSS transformations. Whilst every one of them has been different in many ways, we’ve sought to create building blocks along the way. These building blocks have been designed to make the process more repeatable and less risky. We continue to refine the process and customise for each customer’s unique situation. The link below provides a high-level overview of the process we follow:

Download the Passionate About OSS Transformation Methodology here.

When conducting an OSS / BSS vendor selection process, the customer is effectively choosing a strategic business partner. It is likely that the solution will remain an important tool for the CSP for many years. Whilst benefits, functionality and technology are important evaluation factors, it’s also important to choose a vendor / integrator that is able to form a tight-knit business relationship with the customer.

Whilst we identify key factors for the CSP to determine their appropriate vendor, by correlation it will also identify key insights into how a vendor should position itself or differentiate itself to best form a lengthy relationship with the CSP.

We are clearly of the opinion that selling is about giving the customer what they need rather than trying to sell them on a product. As such, the vendor’s solution must be positioned such that it best meets the customer’s needs and this can only occur through a close understanding of the customer, their business model and where they are in the business life-cycle. Our vendor selection mechanisms allow the vendor to understand the CSP better and hence be able to deliver a more specific solution to meet their needs.

In some cases, the vendor may even be able to provide insights and present opportunities directly into the CSP‘s business model that the CSP was never even aware of. Clearly these OSS solutions are a means to an end (business benefits) rather than an end unto themselves (software functions), but the CSP‘s evaluation teams often focus on the latter.

OSS Vendor Selection Process

From the link above, the following is an example of a vendor selection process that I  use to kick off discussions with customers.
PAOSS Vendor Selection Methodology
You’ll notice that it includes conducting an initial shortlisting process to identify the vendors who have the tools of best fit for your requirements, followed by detailed product/vendor analysis, then through to commercials and contract.

If you need assistance with your vendor selection process, please leave your details via the contact page. We have a set of templates refined through helping many customers to select their OSS vendor that may also help your vendor selection.

OSS Pricing Estimations

Naturally, pricing is a major consideration when choosing a vendor product. Each vendor has a different model for pricing their solution, which makes it very difficult to estimate the real TCO (Total Cost of Ownership). There are so many variables when finding the right OSS for a customer’s needs and the vendors have so much pricing flexibility that the best way is to design a set of requirements and request a quote. That’s the reason the RFI (Request for Information) and shortlisting steps have proven to be so important in the process flow shown in the diagram above.

Vendors know that OSS tools are very sticky and they often make it difficult for a CSP to remove them after they have been installed. As such, vendors know that the tools will remain in use for many years and can build their pricing model around this. This could include lowering the up-front costs significantly but reaping greater remuneration during subsequent years.

This blog entry provides initial rules of thumb for estimating the cost of your OctopOSS. It should be clearly noted that the variables are many so cost analysis requires a deep investigation of the vendor and their offering.

Some of the fundamental pricing questions for the vendor/s include:

  • What licensing model do you use – Examples include per user, per concurrent user, per processor (ie servers and/or PCs that the applications are installed upon), open-source and/or cloud / consumption-based models. It also includes whether the licenses are recurring (eg annual) or perpetual. Annual licenses are often intertwined with the support fees (see next point)
  • What warranty / support model do you offer – Examples include business hours only, 24×7, on-site support, remote support, etc. This also includes response times and other service level agreements (SLAs) that may be necessary
  • Preferred pricing profile – one-time capital expense (CAPEX), versus ongoing license (OPEX) or a blended profile to suit budget profiles
  • Update schedule – how often are updates released to customers (eg every 3 months, as needed, etc). This also can tie in with the license costs and support models offered by the vendor
  • What turnaround is offered when remedying bugs and are there separate classifications depending on the severity of the required bug-fix (eg mission critical / severe, major, minor, etc)
  • What is the scaling model in terms of licenses (eg do licenses increase in blocks of 50 additional concurrent licenses or increments on a per user basis)
  • What is the scaling model in terms of hardware/software (eg can the hardware/software be scaled and if so, what metrics are used). More importantly, are there any upper limits on the scalability of the solution being offering
  • What are the known risks / issues to be aware of when installing the vendor’s solution. There are always risks and issues that the vendors should openly share with the CSP so that both parties can deal with them transparently from the start
  • What is the product roadmap for introduction of new products, services, features

OSS Vendor Reference Checks

When conducting reference checks, the following are key questions to identify:

  • What functionality / modules did the vendor implement for you? Often the vendor has commissioned a completely different set of modules, which may be more advanced/mature than the modules that they are offering to the new CSP. For example, a particular vendor may specialise in alarm/fault management but also have rudimentary inventory management tools that they’re offering to the new CSP
  • What type of network do you operate (or more particularly what segment of the network is now managed by the vendor’s OSS). Sometimes the vendor’s products are well suited to some network types (eg circuit-oriented) but not others (eg packet-switched)
  • What type of services do you offer (or more particularly what sub-set of services are now managed by the vendor’s OSS)
  • If there are restrictions on revealing financial details, what are the other dimensional data that can be divulged (eg number of users, number of interfacing systems, number of devices, number of transactions such as alarms, etc)?
  • How would you rate the vendor’s overall performance (on a scale from 1-10)?
  • How would you rate the vendor’s quality of work (on a scale from 1-10)?
  • How would you rate the vendor’s staff (on a scale from 1-10)?
  • How would you rate the vendor’s ability to interact with your in-house staff, including their willingness to help guide you through your internal issues that arise on OSS projects (on a scale from 1-10)?
  • How would you rate the vendor’s conflict resolution and change management skills (on a scale from 1-10)?
  • How would you rate the vendor’s ability to manage the data migration process (on a scale from 1-10)?
  • How would you rate the vendor’s ability to manage the solution cutover process (on a scale from 1-10)?
  • How would you rate the vendor’s:o Technical skills / knowledge
    o Operational skills / knowledge
    o Ability to understand your unique organisational features such as networks, processes, naming conventions, etc
    o Ability to map your features into their tool-sets to produce a solution that was easy to understand and transition to by your operators
    o Ability to map business needs into technical solution rather than forcing the business needs to retro-fit into the technical solution
  • Strengths / weaknesses of the application suite. For example, was the product functional out of the box or did it require significant local configuration before it was able to do anything tangible, have you noticed major performance degradations, has it been intuitive for users to pick up, etc
  • Strengths / weaknesses of the implementation (eg time / cost slippage, implementation / management methodologies, etc)
  • Strengths / weaknesses of the ongoing support including ticket turnaround
  • Ability to meet deadlines
  • Availability of suitably skilled resources throughout the whole life-cycle (eg grads assigned to the project)
  • Did the supplied test cases provide suitable test coverage or have issues since been identified in testing blackspots
  • Did the training provide your users with an acceptable level of knowledge given any time/budget constraints that you may’ve had?
  • Was the training generic in nature or contextually relevant for your organisation
  • How would you rate the level of ongoing support
  • Was the vendor ambitious in seeking scope creep, logging change requests, etc versus accepting configuration changes / evolution within the scope of the initial contract
  • Anything that you would do differently if implementing this project again
  • How did you conduct the vendor selection process (eg EOI, RFP, direct vendor contact, etc). Did you have any learnings from the vendor selection process that you can recommend to us
  • Have you collected any KPIs before / after the implementation of the OSS that show any improvements / degradations in performance (eg customers provisioned per day, fault rectification times, etc)
  • Relating to the item above, when compared with your initial business case, would you suggest that the vendor’s solution has been recognised at executive level as being good value for investment, even if financial figures such as ROI is difficult to ascertain
  • Is there anything you would like to add concerning this vendor or anything in particular that we should be aware of
  • Having been through an OSS transformation, do you have any recommendations regarding organisational or operational structures or re-structuring that has arisen as a result of the introduction of the vendor’s tools (eg reallocating staff between business units, creation of a dedicated OSS team, resources to handle the support process, ongoing configuration or process refinements, implementation of ongoing projects, etc)
  • Some vendors are adept at building in hooks that make their tools nearly impossible to remove from a CSP‘s environment once implemented. Some vendors also devise products that need cascading upgrades (ie if one module is upgraded then all other adjacent products also need upgrading), introducing cascading life-cycle costs.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.