The conglomerate onboarding problem
An Indian conglomerate with 20 group companies — manufacturing, services, IT, real estate, hospitality — hires 1,500-3,000 people every year across these entities. The CHRO sits at the top of this organisation thinking about workforce strategy. The CEOs of the operating companies sit below, focused on running their businesses. The HR teams of each entity handle their own hiring and onboarding.
The result, in almost every conglomerate I have worked with, is 20 different onboarding processes, 20 different document checklists, 20 different IT-account provisioning workflows, 20 different ID card formats, and 20 different experiences for a new joiner. New joiners moving between group companies (a common career path in conglomerates) face fresh paperwork as if they had never been with the group.
This is not strategic differentiation. It is accidental fragmentation that nobody designed.
Five concrete costs:
- 1Inconsistent compliance. Some entities verify PAN; others do not. Some run background checks; others skip them. The conglomerate is one bad hire away from a regulatory issue at the weakest entity.
- 1Duplicated technology. Each entity has its own HRMS or its own Excel workflow. The group pays for 20 HR systems and none of them speak to each other.
- 1Wasted onboarding effort. When an employee moves from Company A to Company B (a transfer or promotion), they re-do background verification, re-submit documents, re-do orientation. Two weeks of productivity lost per transfer.
- 1Brand inconsistency. New joiners experience wildly different first weeks at different group companies. Some are excellent; some are awful. Word travels fast on Glassdoor and LinkedIn.
- 1No group-level workforce visibility. The CHRO has no consolidated view of hiring velocity, new-hire profile, time-to-productivity, or first-90-day attrition across the group. Decisions are made on anecdote.
The fix is centralised onboarding — one process, one platform, one experience, multiple entities. Below is the architecture.
What "centralised" must mean (and what it must not)
The instinct is to centralise everything. This is wrong. Some things must stay entity-specific. The architecture has to distinguish.
Centralise (group level)
- Onboarding process and policy. One process across all entities. One policy document. One quality standard.
- Document checklist and verification logic. Same documents collected and verified the same way across all entities, with entity-specific additions where regulation demands.
- Background verification. One BGV vendor relationship at group level (volume drives pricing). One quality standard. Results stored centrally so an employee moving between group companies does not re-verify.
- Identity master. One employee record with a group-wide employee ID. Movement between entities is a transfer, not a fresh hire.
- Pre-boarding experience. One welcome workflow from offer-acceptance to Day 1, including pre-Day-1 communication, document upload, manager introduction, and first-day logistics.
- Onboarding analytics. One dashboard showing time-to-productivity, first-90-day attrition, new-hire NPS — by entity and consolidated.
Keep entity-specific
- Statutory compliance. PF, ESI, professional tax, gratuity registration, and labour law compliance must be done per entity per state. The group cannot blur these.
- Compensation structure and benefits. Each entity has its own salary bands, benefits, and stock plans.
- Manager and team introduction. A new joiner at the manufacturing company meets manufacturing leaders; one at the IT services company meets IT leaders. The introduction content differs.
- Operational orientation. Each entity's day-to-day systems (factory floor, IT systems, client portals) are entity-specific.
- Culture and values. Group values exist but each entity has its own culture overlay.
The split is the central design decision. Get it right and centralisation enables consistency without bureaucracy. Get it wrong and it produces either friction (over-centralisation slowing decisions) or chaos (under-centralisation defeating the purpose).
The technology architecture
A centralised onboarding platform has four logical layers:
Layer 1: Group identity and employee master
One source of truth for every employee record. When a person joins any group entity, they get a group-wide employee ID. Their identity record holds: personal details, identity documents (Aadhaar masked, PAN, driving licence), background verification status, qualifications, certifications, previous roles within the group, and current role.
When the same person transfers between entities, the record persists. The new entity sees the verified history, the previous BGV, and the qualifications. Onboarding for transfers becomes a 1-day exercise rather than a 2-week one.
Layer 2: Workflow engine
The workflow engine orchestrates onboarding tasks across systems and people. Tasks include: send offer, receive acceptance, request documents, verify documents, run BGV, create payroll record, provision IT, schedule orientation, schedule manager introduction, schedule department orientation, deliver ID card, complete onboarding survey.
The workflow has entity-specific branches (statutory compliance tasks differ by entity and state) but the common spine is the same. Status visibility is real-time across all in-flight onboardings.
Layer 3: Integration fabric
The platform integrates with: - Entity-level HRMS systems (where they exist and continue to operate) - Payroll systems for new-hire record creation - IT provisioning systems (Active Directory, Microsoft 365, Google Workspace, Slack, etc.) - Document storage systems - BGV vendors via API - Aadhaar offline e-KYC for identity verification - e-Stamping and e-Sign for offer letters and employment contracts - Learning management systems for onboarding training - Communication channels (email, WhatsApp, SMS) for joiner communication
Layer 4: Analytics and governance
Group-level dashboards show: hiring velocity by entity, time-from-offer-to-Day-1 by entity, onboarding completion rates, new-hire NPS, first-90-day attrition by entity and by role family, BGV findings and trends, and cost per onboarding by entity.
This visibility is what the CHRO needs to manage group-wide talent strategy.
The implementation sequence
For a conglomerate consolidating onboarding, a typical 18-month sequence:
Months 1-3 — Discovery and design. Map current onboarding processes across all entities. Identify common patterns and entity-specific variations. Design the target architecture.
Months 4-6 — Pilot entity selection and rollout. Pick one mid-size entity (typically the corporate HQ or the largest single business) and roll out the centralised platform. Use it as a working prototype.
Months 7-12 — Wave 1 rollout. Roll out to 5-8 additional entities in a phased manner. Refine the process and platform based on learnings.
Months 13-18 — Wave 2 rollout and stabilisation. Roll out to the remaining entities. By month 18, all 20 entities operate on the centralised platform with their entity-specific configurations.
This is slower than most conglomerates initially plan for. The slowdown comes from change management — every entity has its own HR habits and its own resistance. Rushing this phase produces incomplete adoption and configuration debt.
The compliance dimension
Indian onboarding has compliance touchpoints that the platform must handle correctly:
- PF (Provident Fund) — UAN allocation, UAN-Aadhaar linking, account creation
- ESI (Employee State Insurance) — registration where applicable
- Professional tax — state-specific registration
- Gratuity — eligibility tracking from Day 1 (though payable only after 5 years)
- TDS — first-month TDS calculation based on declared regime
- State labour law registrations — varies by state and company size
- POSH compliance — anti-harassment policy acknowledgement and mandatory training
- DPDPA compliance — informed consent for personal data processing
- Industry-specific — security clearance for defence-related entities, etc.
A centralised platform that handles all of this correctly while still accommodating entity-specific variations is non-trivial to build but essential for the conglomerate use case.
What changes for the conglomerate
A group running 12-24 months on centralised onboarding typically reports:
| Metric | Before | After |
|---|---|---|
| Time from offer to productive | 35-50 days | 18-28 days |
| Onboarding cost per joiner | ₹18-30k | ₹9-15k |
| Document re-collection on inter-entity transfer | 100% | 5% |
| BGV cost per joiner | ₹3.5-6k | ₹1.8-3k (volume) |
| New-hire NPS | 5.5/10 | 7.8/10 |
| First-90-day attrition | 12-18% | 7-10% |
| Group-wide workforce visibility | Manual | Real-time |
| Compliance audit readiness | Mixed | Consistent |
For a conglomerate hiring 2,000 people annually, the cost savings alone (₹15-30k per joiner × 2,000) is ₹3-6 crore per year. The qualitative benefits (consistent experience, retention improvement, brand consistency) are larger but less quantifiable.
The bottom line
Centralised multi-entity onboarding is one of the highest-leverage strategic moves a conglomerate CHRO can make. The technology is mature, the architecture is well-understood, and the financial and experience benefits are substantial.
For Indian conglomerates that have not yet centralised, the cost of inaction is paid quarterly in inconsistent experience, fragmented operations, and missing strategic visibility. Centralisation is a 12-18 month journey; the sooner it starts, the sooner the benefits compound.



