SAP across a national retailer: the integrated estate

Interviewer: Thanks for making the time. I want to understand how SAP actually runs across the business, the whole picture, the way you'd explain it to someone senior joining the enterprise applications team. It's a big surface, so wherever you want to start.

Architect: Happy to. And I'll set expectations, because the first thing people get wrong is they say "SAP" like it's one thing, one system you log into. It isn't. For a retailer our size, SAP is really the connective tissue across the whole company. It's how we buy merchandise, how we move it, how we sell it, how we pay for it, and how we close the books on all of it. So let me walk the lifecycle of a product through the business, and you'll see SAP show up at every stage. But before any of that, I have to start underneath it, with master data.

Interviewer: Master data being what, exactly?

Architect: The foundational records that everything else references. The article, which is the retail word for a product. The vendor we buy it from. The site, which is a store or a distribution center. And pricing. We govern all of that in a master data platform, with a real process around creating and changing it. And I cannot overstate this: it is the foundation the entire enterprise stands on. If someone sets up an article with the wrong unit of measure, or a vendor with the wrong payment terms, that error doesn't stay put. It flows downstream into purchasing, into receiving, into finance, and you find it three weeks later as a problem in the close. So a surprising amount of our discipline goes into governing data that, on the surface, looks boring.

Interviewer: Okay, so the data's in place. Walk me into the buying.

Architect: Right. It starts with the merchants planning the assortment. What are we going to range, in which stores, for which season. That plan drives the buy. Then forecasting and replenishment. The system forecasts demand and generates replenishment proposals automatically, store by store, so we're not hand-keying what every location needs. A buyer can override it, and they do when they know something the model doesn't, like a regional promotion, but most of the volume flows through automatically. Those proposals turn into purchase orders.

Interviewer: And the purchase orders go to the vendors.

Architect: They go out, mostly over EDI or through our sourcing platform. That's the start of what we call procure-to-pay, which is one of the big end-to-end chains. The vendor confirms the order, sends an advance ship notice so we know what's coming and when, and the goods go into transit. Then they arrive at a distribution center, and our warehouse system takes over. We receive against the purchase order, put the stock away, and the inventory and its value update in real time. And there's a branch right there, because receiving is never perfectly clean. If what shows up doesn't match the order, short shipment, damage, wrong item, that goes to blocked stock and kicks off a vendor claim. It doesn't just silently flow through.

Interviewer: Then it has to get to the stores.

Architect: Then transportation management takes it from the DC to the stores. We allocate the stock, plan the loads, manage the freight and the carriers. The store receives it, and now store-level inventory updates, which feeds the next replenishment cycle. And this is worth pausing on. Inventory accuracy is the heartbeat of a retailer. Every one of these movements, the receipt, the transfer, the shipment, is also a financial event in the background. So the supply chain and the finance system are talking constantly, whether anyone's looking or not.

Interviewer: So now we're at the store. The product gets sold.

Architect: The product gets sold, and this is where a lot of people are surprised that SAP is even involved, because the customer is just tapping a card at a register. The point of sale is its own system. But every transaction flows back into SAP through what we call POS data management and sales audit. Sales audit reconciles the day. It balances the tenders, the cash, the cards, the gift cards, makes sure the money that should have come in matches what the registers say, and then it posts the sales and the individual inventory movements into the core. And it's not just stores anymore. An online order, or a buy-online-pickup-in-store order, takes a different path through the same machinery, because the inventory might be in a store, a DC, or in transit. Omnichannel made this much more complicated than it was ten years ago.

Interviewer: And once the sale posts, the money side kicks in.

Architect: Right. The sale drives inventory valuation and cost of goods, so we know our margin, and by the way our shrink, the stuff that walks out the door or gets miscounted. Meanwhile, on the buying side, procure-to-pay finishes. The vendor sends an invoice, and we do a three-way match. The purchase order, the goods receipt, and the invoice all have to agree before we pay. If they don't, the invoice is blocked and someone has to resolve it. And in retail there's an extra wrinkle there, vendor allowances and trade funds, the money vendors give us for promotions and placement. That's real money and it has to be tracked and settled correctly, which is its own little discipline.

Interviewer: You mentioned the books a couple of times. Where does the accounting actually live?

Architect: All of it lands in financial accounting and controlling, which is the heart of the ERP. Every operational event we've talked about becomes a journal entry somewhere. The general ledger, cost centers, profit centers, intercompany postings between our legal entities. On the cash side we're reconciling card settlements, any business-to-business receivables, and the bank statements. And then periodically we close. Month-end, quarter-end. Accruals, reconciliations, consolidation across entities. And because we're a public company, every bit of that sits inside SOX controls. There are documented controls, segregation of duties, approvals, and if a control throws an exception, we remediate it before we close, not after.

Interviewer: That sounds like the high-stakes part.

Architect: It's the part where the deadlines are real and external. The market expects our numbers on a schedule. So the close is this firmwide effort that pulls in finance, the controllers, and frankly my team, because if an interface didn't run or a batch failed, it shows up as a gap in the close. And the output of all of it feeds reporting and analytics, our data warehouse and analytics tools, which serve everything from a store manager's daily sales dashboard all the way up to the statutory filings and what we report to the SEC. Same data, very different audiences.

Interviewer: We haven't talked about people yet.

Architect: Good catch, because it's a whole chain of its own, hire-to-retire. Our HR and payroll run on SAP's people systems. Hiring, the org structure, time and labor, which matters enormously for a retailer with tens of thousands of hourly store associates, and then payroll, which posts straight back into finance as one of our largest expenses. So even the workforce ties back into the same financial core.

Interviewer: So that's the functional picture. What holds it all together?

Architect: Two things I haven't given enough credit to yet, and they're where the real difficulty lives. The first is the integration layer. Almost nothing I described is purely inside SAP. The point of sale is a separate system. E-commerce is a separate platform. We use third-party logistics providers. We connect to banks. We exchange documents with hundreds of vendors over EDI. All of that runs through middleware that moves data back and forth, thousands of interfaces, many of them on schedules through the night. And when one of those interfaces fails, and they do fail, a file doesn't arrive, a format changes, a vendor sends something malformed, that's not a quiet problem. Sales might not post. Inventory might be wrong in the morning. So we monitor those interfaces closely and we have to investigate and replay them. Honestly, a lot of our day-to-day firefighting is at the seams between systems, not inside any one of them.

Interviewer: And the second thing?

Architect: Governance and lifecycle. Every change to this environment moves through controlled transports and change management, because you can't just edit the system the whole company runs on. There's testing, there's approval, there's SOX change control. And the big one hanging over all of it right now is our migration to S/4HANA, SAP's newer platform. Moving an environment this interconnected, with this many integrations and this much history, is a multiyear program, not a weekend upgrade. The center of excellence I sit in is what holds the standards, the documentation, and the institutional knowledge of how all these pieces fit.

Interviewer: So if you had to name the thing people get wrong about running SAP at this scale, what is it?

Architect: They think the hard part is the software. That if you just configure the modules correctly, you're done. But the modules mostly work. The hard part is two other things. It's the master data, getting the foundational records clean and keeping them clean, because errors there ripple everywhere. And it's the integrations, the brittle seams between SAP and the dozens of systems around it, where most of the real failures actually happen. And there's a third thing I'd add, quietly. For all the sophistication, there's an enormous amount of process knowledge that lives in people's heads and in spreadsheets around the edges. How the close really works. Which interface to check when sales look low. The workaround that bridges two systems that were never meant to talk. That knowledge is the most valuable and the most fragile asset we have, because it isn't really written down anywhere a system can see it. So when people ask what keeps me up at night, it's not SAP going down. It's the master data, the seams, and everything we know that we've never actually captured.

Interviewer: That's a fantastic place to end it. Really, thank you, this was great.

Architect: My pleasure. It's a sprawling thing to describe, so it's genuinely useful to lay the whole map out in one go.