IT Organisation 2025

Thomas Heinevetter: How will the IT organization change in the next five years? To establish a common basis for understanding, let me briefly outline four scenarios. In scenario one, IT and business merge completely. Product-oriented end-to-end teams also handle IT. The infrastructure is completely outsourced. Cross-cutting governance may be handled by a small team, possibly consisting of former IT personnel. The second scenario also involves a complete merging of teams, but the infrastructure is still provided by the IT organization as a so-called platform IT. In the third scenario, which we call Product IT, there are also end-to-end teams consisting of both business and IT, but these teams are virtual. The IT remains in its structure. It also continues to provide the infrastructure. We call scenario 4 hybrid IT. In it, the IT is structured similarly to today. While there are virtual end-to-end teams, there are also teams divided into plan, build, and run.

Martin Haury: Currently, we are operating in scenario 4. Selected teams, such as those in presales applications or in the Sales Force environment, are already working end-to-end. In the SAP world, where the majority of our applications reside, we are still very classical. SAP does not support working in short cycles and small teams well. I believe that our IT organization will evolve from scenario 4 to 3 and eventually towards scenario 2. The speed of development also depends on how quickly a platform IT develops. With increasing democratization and with low- and no-code platforms, this development is clearly heading in that direction.

The business side is increasingly developing its own IT skills, for example, in supply chain and sales. The IT’s monopoly as the guardian of enterprise IT is diminishing. Currently, we have process owners and key users on the business side, but I see a trend where departments themselves want to implement more IT projects. However, in terms of compliance, governance, security, and enterprise architecture, I see some challenges. The business side is not very keen on dealing with these matters because efficient operation of the entire IT system, security, release capability, or compliance with legal requirements do not bring immediate benefits to individual business areas, even if many services are obtained from the cloud. A common perspective between IT and business still needs to be developed here. It helps if colleagues in the business with higher IT affinity understand that individual applications almost always have implications for the entire IT landscape of a company, even if many services are obtained from the cloud. If they develop a broader view, then we can also bring IT and business closer together.

Heinevetter: In the aforementioned end-to-end teams, end-to-end responsibility would also have to be assumed. Do you see each team having its own security or architecture resources?

Haury: Presumably, this would be organized through shared services. In an IT organization like ours, with 140 full-time employees, not every product team can have its own security or architecture specialists. If that succeeds, I could well imagine scenario 2 becoming a reality. Provided that the speed at which skills are acquired and new applications are offered remains as high as it is now.

Heinevetter: Do you think low- and no-code platforms promote the convergence of IT and business?

Haury: Absolutely! With low-code platforms, you can set the framework and let the business areas do their thing within these guidelines. We have already had good experiences, especially in the Microsoft environment. For example, one of the development areas built their own application with the help of a consultant using Power Apps. They also administer it themselves. However, it is important to differentiate: the more it goes towards enterprise IT, the more important integration and scalability become, the more these things remain the domain of enterprise IT.

Heinevetter: Does ifm IT already provide low- or no-code platforms to the business today, or are these organized by the business itself?

Haury: Unfortunately, we have both. We provide Microsoft Power Apps in a controlled manner, but on the other hand, someone from the business sometimes tells us that they have downloaded something from the cloud and now they want it integrated. We try to intercept this through the classic demand process, but it doesn’t always work. Such situations would no longer occur with end-to-end teams. But I see the difficulty in finding the clean product interface. When teams are organized according to applications, often adjacent services are left out, which no dedicated team wants to take care of or which are too small for their own team.

Heinevetter: How far do you think citizen development should go? Should it extend to core applications?

Haury: I don’t see that in the short to medium term. Our enterprise applications are used worldwide in the ifm group. I see citizen development growing from the workplace through work groups and departments. That’s also the chance for IT. We get to know the people in the business who are IT-savvy and can involve them more strongly. This applies equally in reverse. With more intense exchange between business and IT, IT professionals also learn a lot about the business.

Heinevetter: You mentioned that the business is increasingly hiring people with IT skills. Doesn’t this also increase the overall understanding of IT?

Haury: The skill set is one thing, process responsibility is another. I only get the latter when I have teams composed of both IT and business.

Heinevetter: Many companies are currently grappling with the question of how best to set up a product-oriented approach. Two questions arise, especially: How far should the teams reach into both business and IT? Is the product owner from the business sufficient for the joint team, or should process specialists from the business department also be included? On the other hand, there is the question of whether the IT infrastructure is also the responsibility of the teams. The other essential question is the one about the success factors for product teams.

Haury: We have just set up a pilot team to build accounting with SAP. We fill that almost on a par. On the business side, there are the classical key users, and the process owner becomes the product owner. From the IT side come the consultants, the application managers. The question of whether the team also needs its own developer, or whether they are busy enough with that, is still open. How we make the cut is still a challenge at the moment. Do we purely orientate ourselves to the accounting processors or to the IT products used?

Heinevetter: There is no one truth, and it makes sense to consider each case individually. What’s important is to stick to the product idea. It’s secondary whether you focus on the IT product or the customer product/service. How big is the team?

Haury: Eight people in total. Including the product owner, five come from the business and three from IT.

Heinevetter: And the success factors?

Haury: Parity between IT and business is very important. Furthermore, the groups need a shared budget and complete transparency.

Heinevetter: How is the pilot team being received in the company?

Haury: Very positively by those who know this way of working. But of course, there are also skeptics, for example, in the classical business areas. They fear losing control and oversight.

Heinevetter: How do you see demand management in the context of product-oriented end-to-end teams?

Haury: I believe that it will not lose its justification team-wide even in the longer term, to classify the demand and guide it in the right direction.

Heinevetter: Providing teams with sufficient and appropriately skilled personnel resources can also potentially be problematic. Have you already thought about this?

Haury: I can’t give every team every specialist it might need at some point. There will always be cross-cutting issues like security. Such skills would be held in cross-cutting teams that would then support the product teams when needed. On the other hand, the skills in the product teams will become broader simply because people coming in as application managers or process specialists will learn.

Heinevetter: Change of topic. Data-driven organization. How have you planned to organize yourselves? Central – in the extreme with its own Chief Data Officer? Or decentralized, so that – again, thinking extreme – there must be data know-how in every product team?

Haury: We are in the process of clarifying that. Traditionally, controlling is the guardian of data, data governance, and data quality for us. But of course, business and IT are also interested in actively addressing their aspects of data-driven. It is clear that there will be new responsibilities and roles. We have not yet finally decided how we will approach this.

Heinevetter: Where do you see the biggest challenges for ifm in these four data areas?

Haury: At the moment, in providing the platform because it’s new territory for us. We are currently integrating three data warehouses into a data lake, into which we also want to incorporate external data.

Heinevetter: Transformation is a big term, but it describes the change of an organization towards product orientation and a data-driven approach. What factors make such a transformation successful? What would you advise your colleagues?

Haury: Taking small steps, trial and error, because it’s new territory for many of us. It means embracing a lot of change. I also think it’s very important to develop a transitional scenario in which you still have traditionally working employees but also new teams. The pioneering teams must be willing to share their experiences, and the later ones must be willing to accept and use them. There will definitely be some friction at the beginning.

Heinevetter: Should this be tackled simultaneously with the business or should IT come first and then the business?

Haury: Simultaneously. I believe it can only be done together, especially because we don’t yet know all the details of what certain changes will mean. For example, what happens if IT and business actually release people into the groups? How will that affect leadership, employees, etc.? You can’t just impose it on the other area. It must be approached together.

Heinevetter: What are your top three priority areas in the next few months, in the context of our interview?

Haury: First, preparing all stakeholders for this change and developing a shared understanding. This is more than just a new organizational chart; it’s a new way of working. Second: Building and steering cross-cutting themes such as security, architecture, governance, and compliance. The third area is certainly the topic of data, and from our perspective, it’s mainly about providing data on a data platform.