The Tactical Layer - In Projects and Change Requests

If the strategic layer decides what a company wants to achieve, the tactical layer decides what this means in practice.

This is the level where, in terms of hours spent, most of the project work takes place today. Software features are explained to the business, requirements are mapped to standard software features, gaps are defined, implementation plans are made. Project heads, team leads, consultants, business representatives and architects try to turn broad project goals into software that actually works.

Methodologies have changed over time, each time promising some percentage of effort saved. But at the core of this level is still a negotiation process.

Which requirements are really beneficial, meaning they have a positive return when implementation cost, maintenance cost, process complexity, training effort and upgrade risk are taken into account? Which ones do not? When going down to the actual meaning of the requirement, not the way it was implemented in the legacy system, can it be addressed with a more or less creative use of standard software features, or can it not?

The eternal question: SAP Standard or not?

This is where the familiar question appears again and again:

Can we solve this with standard software, or do we need a custom development?

The conventional answer is often too simple. “SAP standard is cheaper.” “Custom development is expensive.” “Stay close to standard.”

These statements are often right. But not always.

Against conventional wisdom, finding a creative solution within SAP standard might take longer and cost more during implementation than a custom development. In many cases, it will still be cheaper in maintenance. In other cases, an overly creative use of standard functionality might be cheap in implementation, but a nightmare in maintenance. And a clean custom development might sometimes be cheaper, clearer and more stable than forcing the business process into a standard mechanism that was never designed for it.

Consulting requires judgment

This is why good consulting on the tactical layer is not about ideology. It is about judgment.

In the optimal case, experienced consultants take the guidance from the strategic layer and translate it into practical solution decisions. They understand the business requirement, the software standard, the maintenance implications, the project budget, and the people who will have to live with the result after go-live.

Their job is to get to the core of the requirement: to understand whether the deeper reasons and objectives behind it can be explained, whether they still hold today, whether they may become irrelevant because of SAP standard functionality, and, after all this, whether there is a solution in or close to the standard without abusing it.

Many things can go wrong on this level.

Excess pressure on project budgets or fixed-price mechanisms might lead to solutions that are easier and quicker to implement, but will either fail already during testing, when exposed to reality at go-live, or become a headache in maintenance, even when the consultants are qualified and experienced.

A lack of experience, whether with projects, maintenance, or both, may have similar effects. On the other hand, project teams that will later also be responsible for maintenance might develop an exaggerated focus on ease of maintenance, leading to never-ending discussions and projects.

What changes with AI

So what benefits and disadvantages will AI bring us on this level?

With AI systems, it is possible to analyze large information sets on legacy processes and requirements in a minimal amount of time. This can include direct code analysis, but also past requirements, specifications, tickets, test cases, process descriptions and documentation. With enough knowledge of the standard software functionalities and licensing costs, AI systems will soon be able to create possible implementation plans.

Analyzing requirements and specifications will use AI’s capability for disambiguation. AI will be able to identify gaps in the specification and point them out to consultants or business representatives in order to clarify them.

Coding might often be less ambiguous, but only if the system architectures and interfaces leading to the current design are also documented and presented as context. Without this context, AI may explain or translate code correctly, and still miss why the solution exists, whether the reason still holds, and whether the requirement should be carried into the future.

There are several challenges.

Legacy documentation and coding will represent the organization’s goals and preferences at the time of implementation. One of the main challenges on this level is to find out if they still represent the goals and preferences of the organization today.

Often, neither documentation nor IT or business departments will be able to explain coherently why the solution was implemented like this, and if the original goals still stand. To map legacy functions to standard software, and to understand which portions can be changed or adapted, understanding the underlying goals is imperative.

Many requirements simply disappear as soon as the new standard software is properly understood, or as it becomes clear that the challenges of previous times no longer apply today.

For an AI, it may be relatively easy to migrate a solution from a legacy language to a modern programming language. But this is not what we try to achieve when we implement standard software. We are not trying to preserve the past perfectly. We are trying to understand what the business actually needs now, and how much of that should be solved with standard software, configuration, process change or custom development.

The biggest challenge arises from the progress made on the delivery layer. Implementation and testing efforts are dropping at remarkable speed. SAP software is just at the beginning of this process, while in other environments AI-aided development, including agentic development, is rapidly becoming normal.

Why would a decision maker accept lengthy discussions about the merit of a feature if it can be implemented in a day, tested quickly, and perhaps even maintained with the help of AI?

IT people intuitively understand the risk of an endless flood of features implemented quickly and understood only partially. But how do you stop a decision maker from opting for implementation if the counter-argument amounts to no more than “it only takes two days to build and test,” plus a concern about future maintenance that is difficult to quantify?

This is one of the main strategic issues for SAP and for every enterprise software vendor. Who will invest days into deeply understanding the requirement, and into finding a creative use of standard software to address the core of the issue, instead of having AI generate a custom solution based on legacy documents, program it, test it, and hand it over to the business department?

Conclusion

I believe the conclusion that standard software becomes irrelevant is wrong.

Using standard software as widely known as SAP has many advantages that are not easily measurable in TCO terms. When a company hires people who know the standard software, they onboard much more easily. Ideas travel between companies. Labor mobility improves. The exchange of experience becomes easier. This is very different from running a fully custom software landscape that no one outside the organization, and perhaps no one except the AI agents involved, truly understands.

This does not mean that AI-assisted custom development is bad. On the contrary, it will often be highly valuable. But it changes the nature of the tactical discussion. The question will less often be whether something can be built at all. In many cases, the answer will be yes, and the effort will be much lower than we are used to.

The more important question will be whether the feature should be built: whether it should be a custom development, a configuration, a process change, a controlled extension, or perhaps not implemented at all. SAP’s Joule for consultants and other consultant-facing AI tools like our accelet.ai platform are certainly a move in the right direction. If AI can help consultants understand requirements faster, compare them against standard functionality, identify gaps and prepare possible solution paths, it supports exactly the work that happens on this tactical layer.

These tools will still have to prove how much they can strengthen the role of standard software, and whether they can tilt the direction away from uncontrolled AI-generated custom development in ABAP or other environments.

Overall, the potential for AI on this level is great. It will change how we deal with standard and custom software, and how consultants, IT and business departments work together. We are only seeing the beginning of it.

AI will not remove the need for consultants. It will give good consultants better instruments, while making poor scope discipline more dangerous. The future of SAP projects will not be “standard only” or “AI builds everything.” It will require using AI to understand faster, SAP standard where it creates stability, custom development where it creates real business value, and enough human judgment to know the difference.

What acceletail offers: With or without AI, our experienced consultants aim to understand our customers’ goals deeply enough to help them make the right decisions and design sustainable IT solutions. With accelet.ai, we can process and analyze documentation, analyze SAP legacy code via ADT and MCP servers, and help our consultants lead the conversation with better context.