ERP Implementation Consultant, Kuwait

Why group rollouts in Kuwait lose momentum

Group ERP programs in Kuwait tend to struggle in recognizable ways, and most of them start in the first wave:

• The pilot becomes a one-off. The first company's design is shaped around its own preferences, with customizations nobody checked against the other businesses. When the second company arrives, much of it has to be redone.
• Shared people are overloaded. Group finance, procurement and IT staff support every company. During the first rollout they are stretched thin, and later waves are delayed because they are still fixing the first.
• Decisions are made informally. Owners and senior managers give instructions in conversation, and the partner builds to whichever instruction came last.
• Intercompany flows tested late. Trading between group companies only works once two of them are live, so the problems surface after the second go-live rather than before.
• Later contracts left vague. The partner's commitments for subsequent companies were never priced precisely, so each new wave becomes a fresh negotiation.

None of these require a different platform to fix. They require a group-level view held by someone whose job is to protect it. That is the role I take, working from the owner's side. If a group rollout has already stalled, the ERP recovery service is the better place to begin.

Designing a group template and a pilot company

A group template is the set of design decisions every company in the group will share. Agreeing it before the pilot design is finished is the single most useful thing a Kuwaiti group can do to keep later waves affordable.

With group finance, the partner and the heads of each company, I work through the template elements:

• A common chart of accounts and the dimensions used for reporting, such as branch, brand, project or principal.
• Rules for shared master data: which customers, suppliers and items are common, who owns them and how duplicates are prevented.
• Approval limits and roles that apply group-wide, with room for company-specific additions.
• Standard document layouts in English and Arabic, whose Arabic text comes from your staff or the partner.
• The group reports owners expect to see, defined once and reused for every company.

The pilot company then implements the template plus its own specific needs, and every design decision is tagged as either template or local. That tagging makes it obvious, when the second company starts, what can be reused and what must be built again. Choosing the pilot also matters: it should be representative enough to test the template, but not so complex that it delays everything else. The multi-company ERP page describes common group structures in more detail.

Opening balances across related companies

In a Kuwaiti group, each company may be moving from a different system: a local accounting package in one, Tally or QuickBooks in another, Sage in a third, and spreadsheets for stock or project records in several. The partner or your IT staff extract and load the records. The checks that make the opening position trustworthy are owned from the business side.

For each company, I agree what moves and reconcile every trial load with finance: the trial balance account by account, customer and supplier balances one party at a time, warehouse stock in units and value, bank balances and open orders. Because the dinar carries three decimals, I check that totals match the source exactly, and that any source system working with fewer decimals has not introduced rounding gaps.

Intercompany balances need particular care. A receivable in the trading company should equal the payable in the contracting company, and in practice the two sides rarely agree on the first attempt. Timing differences, unrecorded recharges and old disputes all surface. I list every intercompany pair, agree the differences with both finance teams before cutover and document how they were resolved, so group consolidation works from the first month.

See ERP data migration for the full approach, while the legacy software migration page covers older local packages.

Salary transfers, POS feeds and other cutover dependencies

Most of what can go wrong on go-live day in a Kuwaiti group sits at the edges of the ERP, where it connects to banks, outlets and outside partners. I list these dependencies for each company early and make sure each has an owner and a test.

Payroll and salary transfers. Salaries are paid through the banks, and the file the new system produces must match what your bank expects. The switch happens between two pay periods after a parallel payroll has matched the old one employee by employee, and a test file accepted by the bank before go-live. Leave and end-of-service balances are reconciled with your accountant, and labor rules are confirmed by your HR advisor.

POS feeds for franchise and retail outlets. Daily sales, payments and stock movements must flow from each outlet into the right company and branch. I make sure the integration is tested with real outlet data over several days, including refunds and voids, before any outlet relies on it.

Bank payment files and principal reporting. Supplier payment batches in dinars and other currencies are tested with the bank, and reports owed to foreign principals for agency product lines are rebuilt and checked against the last ones sent.

Each dependency becomes a line in the cutover plan with a named owner and a go/no-go check. The broader approach is on the ERP integration page.

Testing, owner sign-off and hypercare for each wave

Every company in the group runs its own UAT, using scripts built from its processes. Process owners test their areas with realistic data, and I record results and defects in a shared log. For later waves, the scripts also cover intercompany flows with companies already live, so trading inside the group is tested before it is relied on.

Owners in Kuwaiti groups want to know whether a company is ready, without reading defect logs. Before each go-live, I prepare a short readiness summary: what was tested, what passed, what remains open, and what the risk is of going ahead. The owner or the delegated sponsor signs off on that basis, and nobody is switched over by default because a date arrived.

After each go-live, I run a daily issue review with the company's key users and the partner until the first period close is complete and the group consolidation includes the new company correctly. Problems found in hypercare are also logged as lessons for the template, so the next company starts from a better position.

Everything happens online and in English, with any visit agreed separately by arrangement. For the final stage, see ERP go-live support; if the group is still choosing a platform, the Kuwait ERP selection page explains how I help.