IT Training Before an ERP Launch in Saudi Arabia: Selecting Practice Transactions

Six weeks before go-live, a Saudi distribution company shares its IT training plan: two days per department and a slide deck covering every screen of every module. On the first Sunday after launch, a receiving clerk in Dammam cannot post a delivery because the supplier shipped cartons against a purchase order raised in single pieces. In Riyadh, an accounts payable accountant waits for that receipt before she can match the invoice.

Neither of them lacked a product overview. They lacked practice on the few transactions their roles would perform in the first weeks, using data that behaved like the real thing, and a clear next step when something did not match. That is the gap pre-launch IT training should close.

This article is for HR teams and functional training owners planning IT training before an ERP launch in Saudi organizations. It covers how to select practice transactions by role, prepare test data that makes them realistic, and build support steps into the exercises, instead of explaining the entire product. The scenario above is hypothetical, as is the later example.

Why a Full Product Tour Is the Wrong Starting Point for IT Training

An ERP is broad by design. Finance, procurement, inventory, sales, and HR often share one database, and each module has dozens of screens. A module-by-module tour feels complete, yet most employees use a small part of the system and forget screens they saw only once. When IT training tries to cover everything, it rarely covers anything deeply enough for people to perform.

Interdependence matters even more. In an ERP, one person’s entry is the next person’s starting point: a goods receipt allows an invoice match, which allows a payment. A meta-analysis by Sharma and Yetton in MIS Quarterly found that the effect of training on the success of information systems implementation is a function of technical complexity and task interdependence. Our practical reading for ERP IT training: design around the work and the handoffs between roles, not around the menu structure.

Many organizations treat an ERP launch as one milestone in a wider Digital Transformation program. The IT training it needs is narrower than the program’s ambitions: the right people, able to complete the right transactions, on day one.

Step 1: Map Each Role to Its First Transactions

Start with a role–transaction map. For each role affected by the launch, list the transactions the person will perform in the first 30 days after go-live. Process owners and the implementation partner usually hold this in their process designs and test scripts; your task is to turn it into an IT training list for each role. Then score each transaction against four questions:

• Frequency: is it daily, weekly, or only at month-end?

• Consequence: what goes wrong if it is done badly, such as a delayed shipment, a wrong payment, or a stock difference?

• Dependency: does another role wait for it before doing its own work?

• Change: is it new, or does it replace a familiar step from the old system or a spreadsheet?

Transactions that score high on at least two questions go into the practice set; the rest can be covered by a reference guide and a short demonstration. Aim for a short list per role, often five to eight transactions, because IT training before launch competes with daily work and with the project’s own testing.

Step 2: Build Practice Sets from Three Kinds of Transactions

For each role, the IT training practice set should include:

• The routine path: the transaction on a normal day, such as a goods receipt against a complete purchase order.

• The common exception: a variation frequent enough to matter, such as a partial delivery, a price difference, or a missing approval.

• The handoff: a transaction that passes work to another role, practiced together with that role so that both see the effect of a wrong entry.

Exceptions deserve more weight than they usually get. IT training scripts tend to follow the routine path because it demonstrates cleanly, yet after go-live, many user questions concern transactions that did not go as expected. A meta-analysis of 24 studies by Keith and Frese found that error management training, which encourages learners to make errors and learn from them, had a positive overall effect, with larger effects on transfer after training than on performance during it, especially for tasks that differ from those practiced.

So design some IT training exercises to go wrong in realistic ways: a quantity that does not match, a supplier on hold, a closed posting period. Learners work out what the system is telling them and how to recover.

Step 3: Prepare IT Training Data That Behaves Like Real Work

Practice transactions are only as realistic as the data behind them. Nobody can practice a partial delivery in an environment with no open purchase orders. Before IT training starts, ask the project team to prepare a scenario data set for each practice set:

• Familiar master data: items, units of measure, customers and suppliers similar to the real ones, in Arabic and English where the live system will show both.

• Open documents in the right state: purchase orders awaiting receipt and receipts awaiting invoices.

• Built-in exceptions: a price difference, a supplier on hold, an item without enough stock.

• Separate data for each learner or pair, and a reset plan between IT training groups.

Do not fill the training environment with copies of live employee or customer records because it is faster. The Implementing Regulation of Saudi Arabia’s Personal Data Protection Law requires controllers to collect only the minimum personal data necessary for the purpose of processing and to retain only the minimum. Purpose-built test records avoid the question; where real data seems unavoidable, agree the approach with your data protection function first.

Step 4: Write Support Steps into the IT Training Exercises

After go-live, part of every employee’s job is knowing what to do when the system behaves unexpectedly. That is one of the most useful IT skills a new user can have, and IT training can practice it directly. For each practice transaction, agree on three support steps before the sessions begin:

• Self-help: a one-page quick reference with the key fields and common system messages, in the language employees use at work.

• First line: the named key user in the department who can resolve routine questions on the spot.

• Escalation: how to raise a ticket, which category to choose, and what to include, such as the document number and a screenshot.

Then end with at least one exercise per role with the support step rather than success: the learner meets a problem beyond their level and must raise a complete request. A ticket that says only ‘system not working’ sends the support team back for details. For transactions that need a visual reminder after IT training, short demonstration videos linked from the quick reference often help more than another slide deck.

Step 5: End IT Training with a Transaction-Level Readiness Check

Attendance at IT training is a weak readiness signal. Before go-live, each learner should complete their practice set unaided while a key user or trainer records the result for each transaction: completed correctly, completed with prompts, or not completed.

Keep the record at transaction level. If most of a team cannot complete a partial receipt, that is a design or data problem to fix before launch. The same view shows where to place floor support in the first week and which quick references need rewriting. It also shows whether IT training has moved people from watching to doing, a distinction explored in our guide to testing whether training moves employees from viewing to practice. If sessions run in a dedicated room, see our article on setting up an instructor-led software lab.

A Hypothetical Example: IT Training for a Food Distributor in Riyadh and Dammam

This example is hypothetical and shows only how the selection works.

A food distribution company with warehouses in Riyadh and Dammam is replacing spreadsheets and an older accounting package with an ERP. Its first IT training plan is a two-day module overview per department. The HR lead and the warehouse operations manager, who owns training for the warehouse teams, rebuild the plan around practice transactions.

For receiving clerks, the role–transaction map produces six transactions, and four go into the practice set: a receipt against a complete order, a partial delivery, a damaged carton recorded for return, and cartons delivered against an order raised in pieces. The last runs as a handoff exercise with two accounts payable accountants, who try to match the invoice and see the effect of a wrong receipt. Each pair of learners has its own data set, and each practice set ends with a ticket exercise for a missing item code.

Two weeks before go-live, key users observe each clerk completing the four transactions unaided. Several need prompts on the unit-of-measure case, so the team rewrites that quick reference, adds a short refresher in launch week, and places a key user at the Dammam receiving desk for the first week. The revised IT training plan is shorter than the original, but every hour goes to work the clerks will do on day one.

Questions to Ask Before You Commission ERP IT Training

Whether the sessions come from your implementation partner, an internal team, or an external provider, ask:

• Will the IT training be built from our role–transaction map or from a standard module curriculum?

• Who prepares and resets the training data?

• How many exception and handoff exercises does each role get?

• Are quick references and support steps in scope, in Arabic and English?

• How will readiness be recorded per person and per transaction?

• How will new joiners receive IT training after the launch team leaves?

General IT courses on system features suit administrators and analysts. For end users before an ERP launch, the test of any proposal is whether it trains the transactions your people will perform, with your data and your support routes.

Summary

Pre-launch IT training succeeds when it prepares each role for the transactions it will perform first, not when it explains the whole ERP. Map roles to transactions, select a practice set of routine paths, common exceptions and handoffs, and prepare test data that behaves like real work.

Build support steps into the practice, check readiness transaction by transaction, and fix the gaps before go-live. The result is IT training that is smaller in scope and much closer to the work employees will do on their first day in the new system.

If you want Skillup MENA to help you, click here.