Business Engineering

Weltweite Konkurrenz, extremer Kostendruck und immer kürzere Produktentwicklungszyklen charakterisieren die heutigen Märkte. Auch oder vor allem die IT-Organisationen müssen diesem Wandel Rechnung tragen und eine Neuausrichtung finden. Die IT-Abteilung wird von Fachbereichen oft als langsam, kompliziert und bedenkenüberladen wahrgenommen und erntet bei Rückfragen, die in vielen Fällen durchaus ihre Berechtigung haben, eher Unverständnis. Mit Scrum oder scrum-ähnlichen agilen Software-Entwicklungsprozessen geht die IT neue Wege, die eine Antwort geben sollen auf die trägen und Wasserfall ähnlichen Realisierungsprozesse. In der Praxis führt dieser Schritt nicht selten zu (neuen) Konflikten. Während die IT Agilität und Selbstverantwortliches Arbeiten groß schreibt und eine hohe Erwartungshaltung mit ihrer Beauftragung verbindet, stehen die Fachbereiche kopfschüttelnd und voller Unverständnis da und erwidern: „dabei ist das doch ganz einfach, warum soll das jetzt 20 PT dauern und überhaupt, wie viele Rückfragen will man jetzt noch stellen“?

Trotz Scrum, Kanban oder anderen agilen Entwicklungsprozessen bleibt der Konflikt oftmals der gleiche - die Herausforderung, ein gemeinsames Verständnis zwischen Fachbereich und Entwicklungsabteilung herzustellen, ist sehr groß. Die Denkweise und die Charaktere der jeweiligen Abteilungen sind unterschiedlich und die Sprache ist selten die gleiche.

Die Idee

Das Business Engineering versteht sich im ersten Schritt als ein Übersetzer zwischen Welten. Der Business Engineer versteht den Fachbereich, dessen Vorstellungen, Ideen und Bedenken. Aber gleichzeitig spricht er die Sprache der IT und sieht die teilweise heiklen Folgen, wenn die Anforderungen des Fachbereichs einfach „so“ umgesetzt werden. Er weiß, dass gewisse Rahmenbedingungen berücksichtigt werden müssen, um zukunftssichere IT zu realisieren, und hat gelernt, dass, obwohl der Fachbereich auf solche Mittel und langfristige Überlegungen vordergründig keinen Wert legt, trotzdem in deren Sinne gehandelt wird, wenn ein gutes und wirtschaftlich relevantes Maß zwischen time to market und betrieblichen Aspekten gefunden wird.

Klassische Projektmanagementmethoden in Kombination mit Scrum reichen dafür alleine nicht aus; die Anforderungen aus dem Business dürfen nicht mehr nur 1:1 von der IT umgesetzt werden; es müssen gleichzeitig Aufbau und Verankerung eines Business-Fundaments in der IT zustande kommen. Moderne IT-Organisationen zeichnen sich dadurch aus, dass sie über dieses Fundament verfügen und damit in der Lage sind, das Business ihrer Kunden pro-aktiv mit zu gestalten. 

Primär richtet sich das Business Engineering auf die langfristige IT-seitige Abbildung der zugrundeliegenden Geschäftsprozesse der betreffenden Firma. Dabei werden die übergreifenden Geschäftsprozessketten an einigen fachlich logischen Stellen aufgeteilt und der Verantwortung von sogenannten Competence Centern (Teams), bestehend aus Vertretern der Fachlichkeit und mehreren Entwicklern übertragen. Ziel ist es, das fachliche und das technische Know How zu dedizierten Teilfachlichkeiten zu bündeln und so zu entwickeln, dass im Laufe der Zeit eine höchst effektive und effiziente Projektumsetzung möglich wird.

Durch die Konzentration auf die IT-seitige Abbildung der Geschäftsprozesse ist sichergestellt, dass die damit einhergehenden Aufwände an IT-Investitionen ein hohes Maß an Zukunftssicherheit besitzen, weil die Kerngeschäftsprozesse einer Firma sich nicht so häufig ändern. Eine neue Anforderung aus einem Fachbereich (Featurewunsch) wird im Idealfall so übersetzt, dass sie als Weiterentwicklung eines bestehenden Geschäftsprozesses realisiert werden kann und zukünftig weitere Anforderungen bedienen kann.

Der Auftrag

Die Grundlagen eines Auftrags werden durch den Kontext und die Prozesse des Kunden / des Fachbereichs beschrieben. Der Kontext ergibt sich aus den spezifischen Anforderungen des Kunden, welche prägnanten Einflussfaktoren wie Marktbedingungen, finanziellen Ressourcen, Qualität und Time to Market unterliegen. Diesen kundenspezifischen Kontext gilt es mit seinen Anforderungen in die IT-Welt zu übertragen. Hier gelten andere Einflusskriterien – Sicherheit, Skalierbarkeit, Datenintegration und Nachhaltigkeit im Bezug auf die funktionale Basis. 

"Neu schneiden" des Auftrags

Dieser Übergang von der Kunden- in die IT-Welt muss so ausgearbeitet werden, dass eine strukturierte Interpretation beider Welten gewährleistet ist. In fast allen Fällen ist es ratsam, den ursprünglichen Kundenauftrag „neu zu schneiden“ und in einen IT-Auftrag zu überführen, dabei eventuell mehrere Kundenaufträge zu einem Auftrag bündelnd. Entscheidend ist hierbei, dass der Kunde das Auftragsziel explizit beschreibt, nicht den Weg dorthin. Dieses Ziel aus dem Kundenkontext muss daraufhin in ein Ziel im IT-Kontext transformiert bzw. „neu geschnitten“ werden. Gleichfalls muss die Basisstruktur des IT-Gerüsts so konzeptioniert sein, dass stets Änderungen innerhalb der Erweiterung möglich sind, welche jederzeit an die Basis angebaut werden können. Die erfolgreiche Transformation schlägt die Brücke zwischen den beiden Kontext-Welten und ist als Ziel der Auftragsphase zu betrachten.

Das Ziel des Auftrags

In der Auftragsphase ist es daher die Aufgabe des Business Engineers, welcher die fachkompetente Schnittstelle zwischen Kunde und Technik verkörpert, das Ziel des Kunden inhaltlich zu verstehen, sowie fachbezogen realistisch einzuschätzen. Gegebenenfalls kann der Business Engineer hier weitere Vorschläge gegenüber dem Kunden darlegen. Ist das Ziel definiert, wird eine mögliche Strategie zur Zielerreichung erörtert. Diese enthält einen groben Ausblick auf die zu ändernden Geschäftsprozesse. Der Business Engineer muss also die Geschäftsprozesse des Kunden sehr genau kennen und verstehen, um mit ihm gemeinsam das Ziel klar zu definieren, die Machbarkeitsstudie zu erstellen und im nächsten Schritt das Fachkonzept für die tatsächliche Umsetzung erarbeiten zu können.

Im Falle eines agilen Entwicklungsprozesses wird der Auftrag des Kunden in dieser Phase vom Business Engineer und seinem Team so geschnitten, dass ein Scrum Backlog sinnvoll und zielführend gefüllt werden kann. Durch das frühzeitige Zusammenführen von Fachlichkeit und Technik entstehen entscheidende Vorteile. 

Innovationskraft

Der Abgleich von fachlichen Anforderungen und technischen Möglichkeiten eröffnet ein großes Potenzial für einen innovativen Gestaltungsraum. Diese Spielwiese kann genutzt werden, um Möglichkeiten, welche die Technik bietet, aktiv in das Business einfließen zu lassen. Dadurch, dass der Business Engineer beide Seiten (Business und Technik) beherrscht, kann er Vorschläge erarbeiten und nicht selten dem Business neue Möglichkeiten oder Wege aufzeigen. In dieser Konstellation kann das kreative Potential in der IT vom Business Engineer fachlich übersetzt und dem Auftraggeber / Kunden vorgelegt werden. 

Effizienz und Effektivität

Der Abgleich von fachlichen Anforderungen und technischen Möglichkeiten lässt zudem eventuelle Irrwege frühzeitig erkennen und reduziert die Anzahl der Missverständnisse auf ein Minimum. In einer zielführenden Diskussion zwischen dem Fachbereich des Auftraggebers und der IT-Welt des Auftragnehmers kann der Business Engineer potenzielle alternative Wege aufzeigen, und es kann entschieden werden, mit welchem Aufwand welche Zielerreichung sichergestellt werden kann. In vielen Fällen kann bspw. der Implementierungsaufwand minimiert werden, indem das Potential eines bestehenden Systems besser genutzt wird, anstatt eine vergleichbare Funktion an anderer Stelle zu implementieren.

Time to Market

Höhere Effektivität führt zu kürzeren Realisierungsprozessen und zu einer höheren Planungssicherheit. Beides wirkt sich positiv auf den Time to Market aus. Meistens kommt der Kunde mit sehr klaren Vorstellungen im Bezug auf den Fertigstellungszeitpunkt zum Auftraggeber. Nicht immer lassen sich die Vorstellungen des Kunden im vorgeschlagenen Zeitrahmen realisieren. Aufgrund seiner Fähigkeit, Fachlichkeit und Technik zur gleichen Zeit zu betrachten und abzuwägen, kann der Business Engineer jetzt mit dem Kunden in kurzen, agilen und iterativen Schleifen den maximalen Leistungsumfang abstimmen, der sich innerhalb des gesetzten Zeitrahmens realisieren lässt. 

Qualität

Als IT-Consultant mit dem entsprechenden Know-How kann der Business Engineer bereits ganz am Anfang des Prozesses, nämlich beim Auftrag, aktiv Qualitätssicherung betreiben. Als Process Owner schaut der Business Engineer aus Sicht des Geschäftsprozesses auf den Auftrag. Diese Vogelperspektive hilft ihm dabei, Lücken in der Beauftragung zielführend zu schließen oder ggf. nochmals aktiv nach dem Mehrwert des vorliegenden Auftrags zu fragen. Hiermit kann vermieden werden, dass an falschen Aufträgen oder falsch an den richtigen Aufträgen gearbeitet wird. Dies kann die Zukunftssicherheit und damit die Qualität der Systeme sicherstellen.

back Author: Hanno Hensing (2016)