The move to the Cloud – particularly, Software as a Service (“SaaS”) solutions – has been a dominant theme in IT, becoming mainstream over a decade ago. The benefits driving this move are well-known and, in the right environment, compelling. These include:

Flexibility and Scalability

Cloud-based platforms help utilities rapidly scale IT resources to meet demand, handling peak loads without over-provisioning infrastructure. Additionally, new services can be deployed efficiently, enabling faster responses to market changes and consumer needs.

Inherently Up-to-Date Software:

Instead of periodic major upgrade projects, enhancements and new features are routinely made available to selectively take advantage of.

Improved Disaster Recovery and Service Efficiency

Cloud solutions protect critical data and applications against loss or outages. The cloud’s robust disaster recovery and backup capabilities enhance utility operations resilience.

Enhanced Collaboration and Mobility

Cloud-based platforms can enhance seamless cooperation between a utility company’s employees, contractors, and other stakeholders.

Minimizing Underutilized Skillsets

The utility’s IT staff can focus on business needs, leaving the specialized skillsets needed to cover technical architecture to the provider’s dedicated specialists.

Cost-Effectiveness

Cloud hosting minimizes the need for installation and operation of on-premises data centers with racks of servers and hardware lifecycle management. With a pay-as-you-go model, utilities can optimize costs, aligning them closely with actual usage.

But are energy and water distribution companies ready to make this leap? Objections abound; some commonly heard ones include:

Cybersecurity concerns

Is it prudent for a utility to let its data reside in someone else’s infrastructure? What does this mean for evolving regulatory requirements for protecting customer data, especially if you lack visibility into where the cloud infrastructure physically resides?

Outsourcing has been widely adopted in some areas. No one would even think of web searching any other way. Email and productivity software are increasingly run as SaaS offerings.

But are we, as an industry, ready to do this for customer service and billing systems? (The traditional name for such systems is “CIS,” though the boundaries are loosely defined and vary between vendors.) These are among the most complex systems used in the industry. Complexity factors include:

Capitalization vs. O&M and the rate base

Investor-owned utilities, whose profitability is tied to the return on capital investment, have traditionally treated the cost of SaaS as O&M expenses rather than capital investment, excluding them from a utility’s rate base. Will SaaS arbitrarily sacrifice the ability to provide a fair return to stakeholders?

Giving up control

To achieve the advantages it offers, cloud environments, by definition, transfer responsibility for the software and the infrastructure it runs on from the utility to the cloud provider. Although it is mentally reassuring that the cloud provider has a deep, dedicated, specialized technical team, is a utility truly ready to outsource responsibility for this IT infrastructure?

• CISs serve complex business requirements.
• Requirements vary by jurisdiction; unlike word processing or solitaire, which are standard across the world, how a distribution utility is allowed to serve and bill its customers varies tremendously across jurisdictions and types of service.
• CISs integrate with numerous other systems within the utility’s IT/OT footprint—typically more than any other system.

As a result, these systems have historically been highly customized. They tend to be monolithic, with end-to-end support for cross-functional processes built into the source code. Consequently, updating or replacing them is a significant project. In our industry, CISs often live on for many decades; there are utilities where systems first implemented in the 1970s are still running today, and they struggle to find staff to support their technology.
Big projects are undertaken with hesitation for a reason. Large software projects have often earned their reputation for being high risk and high cost. The initial implementation timeline is long, and evolving business needs during the implementation extend it iteratively further. If one can “get by” with an existing system, inelegant as it may be, it can be easy to just say no and limp along rather than tie one’s reputation to those risks and take on the expected “death march” project to replace it.
But what if the case for SaaS and customer service/billing could be made low-risk and cost-effective? What if the adoption of a SaaS solution could mitigate risks, reinforce architectural flexibility and nimbleness, all while reducing costs? Oracle CCS, when done right, will deliver on these promises.

A successful move to a SaaS customer service solution will:

Mitigate risks

with a widely used product already proven to work not just generically for a startup overseas, but for your specific jurisdiction and services.

Reduce costs

with a lower implementation cost upfront, followed by ongoing manageable operations and maintenance.

Reinforce flexibility

with an enterprise architecture built for core features and integration for end-to-end intelligent processes spanning loosely coupled systems.

• Oracle Customer Cloud Service (CCS) is Oracle’s SaaS offering to support customer care, service orders, scalar and interval metering services, and billing processes. CCS inherits the rich legacy of Oracle Customer Care & Billing (CC&B), Meter Data Management (MDM) and many supporting components.
• With this SaaS offering, the system runs on Oracle Cloud Infrastructure (OCI), with Oracle operating and maintaining the application. Oracle makes its latest CCS enhancements available three times per year at predictable intervals. CCS runs in a single-tenant environment dedicated to the contracting utility, allowing the utility to control when these changes will be made available to its user base, and ensuring that none of its data is mingled with anyone else’s.
• This is the same software that can be licensed as Oracle Customer to Meter (C2M) and implemented and managed by the utility on its own IT infrastructure, whether on-premises, IaaS, or PaaS. Additionally, application components can be licensed separately for specific needs.

In an increasing number of jurisdictions, regulatory authorities accept accounting for these costs appropriately in the rate base, justifying the benefits to rate payers.

Oracle CCS is Oracle’s leading SaaS system that delivers these benefits compellingly. CCS provides all the same functionality as non-SaaS C2M; both are truly industry-leading, but functional evaluation is outside the scope of this document. Some specific benefits of CCS to highlight are:

Immediate operational readiness

The software runs “out of the box,” allowing implementation projects to focus on adapting it to the utility’s needs and integrating it into your environment.

Extensibility and scalability

While avoiding customization is ideal, jurisdiction-specific requirements must be met to stay in business, and the flexibility to integrate with other services and applications in the enterprise remains crucial. Unlike many entrants in this domain, CCS has a robust ability to extend core functionality. When extensions are built, they will be architecturally compliant, cutting off the temptation to take shortcuts. If additional storage, compute, or networking is required, it only takes a transaction to make them available.

Regular updates

The platform is regularly updated with the latest enhancements and improvements from Oracle. Gone are the days of expensive and risky major upgrade projects every few years; three times a year, those features are rolled out to CCS clients in manageable releases.

Managed IT infrastructure

Oracle provides and operates the entire technology stack – operating systems, networking, and middleware are always up-to-date along with the application software, with highly tuned processes and specialized staff protecting against emergent cybersecurity threats – all without the utility needing to maintain niche systems administration skills. The hardware replacement lifecycle is seamlessly managed in the process.

But it has to be done right, and that includes some different ways of thinking. Some of these are unique to CCS; some are unique to SaaS; and some are good principles of complex system integration regardless of the context.

Use CCS for What It Was Built For

Older approaches to CIS started with figuring out what you wanted the solution to do, developing a solution outline, procuring and building out infrastructure, and going through analysis and design, with some level of development before, months later, the team gets the first look at the emerging application.

For SaaS software, you still need to understand what the system needs to do. But to do it right, switch approaches, understand CCS and how it fits into your operations “out of the box,” and understand complex tariffs and ratings. It excels out of the box; configure it. But resist the temptation to customize the application to fit needs it wasn’t built for.

What Does CCS Do?

CCS has proven, robust features that will operate the core customer service business of the most complex utility distribution companies, including:

• Customer Care
• Service Orders
• Metering
• Rating and Billing
• Scalar, Interval, and Unmetered Services

The software is in daily production use, supporting tens of millions of customers across various service types, including electric, gas, water, and solid waste collection. It operates in every conceivable regulatory model, serving utilities’ needs on every populated continent.

Differentiate the “What” from the “How”

After a utility has grown accustomed to one way of doing business over the years, it can be hard to differentiate between the two. For example, if you are used to looking up data on a report, the same data delivered by an online portal can be a better way to meet the underlying need; or maybe that need from the legacy system is no longer relevant. Abstract from how you used to do something to what you always really needed to accomplish.

Too often, utilities understood their legacy systems and had grown comfortable; implementation projects started with inane requirements lists (think, “ability to search for customer by address or name”) and quickly turned into slogs to customize new systems to recreate the old way of doing things.

Design intelligent processes that integrate SaaS-delivered functionality.

Rather than customizing CCS, complement and integrate it with other components to meet business requirements that aren’t a fit. The integrated solution needs to support your business needs. CCS belongs in an ecosystem with other applications that work together. Field Service? Customer Portal? Payment Processing? There are great options on the market. Design the processes for end-to-end service flows that provide great integration across all components.

Build In Up-to-Date.

In the on-premises world, upgrades or implementations occur no more frequently than every few years. Successful projects always include months of organizational change management, system testing, integration testing, and end-user training and communications. (Change management and testing are needed for SaaS implementation projects! You’re changing how you operate the business, not just installing technology.)
Once a SaaS application is live, the same needs exist but on a different scale. Every four months, when Oracle makes a release of CCS available, you have time to evaluate it and prepare before migrating it to production. However, you do need to perform that evaluation:

• Should any of the new features now available be put into service? Do any existing processes need to be updated? What communications or training are required?
• Do existing processes within the application—or across integrations—still work?

The benefit of regular releases is coupled with the responsibility to accept them. The vendor rolls out application software that is proven, but CISs don’t exist in silos, and every utility needs to evaluate process adaptation and perform robust regression testing to ensure end-to-end processes still work.
You will need robust regression testing for the CCS releases that come three times per year. Oracle provides testing tools that work inside the SaaS boundaries. Our approach has been to build batch and online testing with open-source tools that extend beyond to testing key integrations and batch billing accuracy, so that when you go live, you know that key end-to-end processes will still function.
Of course, when other software is released on a different schedule, you’ll still need to test integration still. For example, Oracle ERP Cloud from the same vendor is released on a different schedule; you need to ensure that financial integration between the two will keep working through both sets of releases.

The use of CCS enforces architectural discipline. This section outlines practices that were always recommended but are now enforced as mandatory for a SaaS implementation.

O/S Safe Extensions within CCS: One of Oracle’s customer platform strengths has always been its extensibility. Along with robust core functionality, the platform provides effectively unlimited plug-in spots where extensions can be written to take care of new requirements specific to individual utilities. Constraints have been put in place for CCS customers to run safely in a SaaS environment. It would threaten every client if any client could put the operating system-level components at risk. To protect against this, extensions can only be created in cloud-compatible Groovy or through Oracle Configuration Tools. Groovy is syntactically very similar to Java but does not allow access to the file system. As part of using the SaaS package for what it does, customizations that operate outside of this constraint need to be built external to CCS and integrated through safe integration protocols as described below.

• Clients migrating from non-SaaS implementations of Oracle CC&B or C2M to CCS need to migrate any extensions written in Java to Groovy. Migrating from an old instance of CC&B that still uses COBOL? That needs to be migrated to Groovy too. In some cases, it may be more appropriate to separate these components should be separated into external, callable applications.

Extending on the theme above, the database structure and access within CCS also contain constraints specific to SaaS operation. This includes the following aspects:

Data model extensions are limited to built-in attributes. The platform comes with a very robust core data model. All key entities are extensible by user-definable attributes that allow both 1:1 and 1 extensions. In addition, the platform provides a generic and similarly extensible ‘Fact’ entity that can store new entities. However, the database schema cannot have new tables or columns added.
• Clients migrating from non-SaaS implementations with database schema modifications need to redesign and rebuild them for compatibility.

No direct database updates

• “Data repairs” have been a common quick-and-dirty technique in every CIS. If a code problem, data conversion error, or any other operation went awry and mucked up data, often the easy approach is to run a SQL script to undo the damage. But CCS is necessarily architecturally compliant, and any database updates need to be performed through compliant application logic.
• Clients migrating from a non-SaaS implementation with code that includes direct SQL updates to tables need to reimplement those through architecturally compliant business objects.

CIS applications are always integrated with numerous other systems; the art of systems integration is to do that well. To isolate application logic from its physical implementation, all data modification in CCS needs to be performed through the business object layer.

CCS runs on Oracle’s cloud, Oracle Cloud Infrastructure (OCI). That brings enabling technologies along with it, including the cloud implementation of Oracle’s integration platforms:

• Oracle Integration Cloud (OIC)– the enterprise service bus platform.
• Oracle Data Integrator (ODI) – the ETL/ELT platform.

These integrations need to be built and proven to function in detail for every transaction and at scale for projected business volumes.

• For CCS implementations, the CCS side of all application integrations needs to be migrated to OIC and ODI.

Internet access takes on new importance with the exposure of customer operations running to an external service provider. The hosting environment for CCS is unusually secure: Oracle hosting has dedicated experts to protect the environment with discipline, continually monitoring for and preemptively eliminating any emerging threats, in a way that few in-house IT teams would be able to do.
Data access from the utility’s environment, however, will go across the internet. This includes end users running the application user interface through a browser and every data set transferred by batch or online interface.

• Set up networking with adequate and proven security, as well as bandwidth and latency for all activities.

It is always important to manage environments with disciplined configuration management and well-executed code/configuration migration. This takes a lot of effort for on-premises implementations. With CCS, the burden is different: the utility is dependent on Oracle’s migration schedules and availability.

It is especially noteworthy that there are hard limits on migrating configuration between different versions of CCS. When a new tri-annual release is being adopted, any changes related to regression issues are especially important to manage. While cloud environments are much more easily provisioned than their on-premises peers, they need to be procured and budgeted for appropriately.

• For CCS implementations and operations, it is critical to have staff that have the understanding and experience of managing environmental nuances manage this activity.

Product defects happen – in every product. On-premises, the most effective path to get past them sometimes is to work around them: build a customization that delivers what’s not working in the product. With SaaS software, as a by-product of not being able to customize, that option is taken away. As a result, service requests to the vendor to resolve any defects take on new urgency to avoid risking the implementation critical path.

CCS Implementations Are Still CIS Implementations

Of course, all the principles of successful systems integration and software engineering build on each other; SaaS implementations continue to build on them. The keys to successful implementation, learned over the years, remain as important as ever. While it’s beyond the scope of this document to explore them in depth, any implementation needs them.

Great Organizational Change Management and Training

Staff who use and support the application will do things differently with CCS; how differently depends on what was in use before. Make sure you understand the impact on each role: what roles will be impacted, how they will be impacted, what roles will become unnecessary, and what new ones will be required. Where will staffing levels decrease and where will they increase? How will people perform high-frequency activities efficiently? How will they remember less frequent activities? How will you measure whether staff are ready to operate the new system? How will you manage the productivity impacts as users build efficiency using the new system through production use?

Staff Adequately

Even one person who can do anything cannot do everything. Your people know how business runs. To bring that knowledge to the implementation project, you will need to pull the best ones in. But day-to-day operations must continue. To support both, map out when project activities will require people’s time, and how much time, whether for workshops, action items, testing (and retesting), training development or delivery, data conversion validation, and so on. Schedule it. Backfill rather than creating “death marches” that burn people out, assuming they can shuffle both project and operations activities.

Accurate and Complete Process Migration

The source system being migrated to CCS will not have the same functional footprint as CCS (unless you are porting from non-customized C2M to CCS). As it is key to keep CCS doing what it does, any additional functionality needs to be dispositioned. Are the functions not supported in CCS still required? If so, where will they be performed in the future? What project work will it take to enable that?

Accurate and Complete Data Migration

Just as some functionality in an old system won’t map one-to-one to CCS, data from the old system needs to be dispositioned. CCS needs a set of data to operate; one side of data migration is to find sources for that data and load it in the form CCS needs. But just as CCS should only be used for what it’s built for, it should only master the data that it needs. The second side of data migration is to dispose any other data in the system being replaced. If it’s not going into CCS, where will it be stored? Beyond functionality, look at data age. Older legacy data will have more errors accumulated in it and will require retroactive configuration to operate. Do you really want to configure and test rates at the data age after retiring and scrolling through the historical broken meters and erroneous meter reads that triggered those billing exceptions? Most utilities have regulatory requirements to keep data accessible for “N” years, many more than are required for operational purposes; instead of cluttering CCS with it, we advise converting only what is necessary for current operations and storing the rest in a readable archive.

Adequate Requirements Analysis

CCS supports broad and complex business processes. Follow a business process-driven approach, but drill into the details. In our industry, you must think through the full life cycle with all the “what ifs.” Adapt your business to the functionality of CCS rather than trying to recreate the legacy system in it, but make sure that everything you need to do – in all its glorious combinations and permutations – works right. The 80/20 rule doesn’t apply here: even if you make the system work for 99% of accounts, that can still mean millions of bills are not created properly and payments are not applied correctly.

Operational Readiness

Make sure you are prepared operationally to handle the volumes, timing, and management of tasks. Using a few samples that come with stories from industry history:

• Not only must back-office agents know how to resolve each type of exception; their supervisors need to know how to view the volume of exceptions and allocate staffing accordingly before they snowball out of control.
• Not only must the system be able to post every payment in a payment file; it must post every payment file once, and no payment file more than once.
• Not only must the system bill correctly on converted data; it must bill correctly a second time on the next cycle.

Test Thoroughly and Repeatably

All the combinations and permutations of scenarios that can occur in production for utility customers have to work. Every rate, for every customer in every collection status, for every type of meter, with every type of service order, for every scenario – the list goes on; each and every combination has to work correctly. Requirements traceability and coverage remain important, but a test plan that covers inane business requirements once is not adequate (testing the “ability to search by last name” isn’t a high-value activity, even if repeated thousands of times). Execute an effective test strategy that meets the complexities of the business domain CCS serves. And be ready to regression test for each release three times per year.

Project Manage Well

Plan the schedule and deliver to it; manage staffing; identify, mitigate, and manage risks; manage change; resolve issues; communicate up and down; and so on. All project management disciplines continue to be required to serve the rest of the project team and organization.

Pick a Competent Team with Cultural Fit

When you embark on a complex project such as this, both competence and cultural fit matter. Competence completes tasks successfully. Every idea surfaced above has a depth of implementation detail that can be done well or can be superficially “checked off” by people with inadequate experience and understanding. Select the team that understands what it takes and how to do it right and will do so.
But equally, you need a team that will work together. Beginning at the top, a culture needs to be put in place for success—in words, matched with deeds. Success depends on clarity of responsibilities and expectations, transparency, mutual respect, trust (earned and given), humility, and vulnerability. When selecting a vendor for an implementation project, think about the organizational fit that you will both go through for an intense period of many months. One hard-to-work-with person put in the wrong place can derail everyone else’s efforts. Set yourself up to smile fondly when you look back from the other end.

Ready, set…

The case for action is compelling. CCS, done right, will be transformational for the good of the people of the utility and those of the community it serves. The author wishes you every success on your journey, and our team is poised and ready to help.