Sooner or later, every conversation about moving to S/4HANA arrives at the same question: which of our processes have we actually changed? The usual answer is a list of a few thousand programs, sorted by package and namespace. That doesn't answer the question. To answer it, the custom code would have to be organised by business process, and hardly any company keeps that mapping.
Every custom development had a reason
Behind every custom program there was once a requirement the standard couldn't meet. Usually it was one of three reasons, and only the first one makes a company genuinely different:
- Competitive advantage. The process is meant to run differently from the rest of the industry.
- Obligation. A law, a collective agreement, a regulator or a key customer demands it.
- A gap at the time. The standard couldn't do it when the program was written. Whether it can today, nobody has checked.
The third group is the expensive one, because after a few years nobody recognises it as such. The developer has retired, the design document sits on a drive that no longer exists, and the program runs every night. Clean Core doesn't help with this question, by the way: SAP's levels A to D rate how an extension is attached to the standard, not whether you still need it.
One customer system, by module
A first overview comes from the split across SAP modules. The chart comes from the analysis of one customer system, anonymised and with the figures slightly altered.
The system has around 3,500 custom programs, almost a third of them in materials management. Together with sales and quality management that makes a good two thirds. Whether the 590 programs in quality management are what sets this company apart, or whether they rebuild an inspection process the standard has long covered, the number alone won't tell you.
Then there are 240 programs in Basis: tools, interfaces, utilities. For those, the first job is to find out which processes they support and who owns them.
Even this module view doesn't come out of the system by itself. Packages grow over years and projects, and a sales package often holds programs that maintain material masters or post accounting documents. The package says little about what a program is for. Sysparency therefore derives the module from the code: the tables a program reads and writes, the standard interfaces it calls, and the functional description Sysparency generates for every program.
That's still not a process view. But ten areas with an owner each are easier to talk about than 3,500 individual objects.
From module to process
A module isn't a process. Order-to-cash runs through sales, logistics and finance, and an SD program can belong to order entry just as well as to complaints handling. Nothing in the SAP system records which process a program belongs to. The ABAP Test Cockpit checks objects technically, and process mining shows the flow but not the code behind it.
The mapping can be derived from the code, though, and reasonably well. The same clues that reveal the module carry further: tables, standard interfaces and functional description. Add the transaction a program is started from and how often it runs according to the usage data of the production system, and together that shows fairly precisely which business activity a program belongs to. On that basis Sysparency assigns every custom object to a module and an end-to-end process, and describes per process what was extended beyond the standard.
The mapping is a proposal you can check against the code. Whether a deviation is a competitive advantage can't be read from the code. That's for the process owner to judge, and they now have a complete list to judge it from.
An example: hire-to-retire
The following example is made up, and so are the numbers. Anyone working in HR IT will recognise the pattern anyway.
A company has run SAP HCM for twenty years. In HR, around 450 custom programs with more than 700 custom Dynpros have accumulated: custom infotypes, entry screens for time management, reports around payroll. Mainstream maintenance for SAP ERP ends at the end of 2027, with optional extended maintenance to the end of 2030. The choice is between SAP SuccessFactors and SAP HCM for S/4HANA. SuccessFactors has no Dynpros, so a move there means deciding, for each of the 700 screens, what becomes of it.
The matrix shows what gets lost in an object list. Time management and payroll are almost fully in use, and the reason is known: collective agreement and works agreements. Those requirements have to be met in the target system too. Whether the existing implementation is carried over is a separate question.
In travel management, only one program in eight was started at all in thirteen months. That doesn't have to mean anything, a year-end program runs once a year and not every use is measured. But it's certainly worth asking.
Most of the work is in personnel administration. There are 310 Dynpros, a good half of the programs are in use, and for most of them nobody can say any more whether a requirement is behind them or a habit from 2006. Custom infotypes were used over the years to cover all sorts of special cases: work equipment, allowances, side agreements. For some of them the standard now offers a possible replacement, and whether it fits has to be checked per requirement and target release. With the process view, 700 individual cases become a handful of decisions an HR director can actually take.
What an agent needs for this
450 programs and 700 Dynpros, and that's a single process. Nobody checks that by hand before a project starts. An agent can handle the volume, it reads a program in seconds. Whether a rebuild is worth it, it can't tell from the source code alone, because the source doesn't say which process a program belongs to, whether anyone uses it or what depends on it. Without that information an agent works through the list from top to bottom and diligently migrates programs that should have been retired.
With that information it can be more selective. The Sysparency MCP server gives it read access to the knowledge graph: process assignment, usage, dependencies, Clean Core status and functional description, each with a reference to the source line. What the standard offers today comes from SAP's documentation MCP servers. That makes a question like this answerable:
Which custom developments in hire-to-retire were used in the last 13 months, access unreleased SAP objects and implement a function for which the target release has a standard candidate? Cite the source for each hit.
What comes out is a comparison list with evidence on both sides. People still make the decisions, but the process owner can now concentrate on the cases where there is really something to settle, instead of working through 700 screens.
Three questions for the next budget round
- Which processes have we changed, and with how much code?
- For which deviations do we know the reason, and when did someone last confirm it?
- Where has anyone checked whether the standard covers it by now?
With documented answers to these questions you can justify, before the migration, which custom developments are kept, replaced or retired.
We'd be glad to show you what the process map of your system looks like, based on an analysis of your custom code. Request a demo