Your function has to live with what is delivered. Who's making sure it works for you?

BAU protection requires deliberate programme design, not reassurance. The key elements are: defining the boundary between programme and BAU; resourcing the programme without hollowing out teams that need to keep operating; and governing change impact on business functions so competing demands are visible and managed from the outset.

Functional teams are typically expected to provide subject matter expertise in process design workshops, test the system against real business scenarios, support data cleansing, and prepare for adoption through training and practice. The time commitment is almost always greater than initially planned — and when underestimated, teams find themselves failing on both programme and BAU.

SIs design to their template — it is faster and more economical for them. Without active challenge from people who understand your business, process design defaults to standard and workarounds begin at go-live. The answer is ensuring design workshops are led by people who bridge business need and system capability and will challenge decisions that do not serve the business.

Honestly, it typically does. The immediate post-go-live period is the most demanding: teams are in an unfamiliar system, exception volumes are higher, and institutional knowledge of workarounds has not yet built up. The length and severity of this period depends directly on how well change management and business readiness were executed before go-live.

Process standardisation means designing a single, consistent way of performing a business activity across the organisation — rather than allowing each team, region, or legacy system to operate differently. In an SAP context, it reduces customisation costs, makes upgrades simpler, and enables meaningful cross-business reporting.

The strongest candidates are processes that are heavily manual, error-prone, inconsistently executed across teams, or generating significant workarounds in the current system. Running structured discovery workshops with frontline users — not just managers — typically surfaces the real pain points that the existing system has normalised.

This is one of the most common and costly mistakes in SAP implementations. The risk increases when design decisions are left to the SI or process workshops are rushed. The discipline is to challenge every legacy process to justify its existence in the future state before it is designed in.

Data cleansing is identifying and correcting inaccurate, incomplete, or duplicate records before they are loaded into the new system. Poor quality data in a new SAP environment undermines user confidence, reporting accuracy, and process automation from day one — and the problems compound over time. Functional teams typically own this responsibility in their domain.

Not all data needs to move. A data migration strategy should categorise data by quality, relevance, and business need. Historical data that will not be used operationally in the new system can be archived rather than migrated — significantly reducing migration complexity and risk. The decisions require business owners, not just the technical team.

The first step is a structured consultation — typically sixty to ninety minutes — in which we understand your programme's current position, objectives, and the specific challenge you are trying to solve. We will be direct about whether and how Limelight can help. There is no commitment required and no proposal pushed before that conversation.