Organisationen brauchen Software
Für Firmen, Verwaltungen, Institutionen, Clubs, etc. ist Software unternehmenskritisch.
- Bereitstellung von nützlichen und cleveren Services für sich, ihre Kunden und Partner.
- Steigerung der eigenen Produktivität und Qualität.
- Sicherstellung von Transparenz und Compliance (z.B. Nachvollziehbarkeit).
- Und vieles mehr.
Die meisten Software-Projekte laufen aus dem Ruder
Die tiefere Ursache dafür liegt meist nicht bei den Software-Entwicklern —
sondern leider bei den Organisationen selbst.
Typische Probleme solcher Projekte in Organisationen sind:
- Massive Kosten- und Terminüberschreitungen.
- Neuaufstellung oder gar Abbruch von Projekten.
- Untaugliche Ergebnisse (v.a. Software-Lösungen).
- Überforderung und Überlastung des Personals.
- Unzufriedene Mitarbeiter, Kunden und Partner.
- Gewinn- und Reputationsverlust.
- etc.
Die Grundursachen dafür sind:
- Die Prozessse von Organisationen sind unglaublich komplex und funktionieren nur, weil das Personal über jahrelange Erfahrung verfügt und deshalb Unerwartetes bestmöglich handhabt.
- Das macht die Digitalisierung zu einer enormen Herausforderung, die nur von der Fachebene aus gelingen kann — technologiegetriebene Ansätze sind zum Scheitern verurteilt.
- Organisation delegieren Kernaufgaben hoffnungsvoll an Software-Partner, die diese gar nicht wahrnehmen können — leider versuchen sie es dennoch.
- Die Digitalisierungsindustrie ist unreif: sie verfügt kaum über adäquate Werkzeuge und mogelt sich mit Trial-and-Error durch.
Abhilfe: Die Organisation gestaltet und führt ihre Transformation selbst
Die Organisation muss die Verantwortung über ihre eigene Digitalisierung übernehmen und diese selbst gestalten und führen (können).
- Nur die Organisation selbst hat das notwendige, umfassende Fach-, Prozess- und Organisationswissen.
- Software-Entwickler haben meist keine Ahnung davon — und sie sollen Software entwickeln statt Fachspezialisten werden.
- Die Organisation muss für ihre Kernprozesse selbst und kompetent verantwortlich sein (können).
- Digitalisierung ist keine einmalige Angelegenheit, sondern bleibt auch nach einem initialen Projekt eine zentrale Daueraufgabe — Organisationen dürfen ihre Kernprozesse nicht auf unbestimmte Zeit von (externen) Software-Entwicklern bestimmen lassen.
Wie soll das möglich sein?
d-puzzle macht es sich zur Aufgabe, Organisationen mit einer dokumentieren Methode und einem starken, digitalen Tool zu befähigen, ihre Transformation selbst in die Hand zu nehmen.
- Als nachvollziehbare Grundlage haben wir dazu das Semantic Eye Framework entwickelt und bauen dafür zusammen mit Partnern das erste dedizierte, digitale Werkzeug seiner Art.
- Das Tool unterstützt und befähigt das Projekt-Team zu einer neuen Arbeitsweise auf Fachebene, die an die Arbeitsweise in Software-Teams angelehnt ist und von deren Werkzeugen und Erfahrungen profitiert.
- Organisationen lernen das Tool produktiv einzusetzen und übernehmen es zur Dokumentation, Planung und Umsetzung ihrer Prozesse.
- Das Tool bietet erstklassige KI-Unterstützung an. Damit kann auf fachlicher Ebene auf zugängliche Weise das volle Potenzial der Modelle (s.u.) ausgeschöft werden.
Projektvorgehen
Für die Projektabwicklung setzen wir auf ein innovatives, iteratives Projektvorgehen, das bei der Strategie der Organisation beginnt.
Hier ist ein typischer Projektablauf mit seinen wichtigsten Ergebnissen (hervorgehoben):
-
Strategie abholen und verstehen, Auswirkungen abschätzen.
-
Betroffene Fachgebiete identifizieren ➔ Umfang / Scope festlegen.
-
Ist-Situation verstehen & mit relevanten Stakeholders abstimmen ➔ Ist-Modell erstellen.
-
Strategie validieren, ggf. anpassen (lassen).
-
Neue Anforderungen aufnehmen, analysieren & validieren.
-
Technologiekandidaten identifizieren & validieren.
-
Soll-Situation erarbeiten & abstimmen ➔ Soll-Modell erstellen.
-
Umsetzungspartner & -technologien festlegen.
-
Systemarchitektur und -spezifikationen erarbeiten & abstimmen.
-
Migrationspfad / Transformationspfad erarbeiten & abstimmen.
-
Etappiert umsetzen ➔ Realisierung und Einführung der Lösung in Releases.
Bemerkungen
- Die Aktivitäten 3, 4→7, 9→10 und 11 werden am besten iterativ durchlaufen.
- Die ganze Abfolge 1→11 kann und soll iterativ durchlaufen werden.
Was ist daran so innovativ?
Konzeptionelle Ist- und Soll-Modelle sind Kommunikationsinstrumente erster Güte.
Unser Tool befähgt das Team, die enorme Komplexität der Prozesse zu beherrschen.
- Im Gegensatz zu den meisten Projektvorgehen beschränken wir uns nicht darauf, Analysen zu machen und Anforderungen als (Text-) Dokumente niederzuschreiben, und diese an die Software-Teams zu übergeben, damit sie eine Lösung finden und umsetzen.
- Stattdessen verwenden wir ein echt digitales Tool zur Erstellung und Validierung eines kohärenten Modells der aktuellen und der zukünftigen Lösung.
- Wir wollen zuerst in angemessener Breite (Umfang) und Tiefe (Detaillierungsgrad) verstehen, WAS die Organisation heute genau macht, WIE und WARUM sie das tut.
- Daraus erstellen wir ein konzeptionelles1 Ist-Modell der betroffenen Fachgebiete und -prozesse.
- Später erstellen wir ein Zielbild («Wie wollt Ihr in fünf Jahren arbeiten?») und erarbeiten ein konzeptionelles1 Soll-Modell der zukünftigen Lösung.
- Dieses Soll-Modell ist die Basis für alle Spezifikationen und Umsetzungsplanungen. Es entspricht den Bauplänen, wie sie beim Bau eines Hauses, einer Fabrik, eines Motors, etc. angefertigt und eingesetzt werden — seit über 500 Jahren und mit grossem Erfolg.
- Unser einzigartiges Tool übernimmt dabei die zentrale Rolle, die CAD und BIM2 in der Bauindustrie seit über 50 Jahren einnehmen.
- Damit wir dabei kein Luftschloss entwerfen, das sich nicht umsetzen oder nicht finanzieren lässt, integrieren wir von Anfang an Technologie-, Software- und Prozessfachleute3.
- Wir reviewen das Soll-Modell mit allen relevanten Steakholders und passen es an — so lange, bis sich alle einig sind, «So können wir unsere Ziele erfüllen!».
- Zusammen mit den Umsetzungspartnern erstellen wir verbindliche technologiespezifische Systemspezifikationen und überwachen den Umsetzungsprozess.
- Im Gegensatz zu Anforderungen, die nach der Umsetzung generell nicht weitergepflegt werden, werden die Soll-Modelle nach der Umsetzung zum neuen Ist-Modell. Sie werden bei Erweiterungen und Anpassungen zu neuen Soll-Modellen entwickelt und leben so lange wie die Prozesse selbst. Genau wie Baupläne.
Wir befähigen Organisation, ihre Prozesse und Digitalisierung nachhaltig
und ohne uns aufzustellen.
1 konzeptionell = kohärent und abstrahiert, d.h. durchgängig und zu einem guten Teil unabhängig von der technischen Lösung (wobei wir Menschen mit ihren spezifischen Fähigkeiten auch als Technolgoien betrachten).
2 Computer-Aided Design, Building Integration Model.
3 Dies sind meist nicht die Leute, die später die Lösung umsetzen, denn das Soll-Modell dient auch dazu, Umsetzungspartner zu finden und zu beauftragen.