Die "agile Geschäftsentwicklung" und darauf abgestimmtes agiles Anforderungsmanagement unterstützt als eine von drei Säulen die Realisierung einer "Agilen Unternehmenskultur 202X" im geschäftlichen und organisatorischen Bereich. Sie löst die überkommene Sichtweise ab, die Agenden der Geschäftsentwicklung als eigenständigen Unternehmensbereich zu sehen, losgelöst von der Bereitstellung und Verarbeitung der dazu erforderlichen Informationen.

Zu beachten: Erfolgreich realisierte intelligente Geschäftprozesse mit ausreichendem Grad an Automatisierung sind selbst als Produkte der geschäftlichen Entwicklung zu betrachten, die intern, sowie über entsprechende Vertriebskanäle auch von externen Partnern genutzt werden, um Endkunden damit realisierte Endprodukte bereit zu stellen.

Ziele auf operativer Ebene:

• Strategische Transformation des Kerngeschäfts und der dazu erforderlichen Anforderungen an intelligente Geschäftprozesse und Produkte unter Berücksichtigung agiler und sonstiger Methoden
• Grundlagen schaffen: Kenntnis vorgegebener Umfeldanforderungen, z.B. Gesetze, Backendsysteme, externe Schnittstellen, Ausarbeitung grob ganularer Domänen, Domänen-Prozesse mit Events und Geschäftsdaten
• Verschmelzung von Fach- und IT-Bereich zu interdisziplinären Teams mit fachlicher Verantwortung: Domänen-, Prozess- und Produkt:-Verantwortliche, Scrum Teams u. Product Owner
• Agiles produktbezogenes Anforderungsmanagement nach Kriterien des Domain- und Test-Driven Designs, "15 Factor App", Benutzer Erfahrung (UX) und der Anforderungen intelligenter Geschäftsprozesse - vgl. Lean UML und Use Case 2.0 und Erweiterte User Stories.
• Systematische eventbasierte KPI Entwicklung und darauf abgestimmte Prozess Automatisierung, Identifikation von Low-Code/No Code Bausteinen
• Agile Kultur erfordert die Berücksichtigung kontinuierlicher, zeitnaher Rückmeldung automatisierte Tests, KPIs und Feedback von Benutzern und Endkunden während der Entwicklung und während der Laufzeit

Ziele auf organisatorischer Ebene:

• Ergänzende Organisationseinheiten für IT-Transformation, Betrieb zugekaufter Produkte und Dienstleistungen: Infrastruktur (IaaS, PaaS) und Software (SaaS)
• Ergänzende Organisationseinheiten für PMO, Programmentwicklung, und für domänenübergreifende Änderungs- und Integrations-Aufgaben
• Ergänzende Organisationseinheiten für die Abstimmung domänenübergreifender KPIs und damit verbundener Strategien und Anforderungen an erforderliche Daten

Die erfolgreiche Transformation in bestehenden und neuen Geschäftsbereichen erfordert im Zeitalter der Digitalisierung eine genaue Kenntnis der aktuell eingeführten Geschäftsprozesse und der in der täglichen Praxis verwendeten Applikationen, Services und Endgeräte Ihrer MitarbeiterInnen, Ihrer Geschäftspartner und Ihrer Endkunden. Diese Informationen sind unverzichtbar für die kontinuierliche Evaluation und Neugestaltung der Prozesse auf allen Ebenen einer Organisation.

Aus Sicht einer prozessorientierten Unternehmenssteuerung ist die laufend aktualisierte Dokumentation bestehender und neu geplanter Geschäftsprozesse und daraus abgeleiteter Anforderungen für interne Abläufe und IT-Services unverzichtbar für die kontinuierliche Evaluation und Verbesserung von Prozesse auf allen Ebenen einer Organisation. Da die Lebensdauer eines "Projektes" sinnvollerweise begrenzt ist, muss diese Dokumentation Projekt- und Produkt- übergreifend angelegt werden, mindestens aber für die Lebesdauer eines geplanten Produktes.

Nur eine im Intranet online verfügbare Prozess- und Anforderungssammlung oder ein Product-Backlog mit entsprechenden Inhalten z.B.  Schnittstellen/API-Dokumentationen und strukturierte Anforderungen (z.B. in UML Notation) taugt als Grundlage für die Wertsicherung bestehender Geschäftsprozesse und damit verbundener digitaler Produkte. Diese Techniken können auch für das agile Umfeld adaptiert werden, siehe z.B. "Erweiterte User Stories".

Das Pflichtenheft - ein überholter Dinosaurier?

Ja und Nein, denn es gibt unverändert wichtige Bestandteile eines "Pflichtenheftes" zur Initiierung von herkömmlichen oder agilen Projekten, die gut in ein (Wegwerf-)Dokument passen. Auf der anderen Seite steht die initiale Sammlung möglichst strukturierter, funktionaler und nicht funktionaler Anforderungen, für die ein Dokument mit begrenzter Lebensdauer nicht geeignet ist, insbesonders im agilen Umfeld.

Der bewährte Ablauf zur Bestellung neuer IT-Lösungen oder zur Bestellung von Anpassungen und Erweiterungen startet mit der kurzen Dokumentation eines Kundenwunsches (Demand) in der Sprache der beteiligten Anwender.

Warnung: Es wird dringend davon abgeraten, Änderungswünsche nur aus Sicht des Managements zu Formulieren, ohne zumindest ausgewählte Benutzer (Keyuser) der betroffenen IT-Systeme einzubeziehen. Die ausgewählten Benutzer müssen in direktem Kontakt mit den Benutzern stehen, die die bestellte Software tagtäglich verwenden oder verwenden werden.

Erstellung eines Lastenheftes mit den Zielen aus Kundensicht

Der Kundenwunsch aus Sicht des Auftraggebers kann anschließend mit Hilfe eines Spezialisten in ein Lastenheft ausgearbeitet werden.

Wünsche und Ziele im Zusammenhang mit der Erstellung neuer Software oder der Erweiterung bestehender Software müssen sowohl aus Sicht des Auftraggebers (vgl. Lastenheft und Angebot) als auch aus Sicht eines Auftragnehmers (vgl. Pflichtenheft) ausformuliert werden. Wünsche sind für die Erstellung von Software nicht hilfreich, aber Sie können mit den nachfolgenden Fragen leicht in "smarte" Ziele umgewandelt werden:

Im Pflichtenheft smarte Ziele abstimmen und festlegen:

• Welche Ergebnisse wünsche ich nach dem Projektabschluss?
• Wie genau können die Ergebnisse überprüft werden? (Testfälle!)
• Bis wann sind die Ergebnisse zu liefern?
• Sind die geforderten Ergebnisse realistisch und andererseits anspruchsvoll genug um ein Projekt zu starten?

Dabei nehmen die beteiligten Personen meist unterschiedliche Rollen ein, die in der Praxis auch eine andere Sprache verwenden.