Business Function Modeling – Beherrschbares Anforderungsmanagement für das agile Zeitalter

Eschborn, 20.12.2016

Anforderungsmanagement bewegt sich oft im Detail: selbst für kleine Anwendungen sind oft mehr als eintausend Anforderungen zusammenzutragen, zu analysieren und schriftlich zu dokumentieren. Dazu kommen Themen wie Vollständigkeit, Konsistenz und Abhängigkeiten, ganz zu schweigen von der Abstimmung der detaillierten Beschreibungen mit den Stakeholdern. Hier kann schnell ein halbes Jahr ins Land gehen – Zeit, die man oft nicht hat. Zeitnot ist eine der typischen Herausforderungen in aktuellen Projekten. Vorstudien müssen oft unter enormem Zeitdruck greifbare Ergebnisse liefern, da Markt und Digitalisierung die Unternehmen sonst drohen zu überholen. Hier hilft eine Methode aus der Enterprise Architektur: das Business Function Modeling (BFM). Diese beherrschbare Vorgehensweise erzeugt greifbare Resultate in überschaubarer Zeit und erlaubt es zudem den Granularitätslevel so einzustellen, wie er für das aktuelle Projekt gebraucht wird. Und die Ergebnisse sind eine hervorragende Basis, sowohl für agile Projekte als auch für Ausschreibungen.

Nicht nur der Zeitdruck ist eine Herausforderung: häufig liegen die Anforderungen nicht strukturiert vor und können nur schwer in greifbare Form gebracht werden, da sie in den Köpfen weniger Experten, vieler Stakeholder und im Source Code von Legacy-Systemen existieren. Dazu kommt, dass es meist keinen Überblick über die aktuell schon vorhandene Funktionalität gibt, was es schwierig macht für eine Ausschreibung den fraglichen Gap zu identifizieren.

Anforderungen komplex inkonsistent und meist unstrukturiert

Typisch: Anforderungen in Unordnung

 

Business Function Modeling (BFM) ist eine im Enterprise Architektur Management (EAM) weit verbreitete Methode, welche im Wesentlichen darin besteht, Business Capabilities für Unternehmen zu definieren. Eine Business Capability ist in der „reinen Lehre“ eine Fähigkeit, die das Unternehmen besitzen muss, um seine Geschäfte durchführen zu können. Für eine Airline, können z.B. „Tickets verkaufen“, „Personal ausbilden“ und „Flugplan erstellen“ solche Fähigkeiten sein. Für ein Softwaresystem ist diese Granularität natürlich viel zu grob (allein bei „Personal ausbilden“ kommen umgekehrt viele verschiedene Systeme zum Einsatz), so dass man den Scope eine Business Capability im Rahmen eines Softwareprojekts neu definiere muss. So hat es sich als praktikabel erwiesen, für ein Projekt von einer Menge von 5-15 Business Capabilities auszugehen – je nach Größe und Umfang des Projekts. Jetzt sprechen wir von Business Capabilities wie „Preise berechnen“, „Angebote anzeigen“ und „Bezahlung durchführen“. Diese „projektbezogenen“ Business Capabilities findet man z.B. wenn man den übergeordneten Prozess betrachtet, der für das fragliche Softwaresystem relevant ist, bzw. von ihm abgedeckt wird (z.B. ein Verkaufsprozess). Die groben Aktivitäten dieses Prozesses bilden die Business Capabilities.

Tatsächlich sind die Business Capabilities jedoch nicht das wesentliche an dieser Methode. Wie der Name schon sagt, geht es um die Business Function; diese müssen wir finden. Eine Business Function ist nun eine partielle Funktionalität, die das fragliche Softwaresystem besitzen muss, um seine Business Capability zu erfüllen. Auch hier hilft es, zunächst prozessual zu denken und zu überlegen, in welche Teilschritte eine Business Capability zerlegt werden kann. „Preis berechnen“ könnte z.B. in die Schritte „Reiseparameter erfassen“, „Tarif finden“, „Personalisierung anwenden“, „Ermäßigungen anwenden“ und „Preis kommunizieren“ zerfallen. Diese Schritte sind die Business Functions. Typischerweise lässt sich ein Softwaresystem durch 100-200 Business Functions vollständig beschreiben.

Wichtig ist, dass die Fachlichkeit des Systems vollständig durch die Business Functions erfasst wird. Wir müssen also sicherstellen, dass keine Funktion vergessen wird. Daher ist es notwendig, möglichst viele Quellen für Business Functions zu aktivieren und ihren Input zu nutzen. Nach der Erfahrung des Autors gibt es 7 Quellen für Business Functions:

  • Business Capabilities und deren Teilschritte
  • Stärken des Ist-Systems
  • Schwächen des Ist-Systems (Pain Points)
  • Nicht-funktionale Anforderungen
  • Ausschreibungen
  • Strategie des Unternehmens
  • Inspiration (z.B. durch Market Leader)

Nicht alle dieser Quellen können in jedem Projekt vollumfänglich genutzt werden – man sollte aber daran denken.Nicht zu unterschätzen sind vor allem die „Pain Points“, also die Schwächen des Ist-Systems, die meist auf fehlende Business Functions hindeuten. Die Business Capabilities – mit denen wir ursprünglich gestartet waren – sind letztlich auch nur ein Vehikel, um Business Functions zu finden, und daher am Ende von untergeordneter Bedeutung.

 

Die 7 Quellen der Businss Functions

Die 7 Quellen der Business Functions

 

Das „Finden“ der Business Functions (mit den o.a. 7 Quellen) generiert im Wesentlichen eine Bezeichnung für jede Funktion sowie einen Bezug auf eine oder mehrere der Business Capabilities (Mehrfachbezug ist erlaubt). Häufig gibt es unter den beteiligten Personen aber noch unterschiedliche Vorstellungen über die wirkliche Bedeutung (die „Funktion“) der Business Function. Offensichtlich ist dies der Kern der Sache und sollte daher bewusst adressiert werden: es ist absolut notwendig, ein gemeinsames Verständnis über die Business Functions zu erhalten, denn sonst wird jede weitere Diskussion extrem erschwert (und auch jede weitere auf den Business Functions aufbauende Aktivität). Als Best Practice kann der Autor empfehlen, die Business Functions in kleinen Gruppen (bis 5 Personen) zu bearbeiten. In der Diskussion klärt sich so manches Missverständnis und es finden sich gemeinschaftliche Vorstellungen und Definitionen.

Die Dokumentation der Business Functions ist einfach und geschieht am besten unter Nutzung eines klar strukturierten Templates in Prosa. Idealerweise nutzt man dazu ein Wiki oder ein ähnliches Tool, es geht aber auch mit Office Produkten. Das Template sollte neben der „Beschreibung“, welche die Business Function erläutert, vor allem die Bereiche „Vorbedingungen“ und „Nachbedingungen“ aufweisen, da durch sie wesentliche Einschränkungen und Annahmen dokumentiert werden. Wichtig ist auch der Abschnitt „Business Nutzen“, der darlegen soll, warum wir diese Business Function – aus Sicht des Business – brauchen. Ist dieser Abschnitt leer, ist zu überlegen, ob die Business Function überhaupt benötigt wird.

 

Eine Landkarte der Funktionalität

Eine Landkarte der Funktionalität

 

Der große Vorteil an dieser Methode ist, dass man den Detailgrad auf einen für das jeweilige Projekt sinnvolles Maß einstellen kann, während man dennoch eine vollständige Überdeckung der Fachlichkeit erreicht. Gerade für Vorstudien ist eine bis ins feinste Detail ausgearbeitete Anforderungsdefinition gar nicht sinnvoll, schon gar nicht, wenn darauf eine agile Entwicklung beginnen soll. Mit vertretbarem Aufwand und mit beherrschbarer Vorgehensweise entwickelt man mit Business Function Modeling eine komplette „Landkarte“ der Funktionalität des gewünschten Systems – ohne sich im Detail zu verlieren. Die Landkarte ist ein großartiges Hilfsmittel für alle darauf folgenden Aktivitäten, wie Diskussionen zu fachlichen „Hot Spots“ oder zur Organisation von Folgeprojekten. Auch eine logische Architektur lässt sich ableiten. In agilen Projekte können die User Stories dann unmittelbar aus den Business Functions heruntergebrochen werden.

Autor: Juri Urbainczyk

 

Kontakt

Nicole Heyne

Marketing

Person_Bild

Telefon +49 6196 80269-28
E-Mail senden