Knowledge Ownership: Securing Knowledge in Your Business

Many companies are not facing the question of whether they need new software, but a different risk: Software operations depend on a few people, so critical knowledge can be lost.

A developer retires, takes extended leave, or leaves the company. Suddenly, a system that had run reliably for years becomes a risk because few people still understand how it is built, maintained, or needs to be adapted when changes are required. This is especially critical with older technologies such as Delphi or Access. When internal knowledge is missing, finding the right specialists can also be difficult. The real risk is losing the ability to operate, maintain, and further develop the software reliably.

1. Incident: A disruption that affects software operations.
2. Runbook: A step-by-step guide for handling common incidents.
3. Restore test: A test to verify whether a backup can actually be restored.
4. System overview: An overview of systems, dependencies, data flows, and responsibilities.
5. Deployment Process: A defined process for moving changes safely into the production environment.

This page answers the following questions

• How do I know if our software knowledge depends on just a few people?
• What risks does this pose for software operations and manufacturing?
• How do I keep my systems running smoothly when no one fully understands the system?
• What roles and responsibilities do I need to ensure reliablity?
• What documentation do I actually need to keep software operations running smoothly?
• How can I rebuild system knowledge after the developer has left?
• How does soxes take over an existing system so that operations and updates are back under control?

Systems evolve over many years, and important knowledge often stays in people’s minds instead of being clearly documented. When this comes up in initial discussions, we often hear a familiar response: “Yes, that’s true for us too. But so far, it has somehow worked.”

That is precisely the problem. It works until it no longer works. This is particularly common in SMEs because teams are small, responsibilities are widely distributed, and backup plans are rarely established intentionally. Software operations run parallel to day-to-day business and often do not receive the attention they actually need. As long as processes function, a lack of ownership often remains invisible. With legacy systems like Delphi or Access, the situation is further exacerbated. There is less expertise, onboarding takes longer, and without a clear handover, operations quickly become unpredictable.

When knowledge and accountability are lacking, operations don’t just become less safe—they also become more expensive. In production, the situation becomes critical more quickly because a failure brings processes to a halt.

These risks arise because, in practice, two key elements are often missing—elements that are essential for ensuring true operational stability: operational expertise, or the ability to actively manage the system both in day-to-day operations and in emergencies; and knowledge ownership, meaning that knowledge and responsibility are embedded within the company rather than residing solely in individual minds or with the service provider.

Before we talk about solutions, let’s briefly define the terms and what they mean in everyday life. Operational competence means that you’re always able to take action , even without a key person. You can reliably answer the following questions in everyday situations and during emergencies:

• What is currently happening in the system?
• Why is the error occurring?
• What impact does this have on processes and production?
• What is the fastest, safest way to resolve it?
• How do updates get into production without risking downtime?

Knowledge ownership means that this knowledge does not reside with a single person or a single service provider. Knowledge is embedded within the company, with clear access protocols, clear responsibilities, and documentation that can be used in an emergency.

The problem rarely arises at a single point. It develops over the course of years.

Knowledge exists, but it’s not usable

Many companies have documents, tickets, or wikis. In an emergency, however, long descriptions aren’t helpful—clear, up-to-date steps are.

Operations are not formally assigned as a responsibility

Operations happen on the side. Tasks are distributed informally. This works until multiple systems are affected or a key person is missing.

Projects deliver results, but not an operational handover

After go-live, there is often no clear handover for operations. The system is running, but access rights, processes, responsibilities, and typical error scenarios are not documented in a way that allows a team to operate and further develop it with confidence.

Handoffs are underestimated

Partner changes or personnel changes occur, but the handover is not reliable. Then not only is knowledge missing, but also access, permissions, decision-making logic, and routine.

If a system suddenly becomes unstable without a key person, you need to restore clarity in its operation. The goal is to ensure that you can once again manage updates and further development with confidence.

Here’s a brief overview of the proven steps:

• Stabilize: Clarify access and permissions, check backups and restores, make logs and monitoring visible, define incident procedures
• Understand: Create a system overview for each critical process, document typical error scenarios, and establish initial runbooks
• Secure: Define roles and stand-ins, establish deployment and release procedures, set up escalation and onboarding

How soxes implements this

We take over such systems with a focus on operations. That means: stability first, then system understanding, then ownership—so you’re no longer dependent on individuals, even with legacy systems like Delphi, Access, PHP, or LabVIEW.

When a system is critical, simply saying “IT will handle it” isn’t enough. You need clear lines of responsibility that work even in small and medium-sized businesses.

A practical role model often looks like this:

• Incident Lead: manages the incident and ensures structure and pace
• System Owner: makes decisions based on business impact and prioritizes what needs to be restored first
• Technical Owner: performs analysis and resolution and coordinates technical measures
• Communication: informs affected teams and stakeholders and coordinates updates internally and, if necessary, externally

Why is production particularly vulnerable?

In the manufacturing and industrial sectors, a lack of ownership becomes apparent more quickly than in traditional office processes. This is because systems not only support operations but directly determine whether products can be manufactured, packaged, or shipped. ERP, MES, machine data, scanners, labeling, warehousing, and quality assurance are often interconnected. If knowledge or responsibility is lacking in one area, a small error can quickly lead to a complete shutdown.

This is precisely why production needs not only stable systems but also operational expertise that can be relied upon even in the event of a disruption, regardless of who is currently available.