SAP implementation projects: the five hurdles of opening a new store

Hi, this is Rabbit! 🐰

Imagine opening a new restaurant. Finding a good location, designing the kitchen, bringing in equipment, and finally opening the doors — you start with high expectations, but once you’re actually doing it, unexpected problems keep surfacing. SAP implementation projects are exactly like this.

Last time, we looked at how PI (the designer) differs from implementation (the builder). Today’s post is about what those builders actually go through during an implementation project. Interestingly, what makes these projects hard isn’t cutting-edge technology or complex systems. It’s smaller, more human problems than you’d expect. Systems run on fixed logic, but our work always slips slightly outside that logic.

Figure 1. The five stages of an SAP implementation — the process of building a new store

1. Choosing the location — project kickoff

A new restaurant starts with finding a good location and laying the groundwork. This is the kickoff stage of an SAP implementation — the period when the project’s big picture gets drawn, goals and scope get defined, and budget and schedule get set.

The most common trap here is thinking “the place next door does well, so set us up exactly the same way.” Referencing a successful business is fine, but every restaurant has different layout and different customers. Companies are the same. How people work varies as much as faces do, so assuming the same industry means the same business processes is risky. Things that look similar on the surface often turn out to be completely different underneath.

2. Drawing the store blueprint — business blueprint

Now it’s time to draw a blueprint for your own store — deciding where the kitchen goes, how the floor layout works, how customers move through the space. In SAP terms, this is the process of carefully listening to how the business actually operates and translating that into the language of the system.

The biggest reef to run aground on here is the phrase “our work is simple.” The more something was assumed to be simple, the more exceptions turn up once you dig in — things that were handled in Excel or by hand. Saying “just make the dining area open and spacious” without deciding table spacing, kitchen flow, or entrance placement is exactly like being unable to bring in furniture later because none of that was planned.

If these exceptions get missed at the design stage, you’re guaranteed to hear this after go-live: “We used to do this by hand — why can’t the system handle it?” Leaving something out of the design because it happens rarely comes back as a much bigger problem later. The ‘exceptions’ are exactly what deserve the most careful documentation.

3. The real construction — system build and development

With the blueprint done, it’s time to build the kitchen and bring in equipment. Where standard functionality falls short, custom development fills the gap — similar to building a special cooking station for something the standard kitchen setup can’t handle.

What matters most at this stage is communication between people. Something that was clearly discussed in a meeting turns out the other person never heard, or nothing was recorded in a document. Small misunderstandings between planners, developers, and business users pile up one by one and eventually turn into major system defects.

So before building anything, the first habit to establish is aligning everyone’s terminology clearly and putting it in writing. “We agreed on it verbally” is one of the most dangerous phrases there is. It’s common for planners and business users to picture entirely different things even when using the same word.

4. Pre-opening inspection — final preparation and testing

The store is nearly finished. Before taking customers, you need to check that the gas line works, nothing’s blocking foot traffic, and the POS system runs properly. This is the UAT (integration testing) stage, where users try out the system themselves to find issues.

This is the first time users face the completed system. Just as walking through a space in person reveals discomforts you couldn’t see on a floor plan, new requirements start pouring in. “It’d be great if this screen also showed inventory quantity” — these “requirements nobody knew about” are regulars at the testing stage.

Imagining something in your head and actually handling it with your hands are completely different experiences. That’s why testing isn’t just error-checking — it’s the last chance to catch the friction points of a store that’s about to open for real. Functionality everyone assumed would obviously be there but wasn’t turns up more often than you’d expect.

5. Opening day, but the real work starts now — go-live and stabilization

The store finally opens, and every employee starts using the new system. Thinking the project is over at this point is a mistake. The real start is now.

Right after go-live, problems surface all at once. “I can’t log in,” “the production order screen says I don’t have authorization,” “no data is showing up at all” — inquiries pour in. During this period, the project team effectively becomes an emergency response team. This period is usually called the stabilization period, and how fast the team responds during this window determines the project’s ultimate success or failure.

Rabbit has been through this stabilization period firsthand. Right after go-live, questions that weren’t in any manual kept coming in nonstop, and resolving them one by one is when the system finally started fitting the company. It’s not glamorous, but it’s the most human stretch of an implementation project — much like how a new restaurant only builds regulars after surviving the chaos of its first month.

Rabbit’s Takeaway

An SAP implementation project isn’t an IT project that swaps an old system for a new one. It’s closer to changing how a company works, its organizational culture, even how its people think. It doesn’t end with building the store — it’s a process of building, together, a new way of operating that fits that store.

That’s why people matter more than technology, and communication matters more than the system itself. Knowing these five stages ahead of time means you’ll be less caught off guard when you hit these traps, and able to respond a beat faster. 😎

---

Read more

• SAP PI vs. implementation: the person who designs the store and the person who builds it
• SAP’s 10 modules: seeing the whole restaurant at a glance