1. Oracle Utilities NMS / OMS specialists
This is the hardest skill set we see, and the gap between demand and available people is not close. NMS is deployed at a fraction of the utilities that run a customer information system, so the number of consultants who have ever worked in it is small to begin with, and the ones who have tend to stay attached to the same programs for years.
The role also refuses to split cleanly into technical and functional. Someone who knows the NMS platform but has never sat with distribution operations struggles with switching, tagging and restoration behavior. Someone who understands outage operations but not the platform cannot configure or troubleshoot it. We need both in the same person, and that is what makes the pool so thin.
When a utility asks us for NMS help, we plan for a longer search than any other utility ERP role and we are candid about it up front.
2. CIS data conversion leads
Plenty of people have participated in a conversion. Far fewer have owned one. That distinction is the whole difficulty of this role, and it does not show up on a résumé: both candidates write "data conversion" the same way.
The genuine ones have led mapping, cleansing, mock conversion cycles, reconciliation and cutover. They understand what actually happens when hundreds of thousands of customer accounts, service points, meters, balances and payment arrangements have to move correctly, and what it takes to prove they moved correctly to finance and to the business. They talk about balancing and defensibility before they talk about tooling.
This is also the role where a wrong hire is most expensive, because conversion sits on the critical path of every CIS implementation and problems surface late.
3. CC&B / C2M billing and rates leads
Billing and rates is where product knowledge and utility business knowledge have to meet. Configuration skill alone is not sufficient here, and neither is regulatory knowledge without the platform.
We look for someone who understands not just how a rate schedule is configured in CC&B or C2M, but how it lands on an actual customer bill: proration, seasonal and tiered structures, riders and adjustments, taxes, budget billing, and the regulatory requirements and tariff language sitting behind all of it. The test we apply is whether they can explain why a bill came out the way it did, not just where the configuration lives.
Billing errors are visible to customers and to regulators, which is why utilities are rightly unwilling to accept a learning curve in this seat.
4. Senior OUAF technical leads and developers
We see many résumés with OUAF on them. The number of people who can genuinely design and build within the framework is much smaller. Because OUAF sits underneath every Oracle Utilities product, anyone who worked on one of those programs can honestly say they were on an OUAF application, which makes keyword matching close to useless here.
The strongest OUAF technical leads understand the framework deeply enough to know when to configure, when to extend through supported mechanisms, and when not to customize at all. That last judgment is what we value most, and it is the least common.
This is the role where our screening process does the most work. We cover the questions we ask on our screening guide for CC&B and OUAF consultants.
5. Utility integration / meter-to-cash architects
The challenge here isn't finding someone who understands integration. Integration architects are not rare. What is rare is someone who understands how CIS, MDM and AMI, NMS, GIS, payments, finance and the customer portal work together operationally.
That means knowing the sequence and timing as well as the interfaces: when usage has to land for a bill cycle to run, what happens downstream when a service order is completed out of order, how an outage event should and should not affect billing, and where reconciliation belongs. Those are operational questions, learned on utility programs rather than from integration patterns in general.
Generalist enterprise architects can pick this up, but not on the timeline a program in flight usually has.