Wenn die IT es einfach nicht versteht

oder warum eine Digitalstrategie eine Übersetzung braucht

Ich meine wir kennen es alle, Berater und Agenturen präsentieren dem Vorstand und der Geschäftsführung Folien, die schöner nicht sein können, Buzzwords und große Visionen und am Ende gibt es eine neue Digitalstrategie.

Wenn das Ganze dann in der IT landet und umgesetzt werden soll, sieht die Realität meist ernüchternd aus. Viele Fragen entstehen und so ganz durchgedacht wars dann meistens leider doch nicht, denn zwischen Business-Zielen, Legacy-Systemen, neuen APIs und AI entstehen meist viele Missverständnisse.

In den letzten 10 Jahren habe ich oft gesehen, wie genau hier das Geld verbrannt wird. Projekte versandeln oder liefern am Ende etwas, das im Alltag keinem hilft. Schade um die Zeit, die Nerven aller Beteiligten und natürlich um das Geld.

Und wie machen wir es besser?

Brücken bauen!

Wir müssen eine Brücke bauen, damit das Management echte Entscheidungen treffen kann und die IT weiß, warum sie gerade dieses Tool baut.

Damit aus der Vision eine echte Lösung wird, müssen wir die Sprache synchronisieren. Hier sind drei Helferlein, die ich in meinen Projekten nutze, um dieses Verständnis zu ermöglichen:

1. Vom Wunschkonzert zum Bauplan:
   Eine Strategie ist oft ein Wunschkonzert: „Wir wollen die Kundenbindung digitalisieren.“ Fein! Aber was heißt das für die IT?
   An genau der Stelle sollte ein Anforderungskatalog entstehen, der von den Leuten im Fachbereich abgesegnet wird. Was muss das System wirklich tun, damit das Business-Ziel erreicht wird?

2. Den Prozess sichtbar machen:
   Statt über abstrakte Architekturen zu philosophieren besser Mal den Prozess im Arbeitsalltag anschauen. Wie fließt ein Auftrag durch die Firma? Wo hakt es in den Programmen? Indem wir diese Prozesse visualisieren, schlagen wir die Brücke: Das Management sieht den geschäftlichen Impact, und die IT versteht den Kontext. Plötzlich reden wir nicht mehr über „Features“, sondern über „Lösungen für echte Probleme“.

3. Einfach mal ausprobieren mit Prototyping & PoC:
   Das beste Werkzeug, um Projekte auf Schiene zu bringen und das Risiko zu senken ist ausprobieren. Wir bauen also ein kleines Testmodell als Proof of Concept. Das zeigt uns sofort, ob die technische Idee überhaupt mit der Strategie vereinbar ist und ob es in der Realität funktioniert.
   Zusätzlich gibt das dem Management die Sicherheit für die große Entscheidung und der IT die Bestätigung, dass sie auf dem richtigen Weg sind.

Entscheidungsvorlagen:

Damit „Ja“ auch „Ja“ bedeutet

Entscheidende brauchen keine IT-Anforderungs-Vorlage-Dokumente, sondern eine Basis, um eine fundierte Entscheidung zu treffen. Ich bereite das für meine Kunden meistens so auf, dass es auf eine Seite passt:

• Optionen: Welche maximal 3 Wege gibt es?

• Nutzen: Was haben wir davon? Also z.B. „geht schneller in Form von Wochenstunden“ oder „Qualität ist besser“ etc.

• Kosten: Was kostet der POC, was kostet die Umsetzung und was kostet es laufend. Außerdem Amortisierung und ROI also wie lang dauert es, bis sich das auszahlt.

• Risiko: Wo liegen die ehrlichen Stolpersteine bei dem Projekt. Was wissen wir nicht.

Es geht um das „Miteinander“

Digitalisierung klappt nicht durch bloßes Wollen, sondern durch echtes Verständnis an der Schnittstelle. Meinen Job als Berater sehe ich genau da, wo die Brücke gebaut werden muss. Wenn die IT-Projekte zur Strategie passen, sind sie kein „notwendiges Übel“ mehr, sondern ein Werkzeug, das einen Betrieb spürbar besser macht.

Ein weiterer nicht unwichtiger Punkt den ich an diese Stelle abschließend erwähnen will ist, dass IT durch z.B. eine Abteilungsleitung oder den/die CTO bei der Strategiefindung am Tisch sitzen sollte. Das Einbeziehen von Anfang an hat nur Vorteile, die ebenfalls oft vergessen werden.

Mehr zu dem Thema hier:

How to Reduce Costs of Software Development Projects
https://biosistemika.com/blog/reduce-costs-of-software-development-projects/

Tight Budgets? That’s Exactly When UX and Requirements Engineering Matter Most
https://medium.com/@federi/tight-budgets-thats-exactly-when-ux-and-requirements-engineering-matter-most-22a5996de2d5

Poor requirements?
https://re-magazine.ireb.org/articles/poor-requirements