Who Is Really on the Client's Side in the SAP World?

The Israeli SAP market is full of excellent companies. It has deep knowledge, decades of experience, and first-rate professionals. But almost all of them operate on the same business model: they are project companies.
They make money from implementation, upgrades, conversions, development, and selling hours. Many are also official SAP partners, so naturally they operate within SAP's strategy, products, and roadmap.
There is nothing wrong with that. The problem begins when the same party that is supposed to advise the client on what is right for them is also the party that profits from the project it recommends.
This is where Xcon is fundamentally different.
We are not a project company. We are an integration company.
We are not looking for the next project we can sell to the client. We accompany the client from inside their own organization, represent their interests toward SAP, toward implementation companies, and toward technology vendors, and help them make decisions that fit their business.
Sometimes the right decision will be to launch a major project. Sometimes it will be precisely not to launch one.
The pressure to move to S/4HANA
Almost every organization currently running ECC knows this conversation.
The message it receives from the market is clear: you need to move to S/4HANA.
That message is usually reinforced by two arguments that create significant pressure on decision makers.
The first concerns support. The dates 2027 and 2030 are often presented as a kind of finish line, after which an organization that stays on ECC will find itself without adequate support.
The second argument is technological and business-oriented: if you stay on ECC, you will not be able to keep developing. Technology will move forward and you will be left behind. And in business, as we know, whoever does not move forward goes backward.
Both arguments are based on real questions that need to be taken seriously.
But the conclusion that every ECC customer must therefore rush immediately into an S/4HANA project is simply not categorically true.
You can stay on ECC. You can receive proper support. And you can keep developing.
You just need to know how to do it right.
Support is something to manage, not a threat to fear
SAP's support timelines matter, and a responsible organization must understand them and prepare for them.
But the end of a specific manufacturer support period does not mean the system stops working the next day. It also does not necessarily mean that the only option available to the organization is to immediately perform a full conversion.
There are third-party support alternatives in the market, and it is possible to build a maintenance model that fits the organization, its system, the level of risk it is willing to take, and the length of time it wants to continue working with ECC.
This is not a solution that automatically fits every customer. There are organizations for which staying on ECC would be the wrong decision.
But in exactly the same way, an immediate move to S/4HANA is also not automatically the right decision for every customer.
The decision should be made based on the system's condition, costs, risks, business plans, technical debt, workforce availability, other projects in the organization, and the value the move is expected to create.
Not based on fear of a date on the calendar.
What about the claim that you cannot move forward with ECC?
Here too, reality is more complex.
An organization that stays on ECC does not have to freeze itself technologically. It can continue improving processes, adding automation, making information accessible, improving user experience, and giving the business new capabilities.
Today there are technology layers and tools that make it possible to extend the capabilities of the existing system without making a deep change to the ERP core every time.
InsightZAP is a good example of this.
Using tools of this kind, it is possible to address new business needs, create more efficient processes, and improve the way users work with the system, even when the core system remains ECC.
From our perspective, this is a critical point.
A decision to postpone a move to S/4HANA does not have to be a decision to postpone innovation.
An organization can decide that the move will happen in three or four years, and at the same time use that period to improve processes, clean up unnecessary developments, handle data, reduce complexity, and prepare itself for a future move in a much smarter way.
In some cases, this can be a better strategy than rushing into a project just because the market creates a sense of urgency.
And still, S/4HANA has enormous advantages
We want to emphasize this, because our position is not against SAP and not against S/4HANA.
On the contrary.
S/4HANA is a very advanced platform, and in many organizations the move to it is the right decision.
It enables simplification of architecture and data models, improved performance, more advanced analytics, a modern user experience through Fiori, shedding some of the complexity accumulated over the years, and building a better foundation for automation, cloud, data, and AI capabilities.
An S/4HANA project is also a rare opportunity for an organization to re-examine processes built ten, fifteen, and sometimes twenty years ago, and ask whether they still make sense.
There are customers who need to start this journey now.
Their ECC system is already limiting the business, maintenance costs are high, technical debt is significant, it is hard to recruit suitable expertise, the organization needs new capabilities, or its business plans require a fundamental change to the ERP environment.
To such customers we will say clearly: it is time to move forward.
But there are also other customers.
Customers with a stable system that works well, large investments made in recent years, business needs that are well served, or other priorities that justify directing capital and management attention elsewhere right now.
Why should such an organization spend tens of millions of shekels now just because that is the direction the market is pushing it?
The question is not what SAP wants to do. The question is what the business needs to do
SAP needs to manage its own roadmap.
The implementation company needs to manage its own business.
And the client needs to manage its own business.
These are three different interests, even when they overlap.
When a company that profits from an S/4HANA project recommends launching an S/4HANA project, the recommendation can be completely professional and correct. But there is still a commercial interest in the background.
That is why an organization needs by its side a party whose only question is: what is right for the client?
That is exactly Xcon's role.
We can examine the option to move to S/4HANA and the option to stay on ECC with equal seriousness.
We can examine an SAP product alongside a solution from another vendor.
We can look at a scope proposed by an implementation company and ask whether all of it is really needed.
We can look at a 30-million-shekel project and ask a question that is sometimes very hard to ask after all the vendors have already entered the room: what would happen if we simply did not do it now?
Real integration begins long before the technical integration
The term "integrator" has become in the technology market a word that describes almost every implementation company.
We look at it differently.
Real integration is not just connecting SAP to another system. It is the ability to connect technology to the organization's business strategy.
Understand the ERP, but also the budget.
Understand architecture, but also the business roadmap.
Know SAP's products, but not be committed to them.
Know the implementation companies, know how to work with them and respect their expertise, but also be able to challenge them.
And above all, be able to look at dozens of vendors, systems, products, and interests and build from them one picture that serves the client.
That is the integration we are talking about.
We do not want to replace implementation companies
On the contrary. SAP customers need strong implementation companies.
When you embark on a significant project, you need a body that knows how to execute it. You need project managers, architects, implementers, developers, Basis people, integration specialists, and infrastructure people.
But when the implementation company manages the project, someone else needs to make sure the project is managed in the client's interest.
Someone needs to examine the scope.
Someone needs to check whether a change request is really necessary.
Someone needs to challenge architectural decisions before they become a fact that is difficult and expensive to change.
Someone needs to make sure the client is not copying twenty years of unnecessary complexity into the new system.
And someone needs to be able to sit with SAP, with the implementation company, and with the organization's management and say the exact same thing, even when it is uncomfortable for all sides.
That is our place.
Why does every SAP organization need such a party by its side?
Because SAP decisions are very expensive decisions, and the price of a wrong decision can follow the organization for years.
The big risk is not only that a project will be delayed by three months or exceed the budget.
The bigger risk is carrying out the wrong project.
Moving too early. Moving too late. Choosing a scope that is too large. Choosing a solution that does not fit. Replacing a system that works very well without sufficient business justification. Or, on the other side, continuing to hold a system that is already harming the organization's ability to compete and develop.
Each of these mistakes can cost millions.
Therefore, from our perspective, Xcon is not just another vendor in the project.
Xcon is the client's professional protective layer.
We are there to make sure that a decision worth tens of millions of shekels is made because it is right for the business, and not because someone managed to create enough pressure for the organization to sign.
We are not against SAP. We are for the client
And this is perhaps the most important difference.
We have no interest in persuading customers to stay on ECC, just as we have no interest in persuading them to move to S/4HANA.
We want them to do the right thing at the right time.
If they need to move now, we will say move now.
If it makes sense to prepare for two years and only then move, we will build the path there.
If it is possible to stay on ECC for now, receive suitable support, and continue developing the system and the capabilities around it, we will say that too.
And if along the way we discover that the underlying assumption has changed, we will change the recommendation.
Because in the end, SAP's roadmap is SAP's roadmap. The implementation company's roadmap is its own. And the client's roadmap must be written according to the client's business.
In a market where almost everyone sitting around the table has something to sell, the client should have at least one party that has no interest in selling them the next project.
A party that knows SAP, knows the market, knows the alternatives, and knows how to work with all the vendors, but wakes up every morning with one interest only: that the client makes the right decision for them.
That is Xcon.
Not another project company.
A real integrator on the client's side.
