Die eierlegende Wollmilch-IT im Mittelstand

Ich habe manchmal das Gefühl, dass im Mittelstand unter „IT“ etwas ganz anderes verstanden wird als das, was man eigentlich leisten kann. Da wird jemand gesucht, der „sich um die IT kümmert“. Klingt erstmal überschaubar. In der Realität bedeutet das dann aber: Der Server läuft, die Arbeitsplätze funktionieren, der Shop bringt Umsatz, die Website ist sichtbar, die Prozesse sind digital, die Daten sind sicher — und wenn möglich bitte noch ein bisschen KI obendrauf.

Und irgendwie soll das alles zusammenpassen. In einer Person.

„Du bist doch IT“

Was ich dabei immer wieder höre, ist dieser eine Satz: „Du bist doch IT, du kannst dich da ja schnell eindenken.“ Und ja, das stimmt auch irgendwo. Man kann sich in vieles einarbeiten. Man findet Lösungen, probiert Dinge aus, bekommt Systeme ans Laufen. Was dabei aber oft komplett untergeht, ist der Weg dahin.

Neue Themen kommen nicht einfach dazu und funktionieren sofort. Man muss sich einarbeiten, Dinge verstehen, testen, auch mal scheitern und wieder neu aufsetzen. Das gehört dazu. Und manchmal bedeutet „eindenken“ eben nicht eine Stunde Googeln, sondern zwei Wochen Dokumentation lesen, eine Testumgebung aufbauen, drei Ansätze verwerfen und beim vierten merken, dass der erste doch der richtige war — nur mit einem Detail, das man beim ersten Mal übersehen hat.

Wer schon einmal einen neuen Dienst in eine bestehende Infrastruktur integriert hat, kennt diesen Moment: In der Demo sieht alles sauber aus, die Dokumentation verspricht einfache Einrichtung, und dann stellt sich heraus, dass die eigene Umgebung drei Sonderfälle hat, die nirgends beschrieben sind. Dann wird aus „schnell eindenken“ plötzlich ein Projekt. Und nebenbei muss trotzdem alles andere weiterlaufen — der Shop, die Backups, die Tickets, die Kollegin, deren Outlook nicht synchronisiert.

Diese Zeit ist selten eingeplant, weil von außen nur das Ergebnis zählt, nicht der Weg dorthin. „Läuft doch jetzt“ ist das höchste Lob. Dass vorher drei Abende draufgegangen sind, weil man das Problem nicht einfach bis morgen liegen lassen konnte — das sieht niemand. Und ehrlich gesagt erwartet auch niemand, dass man das erzählt. Man macht es einfach. Weil es sonst keiner macht.

Gesehen wird das meistens erst, wenn etwas nicht funktioniert.

Wer sorgt eigentlich dafür, dass Geld reinkommt?

Und dann dieser Gedanke, der mir immer wieder kommt: Ein Geschäftsführer steuert das Unternehmen. Ich sorge dafür, dass das System, mit dem überhaupt Geld verdient wird, existiert. Wenn der Shop nicht läuft oder die Sichtbarkeit fehlt, kommen keine Anfragen rein. Und dann gibt es auch nichts mehr zu steuern.

Das klingt vielleicht hart, aber es ist die Realität in jedem Unternehmen, das digital Umsatz macht. Der Onlineshop ist kein nettes Beiwerk, er ist das Kerngeschäft. Die Website ist nicht „auch noch da“, sie ist oft der erste und einzige Kontaktpunkt, den ein Kunde mit dem Unternehmen hat. Wenn diese Systeme stehen, steht alles. Der Vertrieb kann keine Angebote verschicken, das Marketing kann keine Kampagnen fahren, der Kundenservice kann keine Bestellungen einsehen. An diesem Punkt wird jedem schlagartig klar, wie viel eigentlich an der IT hängt. Nur eben erst an diesem Punkt.

Die Bedeutung davon wird oft unterschätzt. Auch beim Gehalt. Für viele ist der Geschäftsführer immer noch die wichtigste Rolle im Unternehmen — derjenige, der die Richtung vorgibt, die Entscheidungen trifft, das Steuer in der Hand hat. Und das stimmt auch. Aber ohne funktionierende IT fehlt am Ende die Grundlage, auf der überhaupt Entscheidungen wirken können. Die beste Strategie nützt nichts, wenn die Werkzeuge nicht da sind, um sie umzusetzen. Dabei ist das kein Gegeneinander. Beides gehört zusammen. Nur wird die eine Seite oft gesehen — die Meetings, die Präsentationen, die Quartalszahlen — und die andere läuft still im Hintergrund mit. Solange sie funktioniert, ist sie unsichtbar. Und unsichtbare Arbeit wird selten so wertgeschätzt, wie sie es verdient hätte.

„Der Bekannte kann das nebenbei“

Und dann gibt es die Alternative, die ich fast noch häufiger sehe: Man lagert es ins Bekanntenumfeld aus. Nach dem Motto: „Der Sohn von meinem Nachbarn macht irgendwas mit Computern, der kann das schon irgendwie nebenbei lösen.“ Oder der Schwager, der mal eine Website gebaut hat. Oder der Freund, der „sich mit Technik auskennt“.

Ich will das gar nicht abwerten — jeder fängt irgendwo an, und viele dieser Leute sind durchaus fähig. Aber was dabei fast immer fehlt, ist der Blick für die Zusammenhänge im System. Der Bekannte sieht die eine Aufgabe, die vor ihm liegt: eine Website aufsetzen, ein Plugin installieren, einen Fehler beheben. Was er nicht sieht — und auch nicht sehen kann, weil er nicht täglich im Unternehmen steckt — ist, wie diese eine Änderung mit dem Shop zusammenhängt, wie sie sich auf die Ladezeit auswirkt, ob sie den Datenschutz tangiert, ob der Server das Backup noch sauber durchbekommt, wenn plötzlich doppelt so viele Daten anfallen.

Der Bekannte wird eher als Lückenfüller gedacht. Man ruft ihn, wenn etwas brennt, und hofft, dass er es löscht. Zwischen den Bränden passiert nichts. Keine Updates, keine Wartung, keine strategische Weiterentwicklung. Wird schon irgendwie laufen. Und meistens tut es das auch. Eine Weile. Bis das erste größere Problem auftaucht — ein Sicherheitsleck, ein veraltetes System, ein Datenverlust — und dann stellt sich heraus, dass „nebenbei“ eben doch nicht dasselbe ist wie „richtig“.

Dazu ist die IT-Welt schlicht zu komplex geworden. Ein Onlineshop allein besteht heute aus Dutzenden Komponenten: Webserver, Datenbank, Caching, CDN, Payment-Provider, Versandschnittstellen, Consent-Management, Analytics, Monitoring. Jede einzelne Komponente hat ihre eigene Konfiguration, ihre eigenen Updates, ihre eigenen Fallstricke. Wer das nebenbei betreut, wird irgendwann Abkürzungen nehmen müssen. Und Abkürzungen in der IT haben die unangenehme Eigenschaft, dass sie erst Monate später als Probleme sichtbar werden. Nebenbei, stabil und sehr gut — das klappt selten.

Fünf Rollen, ein Stuhl

Das Problem ist gar nicht, dass man die Themen nicht hinbekommt. Was wirklich anstrengend wird, ist diese Erwartung, dass alles gleichzeitig laufen soll. Dass nichts liegen bleibt. Dass man jederzeit reagieren kann. Dass Montag ein neues Feature im Shop live geht, Dienstag die Datenschutz-Audit-Fragen beantwortet sind und Mittwoch das Backup-Konzept für den neuen Standort steht.

Dabei sind das oft komplett unterschiedliche Rollen mit ganz eigenen Anforderungen. Entwicklung braucht Fokus — tiefes Eintauchen in ein Problem, stundenlang, ohne Unterbrechung. Wer Code schreibt, baut im Kopf ein Modell auf: Wie hängen die Klassen zusammen, wo fließen die Daten hin, was passiert bei einem Fehler in Zeile 247? Dieses Modell ist fragil. Eine einzige Unterbrechung, und es zerfällt. Dann fängt man nicht da weiter, wo man aufgehört hat — man fängt von vorne an, das Modell im Kopf wieder aufzubauen.

Infrastruktur braucht das Gegenteil von Spontanität. Server-Updates, Firewall-Regeln, Zertifikatserneuerungen — das sind Aufgaben, die Ruhe und Planung brauchen, weil ein Fehler dabei nicht nur den eigenen Code betrifft, sondern das ganze Unternehmen lahmlegen kann. Änderungen an Produktivsystemen macht man nicht zwischen zwei Meetings. Man macht sie abends, am Wochenende, oder in einem Wartungsfenster, das man vorher mit allen abgestimmt hat. Also theoretisch. In der Praxis macht man sie, wenn es gerade irgendwie passt, und hofft, dass nichts schiefgeht.

Support ist das genaue Gegenteil von beidem: reaktiv, sofort, oft mitten in etwas anderem. Und dann gibt es noch die strategischen Themen — Digitalisierung, Prozessoptimierung, Datenschutz, KI-Integration — die eigentlich Konzepte und Recherche brauchen, aber nie die ungestörte Zeit dafür bekommen. Diese Themen schieben sich von Woche zu Woche, von Monat zu Monat, bis irgendwann jemand fragt: „Warum sind wir da eigentlich noch nicht weiter?“ Die Antwort ist immer dieselbe. Aber sie will keiner hören.

Der Kontextwechsel als Dauerzustand

Vielleicht kennst du das auch: Du bist gerade tief in einem Datenbankproblem, hast den Zusammenhang zwischen drei Tabellen im Kopf, weißt genau, wo der Fehler liegt — und dann klingelt das Telefon. Jemand kann nicht drucken. Du hilfst, löst das, legst auf. Und dann sitzt du wieder vor deiner Datenbank und brauchst zwanzig Minuten, um den Zustand im Kopf wiederherzustellen, den du vorher hattest.

Das ist kein Einzelfall. Das ist der Normalzustand. Studien zeigen, dass Entwickler nach einer Unterbrechung im Schnitt 15 bis 25 Minuten brauchen, um wieder in den vorherigen Denkprozess zurückzufinden. Wenn das dreimal am Tag passiert, verlierst du eine Stunde produktive Arbeit — nicht durch Faulheit, nicht durch schlechte Organisation, sondern allein durch die Struktur deines Arbeitstages.

Und das Tückische daran: Von außen sieht es so aus, als würde man den ganzen Tag arbeiten. Man ist ja ständig beschäftigt. Nur eben nicht mit dem, was eigentlich Fortschritt bringt. Am Ende des Tages hat man zwanzig kleine Probleme gelöst, aber das eine große — das, wofür man eigentlich angestellt ist — liegt immer noch auf dem gleichen Stand wie heute morgen. Und dann kommt die Frage: „Wie weit bist du mit dem Projekt?“ Und man steht da und kann nicht erklären, wo die Zeit geblieben ist, obwohl man den ganzen Tag nicht stillgesessen hat.

Keine Frage der Organisation

Ich habe für mich irgendwann gemerkt, dass das nicht an mangelnder Effizienz liegt. Auch nicht daran, dass man sich schlecht organisiert. Man kann Zeitblöcke definieren, Kalender färben, Benachrichtigungen stumm schalten und trotzdem jeden Tag das Gefühl haben, nichts wirklich zu Ende gebracht zu haben. Weil das Problem nicht die Organisation ist, sondern die schiere Menge und die Gleichzeitigkeit der Erwartungen.

Und vielleicht ist genau das der Punkt, über den man ehrlicher sprechen müsste: Wenn man fünf unterschiedliche Spezialisten in einer Person vereint, dann ist das nicht „eine Stelle“. Es ist die Verantwortung von fünf Rollen, die irgendwo zusammengezogen wurde. In größeren Unternehmen sind das separate Abteilungen mit eigenen Budgets, eigenen Teamleitern und eigenen Zielen. Ein Infrastruktur-Team, das sich um Server und Netzwerk kümmert. Ein Entwicklungsteam, das Anwendungen baut. Ein Support-Team, das Tickets bearbeitet. Ein Sicherheitsteam, das Audits durchführt. Und eine Digitalstrategie-Abteilung, die das Ganze zusammendenkt. Im Mittelstand ist das eine Person. Vielleicht zwei, wenn es gut läuft.

Die meisten IT-Leute im Mittelstand, die ich kenne, haben gelernt, damit umzugehen. Sie priorisieren, schieben Themen, fangen Brände ab, bevor sie ausbrechen. Manche haben ein System dafür entwickelt, andere machen es aus dem Bauch heraus. Aber es gibt diesen schleichenden Effekt, den alle kennen: Die strategischen Themen — die, die das Unternehmen langfristig weiterbringen würden — bleiben liegen. Die Modernisierung des Shops, die Migration auf eine neue Serverversion, die Automatisierung von Prozessen, die immer noch per E-Mail und Excel laufen. Nicht weil diese Themen unwichtig sind, sondern weil das Tagesgeschäft immer lauter schreit. Und irgendwann hat man sich daran gewöhnt, dass die wichtigen Dinge nie drankommen. Das ist der Moment, in dem es gefährlich wird — nicht für die Person, sondern für das Unternehmen.

Was helfen würde

Ich erwarte nicht, dass jedes mittelständische Unternehmen eine eigene IT-Abteilung aufbaut. Dafür fehlen oft Budget und Bedarf. Aber was helfen würde, ist ein realistisches Bild davon, was „IT“ eigentlich bedeutet. Nicht als Stellenbeschreibung auf einem Blatt Papier, sondern als ehrliche Einschätzung der Anforderungen, die damit verbunden sind. Und das fängt schon bei der Frage an, wie man die Rolle definiert — ist es eine Supportstelle mit ein bisschen Entwicklung dazu? Oder ist es eine Entwicklerstelle, die auch mal ein Druckerproblem löst? Das sind fundamental verschiedene Jobs, und die Antwort bestimmt, was man realistisch erwarten kann.

Wenn jemand gleichzeitig entwickeln, administrieren und supporten soll, dann braucht diese Person geschützte Zeitblöcke für Fokusarbeit. Dann darf es Zeiten geben, in denen das Telefon nicht sofort beantwortet wird. Dann muss akzeptiert werden, dass nicht alles gleichzeitig geht — und dass Priorisierung manchmal bedeutet, dass ein Thema warten muss. Nicht weil es unwichtig ist, sondern weil gerade etwas Wichtigeres brennt. Und ja, manchmal bedeutet das auch, dass jemand einen halben Tag auf eine Antwort warten muss. Das ist kein Zeichen von Faulheit. Das ist das Ergebnis einer Priorisierungsentscheidung, die jemand treffen muss, weil es eben doch nur eine Person ist.

Und es würde helfen, wenn die Wertschätzung dieser Arbeit sich nicht nur in einem „Danke, läuft ja“ äußert, sondern auch in der Art, wie die Rolle behandelt und vergütet wird. Wer die digitale Infrastruktur eines ganzen Unternehmens verantwortet, sollte nicht das Gefühl haben müssen, dass seine Arbeit weniger zählt, nur weil sie im Hintergrund passiert.

Ehrlich gesagt würde es schon reichen, wenn öfter mal jemand fragt: „Was brauchst du, damit das funktioniert?“ statt „Wann ist das fertig?“

Wenn man fünf Spezialisten in einer Person vereint, ist das nicht eine Stelle. Es ist die Verantwortung von fünf Rollen — und eigentlich kann man nicht erwarten, dass das wie eine einzelne Position behandelt wird.

Genau darüber wird viel zu selten gesprochen. Nicht als Beschwerde, nicht als Vorwurf an irgendjemanden. Sondern als Realität, die man anerkennen muss, wenn man möchte, dass die IT im eigenen Unternehmen langfristig funktioniert — und nicht nur so lange, bis die eine Person, die alles zusammenhält, irgendwann nicht mehr kann. Oder geht. Und dann steht man da und merkt, dass niemand sonst weiß, wie der Server konfiguriert ist, wo die Zugangsdaten liegen, warum der Cronjob um drei Uhr nachts läuft und was passiert, wenn man ihn abschaltet.

Vielleicht ist das der unbequemste Gedanke von allen: Dass die Person, die am wenigsten sichtbar ist, oft diejenige ist, deren Ausfall am meisten wehtun würde.