Home / Utility ERP and CIS / Oracle CCS

Oracle CCS staffing and consultants

Oracle Utilities Customer Cloud Service (CCS) is the SaaS delivery of Oracle's converged customer information and meter data platform. It is where most new utility CIS implementations now start, and where many CC&B utilities are heading. Mako places CCS functional consultants, configuration analysts, integration developers and conversion leads.

Senior CCS talent for new implementations, CC&B migrations, release adoption and ongoing production support.

  • Submittals within 48 hours
  • 80% of submittals hired at a utility client
  1. Meter read

    AMI head-end into Oracle MDM

    AMI Integration Developer
  2. Validate

    VEE rules in Oracle MDM

    MDM Functional Consultant
  3. Bill determinants

    Usage to billing in C2M

    C2M Configuration Lead
  4. Bill

    Rates and bill calculation in CC&B

    CC&B Rates Analyst
  5. Pay and collect

    Payments, credit and collections

    Collections Analyst
Oracle Utilities meter-to-cashExample roles at each step

What Oracle CCS is

The cloud-delivered, Oracle-managed version of the converged customer and meter data product line.

CCS delivers Oracle's converged customer information and meter data functionality as a service. The same meter-to-cash scope utilities know from Customer Care and Billing (customer and service relationships, rate configuration, billing cycles, payments, and credit and collections) sits alongside measurement, validation and usage processing in a single product that Oracle operates and updates.

The customer-managed equivalent of the same converged product is Oracle C2M, deployed on-premise or on infrastructure the utility controls. The standalone predecessor is Oracle CC&B, which most utilities run with a separate Meter Data Management instance. CCS is the go-forward destination of that line.

Converged customer and meter data

CCS carries the customer, account, premise and service point model together with measurement, VEE and usage processing in one product. Billing and meter data teams design against a single platform instead of negotiating across an interface between two systems.

Oracle-managed delivery

Oracle provisions and operates the environments and applies product releases on a regular cadence. The utility keeps ownership of configuration, data and integrations, but not of the infrastructure, patching schedule or upgrade mechanics.

Why utilities are choosing CCS for new implementations

Real advantages, and the trade-offs that come with them.

Less infrastructure to carry

Environment provisioning, patching and platform operations move to Oracle. Utilities that struggled to keep non-production environments current or to staff a platform operations team see the clearest benefit here.

Predictable release cadence

Product updates arrive on a regular schedule rather than as a multi-year upgrade project. Functionality and fixes land sooner, and the platform does not drift years behind the supported version.

Configuration-first delivery

Requirements are met through supported configuration, business objects, algorithms, scripting and extension points, which keeps the solution upgrade-safe and shortens the path from design to working functionality.

Trade-off: less freedom to customize

Extensions must stay inside supported boundaries. Requirements that a customer-managed deployment would have solved with custom code need to be reshaped, deferred, or handled outside the platform. That is a real design constraint, not a formality.

Trade-off: staying current is mandatory

The utility does not choose to skip releases. Adoption of each update has to be planned, tested and absorbed by the business, which makes release management an ongoing operational commitment rather than an occasional project.

Trade-off: process alignment

Fitting utility processes to the delivered product often means changing the process rather than the software. That is usually the right outcome, but it requires business ownership and decision-making discipline that a program has to plan for.

What changes for the delivery team

The skill mix on a CCS program is not the same as on a customer-managed CIS build.

Configuration replaces custom development

The center of gravity shifts from building code to configuring the delivered product and extending it through supported frameworks. Teams need people who reach for a business object or algorithm before writing something bespoke.

Regression testing becomes a standing function

Because releases arrive continuously, testing is no longer confined to an implementation phase. Programs need documented or automated regression coverage and a test resource who stays with the platform after go-live.

Cloud-appropriate integration patterns

Integration happens through published APIs, messaging and supported file mechanisms rather than direct database reads and writes. Integration developers need API and middleware fluency alongside utility domain understanding.

Extension discipline needs an owner

Someone senior has to hold the line between supported configuration and unsupported workaround. Without that role, a program accumulates technical debt that the next release makes expensive.

Roles we place on CCS programs

Functional, technical, conversion and program roles on contract, contract-to-hire or full-time.

  • CCS Functional Consultant
  • Billing & Rates Analyst
  • Meter Data / MDM Analyst
  • CCS Solution Architect
  • Integration Developer
  • Conversion / Data Migration Lead
  • Configuration Analyst
  • Test Lead
  • Cutover Manager
  • CCS Project Manager
  • Production Support Analyst

Moving from CC&B to CCS

What the move actually demands of the team.

At a staffing level a CC&B to CCS move is dominated by four workstreams. Conversion carries customers, accounts, service agreements, balances and usage history into the converged model, and reconciliation is what proves the load is right. Integration rework replaces database-level and legacy interface patterns with API and messaging based integration. Testing expands, because regression coverage has to survive the release cadence after go-live. Cutover needs its own owner.

The encouraging part is that CC&B functional knowledge largely transfers: rate configuration, billing, credit and collections and the core data model are the same conversation. Deep custom-code and framework-hacking skill matters less, while configuration judgment, integration fluency and testing capability matter more. For how the two product generations compare, see CC&B vs C2M vs CCS, and for the wider role plan see our CIS implementation staffing overview.

Oracle CCS staffing questions

What is Oracle CCS?

Oracle Utilities Customer Cloud Service (CCS) is the SaaS delivery of Oracle's converged customer information and meter data platform. It combines the functional footprint of Customer Care and Billing with Meter Data Management in one product, with Oracle operating the environments and applying releases on a regular cadence.

What is the difference between CCS and C2M?

CCS and C2M share the same converged functional footprint. C2M is the customer-managed deployment, run on-premise or on infrastructure the utility controls, where the utility owns environments, patching and upgrade timing. CCS is delivered as a service by Oracle: Oracle manages the infrastructure and releases, and extensions must stay inside supported cloud boundaries.

Is CCS replacing CC&B?

Not in the near term. CC&B remains widely deployed and supported, and many utilities will run it for years. What has changed is direction: most new utility CIS implementations now start on CCS, and CC&B utilities increasingly plan a move to the cloud-delivered platform. This is a multi-year industry transition, not a switch-off, so demand for CC&B skills continues alongside CCS demand.

Do CC&B skills transfer to CCS?

Functional knowledge transfers well. The customer, account, premise and service point model, rate configuration, billing cycles, payments, and credit and collections logic are recognizably the same work. What transfers less is deep custom Java development and direct database work; on CCS that effort moves toward supported configuration, extension frameworks, integration and regression testing.

What roles are needed on a CCS implementation?

A typical CCS program needs functional consultants for billing, rates and credit, a meter data analyst for VEE and usage configuration, a solution architect to hold extension discipline, integration developers for head-end, payment and finance interfaces, a conversion or data migration lead, configuration analysts, a test lead with regression capability, a cutover manager and production support analysts after go-live.

A 30-minute hiring call with our team

We'll talk through the role, the experience your team needs and your timeline. You don't need a finished job description.