Clean Code

Digitization

Development

Der Bus-Faktor in der Industrie: Wenn eine einzige Person zum Unternehmensrisiko werden kann

Why Mission-Critical B2B Software Needs More Than Just Good Code – And How Industrial Companies Can Systematically Eliminate Their Dependencies

Monday, 7:15 AM. A system throws a critical error after an update. Orders can no longer be created, production is at a standstill, and access to key dashboards is gone. All eyes turn to Thomas in IT – the only person who knows how the software is configured. But Thomas is sick. Or on vacation. Or he quit last month.

What happens next has a name: the Bus Factor or commonly know as Truck Number.

Put bluntly, the Bus Factor measures how many people would have to "be hit by a bus" before a company becomes unable to operate in a given area. What sounds macabre represents a very real threat to industrial companies: if knowledge about ERP interfaces, production software, machine connectivity, or central system access rests with a single person, manufacturing lines can grind to a halt in the worst case.

The question is not whether this moment will come – but when.

The Silent Hero: Your company has that one person who "just knows everything." Software configurations, the historical interface logic between order management and production, workarounds in the machine connectivity layer that are documented nowhere. Everyone knows it. No one says it out loud. What happens if that person quits tomorrow?
Grown Complexity: Over the years, software features were added, the CRM was connected, production configurators were built, document management systems were integrated – all without any overarching architecture. Today, only a handful of people understand how everything fits together. Every change feels like open-heart surgery. So no one touches anything. Does that sound familiar?
The External Rescuer: A former employee or external service provider is called in again and again because only they understand certain systems – whether it's the interface between ERP and production or a historically grown custom application. You pay premium day rates for knowledge that should reside within your own company. And with every engagement, the dependency grows. Have you ever calculated what that costs you per year?
The Knowledge Monopoly: An automation engineer or IT manager sits on critical knowledge about the entire system landscape – and knows it. Knowledge transfer? Kept getting postponed. Documentation? "I'll do it when I have time." That time never comes. And deep down, everyone knows: if this person leaves, we have a problem.
The Knowledge Island: Production works with different tools than sales, the warehouse has its own processes, quality assurance has its own databases. The person who understands the full picture – how ERP, CRM, production systems, and document management interact – is often a single individual. If they're out, it's not just individual processes that stop. The bridge between systems collapses.

How many scenarios did you recognize? If you nodded at even one: your instinct is right. Most industrial companies we speak with recognize themselves in three or more of these scenarios. It's one of the most common and, at the same time, most underestimated risks in the industrial software landscape.

And after reading this article, you'll start noticing these dependencies in your everyday work – in the weekly sync, when everyone looks to one person again. In the project meeting, when someone says "Thomas needs to decide that." In the hallway conversation, when someone mentions the next upcoming retirement. The Bus Factor is everywhere – you just have to look.

What Is the Bus Factor: A Definition

The term Bus Factor comes from risk management and is used to assess project risk. It quantifies how many people can drop out of a project before a company becomes unable to operate in a given area.

The lower the number, the higher the risk. A Bus Factor of 1 is the worst possible score – it means a single team member is critical to the success of a project, the management of a system, or the operation of mission-critical software.

Especially in industry, where software directly intervenes in value creation processes – from order entry to production control to quality assurance – a Bus Factor of 1 can be existentially threatening. And yet it is silently accepted in most companies. Not because no one sees the risk. But because inaction feels more comfortable than action. As long as nothing goes wrong.

„Could an 82-year-old employee pose a risk?“

What sounds macabre – or overly pessimistic – is not uncommon, as Marcel Dambach, Team Lead Software Engineering at generic.de, knows from experience. For over 25 years, generic.de has supported industrial companies in developing and modernizing mission-critical software. In his role, Marcel regularly visits clients on-site, analyzing responsibilities, system landscapes, and project risks.

He says: "In principle, most clients are aware that individual knowledge holders – for example, the person responsible for a business-critical piece of software – represent a potential risk. They don't need to actually be hit by a bus. It's enough if they leave the company, whether by resigning or retiring.

Marcel Dambach, Team Lead Software Development, generic.de

But even though the latter case represents a plannable risk, it tends to be overlooked or pushed aside in the day-to-day. I've encountered this in projects: we were brought in to overhaul a very old but business-critical piece of software. When we asked where the source code was, the answer was: 'Well, that's actually one of the reasons you're here. The only person who knows this software is our former colleague. He still handles it on the side, even though he's 82 years old and has been retired for 15 years.' We nearly fell off our chairs."

What surprises many: this company, too, had known about the risk for years. There too, the thinking was: "It'll be fine." We encounter situations like this in industry on a regular basis. Historically grown software landscapes where knowledge about production systems, ERP configurations, and custom developments has accumulated in single individuals over decades. The problem is never that no one saw it – but that it kept being deferred because day-to-day operations took priority.

What happened to the 82-year-old? The company eventually acted – but late. Recovering the knowledge and modernizing the software took months and cost several times what timely planning would have.

The Cost of Downtime: How Expensive Is a Sick Day?

When that one person is unavailable, we're not talking about a minor inconvenience. But the costs don't begin at the point of failure. They accumulate every day the risk exists:

‍Production Stops and Manufacturing Outages: When the sole knowledge holder for a critical production system is unavailable, manufacturing lines go down. In the production industry, every hour of unplanned downtime can cost between €10,000 and €100,000 – often considerably more, depending on the sector and order volume. OEE drops, delivery deadlines are at risk, contractual penalties loom. Imagine what the call to your most important customer sounds like: "We can't deliver this week."
Knowledge Loss That Cannot Be Recovered: What isn't documented is irretrievably lost when the person walks out the door. At one of our clients in mechanical engineering, onboarding a successor took six months – because all the knowledge was in a single person's head. Reverse-engineering custom software that has been adapted to specific production processes over years costs many times the original development investment. For a project that originally cost €200,000, we're quickly talking about €500,000 or more for reconstruction.
120 Hours Per Month – For Nothing: Companies with grown system landscapes lose an average of 120 working hours per month due to media breaks between systems that don't communicate with each other. That's one and a half full-time positions occupied with duplicate data entry, manual reconciliation, and workarounds. What could your team do with that time if the systems finally talked to each other?
Innovation Backlog: Teams dependent on individual people innovate more slowly. Digitalization projects are postponed because "we first need to figure out how the legacy system works." Modernizing on-premises infrastructure, AI-supported process automation, integrating new data sources – all of it stalls. And while you wait, your competitors take their next step.
Missing Integration Leads to Flying Blind: When the knowledge holders who are the only ones who understand how ERP, CRM, production systems, and document management interact fall away, data silos and information gaps emerge. Imagine your production manager making decisions based on data that hasn't been updated in weeks – without knowing it. Orders are entered twice, inventory figures are wrong, customer inquiries can't be tracked.
Expensive Emergency Solutions: When the worst case hits, external specialists are brought in under panic – at premium rates, under time pressure. And often, the new service provider creates the next dependency. You haven't solved the problem – you've just changed the name on the invoice.
The insidious part: most industrial companies know they have a Bus Factor problem. But as long as production is running, it gets suppressed. And that is precisely the most expensive part: not the moment it happens. But the months and years before, in which you bear the cost of inaction – without seeing it on any invoice.

The question is not "Will it happen?" – but: what does every additional month of deferral cost you?

Self-Assessment: How High Is Your Bus Factor Risk?

Take 60 seconds. Go through the following eight questions – and count honestly:

There is at least one person without whom a critical production or ERP system cannot be maintained
Important system access credentials, admin permissions, or interface configurations are held by a single person
You have custom software in use whose source code no one on the current team fully understands
Documentation for critical systems and interfaces is outdated, incomplete, or nonexistent
A former employee or external service provider is regularly called upon for maintenance or knowledge queries
Changes to certain software are avoided because "it's too risky" or "nobody knows what would happen"
Your system landscape (ERP, CRM, DMS, production systems) has grown over years – without an overarching integration architecture
The thought of a specific person resigning or retiring causes you genuine concern

Even two checkmarks are a clear warning signal. Most industrial companies that come to us check five or more items. If that applies to you: you're in good company. And every one of these problems is solvable – if you address it before the emergency strikes.

Not every risk needs to be resolved immediately. But every risk should be consciously known. You've just taken the first step: looking honestly.

‍

What Does RACI Mean in Risk Analysis?

In the case described above, the risk was obvious. But that isn't always so. Bus Factor risks often lie dormant where you least expect them – in permissions, access credentials, configurations, or undocumented workarounds.

To identify where potential vulnerabilities may exist, generic.de works with the Responsibility Assignment Matrix, also known as the RACI diagram. Many of our industrial clients have since adopted this tool as a permanent part of their project work.

A RACI diagram describes team member responsibilities in a given project across four categories:

Responsible | Execute the Task: This person is accountable for ensuring a specific task is completed within the agreed parameters and deadline. A task can have multiple responsible persons.

Accountable | Project Oversight: The person who ensures that the task is completed by all responsible parties. To avoid creating a Bus Factor of 1 here as well, a deputy arrangement should be established directly.

Consulted | Knowledge Provision: The "consulted" person is a knowledge holder within the team. They offer help, additional context, and advice, provide needed information, and grant access.

Informed | Receives Status Updates: Stakeholders who receive or need information about the project.

‍

Especially in industry, where IT managers, production managers, automation engineers, and external service providers must work together, the RACI model quickly surfaces vulnerabilities: Who has which system access? Who understands the interfaces between ERP and production? Who can grant permissions or change configurations?

Often, a single look at the completed matrix is enough to see the need for action in black and white. Marcel Dambach knows: "Sometimes the people who carry a great deal of responsibility don't want to give it up at all. That's when persuasion work needs to happen – ideally from the outside. The Bus Factor argument can sometimes be a wake-up call."

A concrete tip: Take your three most critical systems and ask: Who can configure, maintain, and restore this system in an emergency? If the same name appears for all three systems, you've found your Bus Factor.

Actively Driving Knowledge Sharing to Ensure Traceability

What applies to the RACI matrix applies to the entire project: there must be ongoing communication among all project participants. Because without regular communication or documentation, the same problem as at the outset can reemerge. The result: no one knows anymore what was developed, why, and how. This becomes especially problematic for the evolvability and traceability of code – and in industry, where software directly intervenes in value creation processes, insufficient traceability can mean production risk.

According to Marcel Dambach, this point is decisive for many industrial clients when selecting a development partner: "Clients today no longer want to be dependent on a particular product or company. The so-called vendor lock-in, which prevents clients from switching providers, must be avoided.

We ensure this through absolutely transparent collaboration with the client, who has full access to the source code at all times. By applying Clean Code Development principles, we ensure that technical debt is minimized. This means that both we and any other developers who may later take over the project can understand why specific decisions were made."

Why this is especially critical in industry: resolving a Bus Factor by replacing dependence on an internal person with dependence on an external service provider doesn't solve the problem – it merely relocates it. In a sector where proprietary systems, vendor-dependent ERP modules, and grown on-premises infrastructure already create dependencies, the goal must be different: not a rebuild, but intelligent networking of what already exists. Not new dependencies, but traceability. Your knowledge stays with you, your code belongs to you, and you can decide at any time how things proceed.

But what if there were a way to make the knowledge embedded in your code accessible – even to developers who have never seen it before?

How Artificial Intelligence and the Model Context Protocol Make Knowledge Accessible

The classic response to the Bus Factor is: Clean Code – better documentation, more pair programming, regular code reviews. That remains important. But it has a limit: people forget, change jobs, and documentation becomes outdated faster than it's written.

Today, there is an additional approach that fundamentally changes the game: AI-powered code interaction via the Model Context Protocol (MCP).

What Is MCP?

The Model Context Protocol is an open standard that enables AI models to access external data sources in a structured way – including codebases, documentation, ticketing systems, or knowledge bases. Instead of a new developer spending weeks reading through thousands of lines of code, they can ask the AI – and receive answers based on the actual code and its history.

An Example: How a New Developer Understands Legacy Code

Imagine the following scenario: Lisa has been on the team for two weeks. She's been asked to continue developing a module written five years ago – by a developer who left the company long ago. The code is functional, but complex. No comments, no architecture documentation, no README.

Without MCP: Lisa spends days reading the code line by line. She understands the syntax, but not the intent. Why was a workaround built here? What business rule lies behind this validation? What side effects would a change at this point have? She asks colleagues – but no one was there when the code was written. After two weeks, she has a rough understanding. She's far from productive.

With MCP: Lisa opens her development environment, which is connected via MCP to the entire codebase, the Git history, the linked tickets, and the existing documentation. She asks the AI:

"Why was a separate validation step for existing customers added to the OrderValidation class?"

The AI analyzes the code, the associated commits, the linked user stories, and responds: The step was introduced because existing customers had different pricing conditions in the old system. Ticket XY-1247 describes the requirement. The workaround circumvents a limitation of the database structure at the time, which has since been resolved – meaning the workaround could be removed.

Lisa has understood in five minutes what would have taken her two days without AI. And she has not just the what context, but the why context – the most valuable and hardest-to-transfer form of knowledge.

What MCP Concretely Delivers

Making the codebase comprehensible: New developers can "talk" to the code – they ask questions in natural language and receive answers based on the actual code, the commit history, and linked documents.

Making implicit knowledge explicit: The reasoning behind architectural decisions that previously existed only in the original developer's head becomes reconstructable through AI analysis of code, commits, and tickets.

Dramatically accelerating onboarding: Instead of months, new team members need weeks to become productive – because they always have an AI-powered "mentor" that knows the entire code history.

Reducing dependency on individuals: When knowledge resides not only in people's heads but also in an AI-accessible knowledge base, the Bus Factor measurably decreases.

Making legacy code modernizable: Before legacy code can be refactored, it must be understood. MCP-powered AI makes that understanding faster, cheaper, and less dependent on individual people.

The Difference from Classical Documentation

Documentation is a document. It is static, becomes outdated quickly, and is rarely read where it's needed.

MCP-powered AI is different: it is context-aware – it responds exactly where the question arises: in the code, in the IDE, at the moment of not understanding. It is current, because it accesses the live codebase directly. And it is interactive – you can follow up, refine, dig deeper.

This doesn't replace good documentation or pair programming. But it adds a dimension that was previously missing: knowledge that stays accessible – even when the person who had it is no longer there.

Not Every Bus Factor Is a Catastrophe

Ein wichtiger Punkt, der in der Diskussion oft untergeht – und den wir Ihnen bewusst sagen, auch wenn es uns keinen Auftrag bringt: Nicht jedes Bus-Faktor-Risiko muss sofort und mit maximalem Aufwand aufgelöst werden. Es gibt Situationen, An important point that often gets lost in the discussion – and one we tell you consciously, even if it doesn't win us a contract: not every Bus Factor risk needs to be resolved immediately and with maximum effort. There are situations in which we honestly tell companies: "You don't have an acute problem. Monitor it, document selectively, and act when the situation changes."

Sometimes a Bus Factor of 1 for a non-critical internal tool is acceptable. Sometimes good documentation is sufficient as a first step. And sometimes the honest answer is: this system should be replaced anyway before investing in knowledge transfer.

Especially in industry, where dozens of systems run in parallel, the point is not to tackle everything at once. What matters is prioritization:

Which software directly intervenes in value creation?
Where would an outage cause production stops?
Where are the costs highest if knowledge is lost?
And where does it make sense to consciously accept a risk?

What matters is that you know your risks and prioritize them consciously – rather than suppressing them until the emergency arrives. The question is not: "Do we need to change everything immediately?" But: "Do we know where it would catch fire if someone were unavailable tomorrow – and have we consciously decided to carry that risk?"

Conclusion: Act Before the Bus Arrives

Remember Thomas? Monday, 7:15 AM, ERP error, production at a standstill. The companies that remain calm in this situation have one thing in common: they acted ahead of time. Not in panic, not with a massive project – but with a clear view of their dependencies.

What these companies did differently:

Looked instead of suppressed – they know their Bus Factors and have made a conscious decision about which ones to resolve and which ones to accept
Documented as part of the work process – not as a project, but as an attitude
Made knowledge accessible – through Clean Code, AI-powered code interaction via MCP, and systematic knowledge transfer, so new developers become productive in weeks rather than months
Created no new dependencies – no vendor lock-in through proprietary systems or undocumented code
Relied on traceability – so their software can still be further developed five years from now, regardless of who's doing it

The Bus Factor is not a theoretical thought experiment. It describes a concrete, measurable business risk that becomes more real every day – with every undocumented workaround, every deferred knowledge handover, every unplanned interface between legacy systems.

The question that remains is simple: Do you know where you stand?

Three Ways You Can Move Forward Now

If, while reading this article, you thought of specific people, systems, or situations in your company – then you've already taken the most important step. You've looked.

What comes next depends on where you are:

Path 1: Start Yourself – 30 Minutes That Could Change Everything

Take the self-assessment from above, print it out, and put it on the table at your next weekly meeting. Go through it together with your development team. Not as a blame exercise – but as an honest conversation: Which modules does only one person understand? Where would we be stuck?

Often, just this conversation creates a dynamic that had been missing for years. It costs you nothing – except 30 minutes of honesty.

Path 2: Get an Outside Perspective – For Those Who Want to Know How Critical It Really Is

If you're unsure whether your situation is acute or where to start – talk to someone who sees situations like this every week.

In a short, no-obligation conversation, we'll work through together whether and where action is needed. We'll also show you what MCP-powered AI interaction looks like concretely – using your own codebase, not a demo example. We'll tell you honestly if we think you don't have an acute problem – or if a different path is the right one. Not every conversation leads to a project. Sometimes a good piece of advice is the most valuable first step.

Path 3: Make the Codebase Accessible – For Companies Ready to Tackle It Now

For companies that know they have a problem and want to address it systematically, we offer a focused Discovery Workshop:

1–2 days, not 6 months
A concrete focus: your most critical codebases and knowledge dependencies
Together with your team: you prioritize the modules, you decide where MCP-powered AI interaction provides the greatest leverage
The outcome belongs to you: mapped dependencies, a first MCP prototype for your most important use case, and prioritized next steps – regardless of whether we continue working together afterward

No vendor lock-in. No follow-on obligation. Clean Code and knowledge transfer are not add-ons for us – they're the standard. You retain full control – over the process, over the code, and over the decision of how things proceed.

Write to us at [team@generic.de] or call [+49 721 6190960] – we'll respond within 24 hours.

generic.de has been helping industrial companies resolve their software dependencies for over 25 years – transparently, traceably, and without creating new vendor lock-in. Through Clean Code Development, Dual Track Agile, consistent knowledge transfer, and AI-powered code accessibility via the Model Context Protocol, your knowledge stays with you – even when the people who had it are no longer there.