October 3, 2019

Shifting to Outcome-Based Procurement

Technology investments for any digital transformation project must be based on a business outcome with both qualitative and quantifiable benefits, not just a basic use case.

In nearly every country around the world, the dreaded RFx approach in use today is based on decades-old government procurement practices. This is because in the past the public network was government-run and procured the same way as satellites, toilet paper or office space. At that time, everything was “built-to-spec,” meaning that technology vendors that responded to those requests were being told not only what to build, but how to build it.

Twenty years into a new century, the telecommunications industry can do better. Communications service providers (CSPs) are realizing that their expertise is best applied to designing the network, not the hardware and software required to build it. CSPs have shifted focus to look at end outcomes, such as the clarity of understanding what services customers want and designing a technology approach that meets that need. Outcome-based projects, as any IT exec will tell you, are much better guided than past projects where systems are built and services designed around their technology reach. Business outcome-based investments allow CSPs to decide what revenue assurance and customer experience mean to them, and select solutions that not only implement those features but are configurable and adjustable for an unknown future.

Use Cases Encourage Innovation

In a multi-step procurement process, CSPs will still want to try before they buy, and the most objective approach to that is the use case. This not only simplifies the process for vendors, but CSPs are forced to really think about the business or technology problems they are trying to solve and the opportunities they want solutions to enable.

Some operators will be precise and certain with their use cases, as in, “We need to dynamically allocate bandwidth.”

Some will be more general, as in, “We need a dedicated business services platform.”

In either case, the CSP is more concerned with features, functionality and end result, and less concerned about how a solution is built. That clears the way for vendors to offer innovative approaches and ingenious applications of technology. However, the CSPs are still ultimately responsible for the utilization and management of those systems, thus there is a need to establish corporate standards and metrics for interoperability and integration across platforms, solutions and data.

Delivering Outcomes

Defining business outcomes must have both quantitative and qualitative benefits. CSPs cannot just insist on improvements they need to define metrics in order to evaluate solutions. Critical business metrics that define an increase in performance are typically aligned to areas such as:

  • Scalability
  • Security
  • Reliability
  • Availability
  • Configuration and changes
  • Data capture, access, processing, and
  • Interoperability with proposed systems, optimized workflows and process automation

CSPs that take a measured approach to digital transformation are insisting on interoperability with legacy systems, however it is much more important that newer solutions work together seamlessly, and critical data is available and valid from the start. Likewise, updating a system for an outdated process doesn’t accomplish much. New solutions should implement business processes that have been thoroughly scrubbed and optimized for a digital service provider.

The Fine Print

The move to procuring solutions against outcomes is important, necessary and long overdue; however, there are foundational requirements that must be part of the procurement process. And, more often than not, these requirements are (or should be) inviolate, specifically:

  • Data models, storage and management
  • Interface specifications and APIs
  • Security
  • Interoperability with IT architectures and platforms
  • Interoperability with network architectures and platforms

Defining corporate architecture and platform standards takes time, but so does composing detailed system specifications and development standards. Rather than using scarce talent to write system specifications, it’s better to face those specialists inward to define corporate standards, metrics and business processes that every vendor, system, platform, component and service must adhere to.

If not? Then don’t expect the business outcome you wanted at the start.

Latest

Monetizing Premium Video Content over 5G

Read More

Creating SD-WAN Service Differentiation in a Competitive Market

Read More

How Microservices are Transforming OSS and BSS

Read More