Multi-entity by construction, and the structure was set before you arrived.
Workforce and ERP program leadership across large, multi-entity telecommunications environments. What makes this sector its own problem is inheritance: entity structures built through acquisitions and regulatory requirements over decades, carrying rules nobody currently employed decided on. Walk the five decisions, find your seat, then run the two-minute check.
Five calls that decide a telecoms program
Set early, inherited from decisions made years ago, and expensive to revisit. Pick a decision.
The current entity structure looks unnecessarily complicated, and simplifying it is an obvious early win.
Understand why each entity exists before proposing to change any of it, and separate the statutory reasons from the historical accidents.
Entities in this sector exist for license, regulatory, tax and acquisition reasons, and the person who knows why a particular one exists may have retired. Simplification proposed before that understanding is how a program acquires a regulatory problem it did not need. Some of the structure genuinely is accident and can go; the work is telling which is which.
For each entity, do we know why it exists and who confirmed that?
HCM design assumes a worker with a manager, a location and a schedule. Field technicians have dispatch, territories, on-call rotations, certifications and vehicles.
Design the field workforce model as a first-class population with its own owner, and route it explicitly rather than treating it as an exception.
Field populations are usually a large share of headcount and almost all of the operational risk. Treated as an exception to an office-worker template, the approval workflows become obstacles, dispatch works around them, and your workforce data stops describing where people are and what they are qualified to do.
Who owns the field workforce design, and has a dispatcher reviewed it?
Network inventory, provisioning and field service systems already run. They create the work, consume the materials and hold the truth about the network.
Name a client-side owner for each interface and agree the master for every shared record before design.
Materials consumed in the field, work completed and assets deployed all cross that seam. Without a named master the ledger and the network records diverge slowly, and in an asset-heavy business that divergence is a balance sheet problem rather than a reporting inconvenience.
Which system is master for deployed network assets, and who decided?
There is no window in which the network stops, and the maintenance windows that exist are for the network, not for your ERP.
Identify which operating cycles can absorb a gap and which cannot, and build the cutover around the ones that cannot.
The immovable cycles are usually payroll, field dispatch and materials replenishment, and customer commitments. Month-end close is painful and recoverable given a planned extension. Once that list is agreed the cutover becomes a scheduling problem instead of an argument about whether a window exists.
Which of our operating cycles can absorb a two-day gap, and which cannot?
Technician certifications get scoped as HR data, while dispatch systems read them to decide who can be sent to what work.
Make the certification record authoritative by design, and confirm both HR and dispatch read the same source.
Certification drives both pay and dispatch eligibility. If it is treated as an HR nicety in design, you end up with a pay rule and a dispatch rule reading data nobody made authoritative, and the first symptom is a technician dispatched to work they are not certified for.
Do HR and dispatch read the same certification record, and who verified that?
What those five mean for the chair you sit in
Telecoms programs get judged on field productivity and on statutory reporting. Each seat's exposure, the early sign, and the question worth asking this quarter.
Dispatch will route around you
Field operations solve problems in minutes because customers are waiting. Any approval workflow slower than the workaround loses, and once dispatch works around the system your view of where technicians are and what they are certified for stops being accurate. Certification is the sharpest case, because it governs who may be sent.
No dispatcher has reviewed the field worker model or the certification design.
Has a dispatcher reviewed how workers and certifications are modeled?
Entity structure is a statutory obligation
License, regulatory and tax reasons drive much of the entity structure, and a program that simplifies before understanding acquires a compliance problem. Meanwhile deployed network assets cross a seam into the ledger, and without a named master the asset position and the network records diverge quietly.
A simplification proposal exists before anyone has documented why each entity exists.
For each entity we propose to remove, who has confirmed why it exists?
The field population is the workforce
Technicians, dispatch, on-call rotations and certification-driven eligibility are the majority of operational headcount and almost none of the standard template. Add the workforce management clock: on-premises Workforce Central reaches end of life in March 2027, and moving off it is a reimplementation rather than an upgrade.
The field population is being handled as a set of exceptions to the office-worker design.
Is the field workforce a designed population or a set of exceptions?
The network never pauses, and that is the wrong frame
Decision four, drawn out. Continuous operation does not mean no window. It means the window is defined by which cycles can absorb a gap, and only one of them can.
Agree this list before anyone argues about dates. Named cycles turn the cutover into a scheduling problem instead of a debate about whether a window exists.
Four items already on the calendar
None of these are telecoms-specific, and all four land on a multi-entity program. Verify each against your own estate before the next steering meeting.
Engineering stopped at the end of 2025. Moving off it is a reimplementation rather than an upgrade, and any shift-based workforce is in scope.
Extended maintenance runs to 2030 for a fee. If the target platform is a lift and shift of ECC, it arrives with a published expiry date attached.
Oracle support runs past 2036. When an integrator sells urgency on that basis, the pressure is customization debt and scarce skills, not vendor abandonment. Knowing the difference is a negotiating position.
Not a deadline, a treadmill. Two mandatory regression cycles annually, permanently, and the item most reliably missing from a post-go-live staffing plan.
Five questions worth more than a readiness assessment
Answerable from memory, scored on this page, nothing captured and nothing emailed.
These five are the start of the instrument. A full review also covers statutory reporting by entity, materials and asset design, the provisioning interface inventory and hypercare exit criteria. Or skip the tooling and book the program review.
Running a multi-entity telecoms program?
Pre-SOW, mid-build, or stabilizing after a rough go-live with field operations unhappy. I sell no software and staff no builds, so these questions get asked out loud. Tell me where the program is and I will tell you what I see.