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 (Konzepte, Anforderungen, Software-Lösungen, etc.).
  • Überforderung und Überlastung des Personals.
  • Unzufriedene Mitarbeiter, Kunden und Partner.
  • Gewinn- und Reputationsverlust.
  • etc.

Die Grundursachen sind:

  • Die Prozesse 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, womit der Schaden angerichtet ist.
  • Die Digitalisierungsindustrie ist unreif: sie verfügt selten über tiefes Fach- und Prozesswissen, setzt kaum digitale Werkzeuge ein und mogelt sich mit Trial-and-Error-Vorgehen 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).

  • Digitalisierung ist keine einmalige Angelegenheit — sie bleibt auch nach dem initialen Projekt eine zentrale Daueraufgabe.
  • Die Gestaltung, Dokumentation und Evolution der Organisation, ihrer Prozesse, Produkte und Services ist eine Kernaufgabe der Organisation; sie darf nicht delegiert werden.
  • Die Organisation verfügt über das dazu notwendige, umfassende Fach-, Prozess-, Organisationswissen.
  • Prozess- und Software-Architekten helfen, das Digitalisierungspotential zu eruieren; erstellen kohärente, adäquate Prozess- resp. Systemarchitekturen; und stimmen diese mit allen relevanten Stakeholders ab.
  • Software-Teams sind Technologie-Experten, die Systemspezifikationen mitgestalten und bestmöglich umsetzen; sie sind nicht an der Konzeption der übergreifenden Fachprozesse beteiligt.

Wie soll das möglich sein?

d-puzzle macht es sich zur Aufgabe, Organisationen mit einer dokumentierten 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. Das Framework:
    • stellt die Organisation und ihre organisatorischen Prozesse in den Mittelpunkt.
    • schafft eine gemeinsame und präzise Sprache zwischen Fachbereichen und Technologieexperten.
    • setzt die Organisation in den «Driver's Seat» des Vorhabens.
  • Unser dediziertes, digitales Tool:
    • baut auf einer state-of-the-art Open-Source Plattform auf und kann lokal installiert werden oder im Internet-Browser laufen;
    • unterstützt und befähigt das Projekt-Team zu einer neuen Arbeitsweise auf der Fachebene, die sich an der erfolgreichen Arbeitsweise von Software-Teams orientiert;
    • bietet nativ erstklassige KI-Unterstützung, damit auf fachlicher Ebene das volle Potenzial der Modelle (s.u.) in zugänglicher Weise ausgeschöpft werden kann.
  • Organisationen lernen, das Tool wirksam einzusetzen und übernehmen es zur Dokumentation, Planung und Umsetzung ihrer Prozesse.

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):

  1. Strategie abholen und verstehen, Auswirkungen abschätzen.

  2. Betroffene Fachgebiete identifizieren ➔ Umfang / Scope festlegen.

  3. Ist-Situation verstehen & mit relevanten Stakeholders abstimmen ➔ Ist-Modell erstellen.

  4. Strategie validieren, ggf. anpassen (lassen).

  5. Neue Anforderungen aufnehmen, analysieren & validieren.

  6. Zielbild erarbeiten und Digitalisierungspotential bestimmen.

  7. Technologiekandidaten identifizieren & validieren.

  8. Soll-Situation erarbeiten & abstimmen ➔ Soll-Modell erstellen.

  9. Umsetzungspartner & -technologien nominieren.

  10. Systemarchitektur und -spezifikationen erarbeiten & abstimmen.

  11. Migrationspfad / Transformationspfad erarbeiten & abstimmen.

  12. Etappiert umsetzen ➔ Realisierung und Einführung der Lösung in Releases.

Bemerkungen

  • Die Aktivitäten 3, 4→8, 10→12 werden am besten iterativ oder agil durchlaufen.
  • Die ganze Abfolge 1→12 soll iterativ durchlaufen werden.

Was ist daran so innovativ?

Konzeptionelle Ist- und Soll-Modelle sind Kommunikationsinstrumente erster Güte.
Unser Tool befähigt das Team, die enorme Komplexität der Prozesse zu beherrschen.

  • Im Gegensatz zu den meisten Projektvorgehen beschränken wir uns nicht darauf, Analysen zu erstellen, Anforderungen als (Text-) Dokumente niederzuschreiben, und diese an die Software-Teams zu übergeben, damit sie Lösungen 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.
  • Das Ist-Modell reviewen wir mit allen relevanten Stakeholders und korrigieren es — so lange, bis sich alle einig sind, «So arbeiten wir heute».
  • Nun erstellen wir ein Zielbild («Wie wollt Ihr in fünf Jahren arbeiten?») und erarbeiten ein konzeptionelles1 Soll-Modell der zukünftigen Lösung.
  • Das Soll-Modell reviewen wir mit allen relevanten Stakeholders und adaptieren es — so lange, bis sich alle einig sind, «So können wir die Strategie umsetzen und unsere Ziele erreichen!».
  • Damit wir kein Luftschloss entwerfen, das sich nicht umsetzen oder nicht finanzieren lässt, integrieren wir von Anfang an Technologie-, Software- und Prozessfachleute2.
  • Das 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.
  • Zusammen mit den Umsetzungspartnern erstellen wir verbindliche technologiezentrierte Systemspezifikationen und überwachen den Umsetzungsprozess.
  • Im Gegensatz zu Anforderungen, die nach der Umsetzung generell nicht weitergepflegt werden, wird ein Soll-Modell nach der Umsetzung zum neuen Ist-Modell. Es wird bei Erweiterungen und Anpassungen zu einem neuen Soll-Modell weiterentwickelt und lebt so lange wie die Organisationsprozesse selbst. Genau wie die Baupläne eines Gebäudes oder einer Maschine.

Wir befähigen Organisation, ihre Prozesse und Digitalisierung selbstbestimmt, nachhaltig und schliesslich 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 Technologien betrachten).

2 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.

3 Computer-Aided Design, Building Integration Model.