Three Questions That Reveal Whether Your System Integrator Is Actually Fit for SAP Utility Transformation
Choosing a system integrator for a utility transformation program is not just a procurement decision. It is a business risk decision. The wrong partner may know how to run a project, fill a staffing plan, present a methodology, and speak confidently about SAP, but that does not mean they understand the operating reality of a utility. It does not mean they understand how work actually moves through the business. It does not mean they understand where SAP standard ends, where thoughtful configuration or extension begins, and where outdated thinking creates long-term operational and technical debt.
For utilities, SAP transformation is not a generic technology implementation. It touches the operational backbone of the organization. It affects how work is planned, scheduled, performed, completed, updated, settled, reported, and trusted. It affects how field activity becomes enterprise truth. It affects how asset data moves between SAP, GIS, mobile tools, scheduling platforms, finance, and leadership reporting. It affects clean core decisions, exception handling, work order flow, phases, sub-phases, and the ability of the business to operate with confidence after go-live.
That is why utility leaders need better questions when evaluating system integrators. Not broader questions. Not softer questions. Better questions. The kind of questions that quickly reveal whether the SI understands the work, understands SAP standard, and understands the operational consequences of the design choices being made.
Building on a point raised in our first AlphaOak webinar, there are three questions every organization should be asking before trusting a system integrator with a complex SAP utility transformation. The answers will reveal a great deal about whether that partner is truly fit for the job.
Question One: When They Walk in the Door, Are They Still Talking About User Statuses and Notifications?
One of the fastest ways to understand whether a system integrator is operating from current SAP transformation thinking or outdated implementation habits is to listen to what they lead with. If they walk into a utility transformation conversation and immediately start talking about user statuses and notifications as if those are the center of the design, that should raise a serious question.
This does not mean statuses and notifications never exist or have no historical context. It means that if those are the first things an SI wants to anchor around, they may not understand where modern SAP work management is going. In many legacy environments, organizations built enormous complexity around user statuses, notification-driven processes, manual progress indicators, custom status schemes, and brittle logic that became difficult to govern over time. Those approaches often created the appearance of process control while quietly increasing operational and technical debt.
In a clean core environment, that kind of thinking is dangerous. Utilities cannot afford to rebuild yesterday’s complexity inside tomorrow’s architecture. They need partners who understand how to simplify, standardize, and design around meaningful business process flow rather than hiding complexity inside status structures that only a few people understand. If an SI is still treating user statuses as the primary way to control and represent the work, they may be trying to recreate the old world instead of helping the utility move toward a cleaner, more sustainable operating model.
The deeper issue is that statuses can create false confidence. A work order may appear to be moving because a status changed, but the business may still not know whether the right work was performed, whether the asset record was updated, whether the field condition was captured, whether costs are aligned, whether the exception was governed, or whether the next process step is truly ready. Status movement is not the same thing as operational truth.
A strong SI should not walk in and obsess over user statuses and notifications. They should walk in and ask how the business wants work to flow, what decisions need to be supported, what data must be trusted, what exceptions need to be visible, what SAP should own, what should be extended outside the core, and how the organization will know whether the work was actually completed in a way the business can rely on.
If the conversation starts with statuses, the organization should be careful. If the conversation starts with business flow, process integrity, clean core alignment, SAP standard, and operational trust, that is a much better signal.
Question Two: Can They Demonstrate How Phases and Sub-Phases Flow Through the Work Order Process?
The second question is whether the SI is ready to demonstrate how phases and sub-phases actually flow through the work order process. Not describe it in vague terms. Not show a generic slide. Not say, “We have done this before.” Demonstrate it.
This is one of the most practical tests of whether an SI understands utility work management. Utilities do not operate in simple linear steps. Work moves through phases, sub-phases, handoffs, dependencies, field conditions, approvals, scheduling constraints, design inputs, material availability, regulatory requirements, construction realities, closeout activities, and asset updates. If the SI cannot demonstrate how those phases flow through the work order process, they may not understand the operational choreography they are being asked to design.
This is especially important in asset-intensive utility environments because the work order is not just a task. It is the structure through which the business connects planning, execution, asset information, labor, materials, costs, field feedback, completion, and future operational intelligence. The phases and sub-phases are not just project labels. They represent how the work actually progresses and how the business understands where that work stands, what is ready, what is blocked, what is complete, and what still needs attention.
A strong SI should be able to walk a utility through the work order process in a way that feels real to the business. They should be able to show how work is initiated, how it moves through planning, how dependencies are managed, how execution is represented, how field updates are captured, how exceptions are handled, how completion is validated, how asset records are updated, how costs are captured, and how the business can understand the difference between administrative progress and actual operational progress.
They should also be able to demonstrate where SAP standard supports the flow and where the organization may need thoughtful configuration, extension, integration, or process change. If they cannot show that clearly, the business should be concerned. A utility transformation program cannot rely on a partner who only understands the system at a generic level. The SI needs to understand how the system supports the way work actually moves.
This is where many programs get into trouble. The SI may be able to talk about work orders, operations, notifications, statuses, and reporting, but when asked to demonstrate the full flow of phases and sub-phases, the explanation becomes thin. That thinness matters. It usually means the team has not fully internalized the utility’s execution model, or worse, does not know how to translate that model into a clean, scalable SAP design.
For decision makers, this is a simple but powerful test. Ask the SI to demo the work order process. Ask them to show the phases. Ask them to show the sub-phases. Ask them to show where the field interacts with the process. Ask them to show where exceptions appear. Ask them to show what the supervisor sees, what the planner sees, what asset management sees, what finance sees, and what leadership can trust. The answer will tell you very quickly whether they are fit for the job.
Question Three: Can They Define What SAP Standard Actually Means?
The third question may be the most important one in the clean core era: can the SI clearly define what SAP standard actually means? This is not a generic question about whether the organization should customize less. It is a much sharper question about whether the SI understands SAP’s intended standard processes, where those standards create value, and where the utility may be confusing historical habit with legitimate business requirement.
This matters because “standard” is one of the most overused and misunderstood words in SAP transformation. Many people use the word as if it has one obvious meaning, but in real programs it can become slippery very quickly. Sometimes “standard” means true SAP standard functionality. Sometimes it means the way a particular SI usually configures the system. Sometimes it means the fastest implementation path. Sometimes it means “we do not want to build that.” Sometimes it means “the business needs to change,” even when the team has not fully understood why the business operates that way in the first place.
For utilities, that distinction is critical. SAP standard should not be reduced to a slogan or a shortcut. It should be understood as the foundation SAP provides for scalable, maintainable, upgradeable business processes. In the context of clean core, the goal is not to recreate every legacy customization, custom status, manual workaround, or local variation inside the new environment. The goal is to understand what SAP provides as standard, what the business should adopt, what process discipline needs to change, and where a justified extension or integration is truly required.
A strong SI should be able to explain SAP standard with precision. They should be able to show what is standard in SAP, what is configuration, what is extension, what is integration, and what becomes true customization. They should be able to explain why SAP standard exists the way it does, what business behavior it is designed to support, and what the consequences are when a utility moves away from it. They should also be able to challenge the business when a requested requirement is really a legacy workaround wearing the mask of a requirement.
At the same time, a strong SI should not use SAP standard as a blunt instrument. Utilities are complex, asset-intensive, regulated organizations. They have field realities, compliance obligations, capital work structures, GIS dependencies, design processes, scheduling constraints, emergency work, and operational exceptions that need to be taken seriously. The point is not to force the utility into a generic model that looks clean in the design room but breaks down in the field. The point is to understand SAP standard deeply enough to know when the business should align to it, when the process needs to be redesigned, and when an extension is justified without compromising the core.
This is where many transformation programs get into trouble. If the SI cannot define SAP standard clearly, the business may end up with one of two bad outcomes. It may over-customize and create a system that is expensive to maintain, difficult to upgrade, and misaligned with clean core. Or it may over-standardize and create a process that technically follows the standard but does not support the way utility work actually gets planned, executed, completed, and trusted.
The question is not simply, “Will you keep us standard?” The better question is, “Can you prove that you understand SAP standard well enough to know when to follow it, when to challenge us, and when to design around real utility complexity without recreating unnecessary technical debt?” That is the level of answer utilities should expect before trusting an SI with a transformation program.
These Questions Expose the Difference Between Implementation Capacity and Transformation Readiness
Most system integrators can talk about implementation capacity. They can show staffing models, delivery methodologies, prior project experience, technical certifications, and project timelines. Those things matter, but they do not prove transformation readiness. They prove that the SI can participate in a program. They do not prove that the SI can protect the business from making poor design decisions that will live inside the operating model for years.
The three questions above expose something deeper. They reveal whether the SI is thinking from legacy habits or current SAP direction. They reveal whether the SI understands utility work flow or only understands system objects. They reveal whether the SI can demonstrate how work actually moves through phases and sub-phases, or whether they are relying on generic language. They reveal whether the SI can define SAP standard with enough precision to support clean core without damaging operations.
This distinction matters because utilities are too complex for surface-level transformation. A utility cannot afford a partner that simply configures what is requested without challenging the business. It also cannot afford a partner that forces generic standardization without understanding the field. The right partner has to do both. They need to challenge unnecessary complexity while respecting real operational complexity. They need to understand SAP deeply enough to protect the core and utility operations deeply enough to protect the work.
That is a rare combination.
The Real Question Is Whether the SI Can Protect Operational Trust
At the end of the day, the goal of SAP utility transformation is not simply to go live. It is not simply to modernize the system, reduce customization, implement integrations, deploy mobile tools, or produce dashboards. Those outcomes matter, but they are not the final measure of success.
The real measure is whether the business can trust the operating model after the transformation is complete. Can the utility trust the work order process? Can it trust how phases and sub-phases represent progress? Can it trust the asset data being created and updated through execution? Can it trust the integration between SAP, GIS, mobile, scheduling, finance, and reporting? Can it trust that SAP standard was defined properly and not used as a shortcut? Can it trust that clean core decisions strengthened the business instead of simply cleaning up the architecture?
Those are the questions that matter most because they determine whether transformation creates lasting value or simply produces a new version of old complexity.
Before trusting a system integrator with SAP utility transformation, leaders should ask the hard questions early. If the SI walks in talking about user statuses and notifications as the center of the conversation, be careful. If they cannot demonstrate the flow of phases and sub-phases through the work order process, be careful. If they cannot clearly define what SAP standard actually means, be careful.
The answers will tell you whether they are ready for the job. In a utility transformation program, finding that out early is far less expensive than discovering it after go-live.