At a glance
- Client: a nation-wide meat producer, co-owned by JPMorgan Chase Bank - eight full-cycle poultry farms, 14 pig farms, six meat-processing plants, six feed mills, $50 million net profit in 2016
- Situation: 5,000 employees were storing and processing data across separate local WMS and TMS systems; everything was being consolidated into a single SAP ERP
- The problem: the unified database was enormous, and document processing speed was low - a performance tuning problem standing between the company and its migration
- Scope: load scripts emulating the lifecycle of purchases, sales, logistics and related financial processes across eight production plants
- Result: document processing speed increased 8×, integration with external systems tested and optimised under load, with performance metrics captured per business process
- Business outcome: the migration went ahead on evidence, and the company has since grown to 30,000 employees
- Tool: LoadRunner, with load supplied from workstations at the production plants where real users work
Why the migration needed load testing first
Consolidating several legacy systems into one ERP is not a like-for-like move: the merged database is far larger than any of the systems it replaces, and processing that was acceptable on a local WMS can become the bottleneck of the whole business once everything runs through one platform. That is exactly what the client hit - document flow slowed down before the migration was even complete.
The client set a high bar for who would handle it, wanting an experienced team rather than a first attempt, which is how the work came to PFLB.
What was tested
A dedicated SAP ERP test environment was deployed for load testing. Then load scripts and scenarios were built to emulate the real lifecycle of the business - purchases, sales, logistics and the financial processes attached to them - across all eight production plants.
Two details made the testing representative rather than theoretical:
- Load was supplied from workstations located at the production plants, where the actual users work - not from a lab that shares nothing with production conditions.
- Scripts emulated the work of specific tablets used on site, and heavy annual report generation was launched during runs, because that is when the system is under real strain.
The system's behaviour under load was analysed, bottlenecks identified, and a working configuration meeting the client's performance requirements was established.
Results
- Document processing speed increased 8×.
- Load capacity improved in line with the client's business plan, with integration to external systems tested and optimised under load.
- Data migration to SAP succeeded, and the client could make an informed decision about deploying to production - based on a configuration proven to work, not on a hope.
- The improved capacity supported further growth: the company now employs 30,000 people.
Questions this engagement answers
Should you load test before an ERP migration or after?
Before. Here the merged database made document processing slow enough to threaten the project, and testing found a working configuration ahead of the production decision rather than after the cutover.
What does SAP ERP load testing actually emulate?
The business lifecycle - purchases, sales, logistics, finance - across every site, including the specific devices used on the floor and the heavy periodic reports that coincide with peak load.
Where should the load come from?
From where the users are. Load generated at the production plants reflects the network path and conditions real staff work under; a central lab does not.
Is an 8× improvement a tuning result or a rebuild?
Tuning. The engagement identified bottlenecks and a configuration that met the requirement - no rewrite of the ERP was involved.
Migrating onto one platform?
The database you end up with is bigger than any of the ones you are leaving. Whether that matters is a measurable question, and it is cheaper to answer before the cutover than after.
