Digital transformation is supposed to ensure the survival of companies in the auto industry. But the growing complexity of IT systems is proving to be an obstacle. Some companies are taking the right steps but dealing with legacy systems is a tough challenge for CIOs.
CIOs are facing Herculean tasks as they tackle the jungle of their IT landscapes. With the greatest possible efforts, they are wrestling with growing architectural complexity and a multitude of systems and tools. But as in the Greek myth, the corporate IT Hydra grows two heads whenever you cut one off. Even the valiant use of new technology hasn’t helped much. Multi-cloud solutions, micro services and containers are certainly giving the business side greater flexibility and speed. But for years, they have actually been responsible for the growth in applications and components. That trend will continue in 2018.
Frank Schroeder of the Hamburg management consulting firm Darcblue draws a vivid comparison: “You can see this in your garage at home. Cleaning it out here and there from time to time doesn’t really do the job. More stuff accumulates all too quickly. You can’t find things, and you eventually lose the big picture.”
What happens with corporate IT at auto manufacturers and suppliers is not so different, Schroeder said. “If applications, the infrastructure and services are not examined for their currentness and for a robust capacity for expansion, and if legacy applications are not cleaned out, complexity continues to build up without even being noticed.”
The consequences of inaction can be dramatic and can mean companies’ operational efficiency is at risk. In a new study from Dynatrace, a US software company specializing in performance improvement, 75 percent of CIOs surveyed said rising IT complexity will soon make it impossible to effectively manage digital performance. In the US and Germany, about one-third of CIOs polled see the growing chaos as the greatest obstacle standing in the way of a successful digital transformation.
Companies today are already suffering repeated, massive fluctuations in data availability in their main legacy systems – at least once a week. There is also an increasing number of web-based or mobile transactions that are linked to an average of 38 different internal systems or components. That figure was just 26 five years ago. Companies are suddenly paying a price for the complexity. In many cases, their architectural expertise is only mediocre, in hardware and especially in software. At the start of the millennium, nearly every manufacturer brought its system partners in-house for cost reasons, transferred all their operations to them, and then limited their own role to project management.
The result: There were development projects at nearly every automaker where the project manager didn’t know what the IT service provider actually did. This led to time-outs, the loss of functionality, burgeoning costs, and user dissatisfaction in the operating areas. In today’s fast-moving times, it no longer makes sense for an operating unit to define the technical requirements for an IT system, assemble them in a Word or PowerPoint document three years before implementation, and then have an external development provider put it together on its own.
The BMW example
That’s what happened with the Connected Supply Chain project at BMW. The complexity across the entire transportation chain of the southern German premium car group was enormous, affecting processes and the interdependencies of participants such as suppliers and logistics providers. “No one on the project team, either from operating departments or on the IT side, was able to make it through the process and the potential solutions from the outset, and then develop complete specifications,” said Eugen Schantini, who was responsible for reconfiguring processes and developing and implementing new IT systems for logistics.
The experience with other projects was similar: Whether it was BMW’s Connected Supply Chain or the Supply Center 2 at the carmaker’s plant in Dingolfing, a stronger product orientation, better user experiences and continuous process responsibility would have yielded benefits.
Shifting the levers in the command post from outsourcing to insourcing and from the waterfall model to agility is a good start. But these steps alone won’t build up expertise in a company’s own ranks – not by a long shot. Competent employees with years of experience in programming are the only remedy. These experts have to take the right technical approach as they evaluate progress and results. They also have to make decisions on architecture when necessary. At least theoretically, this would create an opportunity to arrest the growth of IT complexity. Companies have to deliberately invest in functional IT architecture management, even if it involves costs they would rather avoid.
And they should not shy away from intervening in supposedly functioning systems. Too many automakers and suppliers still strictly adhere to the “Never change a running system” principle and fall into traps sooner rather than later. Every IT architect should live by a simple idea: Complexity management and standardization versus more development and individualization. But when the standardization is all-encompassing and structures are excessively rigid, architects could easily create problems and promote dissatisfaction in their operating units.
Good judgment needed
It is sometimes unavoidable for an operating unit to need an application that violates the policies of the company’s IT architecture – for example, it might want to differentiate itself from the competition. Good judgment is essential in these matters. Top management must back the policy-making powers of the company’s IT architects. Decisions on the deployment of technology have consequences for users, the IT architecture, operations, and the ability to service systems and expand them. They should not be taken lightly.
That means the job of an IT architect includes specifying clear boundaries and making conscious decisions about deviations in individual cases. External service providers shouldn’t be banned entirely since they could easily prove helpful. But they should not serve as subcontractors as they have in the past, taking over a precisely described subsection of a project. Instead, they would be expert consultants selectively brought into modernization projects. They would then help ensure the quality of a company’s processes and IT over the long haul.