Home / Utility ERP and CIS / How to screen CC&B and OUAF consultants

How to screen CC&B and OUAF consultants

The single most useful screening signal is whether a candidate can describe what they personally did, rather than what the project did. Ask them to walk through one CC&B or OUAF enhancement they owned end to end. Genuine practitioners get specific quickly (business objects, algorithms, plug-in spots, batch processes, service scripts), while observers stay high-level.

The questions we ask, and what we listen for in the answers.

The question we ask first

"Walk me through one CC&B or OUAF enhancement you personally owned. What was the business requirement, what did you build or configure, and why did you approach it that way?"

A strong answer gets specific fast. Within a sentence or two the candidate is naming the components they worked in: business objects, algorithms and the plug-in spots they attached them to, batch processes and their parameters, service scripts and BPA scripts, business services, portals and zones, and the integrations involved.

Just as telling is whether they separate what was base product configuration from what was genuinely custom. People who have built inside OUAF know exactly where that line sat in their work, because they had to make the decision. They also tend to volunteer the constraint they were working around, which is usually the most informative part of the answer.

What a weak answer sounds like

Someone who was merely around the program stays high-level, and the answer describes the project instead of their contribution:

"We implemented CC&B for a large utility and I worked with the development team…"

That isn't enough, and it isn't necessarily dishonest, plenty of people describe their work this way out of habit. The follow-up is simply: "What did you personally build?"

Practitioners answer that immediately and in detail. Observers restate the project scope in different words, move to methodology, or shift to what the team delivered. In our experience one round of that follow-up is usually all it takes to know which you are talking to.

The senior-level question

"Give me an example of something the business wanted customized that you ultimately solved using standard OUAF functionality."

This question separates senior people from capable mid-level ones. Answering it well requires product depth, the confidence to push back on a stated requirement, and enough experience to have seen what happens when a utility accumulates custom code.

The strongest OUAF people aren't the ones who customize everything, they're the ones who understand the product well enough to know when not to customize it.

Over-customization is expensive for utilities in ways that are easy to underestimate at design time. Every custom object is upgrade work: someone has to assess it, retest it and often rebuild it at each version move. It widens regression risk, because behavior that Oracle would have carried forward now has to be verified locally. And it raises long-term support cost, since the people who can maintain it are a smaller group than the people who know the product. On CC&B and C2M installs that have run for years, that accumulated cost is often the single largest constraint on what the utility can do next.

Screening signals summary

What we treat as evidence of genuine hands-on experience, and what we probe further.

Signals of genuine experience

  • Specific technical vocabulary used correctly and unprompted
  • Can explain the trade-offs behind a design decision
  • Clearly distinguishes base configuration from customization
  • Describes what they would do differently a second time

Signals to probe further

  • Describes the project rather than their own contribution
  • Names the platform but offers no component-level detail
  • Claims breadth across many modules with depth in none

None of the signals on the right are disqualifying on their own, they mean the conversation isn't finished. The roles where this screening matters most are the ones covered in the hardest utility ERP roles to fill.

Questions about screening CC&B and OUAF consultants

How do you screen an OUAF developer?

We ask them to walk through one enhancement they personally owned, end to end. Genuine developers move quickly into business objects, algorithms, plug-in spots, batch processes and service scripts, and can explain why they chose one mechanism over another. Vocabulary used correctly and unprompted is the signal we trust most.

What should I ask a CC&B consultant in an interview?

Ask what they personally did rather than what the project delivered. A useful follow-up is to have them explain a specific billing or rates outcome, why a bill calculated the way it did, and what configuration produced it. Observers describe the program; practitioners describe their own work.

How can you tell if OUAF experience is overstated?

Overstated experience stays at platform level. The candidate names CC&B, C2M or OUAF, describes the utility and the phase, but cannot name components or explain trade-offs. One question resolves it: what did you personally build? Genuine practitioners answer immediately and in detail.

Should a CC&B consultant recommend customization?

Sometimes, but the strongest consultants we place start from the product. They look for a supported configuration or extension path first, and recommend customization only when the requirement genuinely cannot be met otherwise, because every customization becomes upgrade work, regression risk and long-term support cost for the utility.

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.