SAP S-4HANA - Simply Explained

Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. What SAP s four Hana actually is? SAP says its customers generate more than eighty seven percent of global commerce, and most of that runs through software you never see. The newest release of that software is called SAP S four Hana, and the name makes it sound far more complicated than it is. Underneath the acronym is one simple shift. The data moved from disk into memory, which is why reports that used to run overnight. Now update as you watch. That change also forced every company running the older SAP system to make a decision, because mainstream support for it ends in twenty twenty seven. So we'll walk through what's four Hana is how it works, how companies run and migrated, where Microsoft fits in, and the parts that don't live up to the pitch. Let's start with the plain definition S four. Hana is an ERP system, and ERP just means the software a company uses to run its core operations taking orders, buying materials, tracking inventory, paying people, and closing the books. If your business makes or sells anything at scale, Something like this sits underneath all of it, quietly keeping the numbers straight. People in the industry call it the system of record, which is a fancy way of saying it holds the official version of the truth. When someone asks what an ERP actually does, that's the honest answer. It remembers everything the business did in a way that can be trusted. Later, the name breaks down more easily than it looks. The S4 part stands for SAP Business Suite four, and the Hana part is the database it runs on. SAP released it in twenty fifteen as the successor to SAP ECC, which itself replaced the R3 system back in nineteen ninety two. That lineage matters because most companies listening to this are running one of those older systems right now. One detail here surprises people. S four Hana runs only on SAP. Hana SAP stopped supporting its core product on other databases, so this wasn't a cosmetic upgrade or a fresh coat of paint on an old engine. It was a rebuild of the foundation, and almost everything else in this episode follows from that single decision. It's also why a migration is never just a software update. Because you're moving the floor. A company stands on why the database underneath changed everything. to see why the database matters. Picture how the old system stored data. ECC kept records on disk organized in rows, so a single customer record sat right next to that customer's order, their address, and their invoice. Reading one field meant dragging a whole row along with it, which gets slow when you're asking a question that spans millions of records. Hana flips both of those choices. It keeps data in memory instead of on disk, and it organizes that data in columns instead of rows. A column holds one kind of value, like every order date in the system. So the database can read just the slice a query needs and skip the rest. That's the core trick. Column storage also compresses well because similar values sit next to each other, so the same amount of memory holds more than you'd expect that efficiency matters, since memory costs more than disk, and sizing the hardware correctly is work of its own. The payoff is bigger than raw speed. In the old world, analytics and everyday transactions lived in separate systems, and reporting usually meant copying data overnight into a warehouse with Hana. Both kinds of work run against one shared copy of the data, so the numbers don't have to travel anywhere to be useful. Let's take a practical example. A finance team closing the books at month end used to wait on batch jobs that ran late into the night, and if something looked wrong, the person who could fix it had already gone home with S four Hana. The figures are already there as transactions land, so the close can happen during the day, while the people who understand the numbers are still at their desks. Anyone who has waited on a batch window knows how much that single change is worth. A second benefit is easy to miss. One data model means fewer places for the same figure to disagree. The sales figure in one report matches the figure in another, because both read from one table instead of two systems that were stitched together years ago. One honest caveat before we move on and it comes back later, SAP's own marketing, says Hana, is thousands of times faster than older databases, and you should treat that as a vendor claim rather than a measured result. Real speed depends on data volume, how the system is configured, and whether the queries themselves are written well. The new interface and the simplified data model. The database change also led SAP rebuild the screens. People actually look at S four. Hana was the first SAP product to use Fiori, which replaces the dense green screens of the old SAP GUI with tile based apps built around the task in front of you. If you've never touched the old interface, here's why anyone cares. Old SAP was famous for transaction codes, short strings of letters and numbers that you had to memorize to get anything done. Fiori organizes the same work into apps with plain names, so a warehouse clerk opens a goods receipt app instead of typing a code they learned in training years ago. Fiori isn't only prettier. Each app is built for a role, so a manager approving a purchase and a clerk entering an invoice get different screens for different jobs. Instead of a crowded transaction that everyone has to learn. It's a small change with a big effect on daily work. The data model got simpler too, and finance is the clearest example. Older SAP finance spread its numbers across many separate tables, which meant reconciliation work just to arrive at a total S four. Hana puts the core finance data into one line item table, known as the Universal Journal. So one entry carries both the accounting view and the cost view at once. Before that change, a reliable profit figure often meant matching several tables together at month end. Now both views right on one line item, and that cuts real work out of the finance calendar that matters for the person doing the job. An accounts payable clerk who used to pull figures from several reports can now open one line item and see the whole story, which means less stitching things together and fewer arguments about which report is right. The business areas it covers. S four Hana is modular, which just means it's a collection of connected areas rather than one giant blob. The main ones cover finance, procurement, sales, manufacturing, supply chain, asset management, project work, and people with human resources often handled by SAP Successfactors sitting alongside the core rather than list them. Let's follow one order through the system because that's where the design shows up. In practice, a customer places an order, so sales records it and checks availability. That check reaches into inventory, which lives in the supply chain area. If stock is short, the system can trigger production or a purchase. And once the goods ship, an invoice goes out and the books update, notice how many areas that one flow touched. Sales, inventory, manufacturing or procurement and finance all acted on the same order. Reading one shared database without anyone copying data between systems or emailing a spreadsheet to a colleague. One system, one set of records. That's what makes the flows work. A second flow shows the pattern on the buying side, someone raises a purchase requisition, which becomes a purchase order, then a goods receipt, and finally a payment to the supplier. Each of those steps posts to finance as it happens, so the cost is visible while the process is still running. A third pair of flows ties the system to the top of the company. Order to cash flows, a sale all the way to money in the bank and record to report pulls transactions from every area into finance. Those two end to end flows are how most teams describe what's four Hana does for them. Beneath that sits the shared master data, the customer, the material, and the supplier. Each exist once and every area reads from that same definition, so one order can move across departments without anyone retyping it. That's the real point. S four Hana isn't one product so much as a shared set of processes built on one shared source of data, and the value comes from how tightly those pieces fit together, how companies actually run it. Now for the decision. Most teams spend months arguing about which is where the system physically lives. There are three main choices, and each one trades control against effort in a different way. Each choice has real trade offs. On premise means the company owns the hardware and runs the system in its own data center. You decide when to upgrade, you can customize almost anything, and you carry the cost and the responsibility that come with all of that freedom. Private cloud is the middle path sold as S four Hana Cloud Private Edition and often delivered under a program called rise with SAP. It's managed for you and runs behind your own firewall, but you keep most of the customization options from the on premise world. The standardized option is public cloud called S four Hana Cloud Public Edition and sold through grow with SAP. It runs on shared infrastructure. SAP pushes the upgrades on its own schedule and it costs less to operate. What you give up is the freedom to bend the software to match old habits. A fourth option is hybrid, where part of the system runs in the cloud and the rest stays where it is. Companies use it to move gradually or to keep a sensitive piece of the business close to home while everything else modernises the trade off is worth saying plainly. Public cloud gives you fewer upgrade headaches and less control, while private cloud and on premise give you more control and more work to carry. There's no universal right answer, and the choice usually comes down to how much the company is willing to change the way it works. That decision sits with the business as much as with it, which is why it takes so long to settle how you get there. And the twenty twenty seven clock, whichever home you pick, you still have to get there from wherever you are today. And that's the migration. Three common paths exist, and the name sounds stranger than the ideas behind them. Timing matters here. Greenfield means a fresh start. You build a new system from scratch and redesign your processes while you're at it. It's the cleanest result, and it's usually the most expensive because you're changing how people do their jobs, not simply moving data between machines. Brownfield means converting the system you already have. It's faster and it keeps your history, but it carries your old habits and old custom code into the new platform, which can quietly limit what you gain. A conversion isn't a simple copy either. It runs the existing system through a technical conversion process checks the custom code for anything the new release no longer supports and fixes whatever breaks. Bluefield, sometimes called hybrid, sits in between. You move some processes onto a fresh model while converting the rest of the existing system, which spreads the change over time instead of swallowing it in one bite. There's no default choice here, and the right path depends on how much process change the business can actually absorb. For a lot of companies, this is now urgent. Mainstream maintenance for the older IC system ends in December twenty twenty seven, and optional extended maintenance runs to the end of twenty thirty for an extra fee. There was also a bridge called compatibility Packs that let classic IC features keep running inside. S four Hana on premise, and that bridge mostly closed on May thirty one, twenty twenty six. So the clock is real, even if the exact cost of running late is still debated. What matters for now is that the decision isn't optional forever, and the longer a company waits, the fewer comfortable options it has left. Keeping the core clean when a migration gets rushed, teams tend to reach for the one thing that causes the most trouble later, which is editing SAP's standard code directly. The fix has a name clean core, and the idea is simple don't rewrite the engine, build add ons that survive and upgrade. In practice, that means extending the system through released interfaces instead of modifying it. SAP offers a set of tools for this, including the SAP Business technology platform for building outside the core, a development model called Abap cloud, and side by side apps that call the core through supported APIs. The phrase to remember is released API. An API is just a supported doorway into the system, and SAP marks which doorways are safe to use? Build against those, and an upgrade tends to leave you alone. Edit the standard code instead and every upgrade turns into a repair job. Take a concrete example. Say a company wants a custom approval screen. Instead of editing a standard SAP program, a developer builds a small, separate app that reads and writes data through a supported interface. When SAP ships an upgrade, that app keeps working and nobody has to hunt through the code to see what broke. The payoff shows up years later. Every upgrade is either a quiet afternoon or a six month project, and the difference comes almost entirely from how deeply the core was modified. That's the whole point of clean core. Where's four Hana meets Microsoft, the two worlds many of us work in meet right here. The connections are more practical than they sound. For data. Microsoft Fabric can pull shape information in through built in connectors for SAP, Hana, SAP tables and SAP BW, and it can mirror SAP data into its one leg storage so reports stay current without a nightly copy job, the mirroring path is worth knowing if you've heard the term SAP data can travel through SAP Data Sphere into Microsoft's cloud storage, and fabric keeps it in sync from there. For simpler cases, fabric's own connectors pull SAP tables or SAP BW data directly. A simple version of that flow looks like this. A sales order lands in S four. Hana fabric picks up the change, and a power BI report refreshes with the new figure. The people reading that report never log into SAP at all, which is exactly the point. It's a real shortcut for business users. Identity is the second connection, and it's the one that saves the most headaches. Microsoft Entra ID handles sign on and multi-factor authentication for SAP apps like Fiori, so users sign in once instead of juggling separate passwords. One caveat matters here enter ID can handle authentication, but it doesn't replace SAP's own authorization rules, which still decide what a person is allowed to see and do inside the system. Automation and security round out the picture power platform and Azure Logic apps connect to SAP through connectors, so a business event can trigger a workflow in Microsoft's Tools and Microsoft Sentinel for SAP watches. SAP audit logs for signs of trouble. Power platform also ships pre-built app templates so a maker can assemble an approval flow without writing code against the SAP interface directly. There's also movement on the AI side, with SAP's assistant Jul announced as integrating with Microsoft three hundred sixty five copilot, and SAP screens able to live inside teams treat those as evolving because availability keeps changing and announcements aren't the same as features you can switch on today. On the cost side, it's worth checking the fine print because some of the replication work is free, while the queries and reports you build on top are charged at normal cloud rates, the honest limits and common mistakes. Now we get to the parts that don't live up to the pitch. Start with speed. The dramatic performance numbers come from SAP's own marketing, and a poorly designed query will still crawl no matter what database sits underneath it. The next mistake is underestimating the migration itself. Teams budget for software and licenses, then discover that cleaning up decades of messy data and redesigning processes eats the real money and the real time. The software is rarely the hard part. Lift and shift is a close cousin of that mistake. Moving IC across as is can carry the same tangled custom code and slow reports straight into a new platform, quietly defeating much of the point of moving in the first place. Public cloud catches people out as well. Teams used to changing anything they like on premise, find that the standardized version won't let them, and that surprise tends to arrive late once the project is already committed. Two quieter traps are worth naming. One is expecting the benefits to show up immediately when the reporting and process gains usually land months after go live once people actually trust the new system. The other is treating the whole thing as an IT project, when the decisions that matter most belong to the business rather than the technical team. The hardest part is rarely technical training people, changing how they work and getting the business to agree on new processes is what decides whether the project lands, and that part usually gets the least budget. None of that is a reason to avoid the move. What to take away. So here's the short version S four Hana is the system a company runs its core business on, rebuilt in twenty fifteen on a database that holds data in memory. And that's what allows live reporting. It simplifies the data model, covers the main business areas, and forces a real decision about cloud migration path and how much custom code you allow near the core Microsoft tools plug in at the data identity and automation layers, and the twenty twenty seven deadline is the reason none of this can wait forever. Here's the question I'd like you to sit with. If your team is still on ECC, do you actually know which migration path it's heading toward, or is that still an open argument? If this made the topic feel less intimidating, subscribe to M365 FM to master the tools and the mindset shaping the future of work.