Reorganizing HR's Three Pillars for Business Results in the AI Era

The article opens with a common scenario: a business unit requests more staff to expand after-sales coverage, HR recruits and trains, AI handles standard queries, yet complex faults still require scarce experts at headquarters. The core problem is that hiring is an action, but a capability combination that delivers on promises is a different matter — one that must be calculated with the business and must clarify whether AI takes over standard consultations or expert time.

First, Reconstruct How the Service Delivers Results

Business asks for people, but HR must judge the operating problem. In the after-sales expansion example, the first step is to define exactly what the customer will receive: which issues can be resolved remotely, which require on-site presence, response-time commitments, safety and qualification requirements, and how restoration is verified. Different promises demand different people, capabilities, support, and investment.

The author references Business Scenario Redesign (BSR) from Mycelium Organization (菌丝体组织): start from the concrete outcome, re-examine service boundaries, evidence, capability combinations, and responsibility arrangements, then decide how to invoke processes and tasks. Existing recruiting, training, ticketing, and repair processes can stay; what must change first is the business arrangement they collectively serve.

Comparing Two Capability Combinations

Assume headquarters has senior diagnosticians, but the new region’s initial complex-fault volume cannot justify a full expert team. Two options are compared:

Option A: Equip every new region with complete diagnosis and field staff — reduces HQ dependence but bears full fixed cost and ramp-up time.

Option B: Centralize diagnosis at HQ, staff locally only for field work — avoids duplicating scarce experts, but incurs remote-diagnosis overhead, HQ queuing, and cross-region coordination costs.

Option B is viable only when several conditions hold simultaneously: a portion of faults can be reliably diagnosed remotely; HQ has available support windows; local staff can perform required checks and repairs; a credible escalation path exists for complex cases. AI can free expert time only if it handles standard consultations with acceptable quality and graceful handoff — reduced reception volume does not automatically equal increased expert capacity.

This trade-off reshapes both launch preparation and ongoing service organization: the region need not wait for a full expert team; once agreed capabilities and HQ support are in place, service can start within approved scope. Tickets are then routed by fault facts: remote-solvable go to central support, on-site needed go to local staff, beyond-local go to HQ specialists. Internal handoffs must be seamless; arrival on-site does not equal problem solved, and one remote reply does not equal a complete repair.

If remote diagnosis cannot cover the gap or central support cannot meet the promise, the company should add local expertise, narrow initial scope, or delay expansion. Avoiding duplicate expert teams is a conditional business choice, not a permanent excuse to never build local capability.

From Request to Pain Point: A Four-Level Filter

The article distinguishes four levels: request ("hire fast"), need (deliver service as promised), must-have (without qualified handling the promise cannot stand), and pain point (the gap already causes delays, rework, or lost opportunity, and the cost of inaction significantly exceeds the full cost of fixing it). Urgency alone cannot replace these judgments.

HR then compares internal redeployment, development, hiring, external services, AI, and work redesign — each with its own lead time, quality, and cost profile. Business and professional leads confirm service targets and technical conditions; decision-makers approve budgets and major trade-offs; HR produces a comparable capability proposal. If HR still starts from "fill every position in every region" without judging capability gaps and service combinations, all three pillars may simply execute faster the wrong recruiting, training, or procurement.

Align Three Pillars' Work and Investment to the Same Trade-off

Choosing centralized diagnosis plus local field work means the original plan — full teams per region, full training programs — must be redone. Otherwise the integrated solution gets broken back into separate recruiting, courses, and tickets, each completed in isolation with no one tracking whether the combination actually works.

The article cites McKinsey’s August 2026 discussion on HR’s agentic transformation: first define the human-AI operating model, then arrange implementation, and discuss product, platform, and flexible-network organization. For a specific enterprise, the more direct questions are: which professional capabilities need long-term maintenance, which support should be bundled with business tasks, and which existing work can be reduced.

Mycelium Organization describes this as "strong core, agile front-end" (强内核、活前端): professional methods, shared standards, and public services are continuously built by a core; people close to the business combine needed capabilities within clear boundaries. Who owns long-term professional capability building and who organizes the current task must be resolved together.

COE: Clarify Capability Requirements and Maintain Shared Services

COE works with the business to break down capability needs: what HQ diagnosis requires, what local field work must have, how people grow step by step. Recruiting profiles, phased learning, and competency assessments are adjusted accordingly. Redundant per-region authoring of the same materials is eliminated; investment shifts to reusable talent-preparation services. Training for full diagnosis not yet needed locally can be phased, but training for current field tasks and qualifications must be preserved, and professional growth paths cannot be cut off.

Shared services need ongoing maintenance: when service scope or product standards change, recruiting criteria, training content, and evaluation methods must update; when entering another region, local applicability must be verified. COE maintains HR professional methods; the corresponding business professional side confirms diagnosis standards, safety requirements, and repair qualifications — a set of learning materials is not a substitute for professional qualification itself.

HRBP: Shift from Per-Region Headcount to Agreed Role Combinations and Cadence

HRBP transforms the "fill every role in every region" recruiting plan into a jointly confirmed role combination and staffing rhythm: which local roles must arrive first, what HQ support can cover, which roles are deferred, what changes trigger building local diagnosis capacity. When people, learning, and qualification data are reliably accessible, less time is spent chasing reports and manually stitching spreadsheets; more time goes to verifying real workload, judging gaps, and adjusting plans. System skill tags still require validation against actual competence.

SSC: Stable Services Plus Reliable Data for the Expansion

SSC continues stable payroll and employee services while ensuring that transfers, learning arrangements, and qualification data for the expansion remain continuously available. When permissions, data quality, and conditions allow, AI assistants or existing systems can handle standard queries, application completeness checks, and status updates — reducing manual replies, duplicate entry, and hand-offs. Professional qualification judgments, candidate fit, and complex employee issues remain with the appropriate people.

Reducing this work also creates new investment: content maintenance, data correction, service audits, and exception handling. Tech teams maintain tool operation; COE and business professionals maintain content and judgment standards; SSC runs daily service and exception processes. Employees must be able to flag errors, get explanations, and see corrections — upload and go-live are not the end of maintenance responsibility.

Task Contract (TC) and Task-driven Accountability Network (TAN)

The three pillars’ work and maintenance spend must jointly answer one result: by the agreed date, can the new region meet the conditions to deliver the promised service? To make this explicit, a Task Contract (TC) is formed, specifying outcomes, boundaries, key judgments, evidence, and escalation conditions: what local handling capabilities exist, what HQ provides, which unmet conditions block expansion, who confirms readiness with what evidence.

HR leads organize talent and organization support within their remit; business professionals verify handling capabilities and support conditions; the after-sales lead decides whether to launch within authorized scope based on complete preparation. Training completion only proves an activity ended; actual drills and fitness assessments support competence judgments; HR readiness does not replace customer-service acceptance.

Task-driven Accountability Network (TAN) links these agreements into ongoing collaboration: who supplies professional capability long-term, who actually owns it in this task, who pulls the end-to-end service, who handles dependencies after changes. HQ support must exist not just on a roster but with confirmed scope and windows; local staff encountering beyond-capability faults must find someone with authority and ability to take over. Sending a request does not mean the other side has caught it; HR does not own all business outcomes.

Expansion preparation is a time-boxed collaboration; post-launch qualification updates, diagnosis support, and employee services enter continuous operations. Stable, repetitive work becomes daily service; only important, time-bound, cross-functional improvements that existing mechanisms cannot absorb are organized as separate time-boxed collaborations. The three pillars need not become five new departments, but their work, budgets, and services must change together.

Separate Time Savings, Re-deployable Capacity, and Cash Savings

Once the new combination is in place, HR leaders must work with business and finance to judge which resources are released, which need reinforcement, and which existing investments should stop. Cross-business budgets, headcount, and major adjustments still require proper approval.

Individual time saved (employees spend less fragmented time) ≠ re-deployable capacity (a block of work redesigned to free capacity for other tasks) ≠ cash cost reduction (net cash outlay actually falls after subtracting new tool, maintenance, review, and development spend). These three cannot be equated.

HR’s own change must be calculated the same way: list the effort and cash for content maintenance, data correction, service audits, and exception handling; then measure how much of the old answering, entry, and reporting actually disappears. Only when digital service stably takes over can redundant processing be retired; running old and new in parallel may erase time savings.

Re-deployed HR hours can go to maintaining shared services, organizing local training, verifying staffing readiness, or handling complex employee issues — matched to actual people capabilities. These hours cannot be directly converted into after-sales expert diagnosis capacity, nor can they be simultaneously used for new services and fully booked as headcount reduction. New work must enter employees’ workload, reward, and development plans; AI time savings cannot be booked as gains while staff work overtime on complex tasks.

Expert diagnosis time truly freed should first secure existing and new region service commitments and leave buffer for complex-case volatility. Cutting expert staff or further expanding coverage while the combination is still unproven risks removing the very conditions that support the new arrangement. The same capacity cannot both fully fund expansion and fully count as headcount savings.

Not replicating full expert teams in every region avoids a portion of planned new spend — it does not mean existing cash cost has already dropped. Part of that budget might be redirected to local preparation, shared development methods, and knowledge maintenance, but the two investment types should be evaluated separately.

Current necessary local training should be judged on whether local people reach agreed handling capability and quality at appropriate full cost, not on whether later regions will reuse it. Shared build and maintenance spend for future reuse must be evaluated on actual later-region usage, quality, and full cost.

Only when the combination stably delivers the promised service should remaining resources be redirected: if new demand persists, quality and load allow, assess broader coverage; if local volume now supports a diagnosis team, or central wait-and-rework cost exceeds full local build cost, compare building a local team; if demand is insufficient or prior outsourcing/hiring is no longer needed, stop that investment.

HR evaluation must therefore go beyond hiring speed, course completion rates, and transaction SLAs to ask whether these activities jointly form the needed capability, what it costs to sustain, and whether they improve service within the agreed scope. Business volume, product faults, and people baseline all affect outcomes — not all revenue growth or quality improvement can be attributed to HR or AI.

Verify Along a Single Repair Ticket Whether Support Actually Reaches the Customer

Expansion readiness approval is the basis to start delivering the promised service. In operation, whether HQ support arrives on time, local staff can handle, and actual costs match estimates must be tested by real tickets — and this evidence must feed back into HR and business capability-combination decisions, not just be used to close the current ticket.

The difficulty: staff qualifications live in HRIS, faults and repairs in the after-sales system, expert schedules in rostering, parts facts in inventory. Each record may be correct individually, yet together they may not add up to a single fulfilled customer promise.

Example: a new-region customer reports equipment downtime; the local engineer is on-site but finds the fault beyond their diagnosis range. The after-sales system shows "dispatched", the learning system shows "training completed", HQ expert receives a help request but hasn’t confirmed when they can support. The customer’s needed recovery progress falls between these local statuses.

If the existing after-sales platform can already reliably connect people conditions, support receipt, handling evidence, and exception escalation, keep using it. When cross-system tasks multiply and manual follow-ups still fail to connect, the enterprise then needs to evaluate an organizational operating system to carry this load.

Mido’s MOOS (Mycelium Organization Operating System) connects the same customer outcome with work agreements at each node. It references the original ticket and its changes, linking applicable staff qualifications, HQ support arrangements, and named responsible people to this specific diagnosis, handling, and result confirmation. Expansion-readiness agreements solve launch conditions; each ticket, based on the approved service scope, forms a task contract for that work instance; both connect through the same capability requirements and support conditions. Original systems remain the authoritative store for tickets, repairs, qualifications, and inventory — MOOS does not build a parallel repair ledger or HR ledger.

Business, professional, and technical people must first confirm fact sources, interfaces, permissions, and status meanings, then configure ticket templates. Routine handovers bring in the current people, scope, and time limits; only when service promises or risk boundaries change does a decision-maker reconfirm. Employees don’t re-fill thick forms every time, but for this instance — who accepted, on what basis they handled, what confirms the result — must be verifiable.

Following one ticket: the local engineer records site observations and check evidence in the after-sales system; MOOS links these to the diagnosis task. HQ professionals confirm acceptance scope and response plan — only then is support considered landed. Diagnosis conclusions, applicable conditions, and follow-up handling requirements are confirmed by the relevant professionals; the local engineer executes within their qualification and authorization. Repair records and parts movements stay in the original business system; MOOS references their results so the service lead can judge which segment is still undelivered.

AI can organize fault materials, flag missing evidence, or suggest actions — but it cannot alter staff qualifications, accept tasks on behalf of experts, or turn "suggest part replacement" into "already repaired". Fact conflicts return to the authoritative source; execution results not yet returned stay in pending-verification state.

If HQ has no one able to accept within the agreed window, or new evidence shows the original diagnosis unfit, the after-sales lead for this ticket triggers escalation: contacts the pre-arranged HQ diagnosis duty lead, who confirms specific professionals, acceptance scope, and response plan. Until the duty lead organizes support, the after-sales lead continues tracking the diagnosis gap and updating the customer; if the duty lead cannot mobilize, it goes to the business lead with authority to adjust resources or service promises. System-configured intercepts limit unauthorized actions; field engineers stop affected work per professional procedure; resuming requires new professional basis and valid authorization — sending a notice or getting no response does not equal takeover.

A repair ends only after agreed re-test, run records, and necessary customer confirmation judge whether function is restored and whether residual items remain. Customer confirmation works only within its proper scope; it cannot replace professional verification. MOOS links these evidences to the instance’s result agreement so the after-sales lead can distinguish "dispatched", "handled", and "agreed problem solved". Follow-up remediation or observation items have their own owners; they don’t disappear when the ticket closes.

Concrete Customer Change and Continuous Capability Calibration

The customer gets tangible change: no repeated explanations between local and HQ, visibility into who is driving and what’s next, and the enterprise spots "dispatched but no one diagnosing" waits earlier. For HR, the same business instance re-tests the capability design: if waits come from insufficient HQ support, revisit role combinations and coverage cadence; if from local handling gaps, add training or people; if from mismatched qualification records, service content, or reality, fix data and maintenance routines. Not every delay simplifies to "hire more".

Verification should select tasks with similar risk, complexity, and service conditions, comparing customer time from ticket to agreed resolution — especially waits and rework on complex and failed tasks — and checking whether original regions are affected. Full cost includes local training, expert support, tools and interfaces, data and content maintenance, manual verification, and remediation; business conditions like parts availability must be verified to avoid crediting HR for their improvement. Shorter prep but lower repair quality, or less customer wait but chronic expert overtime, do not prove the combination is sustainable.

Valuable methods must also pass subsequent reuse tests. Applying this experience to the next region requires qualified people to use, quality-check, and maintain it; then decision-makers decide whether to absorb into shared services. Current customers’ handling need not wait for shared-method completion; extra reuse investment cannot be permanently locked in on one success.

Conclusion

Three-pillar transformation must ultimately change how the enterprise forms and uses capabilities: faced with a business problem, first judge whether the customer outcome and service arrangement need restructuring, then choose the talent-AI combination; once the design is set, let professional building, staffing, services, and maintenance investment change together; when resources release, separate what funds promise delivery, what deserves continued building, and what should stop.

Building full teams per region versus conditionally reusing HQ diagnosis, local handling, and shared talent-preparation services yields different prep times, fixed investments, and response risks. Competitive difference comes from whether the enterprise can adjust this combination by business phase and, within acceptable full cost, keep support continuously reaching the customer. Fewer roles, faster answers, more tasks — none alone proves this.

Next time HR organization adjustment is discussed, bring a live business goal, a recent unresolved customer request, and facts about people capabilities, actual workload, and investment. Put them together to judge what must change: the service promise, the capability formation method, the three pillars’ support, or the already-released but not yet reallocated resources. Only then do org-chart changes have a business rationale.