In my last post, I wrote about how organizations are challenged to implement and iterate new technologies quickly to enable the changes to business processes necessary to leverage new digital technologies to gain competitive advantage, operational efficiencies, and/or improve customer retention. I noted that these efforts often fail and suggested that an important cause of failure is a tendency to focus on technology over people. I ended by questioning how digital technologies can be effectively evaluated when it is difficult — if not impossible — to know all the capabilities an organization will need throughout their transformation journey.
Let’s continue where we left off: with the challenge of digital solution definition, evaluation, and selection. This, in turn, will lead us to the broader question of risk management.
I’ll look at these questions through the lens of billing transformation. In addition to being an area in which I have some experience, billing transformation is a useful case because it is a critical system to any business. Additionally, billing systems are especially difficult to change because:
- Billing systems are mission critical. Reliable and timely billing generates the revenue to power the organization. Billing accuracy and flexibility is essential for building trust and transparency with customers.
- Billing systems are not an isolated system that can be easily replaced. Within the billing system lies the product catalog, pricing engine, as well as invoice generation. It contains critical customer information: what they’ve purchased and when, who is invoiced and when, contract terms, relationships with other entities and sellers, and more. It is integrated with systems to provision services, handle overdue accounts, manage accounting and finance, monitor inventory, and customer self-service portals, to name a few. Integrations can be complex and often have impacts on numerous systems. Moreover, because of these integrations, limitations in the billing system can often cascade to other systems as well; as a result, digital transformation efforts often require changes to legacy billing systems whose limited functionality requires many manual processes.
- Billing systems are complex. Increasingly, billing systems are handling combinations of pre-paid and post-paid charges, pricing consumption of services using complex pricing models, and doing so for interrelated entities that share pricing and pools of usage at special rates. They support a variety of billing cycles, payment methods, currency conversions, and contract durations. Invoices and supporting reports must be clear, customizable and brandable. They must comply with the tax collection and reporting requirements of the jurisdictions they work within. They must be compliant with current privacy and security policies (PCI-DSS, GDPR, etc), and all transactions must be auditable. They must support first party as well as support for resellers of your core products. The list goes on and on.
- Billing systems are at the nexus of operational and business support systems, and thus the billing capabilities must evolve with the capabilities to activate services, measure service utilization, empower customer service, sales and marketing teams with meaningful and current data, feed revenue recognition systems, and more. Billing needs change dramatically over time as organizations grow and change. The result is often a complex patchwork of legacy and custom built software with inefficient manual processes bridging the gaps that have evolved between those systems over time. Many organizations reach a point where the manual processes become a barrier to growth as they attempt to scale their billing systems.
These challenges — and they are certainly not the only ones — have big implications for how to scope a billing transformation. If we understand up-front that the system (in this case, the billing system) stores, generates, and/or transfers information needed by many different systems and users across the organization, then we see too that scoping the change must take into account the needs of the users and the processes that depend upon them.
In my last post, I wrote about how organizations are challenged to implement and iterate new technologies quickly to enable the changes to business processes necessary to leverage new digital technologies to gain competitive advantage, operational efficiencies, and/or improve customer retention. I noted that these efforts often fail and suggested that an important cause of failure is a tendency to focus on technology over people. I ended by questioning how digital technologies can be effectively evaluated when it is difficult — if not impossible — to know all the capabilities an organization will need throughout their transformation journey.
That suggests the need for a lengthy and complex process to understand the requirements for all those groups, evaluate and prioritize them, and finally settle upon the essential capabilities for the platform. This is the opposite of the agile strategy necessary to launch, evaluate, and iterate upon new solutions quickly.
It’s cumbersome and — while it might resolve to a platform that has the capabilities you need — it does nothing to build agility and nimbleness into the organization. Just the opposite: it risks building the new solution around existing business processes without introducing a mandate to change how work is done. It prioritizes the tools over the processes that people use to realize business goals.
So if we know that the billing transformation is hard because there are so many business processes, teams, and systems that interact with it, how do we go about scoping the change?
We start by acknowledging that:
- Existing business processes are optimized to use legacy systems. Legacy systems and the processes that use them form a symbiotic, self-reinforcing relationship; each is meant to sustain the other.
- The existing business processes are in place partly because they have been resilient to change over time. They have a built-in stickiness.
- Existing business processes must be questioned for the role they play in sustaining inefficient or costly processes, and evaluated for the customer experiences they support. No process should be immune.
If this is true, then we shouldn’t select a solution based on a need to support existing processes (not without looking very carefully at whether those processes will sustain the organization into the future unchanged), nor should we select a tool without knowing whether it provides the capabilities needed by the organization. Further, asking our teams about the capabilities needed for a new tool before they know how and when it will be used forces them to infer the new from the old, and puts at risk your ability to make meaningful change. Instead, we need to evolve the two in parallel, iteratively, to meet our digital transformation goals.
What does this mean?
On one hand, business processes need to be assessed against the organization’s strategic objectives to identify the friction points between the current and desired future state. In short, where are the gaps in service, in efficiency? This is the point that Rob Loader, the executive in charge of capital management at Telstra in Australia, makes when he notes “the key issue with many transformations is they often start with trying to correct a historic issue or a sort of historic underperformance. Yet they really should be focused around trying to position an organization for a future. And so when you break that down, the emphasis has to be in the early stages around what’s the real purpose of this transformation? And as a result of addressing that purpose, what’s the end outcome?”
While we need to carefully consider the processes that form the context in which our new system will function, it is also important to begin to survey the solutions available that will support our transformation goals. It’s a bit like coming at the problem from two opposing directions: on the one hand, validate exactly what your requirements are by questioning your business processes and identifying the changes you need to support; on the other hand, assess what the available systems can and cannot do, and which problems they might help you solve.
Does that mean we are returning to comparing feature lists? Only partially, because it’s pretty likely that you have pain for which there isn’t a perfect software solution, and you have goals that may not match with the features available to you. In short, you’ll need to compromise.
This is where perhaps the most important selection criteria of all emerges: the capacity and willingness of the vendor to provide a solution that evolves with you over time.
If we accept that it’s not a small undertaking to identify the business processes and functions that are obstacles to realizing your strategic goals, then we should recognize that becoming familiar with all of the different features available to you to achieve your goals simply isn’t realistic in most cases. This is especially true when a given problem may be solved in different ways by different providers.
Further, if our needs from our billing system — and perhaps any core business platform — will be different today than our needs will be in the future, then it follows that features are not the most criteria for selecting a vendor.
Instead, I suggest that what is more important that the features available today is the vendor’s ability to incrementally deliver the capabilities needed as they emerge, and serve a consultative role in identifying the features that will resolve our business pain as it arises. Digital transformation, after all, isn’t a one-time project, and the process of evaluating our business processes and functions to identify gaps, inefficiencies and obstacles must happen over and over. Each time, it will return different results, and require our vendors to help identify the right remedies.
This means that a successful billing implementation — and I don’t feel billing is very different from other enterprise systems in this regard — demands that organizations select vendors that engage in an ongoing consultative relationships with their customers. It demands a billing platform whose capabilities can be tailored to meet your needs today and into the future. This is different from having the ability to request features to be added to a product roadmap which aggregates the needs of the broadest cross-section of customers. I’m suggesting that flexibility and customizability itself is an important capability, achieved perhaps via options for third party add-ons, modular architecture, deep configurability, or some other means to tailor the platform to your needs.
The consultative, adaptive approach I’m proposing puts demands on you as well: are you willing and ready to allow vendors to work closely with your organization to build solutions, workarounds, and an ongoing dialogue? That requires flexibility and trust, and the willingness to commit the time and money to collaborate with a vendor to ensure the system meets your needs.
No mistake, this is not a simple or easy process. It is more complex than comparing the features of different platforms. It does, however, better position you for success.
It doesn’t mean, of course, that features aren’t important. Due diligence requires you understand the key capabilities your organization needs. Vendors do not understand your business like you do, and the quality of the outcome is only as good as that understanding. So in my next post, I’ll share my thoughts on how to go about determining what those core capabilities are for your organization, as a way to get a broad picture of your billing transformation needs.
