“If I was slashed and cut into pieces, over and over again, and put into the mill and ground into flour, burnt by fire and mixed with ashes – even then, I could not estimate Your Value.”
Sri Guru Granth Sahib
You ask all the difficult questions don’t you?
Actually, “how much will this cost” is a common question asked by organisations that is about to embark on an OSS project, particularly if they haven’t been through a similar exercise recently.
It is also a question that I don’t have a definitive answer for prior to undertaking a detailed vendor / cost analysis. There are just so many variables (eg size of network being managed, number of operators using the applications, the amount of functionality, how much automation, types of service being offered, etc, etc).
Costs can range from negligible (open source products, small networks) to total investments into hundreds of millions (for tier-one international operators).
However, I can describe the rules of thumb I use for VROOM (very rough order of magnitude) cost estimation. However, please take them with a grain of salt and consider your specific OSS.
The major costs to implement [ie CAPEX] (not maintain [ie OPEX]) the OctopOSS includes the following items:
- Software (Applications / Products)*
- Infrastructure (Hardware, Management Network, Hosting)
- Professional Services (Integration, Customisation, Data Migration, etc)
- Network Interfaces (excluded from this rule of thumb)
- Internal Change Management (excluded from this rule of thumb)
* Note that sometimes vendor quotes exclude third-party software (eg database software)
Costs relating to network interfaces and change management are separate from a vendor’s quote for commissioning their application suite.
Implementation Cost Rule of Thumb
As a rough estimate, pricing structure for the OSS is as follows:
- OSS Application Licences (x)
- Third party hardware/infrastructure (0.25 – 1.5x)
- Project Implementation services (1 – 4x)
Where x is the up-front license cost.
Third party hardware/software: varies depending on the requirements of each vendor’s software platforms, but more importantly it depends on the high availability, redundancy, disaster recovery mechanisms required by the CSP. Generally, the more highly available, the higher the hardware and third-party software costs are going to be. Also depends on the number of environments you wish to build. Cloud delivery models have changed the dynamic of this aspect of costing. Cloud tends to be a subscription (OPEX) cost rather than the traditional CAPEX investment.
Project Implementation includes: project management, configuration, install and commissioning, integration, etc. This can vary considerably, particularly if there is a substantial data cleansing / migration requirement or other integration complexities. This breakdown intentionally bundles all of vendor, solution integrator (SI) and client implementation costs together because roles and responsibilities vary by project. When doing your evaluations, you’ll probably break these costs (and therefore the multiplier) based on approximate allocations of effort by each party.
Network Interfaces or System Interfaces (excluded)
This cost component is very important because there are often hidden interface costs that aren’t budgeted for initially by operators.
Some system vendors activate their Northbound Interfaces (NBI) by default for no extra cost. This is common for IP-based systems like switches and routers which invariably have SNMP interfaces. Other vendors indicate that their Network Element (NE), Element Manager (EMS) or Network Management (NMS) platforms are “capable” of producing data streams for northbound applications like OSS. However, what the literature sometimes fails to indicate is that there are often significant costs (up to hundreds of thousands of dollars) relating to the actual “activation” of these NBI. This is common for legacy products like voice switches, transmission equipment, etc.
Another hidden cost is when some functionality (eg alarms interfaces) is activated, but other functionality (eg provisioning or auto-discovery) needs to be purchased separately.
Change Management (excluded)
By change management, I’m referring to the impact that the OctopOSS has on the CSP, as opposed to in-flight contractual change between the CSP and the vendor.
The costs relating to change management are often underestimated. An OSS/BSS has the ability to “touch” most parts of the CSP’s business so change management planning is always significant. Some of the aspects of change management include:
- Impact to adjacent systems
- Process re-design
- Organisation changes
- Report changes
It is extremely important that the implementation of any new system is not done in isolation. Other OSS and BSS tools (eg Asset Management, Provisioning, CRM, etc) overlap and intertwine.
Creating an Enterprise Architecture Plan and/or Data Map is an important step and must be done before implementing any new systems or applications. Identifying what the data is, where the data resides, what format it is, how it is linked, how it is used and who owns it (ie data master or slave) is critical.
Once this activity has been completed, organisational, process and procedural changes can be estimated.
These costs will need to be analysed by the CSP in conjunction with their business teams because implementation resources are often borrowed from other operational teams (ie primarily OPEX costs).
Ballpark Cost Dimensions
The following ranges are really rough estimates I have in mind for these customer categories:
- Tier 1 operators – $20M++
- Tier 2/3 operators – $1-10M
- Utilities – $500k-10M
- Large Enterprise – $500k – 5M
- Medium Enterprise – $100k – 2M
However, as mentioned earlier, there are many factors that could skew your organisation’s OSS/BSS outside these thresholds.