Wann ein Mittelstand-Unternehmen einen Fractional Digital Architect 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.

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. Die Geschäftsführung trifft die Entscheidung, aber sie bekommt vorher eine fundierte Empfehlung statt eines Hochglanz-Verkaufsgesprächs.

Implementierung koordinieren. 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. Nicht selbst alle Schrauben drehen, sondern dafür sorgen, dass die richtigen Schrauben gedreht werden.

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 (etwa bis 80 Mitarbeitende).
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 Bestandsaufnahme: zwei, drei Tage Arbeit, 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 als monatliches Mandat, oder die Erkenntnis, dass die Hausaufgaben erst mal intern gemacht werden müssen.

Was nicht passiert: ein Jahresvertrag ohne Probelauf. Wer mit der Sichtbarkeit eines Architekten nicht klarkommt, sollte das früh merken, nicht nach Monaten.