At a glance
- Client: a leading producer of poultry, pork and processed meat products, centralising disparate databases onto SAP ERP from 2015
- Scope: load scripts emulating purchases, sales, logistics and related financial processes across eight production plants
- Where the load came from: workstations at the production plants themselves, using LoadRunner
- Results: the main logistics business scenario completed more than 2× faster, individual transactions up to 8× faster
- The odd obstacle: part of the system ran on Hercules, a custom tablet issued to plant managers and not available for sale, so there was no equivalent device to test on
- Also delivered: a printing configuration fast enough for the customer, and integration with external systems verified under load
- Follow-on: the client returned years later for load testing of a SAP warehouse management system
What the engagement had to prove
The client was consolidating scattered databases into an automated SAP control system as the business grew. The question for testing was simple to state and expensive to get wrong: are the critical business processes fast enough to run the company on this platform.
Four difficulties, and what they cost
This case is worth reading for the obstacles rather than the outcome, because they recur on almost every ERP programme:
The system was still being updated while the scripts were written. That meant additional test runs every week - scripts written against a moving target need continuous revalidation, and budgeting for one clean run is a planning error.
Test data had to be passed between scripts. Solved with Virtual Table Server, which ships with LoadRunner.
External system emulators were run by third-party contractors, manually - so their behaviour was unpredictable. The fix was organisational, not technical: joint working with the customer and direct communication lines to the contractors, so the right person could be pulled in the moment something broke.
Scripts were developed by a remote team. Coordination was solved with Git plus an explicit ownership system for each script, which also made development status visible. A multi-stage documentation approval process slowed things further, so the team produced a concise load testing methodology the customer's own staff could work from.
The tablet that could not be bought
Managers at the plants worked through an application built for Hercules, a custom tablet that is not sold and has no comparable substitute. That is a real constraint rather than a curiosity: testing on a similar device or an emulator does not guarantee the same behaviour on the native one, so the hardware has to be obtained before the scenario can be trusted. Generic test plans never anticipate it, and it is the kind of dependency worth surfacing in scoping rather than in week three.
Results
- The main logistics business scenario ran more than 2× faster after optimisation based on the test results.
- Individual transactions sped up by as much as 8×.
- A printing configuration acceptable to the customer was identified - mundane, and exactly the kind of thing that blocks a plant's shift when it is wrong.
- Integration with external systems was verified under load.
- The customer could make an informed decision about deploying to production.
The second engagement: SAP warehouse management
The relationship did not end with the ERP rollout. A few years later the same client brought PFLB back to load test a SAP system for warehouse management, with four questions to answer: are business processes interrupted under capacity testing, can the required document volume be processed, does it meet its performance metrics targets, and what limits it.
The obstacles rubbed against the same places. The system was again still in development, so stages had to be repeated. It had to be **adjusted before it could be load tested at all**, which meant working directly with the developers. The project started late, and part of the work was handed to the customer's own team, who turned out not to have the skills for it - a scoping risk worth naming, because it is common and rarely planned for.
The result was partial, and that is the honest version. Business processes were proven not to break, and the required document volume was proven processable. But the system only partially satisfied the performance requirements: developers fixed some of what was found, and the customer accepted the remainder as a declared risk at deployment. PFLB identified several limiting factors, among them locking during document processing, and the developers eliminated part of it on those recommendations.
Questions this engagement answers
How do you load test against a system that is still changing?
You re-run continuously - weekly here - and treat script maintenance as part of the engagement rather than an overrun.
What happens when parts of the test rig belong to other contractors?
Their manual, unpredictable emulators become your risk. The workable answer is direct communication with those teams, agreed in advance, not escalation after each failure.
Can you test an application built for hardware you cannot buy?
It is the constraint to solve first, not a footnote. Here the managers' terminal was a bespoke tablet with no equivalent on the market, and an emulator would not have produced trustworthy numbers.
What kind of gains does ERP tuning produce?
In this engagement: logistics scenarios twice as fast, individual transactions up to eight times faster - from configuration and optimisation, not from replacing the platform.
Standing up an ERP across multiple sites?
The processes that decide whether a plant runs are rarely the ones in the demo. Testing them from the sites themselves, on the hardware people actually hold, is what makes the result mean anything.
