Ensuring IT Operations When Knowledge Is Lacking

Many companies aren’t faced with the question of whether to adopt new software, but with a different risk: knowledge is lost, and operations become dependent on it.

The developer retires. He falls ill. He leaves the company. And suddenly there’s a system that “just worked” for years, but no one can explain how it really works. The situation becomes particularly delicate when it comes to older systems, such as applications built on Delphi or Access. In such cases, not only is the knowledge gone, but often the availability of specialists is as well . The real risk is often not the system itself, but the dependence on it.

1. Incident: A disruption that affects operations and requires active management.
2. Runbook: A sequence of steps for diagnosing and resolving a typical incident.
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: How changes are reliably deployed to production.

This page answers the following questions:

• How can I tell if our IT knowledge is concentrated in just a few individuals?
• What risks does this pose for operations and production?
• How do I ensure IT operations run smoothly if no one really understands the system?
• What responsibilities do I need to ensure reliable operations?
• What documentation do I really need to keep operations running?
• How can I rebuild system knowledge if the developer leaves?
• How does soxes take over an existing system so that operations and updates can be planned again?

Systems evolve over the years, and knowledge almost automatically ends up in people’s heads rather than in clear structures. When we bring this up in initial meetings, we almost always hear similar responses: “Yes, that’s how it is at our company too. But so far, it’s somehow worked out.”

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. 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.