Navigation öffnen Navigation öffnen

Erfolgreich durch den Anforderungsdschungel navigieren

24.10.2023

Sind Standards und Best Practices besser als andere Ansätze? Welche Grundlagen bestehen dazu? Welche Konsequenzen auf den Projektverlauf hat die Anforderungsermittlung? Wie gelingt es, erfolgreich durch den Anforderungsdschungel zu navigieren?

Daniel Frei (Autor)

Mein LinkedIn-Beitrag zu den Chancen und Risiken einer Standardlösung wurde mehrfach kommentiert. Es ist schön zu sehen, wie dieser fachliche Austausch auch über Social Media funktioniert. Hier eine der Reaktionen in gekürzter Form:

  • ... Deine Einschätzung teile ich aus der eigenen ERP-Projekterfahrung. Da heute Standard nicht mehr so zieht, wird es gerne Best Practice genannt. Das Ergebnis ist dasselbe. Customizing nahe am Standard, wie von den Kollegen in den Kommentaren bereits dargelegt, erachte ich als sinnvollen Weg. ...

Das Wort "best practice" hat mich positiv getriggert. In meinem Umfeld werden die Begriffe "Standard" und "Best Practice" hin und wieder verwendet. Das hat mich zu diesem Beitrag motiviert.

 

Professionelle, iterative Anforderungsermittlung

Stellen Sie sich ein Rad vor. Mit diesem Rad steuern Sie durch einen Dschungel von Anforderungen. Sie steuern so gut, wie Sie auf Grundlagen und Erfahrungen zurückgreifen können. Nennen wir es Navigation. Auf einer Rennstrecke steuern Sie anders als auf einer Nebenstrasse, im dichten Stadtverkehr anders als auf einer Bergstrecke.

 

1. die Anforderungen bestehen bereits

Diese Anforderungen können aus bereits erstellten oder von Dritten zur Verfügung gestellten Anforderungskatalogen abgeleitet werden. Eine weitere Quelle sind hierzu gesetzliche Rahmenbedingungen. Anforderungen sind bereits dokumentiert und an vielen vergleichbaren Orten funktionsfähig im Einsatz. Es gibt viele 
sehr gute und direkt vergleichbare Referenzen. Die Anforderungen unterstützen etablierte Handlungsempfehlungen und bauen auf bekannten und gesicherten Prozessen auf.

 Beispiele: 

  • Rechtsgrundlagen 
  • Kooperationsverträge 
  • EN, ISO und weitere Normen 
  • Vorgaben aus der Branche
  • Technische Dokumentationen, bspw. (verbindliche) Schnittstellenbeschreibungen

 

2. die Anforderungen sind teilweise bereits vorhanden

Diese Anforderungen lassen sich aus standardisierten Prozessen ableiten. Sie sind gut dokumentiert und werden teilweise bereits funktionsfähig eingesetzt. Die Anforderungen unterstützen mehrere Lösungsansätze. Die Lösungswege sind den zukünftigen Lösungsanbietern bekannt.

Beispiele: 

  • Betriebssicheres Rechenzentrum 
  • Integration bekannter Drittsystemen 
  • Informationssicherheit 
  • Verfügbarkeitsanforderungen an das System oder einzelne Komponenten davon
  • Zahlreiche fachliche Prozesse

 

3. die Anforderungen können ermittelt und dokumentiert werden

Teilweise bestehen bereits Lösungsansätze. Jedoch können die Prioritäten noch mehrfach ändern. Details und Features können ergänzt, präzisiert oder auch vollständig angepasst werden. Die optimierten Abläufe werden gemeinsam 
erarbeitet, entwickelt und getestet. Sowohl Kunde wie Lösungsanbieter steuern 
das Projekt auf Sicht und mit erhöhter Flexibilität.

Beispiele: 

  • Individuelle Entwicklungen
  • Einsatz neuer technologischer Möglichkeiten 
  • Durchgängigkeit von Prozessen, auch über mehrere Systeme hinweg
  • Integration von neuen Drittsystemen, resp. Modulen 
  • Erweiterter Datenaustausch mit Lieferanten, Kunden und Partnern
  • Aufbau und Entwicklung auf der Basis bestehender Frameworks

 

4. die Anforderungen sind neu oder nur unvollständig erkennbar

Das Vorgehen zielt auf frühzeitige Informationsbeschaffung und kontinuierliche Reflexion. Frühe Prototypen für einzelne systemrelevante Module und/oder Prozesse tragen wesentlich zur Definition der Anforderungen bei. Sowohl der Kunde als auch die Lösungsanbieter steuern das Projekt auf Sicht und mit sehr hoher Flexibilität. 

Beispiele: 

  • Einsatz neuester Technologien 
  • Neue Services, Produkte und Lösungen
  • Produktvision erstellen und sich dieser mit "try and error" annähern

 

Navigation im Anforderungsdschungel

Steuerrad: ein Hilfsmittel zur Navigation

Die passende Methode hängt auch von der jeweiligen Planbarkeit ab. Die Planbarkeit der Anforderungen nimmt von Gruppe 1 bis 4 stetig ab. Oder anders ausgedrückt, die Nicht-Planbarkeit steigt mit jedem Übergang von Gruppe 1 bis 4. 

Steuerrad mit vier Einstellungen

Einfache und komplizierte Elemente können mit bestehendem Wissen (dies wird oft auch best practice und good practice genannt) bearbeitet werden

1. einfache Elemente

  • setzen Sie hier auf vertrautes und geprüftes
  • gehen Sie klassisch strukturiert und geplant vor
  • referenzieren Sie auf Normen, Vorschriften, Gesetze oder Standards

2. komplizierte Elemente

  • setzen Sie hier auf nachvollziehbares, bekanntes
  • hier können Sie noch immer klassisch strukturiert vorgehen
  • referenzieren Sie auf bekannte Lösungen, Referenzen und Branchen (-Standards)

 

Komplexe oder sogar chaotische Elemente sind durch sehr viele Interaktionen und Iterationen gemeinsam zu bearbeiten.

3. komplexe Elemente

  • setzen Sie hier auf Kommunikation, teilen Sie Wissenslücken aktiv
  • gehen Sie agil vor
  • akzeptieren Sie, dass Details und Features noch unklar sind
  • prüfen Sie Lösungsansätze, sei es bei anderen Unternehmen oder von mehreren Lösungsanbietern

4. chaotische Elemente

  • hier fehlt "setzen Sie auf ...", da wir von (aktuell noch) unbekannten Lösungen sprechen
  • gehen Sie agil vor
  • akzeptieren Sie, dass Sie aktuell erst Ausschnitte aus den zukünftigen Abläufen erkennen
  • prüfen Sie Lösungsansätze durch Testen, Versuchen, Üben, ...
  • erstellen Sie Prototypen (oder lassen diese erstellen)

 

Die meisten Strecken durch den Anforderungsdschungel enthalten Anforderungen aus mindestens zwei dieser Kategorien. Erfahrungsgemäss sind es vielfach drei davon. Ihre Hände gehören ständig an das Lenkrad. Dies bedeutet, dass Sie mit grosser Wahrscheinlichkeit in eine Sackgasse fahren, wenn Sie lediglich auf ein Element setzen.

 

Die verschiedenen Practices einfach erklärt

Best Practice (beste Praxis)

... sind die besten verfügbaren Vorgehensweisen für einen bestimmten Anwendungsfall. Sie basieren auf den Erfahrungen von Experten und wurden in der Praxis erfolgreich eingesetzt.

Good Practice (gute Praxis)

... sind bewährte Vorgehensweisen, die sich in der Praxis bewährt haben. Sie können Unternehmen dabei helfen, auf bereits bestehenden Ansätzen ihre Prozesse zu optimieren, Kosten zu senken und die Effizienz zu steigern.

Emerging Practice (aufkommende Praxis)

... sind neue Vorgehensweisen, die sich noch in der Entwicklung befinden. Sie sind noch nicht in der Praxis erprobt. Sie bieten das Potential, bestehende Best und Good Practices zu verbessern.

Nouvel Practice (neue Praxis)

... sind innovative Vorgehensweisen, die sich noch in der Anfangsphase befinden. Sie sind noch nicht weit verbreitet. Sie haben das Potenzial, die Art und Weise, wie Unternehmen arbeiten, grundlegend zu verändern.

 

Chancen und Gefahren

Einleitend habe ich auf meinen LinkedIn-Beitrag zu den Chancen und Risiken einer Standardlösung verwiesen. Dort beleuchte ich das Risiko, wenn Standards oder Best-Practice-Lösungen unkritisch übernommen werden. Dies kann dazu führen, dass Unternehmen nicht mehr in der Lage sind, neue Wege zu gehen und sich an Veränderungen anzupassen. Best-Practice-Lösungen basieren auf Erfahrungen aus der Vergangenheit. Sie können daher nicht auf neue Anforderungen und Herausforderungen von Unternehmen übertragen werden. Standardlösungen können zu starr und unflexibel sein, um auf neue Anforderungen zu reagieren. Dies kann zu einem entscheidenden Wettbewerbsnachteil führen. Und noch eine Ergänzung aus der täglichen Praxis: Best-Practice-Lösungen können dazu führen, dass sich Unternehmen zu sehr auf den Standard (und somit die Vergangenheit) konzentrieren. Dies blockiert die Entwicklung neuer Ideen und Innovationen. 

In der Beratungspraxis durchgeführte Retroperspektiven zeigen auf, welches Potential vorhanden ist. Es ist durchaus möglich, dass am Anfang einer Anforderungsermittlung die Vielzahl von "kopierten" und übernommenen Anforderungen Sicherheitsgefühle wecken. In der Retroperspektive stelle ich jedoch fest, dass unnötig "kopierte" Anforderung die Effizienz, die Zusammenarbeit und den Handlungsspielraum einschränken können.  

Um zu verhindern, dass Standardlösungen Innovation, Agilität und Zukunftsorientierung behindern, ist es wichtig, die Lösungen kritisch zu hinterfragen. Fragen Sie sich, welche individuellen Bedürfnisse bestehen und wie Sie diese berücksichtigen.

Research-Ergebnisse
Ergebnis Quelle

CHANCEN

a. Die Studie mit 100 Softwareentwicklern aus 10 Ländern zeigt, dass Best Practice Software Lösungen zu einer Verbesserung der Effizienz um 20 % führen können.

b. Die Studie mit 50 Unternehmen aus Deutschland zeigt, dass Best Practice Software Lösungen zu einer Reduzierung der Kosten um 15 % führen können.

c. Die Studie mit 25 Unternehmen aus der Schweiz zeigt, dass Best Practice Software Lösungen zu einer Steigerung der Wettbewerbsfähigkeit um 10 % führen können.

 

a. Russo und Lindvall (2012)

b. Müller (2018)

c. Kugler (2019)

GEFAHREN

d. Die Studie zeigt, dass Best Practice Software Lösungen in 20 % der Fälle nicht den individuellen Anforderungen der Unternehmen entsprechen.

e. Die Studie zeigt, dass Best Practice Software Lösungen in 15 % der Fälle zu hohen Kosten führen.

f. Die Studie zeigt, dass Best Practice Software Lösungen in 10 % der Fälle nicht an die individuellen Anforderungen der Unternehmen angepasst werden können.

 

d. Müller (2018)

e. Russo und Lindvall (2012)

f. Kugler (2019)

 

 

Zusammenfassung

Nein, Standards und Best Practices sind nicht besser als andere Ansätze. Sie vermitteln jedoch "gefühlte" Sicherheit. Im Beitrag beschreibe ich die verschiedenen Methoden und Ansätze zur Anforderungsermittlung.

Zunächst stelle ich fest, dass Standards und Best Practices eine gute Grundlage für die Anforderungsermittlung bieten können. Sie können dabei helfen, Fehler zu vermeiden. Allerdings sind Standards und Best Practices nicht immer die beste Lösung. In manchen Fällen sind sie zu starr oder unflexibel, um die individuellen Anforderungen zu erfüllen.

Daher empfehle ich einen flexiblen Ansatz zu wählen, der sich an den jeweiligen Anforderungen orientiert. Dabei unterscheide ich vier Kategorien von Anforderungen. Ich betone, dass die Anforderungsermittlung ein iterativer Prozess ist. Die Anforderungen sollten daher regelmässig überprüft und aktualisiert werden.

Fragen und Hinweise für die Praxis:

  • Interessentenanalyse: Wer sind die Stakeholder und welche Anforderungen haben sie?
  • Analyse des Ist-Zustands: Wie funktioniert das System aktuell?
  • Benutzeranalyse: Wie wird das System von den Nutzern eingesetzt?
  • Klarheit über die Ziele und Anforderungen: Die Anforderungsermittlung sorgt dafür, dass alle Beteiligten ein gemeinsames Verständnis der Ziele und Anforderungen haben.
  • Reduzierung von Risiken: Die Anforderungsermittlung hilft, Risiken zu identifizieren und zu minimieren oder zu akzeptieren.
  • Verbesserte Kommunikation: Die Anforderungsermittlung fördert die Kommunikation zwischen den Stakeholdern.
  • Frühzeitig starten: Die Anforderungsermittlung muss frühzeitig im Projekt gestartet werden.
  • Alle Stakeholder einbeziehen: Die Anforderungen aller Stakeholder sollten berücksichtigt werden.
  • Die Anforderungen dokumentieren: Die Anforderungen sollten klar und eindeutig dokumentiert werden.
  • Die Anforderungen regelmässig überprüfen: Die Anforderungen sollten regelmässig überprüft und aktualisiert werden.
  • Umgang mit Informationslücken: Stehen sie dazu, wenn etwas unklar ist. Beschreiben Sie keine Lösungswege und keine Lösungsannahmen. Dokumentieren Sie die Interessen und die Analyse des Problems oder der Herausforderung. Schliessen Sie Informationslücken mit allen verfügbaren Ressourcen, inkl. Marktanalysen, Mitbewerbern, Kunden und insbesondere möglichen Lösungspartnern.