Wann ein Unternehmen externe digitale Architektur braucht

Die meisten mittelständischen Unternehmen haben kein IT-Problem. Sie haben ein Architektur-Problem.

Die Tools funktionieren. Die Server laufen. E-Mails kommen an. Aber niemand hat das Gesamtbild. Niemand entscheidet, welche Software bleibt und welche geht. Niemand sorgt dafür, dass die Systeme mit dem Wachstum mitwachsen. Diese Lücke füllt klassischerweise ein CIO oder Head of IT. Für ein Unternehmen mit 30 Mitarbeitenden ist das unbezahlbar. Also bleibt die Lücke offen.

Mit KI ist diese Lücke größer geworden, nicht kleiner. Inzwischen gibt es Werkzeuge, die auch in einem kleineren Betrieb echten Hebel haben. Aber jemand muss entscheiden, welcher Anwendungsfall trägt, wo die Daten laufen dürfen und wie das Neue in die bestehenden Systeme passt. Genau das ist Architektur-Arbeit.

Ein Fractional Digital Architect schließt sie. Nicht als externer IT-Dienstleister, der Tickets abarbeitet. Sondern als strategische Funktion, die anteilig eingekauft wird.

Was ein Fractional Digital Architect tut

Drei Dinge:

Übersicht herstellen. Welche Systeme sind im Einsatz, wie hängen sie zusammen, wo liegen die Wahrheits-Quellen. Eine sauber dokumentierte Tool-Landkarte ist die Basis jeder Entscheidung. Sie existiert in den meisten KMU nicht.

Entscheidungen vorbereiten. Welche Software gehört abgelöst, welche bleibt. Wo lohnt sich Integration, wo Migration. Ob ein neues Tool wirklich gebraucht wird oder ob ein bestehendes nur richtig genutzt werden müsste. Ob ein KI-Vorhaben bei Ihnen echten Hebel hat oder nur gerade Hype ist. Die Geschäftsführung trifft die Entscheidung, aber sie bekommt vorher eine fundierte Empfehlung statt eines Hochglanz-Verkaufsgesprächs.

Umsetzung steuern, kritische Teile selbst bauen. Wenn eine Migration ansteht, ist jemand dafür verantwortlich, dass sie nicht im Sande verläuft. Die Dienstleister werden gesteuert, der Zeitplan wird gehalten, die Stolperfallen werden vorhergesehen. Und wo es zählt, wird selbst gebaut: Bei mir enden KI-Anwendungsfälle und Automatisierungen nicht als Konzeptpapier, sondern als laufendes System. Beispiele dafür stehen im Lab.

Wann das Modell passt

Das Modell passt, wenn alle drei Bedingungen erfüllt sind:

1. Das Unternehmen ist groß genug, dass die IT komplex genug für Strategie ist (etwa ab 10 Mitarbeitenden).
2. Das Unternehmen ist klein genug, dass eine Vollzeit-IT-Leitung wirtschaftlich nicht trägt (je nach Struktur bis etwa 300 Mitarbeitende – entscheidend ist, dass es keine eigene IT-Organisation wie im Konzern gibt).
3. Es gibt jemanden auf Geschäftsführungs-Ebene, der bereit ist, IT als strategisches Thema zu behandeln, nicht als lästige Pflicht.

Punkt drei ist der härteste Filter. Wenn die Geschäftsführung erwartet, dass “die IT” sich selbst regelt, funktioniert das Modell nicht. Strategische Entscheidungen lassen sich nicht delegieren, sie lassen sich nur vorbereiten.

Wann das Modell nicht passt

Das Modell passt nicht, wenn:

• Das eigentliche Problem ein konkretes ist (kaputter Drucker, langsames Internet, gehacktes Postfach). Dafür braucht es einen IT-Dienstleister, nicht einen Architekten.
• Das Unternehmen schon einen kompetenten IT-Verantwortlichen intern hat. Dann gibt es niemanden zu ergänzen.
• Die Erwartung ist, dass jemand 24/7 erreichbar ist und Bildschirme repariert. Das ist Help-Desk-Arbeit, nicht Architektur.
• Es geht um den Aufbau einer eigenen Software-Entwicklung. Das ist eine andere Funktion (CTO, Engineering Lead).

Ehrlich gesagt: in zwei von drei Erstgesprächen empfehle ich am Ende etwas anderes als eine Zusammenarbeit. Ein guter Dienstleister vor Ort, ein konkretes Software-Projekt mit einem Spezialisten, eine eigene Person fest einstellen. Wenn das Modell passt, passt es richtig. Wenn nicht, hilft jeder Versuch nichts.

Wie eine Zusammenarbeit beginnt

Im Erstgespräch wird geklärt, ob das Modell passt. Wenn ja, folgt eine kompakte Bestandsaufnahme. Am Ende steht eine dokumentierte Tool-Landkarte plus eine Liste priorisierter Empfehlungen. Daraus entwickelt sich entweder ein konkretes Projekt mit klarem Ende, eine laufende Begleitung, oder die Erkenntnis, dass die Hausaufgaben erst mal intern gemacht werden müssen.

Was nicht passiert: ein großes Mandat ohne Probelauf. Wer mit der Sichtbarkeit eines Architekten nicht klarkommt, sollte das früh merken, nicht erst nach langem Stillstand.