Capabilities statt Funktionen Business Capabilities: So wird aus fachlichem Bedarf eine klare IT-Anforderung 

Anbieter zum Thema

SVA System Vertrieb Alexander GmbH

CADFEM Germany GmbH

d.velop AG

Kendox AG

Business Capabilities zeigen, was ein Unternehmen wirklich können muss – und helfen, daraus passende IT-Anforderungen abzuleiten. So wird etwa aus CRM-Wünschen ein klarer Bedarf statt eines endlosen Wunschzettels.

„Welche Anforderungen haben Sie an das neue System?“ Mit dieser Frage beginnen viele Einführungsprojekte. Die Antworten sind meist zahlreich: Funktionen des Altsystems, individuelle Arbeitsweisen und  neue Wünsche landen gemeinsam im Anforderungskatalog.

Gerade bei der Einführung von Standard-Software wie einem CRM-System ist das problematisch. Denn bevor Funktionen spezifiziert werden, sollte geklärt sein, was das Unternehmen fachlich können muss. Ein geeigneter Ausgangspunkt dafür sind Business Capabilities.

Eine Business Capability beschreibt eine benötigte fachliche Fähigkeit – zunächst unabhängig davon, welcher Prozess, welche Organisationseinheit oder welches IT-System sie realisiert. Im Solution-Architecture-Vorgehen bilden Capabilities gemeinsam mit Prozessen, Rollen und Informationen deshalb die fachliche Ausgangsbasis.

Gerade bei Standard-Software sollten fachliche Bedarfe nicht automatisch in kundenspezifische Anforderungen übersetzt werden. Stattdessen wird der jeweilige Use Case zunächst mit dem vorgesehenen Produkt durchgespielt.

Karsten Sikora, Leiter des Competence Center „Engineering & Architecture“ bei SVA

Wie wird aus einer Business Capability ein konkreter Bedarf?

Eine klassische Capability Map strukturiert die Fähigkeiten eines Unternehmens. Für die Ableitung von Systemanforderungen reicht die reine Landkarte jedoch häufig nicht aus. Eine Capability wie „Lead prüfen und validieren“ sagt noch wenig darüber aus, welche Informationen dafür benötigt werden und welches Ergebnis entstehen soll.

Deshalb werden die Capabilities um Informationsobjekte als Input und Output ergänzt.

Bei einer CRM-Einführung kann die Capability „Leads erfassen“ beispielsweise Informationen aus Events, Marketingkampagnen, Zielkundenlisten und Kundenkontakten verarbeiten. Ihr Output ist ein ungeprüfter Lead.

Damit wird aus einer abstrakten Capability Map ein fachliches Modell, das sich mit Stakeholdern vergleichsweise einfach diskutieren lässt. Genau die Kombination aus Capability-Struktur, Prozessen und Informationsobjekten ist Bestandteil der Business-Analyse im zugrunde liegenden Solution-Architecture-Vorgehen. 

Einen vollständigen BPMN-Prozess (Business Process Model and Notation) zu erstellen ist aufwändig und dafür nicht immer erforderlich. Er sollte ergänzt werden, wenn Abläufe, Entscheidungen, Verantwortlichkeiten oder Ausnahmen detaillierter analysiert werden müssen. 

Digitalisierung

CRM-System und KI: Umsatzziele nachhaltig sichern

Wie entsteht daraus eine Systemanforderung?

Die Brücke von der Business- zur IT-Ebene bilden Use Cases. Für jede relevante Capability wird beschrieben, wie Anwender oder andere Systeme mit der zukünftigen Lösung interagieren müssen.

Aus „Lead prüfen und validieren“ können beispielsweise Use Cases wie „Lead auf Vollständigkeit prüfen“, „Compliance-Prüfung durchführen“ oder „Lead zur Bearbeitung freigeben“ entstehen.

Damit ergibt sich eine nachvollziehbare Kette: Capability > Informationsobjekte > Use Case > Systembedarf.

Das ist ein wichtiger Perspektivwechsel. Der Fachbereich muss nicht abstrakt formulieren, welche Funktionen er sich von einem CRM-System wünscht. Stattdessen beschreibt er seine fachliche Arbeit. Das Projektteam kann anschließend untersuchen, wie das zukünftige System diese unterstützt.

Wie unterstützt das Fit to Standard?

Gerade bei Standard-Software sollten fachliche Bedarfe nicht automatisch in kundenspezifische Anforderungen übersetzt werden. Stattdessen wird der jeweilige Use Case zunächst mit dem vorgesehenen Produkt durchgespielt.

Unterstützt der Standard den Use Case ausreichend, besteht kein Grund, daraus eine zusätzliche Implementierungsanforderung abzuleiten. Erst wenn eine fachlich relevante Lücke sichtbar wird, wird diese als Anforderung dokumentiert.

Die zentrale Frage lautet damit nicht mehr: „Welche Funktionen wünschen Sie sich?“, sondern: „Das ist Ihr fachlicher Bedarf. So unterstützt ihn der Standard. Wo reicht das für Sie nicht aus?“

So wird Fit to Standard zu einer methodischen Vorgehensweise und nicht nur zu einem Projektziel. Gleichzeitig lässt sich vermeiden, dass historisch gewachsene Prozesse und Funktionen des Altsystems ungeprüft in die neue Lösung übertragen werden.

Prozesslandschaft

ERP-Systeme – Wandlung zur Prozesslandkarte für KI und Mensch

Warum wird Traceability wichtig?

Mit wachsender Projektgröße genügt es nicht, Capabilities, Use Cases, Anforderungen und Tests in getrennten Dokumenten abzulegen. Entscheidend ist die nachvollziehbare Beziehung zwischen den Artefakten.

Eine mögliche Kette lautet: Capability > Use Case > Anforderung > Testfall > Umsetzung. 

Damit lässt sich in beide Richtungen fragen: Welche Anforderungen resultieren aus einer Capability? Welche Anforderungen besitzen keinen Test? Und umgekehrt: Warum wird eine bestimmte Anpassung des CRM-Systems überhaupt implementiert?

Das zugrunde liegende Requirements-Engineering-Modell behandelt Anforderungen deshalb als eigenständige Artefakte und Beziehungen als gerichtete, auswertbare Verknüpfungen. Dadurch werden beispielsweise fachliche Elemente ohne Anforderung oder Anforderungen ohne Testfall sichtbar. 

Business Capabilities: Wann braucht die Methode ein Tool?

Auf einem Whiteboard funktioniert dieses Modell für wenige Elemente. In realen Projekten entstehen jedoch schnell Dutzende Capabilities, Informationsobjekte, Use Cases, Anforderungen und Tests. Spätestens dann muss die Traceability strukturiert gepflegt und auswertbar werden.

Hier können Architektur- und ALM-Werkzeuge die Methode unterstützen. Ein Beispiel ist ein vorkonfiguriertes Template der SVA in microTOOL objectiF RPM, das Capabilities, Prozesse, Informationsobjekte, Use Cases, Anforderungen und weitere Architekturartefakte in einem Informationsmodell verbindet. Das Solution-Architecture-Modell zeigt diese Durchgängigkeit bis hin zu Systemarchitektur, Tests und Impact-Analysen.