Prozessanalysen helfen, nützen aber nichts

Ich paraphrasiere den Titel von Dan Ariely’s großartigem Buch „Denken hilft zwar, nützt aber nichts„. Was Denken anbelangt, verweise ich auf sein Buch; zum effektiven Nutzen von Geschäftsprozessanalysen will ich aber meine Erfahrungen und die daraus gezogenen Schlussfolgerungen in diesem Beitrag darstellen.

Wir haben ein Henne-Ei-Problem

„Wir müssen zuerst unsere Soll-Prozesse definieren, denn wir dürfen nicht suboptimale Geschäftsprozesse automatisieren!“, diesen Satz höre ich immer wieder. Völlig richtig ist, dass IT-Projekte Geschäftsprozesse ermöglichen sollen, die optimal auf die Unternehmensziele abgestimmt sind.

Ohne zu wissen, wofür man IT überhaupt einsetzen will, darf man kein IT-Projekt starten. Also startet man eine Geschäftsprozessanalyse ohne Beteiligung der IT, weil man sich ja nicht die Prozesse von der IT vorgeben lassen will. Ich habe schon oft erlebt, dass ein erheblicher Aufwand in solche Analysen investiert wurde, vor allem, wenn man zuerst die Ist-Prozesse im Detail dokumentiert und dann Soll-Prozesse möglichst im gleichen Detaillierungsgrad erarbeitet. Die Enttäuschung war allerdings regelmäßig groß, wenn sich bei der Konkretisierung der Anforderungen an die IT-Anwendungen herausstellt, dass ein Großteil der geforderten Inhalte nicht ohne neuerliche Recherchen und Analysen beantwortet werden kann.

Was sagen die Standards?

PMI definiert im „Business Analysis for Practitioners: A Practice Guide“ folgendes Phasenmodell:

  1. Initiierung: In dieser Phase werden die Ziele und der Umfang der Prozessanalyse festgelegt. Es wird bestimmt, welche Prozesse analysiert werden sollen und welche Stakeholder beteiligt sind.
  2. Anforderungsanalyse: Hier werden die Anforderungen der Stakeholder erfasst und dokumentiert. Techniken wie Interviews, Workshops und Umfragen werden verwendet, um die Bedürfnisse und Erwartungen der Stakeholder zu verstehen.
  3. Prozessmodellierung: Die identifizierten Prozesse werden grafisch dargestellt, um ein besseres Verständnis der Abläufe und ihrer Interaktionen zu ermöglichen. Modellierungstechniken wie BPMN (Business Process Model and Notation) kommen zum Einsatz.
  4. Prozessanalyse: Die Prozesse werden hinsichtlich ihrer Effizienz und Effektivität untersucht. Dies beinhaltet die Identifikation von Engpässen, Redundanzen und Verbesserungspotenzialen.
  5. Prozessdesign: Basierend auf den Analyseergebnissen werden neue oder verbesserte Prozessdesigns entwickelt, die die identifizierten Schwachstellen adressieren.
  6. Implementierung: Die neuen oder verbesserten Prozesse werden in die Organisation eingeführt. Dies kann Schulungen, Anpassungen von IT-Systemen und andere Maßnahmen umfassen.
  7. Überwachung und Kontrolle: Die implementierten Prozesse werden kontinuierlich überwacht und bewertet, um sicherzustellen, dass sie die gewünschten Ergebnisse liefern und um weitere Verbesserungsmöglichkeiten zu identifizieren.

Der Business Process Management Common Body of Knowledge (BPM CBOK) beschreibt einen ähnlichen Lebenszyklus für Geschäftsprozessmanagement mit diesen Phasen:

  1. Prozessplanung und Strategie
  2. Prozessanalyse
  3. Prozessdesign und -modellierung
  4. Prozessimplementierung
  5. Prozessüberwachung und -kontrolle
  6. Prozessverfeinerung und -optimierung.

Der Unterschied besteht vor allem darin, dass PMI naturgemäß den Projektcharakter einer Prozessanalyse stärker akzentiert, während die Association of Business Process Management Professionals International (ABPMP) das Geschäftsprozessmanagement als permanente Aktivität adressiert.

Wann darf, soll oder muss die IT mitreden?

In den Anfängen meiner Projektpraxis dominierte die Aussage, dass man man die Prozesse nicht an die IT-Lösungen anpassen wolle, sondern es nur umgekehrt sein darf. Mittlerweile hat sich das Blatt gewendet. Das Angebot an Standardsoftware ist mittlerweile so groß, dass die Entwicklung von Individualsoftware nach Vorgaben des Business in den meisten Branchen nicht mehr argumentierbar ist. Sowohl die Kosten und die Durchlaufzeit ihrer Entwicklung als auch ihr Beitrag zur Erreichung der Geschäftsziele sind nicht mehr konkurrenzfähig. Zudem ist das Erfolgs- und Kostenrisiko deutlich höher als beim Einsatz von Standardsoftware.

Gerade lese ich in einer Ausschreibung den Satz: „Seitens des Auftraggebers besteht ausdrücklich die Bereitschaft, Prozesse anzupassen, wenn dadurch eine gleichwertige oder bessere Prozessqualität erreicht werden kann und der Anpassungsaufwand der Standardsoftware geringer wird. Diese beiden Aspekte sind im Verlauf der Projektarbeit im Sinne einer Kosten-Nutzen-Analyse abzuwägen.“

Man darf allerdings auch hier nicht von einem Extrem ins Andere verfallen. Es gibt auch unter dieser Prämisse genug zu tun, bevor man sich mit konkreten Softwarelösungen auseinandersetzt.

Vorarbeiten auf Seiten des Business

Das Sammeln von Informationen über den Ist-Zustand kann während der Projektrealisierung viel Zeit ersparen. Das sind die wichtigsten Inhalte, zu denen man am besten ohnehin laufend, spätestens aber beim Start eines IT-Vorhabens Informationen systematisch sammeln sollte:

  • Märkte und Kundensegmente
  • Produkte und Dienstleistungen
  • Geschäftsprozesse (zumindest Prozesslandkarte)
  • Daten
  • Geschäftsregeln
  • Beteiligte Organisationseinheiten und Stakeholder
  • Standorte
  • IT-Systeme (Ist-Situation aus Anwendersicht)
  • Gesetzliche Vorgaben und Compliance-Regelwerke.

Zu jedem dieser Punkte ist eine SWOT-Analyse sinnvoll, um den Änderungsbedarf zu identifizieren und hinsichtlich der Wichtigkeit und Dringlichkeit zu bewerten.

Aber, das ist jetzt die große Einschränkung aus meiner Sicht: Umfang und Detaillierung der Erarbeitung von Soll-Prozessen (Punkt 5 des PMI-Modells bzw. Punkt 3 des BPM CBOK) sollten in dieser Phase nicht zu weit getrieben werden. Es ist durchaus sinnvoll, Soll-Prozesse zu entwerfen, die eine verbesserte Umsetzung der Geschäftsstrategie ermöglichen. Allerdings bringt es wenig, hier zu sehr ins Detail zu gehen, bevor man einen Blick auf die IT-Lösungsoptionen geworfen hat.

Der Blick über den Tellerrand auf vorbildliche Geschäftsprozesse anderer Organisationen und Unternehmen bringt mehr als ein hoher Aufwand für die Detaillierung von Soll-Prozessen auf Grundlage der aktuellen Ist-Situation und der Innen-Sicht.

Wenn man einzelne Geschäftsprozesse schon vorweg im Detail neu konzipiert, dann ist das jedenfalls ein sinnvolles Training für die Herausforderungen der Projektarbeit. Es muss nur allen bewusst sein, dass diese Ergebnisse als Hypothesen zu betrachten sind und im weiteren Verlauf eventuell völlig neu gestaltet werden müssen.

Selbst die unverdächtig erscheinende Empfehlung, sich im Vorfeld eines IT-Projektes über die Ziele und Rahmenbedingungen im Klaren zu sein, ist zu relativieren. Revolutionäre Änderungen des Geschäftsmodells sind in vielen Bereichen erst oder nur mit einer völlig neuartigen IT-Unterstützung machbar. Man bleibt hinter den Möglichkeiten zurück, wenn man ohne Betrachtung der IT-Potenziale Ziele festlegt und Rahmenbedingungen als gegeben nimmt, obwohl sich beides in einem neuen Kontext völlig anders darstellt. Disruptive Änderungen der Geschäftsprozesse ergeben sich fast immer aus neuen Optionen, die aufgrund technischer Innovationen zur Verfügung stehen. Das Internet und E-Commerce sind nicht aufgrund einer Geschäftsprozessanalyse entstanden, gleiches gilt derzeit für die Entwicklungen im Bereich der Künstlichen Intelligenz. KI ist derzeit ein Paradebeispiel für technologiegetriebene Prozessoptimierungen, wobei der Einfluss über die Prozessoptimierung ja weit hinausgeht und vielfach neue Geschäftsmodelle ermöglicht oder gar verlangt.

Vorarbeiten auf Seiten der IT

Die Darstellung aller Aufgaben, die eine kompetente IT-Abteilung (wie immer diese organisatorisch definiert und verankert ist) hier darzustellen, übersteigt den Scope dieses Beitrages. Es übersteigt auch meine inhaltliche Kompetenz. Ich stütze mich in diesem Bereich vorzugsweise auf meinen Freund und Kollegen Wolfgang Keller, der soeben die 4. Auflage seines Buches „IT-Unternehmensarchitektur – Von der Geschäftsstrategie zur optimalen IT-Unterstützung“ veröffentlicht hat.

In den Prozessen „Projektbegleitung“ sowie „Projektprozess“ ist das Zusammenwirken von Business und IT zu verorten. Dass diese Prozesse effektiv und effizient sind, hängt wesentlich davon ab, dass die anderen Prozesse von der IT permanent und professionell exekutiert werden.

Prozesse der IT-Unternehmensarchitektur (W. Keller, a.a.O. S. 394)
Typische Fehlentwicklungen

Unter dem Leitbild der agilen Projektabwicklung wird oft mit IT-Umsetzungen begonnen, ohne dass die notwendigen Grundlagen geschaffen worden sind. Nun habe ich gerade dafür plädiert, gewisse Vorbereitungsaktivität zu reduzieren. Ja, es gibt Aktiväten im Bereich der Prozessanalyse und Prozessoptimierung, die ich aus den dargestellten Gründen zurückschrauben würde. Und es gibt eine ganze Reihe von Aktivitäten, die oft zu kurz kommen (siehe oben).

Dass auch agile Projekte Vorbereitung brauchen habe ich an anderer Stelleschon ausführlich argumentiert und muss es daher nicht weiter ausführen.

Ich beobachte allerdings auch unter agilen Prämissen den Versuch, die Anwender mit immer detaillierteren Anforderungsbeschreibungen quasi festzunageln. Ich hatte schon damit zu kämpfen, dass eine Controllerin die User-Stories „einfrieren“ wollte, weil sonst das Monitoring des Projektfortschrittes nicht möglich sei.

Ebenso habe ich erlebt, dass User-Stories priorisiert werden sollten, obwohl kein Lösungskonzept vorlag, anhand dessen man die Anforderungen hinsichtlich Wichtigkeit, Dringlichkeit, Machbarkeit und Aufwand hätte beurteilen können. Wie komplex das Thema Priorisierung ist, habe ich auch schon an anderer Stellebeschrieben.

Leitlinien für eine gute Praxis

Prozessoptimierung muss sich von Anfang an mit den Möglichkeiten der Informationstechnologie auseinandersetzen, um Leistungspotenziale zu erkennen, die bisher nicht gegeben waren. Es darf weder ein aufbau- noch ein ablauforganisatorisches Konzept finalisiert werden, ohne die technischen Möglichkeiten auf Potenziale für bessere organisatorische Lösungen abzuklopfen.

Aber wie kann das in der Praxis bewältigt werden? Man braucht eine Struktur, in der man diese Flexibilität abhandeln kann. Geeignet dafür ist ein Spiralmodell, das in seinen Grundzügen auf Barry W. Boehm zurückgeht. Dieses Spiralmodell ist ursprünglich im Kontext des Risikomanagements entstanden, mit diesem Vorgehen sollte das Risiko des Scheiterns eines IT-Projektes reduziert werden.

Grundidee des Spiralmodells ist, die unterschiedlichen Themenbereiche immer wieder mit jedes Mal steigendem Detaillierungsgrad zu durchlaufen. Was sind solche Themenbereiche? Es sind die Ziele und Rahmenbedingungen, die Geschäftsprozesse, die eingesetzte Software (Standardsoftware und/oder Individualentwicklung), die zugrunde liegende technische Infrastruktur und natürlich auch die Kosten und der Ressourceneinsatz, der für das Erreichen der gesetzten Ziele notwendig ist.

Nötig ist ein ständiger Dialog zwischen Anwendern und IT. Die Idee, dass Anwender eine Liste von Anforderungen erarbeiten und an die IT übergeben, wird zu keinen besseren Ergebnissen führen, nur weil jetzt Epics, Features und User Stories statt Funktionen in dieser Spezifikation enthalten sind. Man braucht eine Vision für das Geschäftsmodell und die Geschäftsprozesse, in der die Möglichkeiten der IT-Unterstützung bereits berücksichtigt werden. Sicherlich zu Beginn in abstrahierter, möglichst lösungsneutraler Form. Aber durchaus mit Beispielen für mögliche Lösungen aus der Erfahrung der Anwender, auch aufgrund von Erfahrungen in anderen Branchen und im privaten Umfeld. Das kann noch ohne IT-Beteiligung stattfinden, aber je kürzer diese Phase ist, umso besser.

Sobald wie möglich, wird gemeinsam von „Business“ und „IT“ an Lösungen gearbeitet, mit denen die gesetzten Ziele umgesetzt, am besten sogar übertroffen werden können. Aber schon in dieser Phase muss ein Entwurf der Architektur erarbeitet werden und dieser eröffnet eventuell neue Möglichkeiten. Es wird aber auch dazu führen, dass einige Ideen nicht mit vernünftigem Aufwand realisierbar sind und daher verworfen werden müssen. Dann muss der Dialog, die gemeinsame kreative Arbeit, auf dieser veränderten Basis fortgesetzt werden.

Diese Zusammenarbeit endet auch nicht mit dem Start des Projektes. Der/die Product Owner*in kann nicht die einzige Verbindung zwischen der IT und den Anwendern sein, bei jedem größeren Projekt wird dafür ein Team erforderlich sein. Er/sie ist dafür verantwortlich, dass der Dialog, die gemeinsame kreative Arbeit in jeder Phase stattfindet. Die IT ist berechtigt und gefordert, Geschäftsprozesse infrage zu stellen und Vorschläge zu deren Optimierung zu machen, Anwender sind berechtigt und gefordert, die Lösungsvorschläge der IT infrage zu stellen und Vorschläge zu deren Optimierung zu machen.

SAFe betont, dass User Stories keine Anforderungen sind, sondern zitiert Bill Wake, einen der Begründer von Extreme Programming (XP): „Stories act as a ‚pidgin language‘, where both sides (users and developers) can agree enough to work together effectivly“ (S. 209). Solche Mischsprachen sind uns aus vielen Lebensbereichen vertraut, „Denglisch“ ist auch in diesem Text oft vertreten. Von Ron Jeffries, einem anderen Begründer von XP, übernimmt SAFe auch die Charakterisierung von User Stories als „promise for a conversation“ (S. 213). Mit diesem Ansatz, User Stories als ein verbindliches Gesprächsangebot zu sehen, wird die optimale Herangehensweise sehr gut auf den Punkt gebracht.

Terminal Server: Von Time-Sharing zu Cloud-Lösungen

Die Entwicklung der Terminalserver-Technologie erstreckt sich über mehrere Jahrzehnte und ist eng mit dem Fortschritt in der Computer- und Netzwerktechnik verknüpft. Im Folgenden wird die Historie in einzelnen Etappen dargestellt – von den ersten Ideen des Time-Sharing bis hin zu Cloud-basierten Lösungen wie Azure Virtual Desktop und Windows 365.

1. Die Vorläufer (vor 1970): Die Ära der Mainframes und Time-Sharing

  • 1960er:
    • In den 1960er-Jahren entstand das Konzept des Time-Sharing auf Großrechnern (Mainframes). Durch Time-Sharing konnten mehrere Benutzer*innen gleichzeitig auf denselben Computer zugreifen.
    • Die Rechenzeit des Mainframes wurde zwischen den einzelnen Nutzenden aufgeteilt, sodass alle den Eindruck erhielten, exklusiv auf die Ressourcen zugreifen zu können.
    • Die Interaktion erfolgte über einfache Terminals, die nur Ein- und Ausgabegeräte waren und keine eigene Rechenleistung besaßen. Damit war zwar noch kein dedizierter „Terminalserver“ im heutigen Sinn verfügbar, doch das Grundprinzip – zentrale Verarbeitung, dezentrale Nutzung – war bereits geboren.

2. Die ersten Terminal-ähnlichen Systeme (1970er – 1980er)

  • 1970er:
    • Entwicklung spezialisierter Terminals, die über serielle Verbindungen mit Mainframes oder Minicomputern kommunizierten. Ein berühmtes Beispiel ist der VT100 von Digital Equipment Corporation (DEC), der 1978 vorgestellt wurde.
    • Diese „dummen“ Terminals führten keine eigenen Programme aus, sondern dienten als Ein-/Ausgabe-Schnittstelle zum zentralen Rechner.
  • Ende der 1970er / Anfang der 1980er:
    • Das Aufkommen von Minicomputern revolutionierte die IT-Landschaft. Diese kostengünstigeren Systeme unterstützten ebenfalls Time-Sharing und erweiterten das Einsatzspektrum der Terminal-Technologie.
    • Unternehmen konnten nun auf kleineren, weniger teuren Systemen arbeiten, während die Idee des zentralen Betriebs mit dezentralen Zugriffsmöglichkeiten weiter bestand.

3. Die Anfänge des modernen Terminalservers (1980er – 1990er)

  • Mitte der 1980er:
    • Fortschritte in Software und Netzwerktechnik machten erste Terminalserver-ähnliche Lösungen möglich.
    • 1989 wurde Citrix Systems gegründet. Citrix entwickelte im Anschluss bahnbrechende Software wie Multiuser und später WinFrame, mit denen Anwendungen auf einem zentralen Server ausgeführt werden konnten. Die Bildschirmausgabe und Eingaben wurden über das Netzwerk an die jeweiligen Clients gesendet.
    • Das Prinzip, Rechenleistung und Applikationsbetrieb auf einem Host zu bündeln und gleichzeitig mehrere Sitzungen zu unterstützen, legte den Grundstein für moderne Terminalserver-Lösungen.
  • Anfang der 1990er:
    • Weitere Anbieter wie Tektronix stiegen in den Markt ein und boten Terminalserver-Lösungen zur Nutzung von Unix-basierten Anwendungen an.
    • Die Technologie reifte weiter, sodass immer mehr Unternehmen in unterschiedlichen Branchen Terminalserver einsetzten, um zentralisierte IT-Services anzubieten.

4. Der Durchbruch mit Windows Terminal Server (1990er)

  • 1998:
    • Mit der Windows NT 4.0 Terminal Server Edition brachte Microsoft die Terminalserver-Funktionalität direkt in das weit verbreitete Windows-Betriebssystem.
    • Das Remote Desktop Protocol (RDP) wurde als Standardprotokoll eingeführt, um die Kommunikation zwischen Client und Server zu ermöglichen.
    • Dieser Schritt war von großer Tragweite, da Unternehmen, die bislang auf Mainframe- oder Unix-Lösungen angewiesen waren, nun auch im Windows-Umfeld von Terminaldiensten profitieren konnten.

5. Weiterentwicklung und Virtualisierung (2000er)

  • Anfang der 2000er:
    • Microsoft entwickelte die Terminaldienste (Terminal Services) unter Windows 2000 Server und Windows Server 2003 konsequent weiter.
    • Verbesserungen in Leistung, Sicherheit und Verwaltung trugen dazu bei, dass Terminalserver zunehmend in Unternehmen unterschiedlichster Größenordnung Einzug hielten.
  • Mitte der 2000er:
    • Die Virtualisierungstechnologie gewann immer stärker an Bedeutung. Anbieter wie VMware und Microsoft (mit Hyper-V) ermöglichten das gleichzeitige Betreiben mehrerer virtueller Maschinen auf einer physischen Hardware.
    • Diese Entwicklung hatte unmittelbare Auswirkungen auf Terminalserver-Umgebungen: Statt nur einer zentralisierten Windows-Installation konnten Unternehmen nun ganze Serverfarmen virtualisieren und flexibler skalieren.
    • Auch Citrix selbst verknüpfte seine Terminalserver-Lösungen immer enger mit Virtualisierungsstrategien, sodass Unternehmen eine noch bessere Auslastung ihrer Serverressourcen erreichen konnten.

6. Cloud Computing und virtuelle Desktops (2010er – heute)

  • Ab 2010:
    • Das Cloud Computing rückte ins Zentrum des Interesses. Große Anbieter wie Amazon Web Services (AWS), Microsoft Azure und Google Cloud Platform (GCP) etablierten sich mit umfangreichen Infrastructure-as-a-Service-(IaaS)- und Desktop-as-a-Service-(DaaS)-Modellen.
    • Unternehmen lagern ihre IT-Infrastruktur zunehmend in die Cloud aus, um Hardwarekosten und Wartungsaufwand zu reduzieren.
  • 2019:
    • Microsoft stellte Windows Virtual Desktop (mittlerweile in Azure Virtual Desktop umbenannt) vor – eine Komplettlösung zur Desktop- und App-Virtualisierung in der Azure-Cloud.
    • Damit können Organisationen ihren Mitarbeitenden virtuelle Windows-Desktops und -Anwendungen zur Verfügung stellen, ohne sich um physische Server-Hardware kümmern zu müssen.
  • 2021:
    • Mit Windows 365 brachte Microsoft einen „Cloud-PC“-Dienst auf den Markt. Hierbei können Benutzer*innen einen vollwertigen Windows-Desktop in die Cloud „streamen“ und von praktisch jedem internetfähigen Endgerät aus nutzen.
    • Dieser Schritt verdeutlicht, wie sehr sich das Konzept des zentralisierten Arbeitens, das bereits in den 1960er-Jahren mit Time-Sharing begann, inzwischen weiterentwickelt hat.

Zusammenfassung und Ausblick

  1. Vor 1970:
    • Grundlagen durch Time-Sharing auf Großrechnern: Zentrale Rechenleistung, mehrere Nutzer*innen parallel.
  2. 1970er – 1980er:
    • Entwicklung „dummer“ Terminals und vermehrter Einsatz von Minicomputern.
    • Erste terminalähnliche Systeme werden verbreitet eingesetzt.
  3. 1989:
    • Gründung von Citrix, einem Vorreiter im Bereich Terminalserver.
    • Die Idee, mehrere Nutzende per Netzwerk an einen zentralen Server anzubinden, nimmt konkrete Gestalt an.
  4. 1998:
    • Microsoft veröffentlicht Windows NT 4.0 Terminal Server Edition.
    • Integration der Terminalserver-Funktionen in Windows steigert die Verbreitung enorm.
  5. 2000er:
    • Weiterentwicklung der Terminaldienste (Terminal Services) in Windows-Server-Betriebssystemen.
    • Aufkommen der Virtualisierung (VMware, Hyper-V) ermöglicht neue Einsatzszenarien.
  6. 2010er – heute:
    • Cloud Computing wird zum Standard, Desktop-as-a-Service-Lösungen gewinnen an Popularität.
    • Microsoft startet Windows Virtual Desktop (Azure Virtual Desktop) und Windows 365 – zentrale Desktop-Services aus der Cloud.

Über die Jahrzehnte hinweg blieb das Grundprinzip gleich: Anwendungen laufen auf einem zentralen System, während die Anwender*innen nur Ein- und Ausgabesignale senden bzw. empfangen. Was mit Mainframes und „dummen“ Terminals begann, hat sich in Richtung hochgradig skalierbarer Cloud-Lösungen entwickelt. Dieser Wandel zeigt, wie anpassungsfähig das Terminalserver-Konzept ist – und dass die Grundidee der zentralen Anwendungsausführung auch in Zukunft eine wichtige Rolle in der IT spielen wird.

Purple Teaming: die perfekte Fusion für moderne Cybersicherheit

Machen wir uns nichts vor, geht es um Cyberangriffe, kommt kaum ein Unternehmen „vor die Welle“. Zumeist wird lediglich reagiert und essenzielle Sicherheitsmaßnahmen kommen viel zu spät bzw. sie sind schon nicht mehr „state of the art“. Wer nicht nur mit- oder hinterher schwimmen möchte, muss sich zwangsläufig proaktiv an die Bedrohungslandschaft anpassen. Das Purple Teaming hat sich genau dafür als innovative Strategie etabliert. Die Kombination aus Red und Blue Teaming gilt als wegweisend in der IT-Sicherheit. Wir möchten erklären, warum wir das genauso sehen.

Red Teaming: Angriff ist die beste Verteidigung

Red Teams sind die offensive Komponente der Cybersicherheit. Ihre Aufgabe besteht darin, Schwachstellen in IT-Systemen und Prozessen zu identifizieren. Dazu versetzen sie sich in die Denk- und Handlungsweise eines Angreifers. Mit Methoden wie Penetrationstests, Phishing-Simulationen und Exploits ahmen sie reale Angriffe nach. Das Ziel: die vorhandenen Maßnahmen prüfen und Sicherheitslücken aufdecken, bevor Cyberkriminelle es tun. Dieser offensive Ansatz ist unerlässlich, um Einfallstore sichtbar zu machen, aber er hat eine Schwäche. Die Erkenntnisse aus den Angriffssimulationen führen nur dann zu einem besseren Schutz, wenn sie effektiv für eine optimierte Verteidigungsstrategie genutzt werden werden.

Blue Teaming: Wächter an der Verteidigungslinie

Blue Teams bilden das defensive Gegenstück. Sie überwachen Netzwerke, erkennen Bedrohungen und reagieren darauf. Ihr Fokus liegt auf der Prävention und dem Schutz vor Angriffen. Mithilfe von Intrusion-Detection-Systemen, verschiedenster Analysen und Notfallplänen sichern sie IT-Infrastrukturen ab. Doch trotz ihrer zentralen Rolle bleiben Blue Teams oft reaktiv: Sie bekämpfen oft „nur“ bekannte Bedrohungen und optimieren ihre Prozesse erst nach konkreten Vorfällen. Hier fehlt der proaktive Blick auf neue Angriffsmethoden – die Lücke, die das Red Team schließt.

Rot + Blau = Lila

Purple Teaming kombiniert die Stärken beider Welten, indem Red und Blue Team eng zusammenarbeiten. Anstatt ihre Fähigkeiten isoliert einzusetzen, treten sie in einen kontinuierlichen Dialog. Die Angriffssimulation wird direkt mit der Abwehr verknüpft, sodass defensive Strategien in Echtzeit getestet und verbessert werden können. Diese interaktive Feedback-Schleife sorgt nicht nur für schnelleres Lernen, sondern auch für effektivere Sicherheitslösungen. Purple Teaming fördert eine Kultur der Zusammenarbeit, in der Wissen ausgetauscht und Synergien geschaffen werden. Die Teams arbeiten nicht gegeneinander, sondern als Einheit, die Angriffe antizipiert, abwehrt und kontinuierlich dazulernt.

Fazit

Purple Teaming ist die Zukunft der Cybersicherheit und weit mehr als die Summe seiner Teile. Es ist eine Revolution für die Cybersicherheitsstrategie. Die Kombination aus Angriff und Verteidigung ermöglicht einen ganzheitlichen Blick auf die Sicherheitslandschaft eines Unternehmens. Durch die intensive Zusammenarbeit werden nicht nur Prozesse optimiert, sondern auch neue Angriffsvektoren frühzeitig erkannt und entschärft. Das Konzept Purple Teaming steht für Innovation, Effizienz und eine neue Denkweise in der IT-Sicherheit. Unternehmen, die diesen Ansatz verfolgen, gewinnen nicht nur einen robusten Schutzschild, sondern auch die Fähigkeit, den Angreifern immer einen Schritt voraus zu sein.

Unser Tipp:

In einer Welt, die niemals still steht, ist Purple Teaming der Schlüssel, um Cybersicherheitsstrategien auf das nächste Level zu heben. Es ist nicht nur ein Trend, sondern eine Notwendigkeit, um den Herausforderungen der digitalen Ära erfolgreich zu begegnen. Purple Teaming kann nicht weniger als das kontinuierliche Steigern des eigenen Sicherheitsniveaus mit sich bringen, um endlich „vor der Welle“ zu sein.

Das DTS Purple Teaming gehört zu den Besten am Markt. Wir ermöglichen ein separates Red Teaming durch zielgerichtete Cyber Security Assessments, vollumfängliches Blue Teaming durch unsere Top-Experten im 24/7 DTS Security Operations Center und allumfassendes Purple Teaming, integriert in unserem DTS Cockpit als ganzheitliche Security-Operations-Plattform. Sie werden keine Lösungen finden, die professioneller und rund um die Uhr den Reifegrad Ihrer IT-Sicherheit prüfen, Roadmaps und Maßnahmen zur Härtung dieser entwickeln und sukzessiv blinde Flecke beseitigen können – für eine nachhaltige, widerstandsfähige Sicherheitsstrategie.

DTS Red Teaming

Blue Teaming im DTS SOC

Purple Teaming im DTS Cockpit

Die Human Success Platform von Zensai

Zensai: Ausgezeichnet als Gartner® Cool Vendor 2024 im Bereich Digital Workplace Applications

Wir freuen uns, bekanntzugeben, dass unser Partner Zensai als Gartner® 2024 Cool Vendor für seine Human Success Platform ausgezeichnet wurde! 

Warum Zensai im Fokus steht 

Zensai hat die Herausforderungen moderner HR-Lösungen neu interpretiert. Die Plattform bietet nicht nur innovative Funktionen, sondern auch einen revolutionären Ansatz, der schnelle, intelligente und nachhaltige Veränderungen ermöglicht – und das mit minimalem Aufwand. Die Anerkennung durch Gartner® als Cool Vendor 2024 unterstreicht das Engagement von Zensai, Organisationen eine umfassende Lösung für die Integration und Weiterbildung von Mitarbeitenden zu bieten.

Die Einzigartigkeit der Human Success Platform von Zensai

Zensais Human Success Platform hebt sich durch mehrere herausragende Merkmale von anderen HR-Plattformen ab: 

  • KI-gestützt: Die tief integrierte KI unterstützt Unternehmen bei der Leistungsbewertung, der Förderung neuer Fähigkeiten und der Identifizierung von Wachstumschancen. So wird die Mitarbeiterentwicklung effizient und individuell gestaltet.
  • Plug & Play mit Microsoft: Die nahtlose Integration mit Microsoft Teams, SharePoint, Power BI, Viva und Copilot sorgt dafür, dass keine technischen Kopfschmerzen entstehen. Diese Integration erleichtert die Nutzerfreundlichkeit und steigert die Effizienz. 
  • Für den Alltag konzipiert: Ihre Tools für Lernen, Engagement und Leistung (Perform) greifen dort, wo Ihr Team sie täglich braucht. Dies fördert die Technologieakzeptanz und steigert den ROI, da die Mitarbeiter die Tools in ihrem täglichen Arbeitsablauf nutzen können. 
  • Innovation, vereinfacht: Zensai bringt die nächste Generation von HR zum Leben und automatisiert sie, um Ihnen Zeit zu sparen. Dies bedeutet, dass Ihr Team das bekommt, was es braucht – ohne die Komplexität, die oft mit neuen Technologien einhergeht. 

Warum Zensai ein Branchenführer ist

Zensai überzeugt mit drei zentralen Stärken:

  • Innovation, die ihrer Zeit voraus ist: Zensai ermöglicht es ihren Kunden, transformative, proaktive Veränderungen in ihren Organisationen vorzunehmen. Dies zeigt sich in der Art und Weise, wie sie moderne HR-Herausforderungen angehen und lösen. 
  • Einfache Bereitstellung & schnelle Ergebnisse: Zensais Plattform wird von Kunden auf G2 (Plattform für Business und Service Plattform Reviews) für ihre Effizienz und Zugänglichkeit gelobt. Die einfache Bereitstellung und die schnellen Ergebnisse machen sie zu einer bevorzugten Wahl für viele Organisationen. 
  • Eingebaute KI für verbessertes Mitarbeiterwachstum: Zensais KI-Funktionen unterstützen Benutzer dabei, Feedback- und Leistungsbeurteilungsgespräche zu verbessern, Manageraktivitäten zu unterstützen und eine bessere Kompetenzentwicklung zu fördern. Dies führt zu einer insgesamt besseren Mitarbeitererfahrung und -entwicklung. 

Gartner® Cool Vendor für HR

Zensai ist mehr als nur ein Tool – es ist ein Partner, der Unternehmen unterstützt, am Puls der Zeit zu bleiben. Zensai ist die vertrauenswürdige Wahl für Organisationen, die die Integration mit Microsoft Teams, SharePoint und anderen Tools priorisieren. Lesen Sie, warum Gartner® Zensai als Cool Vendor anerkannt hat und erhalten Sie Zugang zum Gartner® Cool Vendors™ Report.

Zensais Erfolgsreferenzen 

Mehr als 5.000 Organisationen vertrauen auf Zensai. Was sind die Gründe dafür? Hier erhalten Sie Auszüge aus einigen ihrer Geschichten: 

  • Flight Centre: „Das Produkt erleichtert leistungsstarke Gespräche über Leistung und Entwicklung – und bietet sofortige Einblicke, wie sich die Menschen fühlen und wie sie besser von ihrem Manager unterstützt werden können.“ 
  • Aston University: „Wir können potenzielle Probleme schnell erkennen, bevor sie eskalieren können. Das hat uns die Sentiment-Analyse ermöglicht.“ 
  • PowerON: „Unsere Mitarbeiter fühlen sich gehört und wertgeschätzt wie nie zuvor. Gespräche zwischen unseren Managern und ihren Teams finden regelmäßig statt und sind zukunftsorientierter.“ 

Fazit: Was bedeutet es für unsere Kunden, dass Zensai ein Gartner® Cool Vendor ist? 

Die Auszeichnung als Gartner® Cool Vendor 2024 bestätigt Zensais Position als führender Anbieter moderner HR-Technologien. Wenn Sie nach einer innovativen, zukunftsorientierten Lösung für Ihre Organisation suchen, ist Zensais Human Success Platform die ideale Wahl für Ihr Unternehmen, um stets auf dem neuesten Stand der HR-Technologie zu sein und von den besten Praktiken und Innovationen zu profitieren. 

edon – electronic donations UG – Digital Management Blog

Gemeinsam mit ihren Kollegen Burak Atmaca, Daniel Ceballos und Thomas Heinze haben Julia Vollendorf, Sarah Liebetanz und Finn Gundlach das Start-up edon – electronic donations UG in Karlsruhe ins Leben gerufen.

Im Fokus der Geschäftsidee des jungen Teams steht die Umsetzung von Nachhaltigkeitsprojekten im E-Commerce. edon entwickelt leicht integrierbare Softwareanwendungen und vernetzt Onlineshops mit den passenden Projektpartnern. Somit unterstützt edon mit seinen Softwareanwendungen Nonprofit-Partner dabei, durch neue und digitale Spendenkanäle eine junge Generation von Spenderinnen und Spendern in ihrem Alltag anzusprechen.

Wie die Gründerinnen und Gründer zu ihrer Geschäftsidee gekommen sind und was sie genau machen – acht Fragen an edon.

Hallo und vielen Dank, dass ihr euch heute Zeit für dieses Interview nehmt. Beschreibt doch bitte kurz wer ihr seid, was ihr macht und was das Besondere an eurer Geschäftsidee ist?

Wir sind das Social Start-up edon, kurz für electronic donations. edon entwickelt digitale Lösungen für Onlineshops, um sich gemeinsam mit seiner Kundschaft sozial und nachhaltig zu engagieren. Der Shop kann aus unterschiedlichen Produkten auswählen und z.B. die Möglichkeit einbinden, selbst ab einem bestimmten Warenkorbwert an ein gewähltes Nonprofit-Projekt zu spenden. Kaufende Personen können sich ebenfalls mit einer Spende beteiligen. Alternativ können Bäume gepflanzt oder ein Klimaschutzbeitrag geleistet werden. Gemeinnützige Projekte, die begünstigt werden sollen, können vor Kooperationsbeginn aus unserem Projektpool mit über 40 Projekten ausgewählt werden, die alle mindestens eines der SDGs (Sustainable Development Goals) unterstützen. Durch unsere Vielfalt an Lösungen und Nonprofit-Partnern können wir also ganz individuell auf die Bedürfnisse und Werte unserer Unternehmenspartner eingehen.

Der größte Stolperstein und der größte Glücksmoment?

Der größte Stolperstein war der Moment, in dem unser damals bisher größter Unternehmenspartner, der uns eine Kooperation zugesagt hatte, aufgrund interner und finanzieller Schwierigkeiten kurzfristig abgesprungen ist. Der größte Glücksmoment hingegen war dann auch genau der Moment, in dem wir mit unserem ersten großen Onlineshop Christ Juweliere, der zu den 100 größten in Deutschland zählt, live gegangen sind und die ersten Spenden getätigt wurden.

Welchen Stellenwert hat das Thema Technologie in eurem Geschäftsmodell und wie stellt ihr hier eine optimale Performance sicher?

Das Thema Technologie hat einen sehr hohen Stellenwert in unserem Unternehmen, da unsere Idee auf Technologie beruht. Unser Ziel ist es, innovative Technologien zu entwickeln, um Gutes tun für Unternehmen einfach zu machen. Die technische Einbindung soll durch unsere API oder Plug-in-Lösungen möglichst einfach und schnell umsetzbar sein. Eine optimale Performance stellen wir durch unsere KPIs sicher, die wir u.a. auch im Rahmen von A/B-Tests regelmäßig tracken und dann optimieren. So erheben wir über unsere Tools natürlich wichtige Daten wie bspw. Conversion Rate, Durchschnittsspende, Customer Lifetime Value, Umsatzsteigerung für Unternehmen mit unseren Tools usw.

Wie bewertet ihr das Rhein-Main-Gebiet als Gründungsstandort?

Sehr gut! Wir haben im Rhein-Main-Gebiet immer sehr viel Unterstützung erfahren und konnten uns von Beginn an in der Gründer:innenszene gut vernetzen, wovon wir sehr profitiert haben.
Insbesondere in Frankfurt haben wir durch unser Stipendium im Social Impact Lab, durch das Netzwerk des Tech Quartiers und durch unsere Förderung durch den Unibator der Goethe Uni viele wertvolle Kontakte zu anderen Start-ups, Gründungsberatung, Mentor:innen und Investor:innen knüpfen können.

Einzelkämpfer oder Teamplayer: Kooperiert ihr mit etablierten Playern oder anderen Startups?

Auf jeden Fall Teamplayer! Unsere Vision ist es, gemeinsam Gutes tun im Alltag leichter zu machen – für Unternehmen als auch für Privatpersonen. Wir sind überzeugt davon, dass wir gemeinsam immer mehr erreichen können und freuen uns deshalb auch immer über wertvolle Partnerschaften und Kooperationspartner, sowohl etablierte Player als auch andere Start-ups. Somit haben wir auch ein großes Netzwerk mit vielen Partnern. Darunter z.B. Klimaschutzagenturen, die uns im Bereich CO2-Kompensation unterstützen oder ein Start-up, das selbst Bäume in Deutschland pflanzt und einen eigenen Klimaförster hat.

Hand aufs Herz – würdet ihr nochmal gründen?

Auf jeden Fall! Die letzten Gründungsjahre als Start-up waren unglaublich spannend und lehrreich! Sicherlich auch nicht immer einfach und manchmal natürlich auch sehr nervenaufreibend, aber auch wenn eine Situation noch so schwierig schien, haben wir als Team immer eine Lösung gefunden, uns weiterentwickelt und eine Menge wichtiger Learnings gehabt.

Ein Klassiker aus jedem Bewerbungsgespräch: Wo seht ihr euch in fünf Jahren?

In fünf Jahren sehen wir uns als etablierte CSR-Agentur in Deutschland als auch im internationalen Kontext, die als Brücke zwischen Unternehmenspartnern und Nonprofit-Partnern fungiert und durch ihre digitalen Lösungen Möglichkeiten bietet, um sich breitflächig sowie effektiv sozial und nachhaltig zu engagieren. Auch unsere Produktpalette wollen wir gerne im Bereich CO2-Kompensation von Produkten erweitern.

Chance oder Showstopper: Welche Auswirkungen hat die Corona-Krise auf das Geschäftsmodell von Edon?

Die Corona-Krise hat negative als auch positive Entwicklungen für unser Unternehmen mit sich gebracht. Zunächst einmal sind einige interessierte Neukunden leider abgesprungen, da sie jetzt schauen mussten, wie sie sich über Wasser halten können. Da der E-Commerce aber insgesamt sehr von der Krise profitiert hat, haben auch bestehende Kooperationen mit Bestandskunden sehr profitiert. Viele Unternehmen haben die Zeit genutzt, um sich zu überlegen, wie sie sich digital als auch in Bezug auf gesellschaftliches, soziales und nachhaltiges Engagement neu aufstellen wollen. Hier kamen unsere Lösungen für viele Shops sehr gelegen.

Vielen Dank für das Gespräch!

Die Rolle der Führung im Projektmanagement

Hier als Podcast in englischer Sprache, generiert von Notebook LM

Ist Projektmanagement ein Supportprozess?

Projektmanagement wird oft als administrative Aufgabe verstanden, ich kenne einige Unternehmen, die diese Leistung als Commodity sehen und regelmäßig per Body-Leasing zukaufen. Bei der Auswahl der Projektmanager wird meist darauf geachtet, dass diese zertifiziert sind, in Deutschland und Österreich ist das oft eine Zertifizierung nach IPMA, international dominiert natürlich die Zertifizierung durch PMI, in einigen Ländern ist PRINCE2 stark vertreten.

Die Professionalisierung des Projektmanagements, die mit diesen Standards und den darauf aufbauenden Zertifizierungen einher geht, ist grundsätzlich zu begrüßen. Allerdings rückt dabei oft der Bezug zum Projektinhalt  in den Hintergrund. Inhaltsbefreites Projektmanagement sehe ich sehr kritisch. Ohne ein Verständnis der in einem Projekt zu leistenden Primärprozesse, also die „Herstellung“ der Lieferobjekte, kann man kein Projekt zum Erfolg führen.

Ebenfalls ein Defizit ist aber auch das Fehlen von Führungskompetenz in Projekten. Wird der/die Projektmanager*in zugekauft und ist das Rollenbild wie oben beschrieben das einer Supportfunktion, ist Führung im Sinne von Leadership ohnehin keine Anforderung. Aber Projekte sind Unternehmen auf Zeit und gerade aufgrund ihrer straffen Ziel- und Ergebnisorientierung ist Führung umso mehr unabdingbar.

Führung ist mehr als Projektadministration

Ich habe wieder einmal PMI Infinity gefragt, was man zu diesem Thema wissen sollte. Hier die Antwort (nach nur einem Prompt):

Führung in Projekten ist ein entscheidender Faktor für den Erfolg eines Projekts. Es geht über die bloße Verwaltung von Aufgaben hinaus und umfasst die Fähigkeit, ein Team zu inspirieren, zu motivieren und zu leiten, um gemeinsame Ziele zu erreichen. Hier sind einige wichtige Aspekte der Führung in Projekten:

  • Vision und Richtung: Führungskräfte in Projekten setzen eine klare Vision und Richtung, die das Team inspiriert und motiviert.
  • Kommunikation: Effektive Kommunikation ist entscheidend, um sicherzustellen, dass alle Teammitglieder auf dem gleichen Stand sind und Missverständnisse vermieden werden.
  • Motivation: Führungskräfte müssen in der Lage sein, ihr Team zu motivieren und zu engagieren, um die bestmögliche Leistung zu erzielen.
  • Entscheidungsfindung: Führungskräfte treffen wichtige Entscheidungen, die den Verlauf des Projekts beeinflussen können.
  • Konfliktmanagement: Führungskräfte müssen in der Lage sein, Konflikte innerhalb des Teams zu erkennen und zu lösen, um eine produktive Arbeitsumgebung zu gewährleisten.

Im Gegensatz dazu konzentriert sich die Projektadministration auf die organisatorischen und administrativen Aspekte des Projektmanagements. Hier sind einige Unterschiede zwischen Projektadministration und Leadership:

  • Fokus: Projektadministration konzentriert sich auf die Verwaltung von Aufgaben, Zeitplänen und Ressourcen, während Leadership sich auf die Führung und Motivation des Teams konzentriert.
  • Aufgaben: Projektadministratoren überwachen den Fortschritt, erstellen Berichte und stellen sicher, dass alle administrativen Aufgaben erledigt werden. Führungskräfte hingegen setzen eine Vision, inspirieren das Team und treffen strategische Entscheidungen.
  • Ansatz: Projektadministration ist oft prozessorientiert und folgt festgelegten Methoden und Verfahren. Leadership ist menschenorientiert und erfordert emotionale Intelligenz und zwischenmenschliche Fähigkeiten.
  • Ziel: Das Ziel der Projektadministration ist es, sicherzustellen, dass das Projekt innerhalb des Zeit- und Budgetrahmens abgeschlossen wird. Das Ziel der Führung ist es, das Team zu Höchstleistungen zu bringen und die Projektziele zu erreichen.

Damit ist es klar, wir brauchen beides!

Was macht erfolgreiche Führung aus?

In der Ausgabe Mai/Juni 2017 des Harvard Business Review wurde über eine Studie berichtet, die 4 Faktoren identifiziert, die erfolgreiche von weniger erfolgreichen Führungskräften unterscheidet. Die Autoren sind Personalberater und die Datenbasis sind ca. 17.000 Assessments von Führungskräften auf Geschäftsleitungsebene.

Was sind diese 4 Erfolgsfaktoren?

  1. Schnell und klar entscheiden („Deciding with speed and conviction“)
  2. Ergebnisorientierung („Engaging for impact“)
  3. Proaktiv handeln („Adapting proactively“)
  4. Zuverlässigkeit („Delivering reliably“)

Die Bedeutung dieser Faktoren ist nicht überall gleich, in Branchen mit hoher Veränderungs- und Innovationsrate ist Faktor 3 (Proaktivität) wichtiger als in weniger dynamischen Branchen. Nicht alle erfolgreichen Führungskräfte sind in allen 4 Faktoren stark, aber die besonders erfolgreichen weisen häufiger mehrere positiv ausgeprägte Faktoren auf. Insgesamt am höchsten ist die Wirkung des Faktors 4 (Zuverlässigkeit)

Erfolgsfaktor 1 kann man kurz und pointiert so zusammenfassen: Schnell entscheiden ist wichtiger als richtig entscheiden. Dazu der frühere CEO von Greyhound Stephen Gorman, der das Unternehmen durch einen Turnaround geführt hat: “A bad decision was better than a lack of direction. Most decisions can be undone, but you have to learn to move with the right amount of speed.” Kluge, aber langsame Entscheidungen werden zu Engpässen, dieser Stil strahlt auf alle Mitarbeiter aus, sie werden auch immer vorsichtiger und langsamer in ihren Entscheidungen. Dieser kumulative Effekt verursacht enorme Kosten.

Erfolgsfaktor 2 betont die essenzielle Bedeutung des Stakeholder-Managements. „We found that strong performers balance keen insight into their stakeholders’ priorities with an unrelenting focus on delivering business results“. Allerdings scheuen gerade erfolgreiche Führungskräfte nicht vor Konflikten zurück, wenn diese zur Erreichung der gewünschten Ziele notwendig sind. Ihre Akzeptanz stützt sich nicht auf Wohlfühlfaktoren, sondern auf das Vertrauen der Stakeholder, mit ihnen erfolgreich zu sein. Wichtige Stakeholder sind auch die Mitarbeiter, die Auswahl und Förderung der richtigen Mitarbeiter ist Teil dieses Erfolgsfaktors

Erfolgsfaktor 3 betont die Bereitschaft, Änderungen durchzuführen, wenn sie als notwendig erkannt werden und das frühzeitig und konsequent. Aber gerade deswegen versuchen solche Führungskräfte auch, sich auf Veränderungen frühzeitig vorzubereiten. „Most CEOs know they have to divide their attention among short-, medium-, and long-term perspectives, but the adaptable CEOs spent significantly more of their time—as much as 50%—thinking about the long term. Other executives, by contrast, devoted an average of 30% of their time to long-term thinking“.

Erfolgsfaktor 4 betont Zuverlässigkeit und Berechenbarkeit von Führungskräften als Vorteil gegenüber High-Performern, deren Spitzenleistungen als wahrscheinlich nicht nachhaltig eingeschätzt werden. In diesem Erfolgsfaktor ist allerdings auch das aktive Management der Erwartungen der Stakeholder inkludiert. Unrealistische Erwartungen von Stakeholdern müssen vermieden oder nötigenfalls korrigiert werden, auch wenn das manchmal weh tut. Zuverlässigkeit in diesem Sinne ist also nicht als Opportunismus und bedingungslose Anpassungsbereitschaft zu verstehen. Dazu gehört auch ein hoher Grad an Organisation: „CEOs who ranked high on reliability employed several other tactics as well. Three-quarters of them were rated strong on organization and planning skills. They established business management systems that included a cadence of meetings, dashboards of metrics, clear accountability, and multiple channels for monitoring performance and making rapid course corrections. Most important, they surrounded themselves with strong teams“.

Jeder dieser Erfolgsfaktoren trägt auch dazu bei, Projekte erfolgreich zu führen. Erfolgreiches Projektmanagement erfordert zweifellos hohes Engagement für alle vier Faktoren. Dass Faktor 3 (Proaktives Handeln) in Projekten ebenso wie in Unternehmen mit dynamischem Umfeld besonderes Gewicht hat, scheint mir evident.

Führung ist nicht nur eine Stilfrage (wie?), es geht auch um konkrete Leistungsprozesse (was?)

Die Studie hat das Wie von Führung, den Führungsstil in den Vordergrund gestellt. Der Ton macht die Musik, könnte man salopp sagen. Autoritäte Führung, partizipative Führung, Servant Leadership sind einige der Schlagworte dazu. Die Frage nach effektiver Führung wird häufig auch mit der Schilderung von charismatischen Führungspersönlichkeiten beantwortet, so wird immer wieder Steve Jobs genannt, immer noch, wenn auch immer seltener Elon Musk. Das ist zwar inspirierend, aber nur ein Teil der Antwort auf die Frage, was erfolgreiche Führung ausmacht.

Die Autoren David G. Bowers und Stanley E. Seashore haben ihre Studie „Predicting Organizational Effectiveness with a Four-Factor Theory of Leadership“ im Administrative Science Quarterly, 11(2), 1966 veröffentlicht, damals die führende wissenschaftliche Zeitschrift für Organisationswissenschaften, vergleichbar dem, was heute noch „Nature“ für die Naturwissenschaften ist.

Sie sind der Frage nachgegangen, welche Aktivitäten einer Führungskraft die höchste Hebelwirkung für die Leistung und das soziale Klima einer Organisationseinheit hat. Sie fanden vier Faktoren, die den größten Unterschied ausmachten und aus heutiger Sicht sind das vier Prozesse, die eine Führungskraft managen muss, um erfolgreich zu sein. Meine These ist, dass genau diese vier Prozesse auch für die erfolgreiche Führung von Projekten entscheidend sind.

Prozess 1: Management der Zielklarheit und Zielakzeptanz

z.B.

  • Verdeutlichen der Arbeitsaufgabe des ganzen Teams und jedes einzelnen Teammitglieds
  • Begründung und Erklärung von Vorgaben und Entscheidungen in übergeordneten Bereichen, aber auch eigener Entscheidungen
  • Vertretung der Teaminteressen gegen unvernünftige Vorgaben
  • Mitsprachemöglichkeiten vorsehen.

Prozess 2: Management der Entwicklung der Teammitglieder

z.B.

  • Beachtung und Ausbau der persönlichen Entwicklungsmöglichkeiten
  • Ausbau der beruflichen Fähigkeiten und Kenntnisse
  • Hilfe bei persönlichen Problemen.

Prozess 3: Management der Beziehungen zwischen den Teammitgliedern

z.B.

  • Anstöße zur Zusammenarbeit geben
  • Verändern und Vermeiden von Außenseiterrollen
  • Möglichkeiten der Aussprache schaffen (z.B. regelmäßige Teambesprechungen)
  • Vermitteln bei Konflikten.

Prozess 3: Management der Arbeitsbedingungen

z.B.

  • Bereitstellen geeigneter Arbeitsmittel
  • Beseitigung störender Regelungen und sonstiger Hindernisse der Aufgabenerfüllung
  • regelmäßige und eingehende Information und Schulung.

Bemerkenswert ist, dass diese Prozesse nicht nur von der Führungskraft selbst erfüllt werden können, sondern dass diese in gut funktionierenden Teams in sehr hohem Maße auch von den Teammitgliedern selbst wahrgenommen werden. Es gibt eine wechselseitige Führung ohne eine formelle Vorgesetzten-Mitarbeiter-Rollenverteilung. Die wechselseitige Wahrnehmung dieser Führungsaufgaben (Bowers & Seashore sprechen von „Peer Leadership“) durch die Teammitglieder ist allerdings dort am höchsten, wo auch die Führungskraft sich stark für diese Prozesse engagiert.

Diese Untersuchung zeichnet sich gegenüber anderen Studien dadurch aus, dass die Leistungsmaße in sehr differenzierter Weise erhoben und ausgewertet wurden. Insgesamt wurden für jede Geschäftsstelle eines amerikanischen Lebensversicherungsunternehmens 70 Leistungsmaße sowohl auf der Grundlage betriebswirtschaftlicher Daten als auch Einschätzungen von Vorgesetzten erhoben. Von den insgesamt 100 Filialen wurden 20 aus dem auf diese Weise ermittelten obersten Leistungsbereich und 20 aus dem untersten ausgewählt. Durch die Untersuchung solcher Kontrastgruppen können die für die Leistung ausschlaggebenden Faktoren besonders deutlich erkannt werden.

Was ist zu tun, wenn man führt?

Das für mich wichtige Merkmal des Ansatzes von Bowers&Seashore ist, dass nicht über Eigenschaften von Führungskräften (ob in Projekten oder in einer Linienfunktion) gesprochen wird, sondern über „Jobs to be done“.

Wenn man sich am Prozessmodell orientiert, wird auch klar, dass Führung nicht nur von einer Person wahrgenommen werden muss und kann. Wenn man selbst in einem dieser Prozesse nicht so kompetent ist wie gewünscht und notwendig, kann das im Team aufgeteilt werden. Entgegen der vielfach vertretenen Meinung, es müsse immer genau einen Projektleiter bzw. eine Projektleiterin geben (das „Highlander-Syndrom“), habe ich mit Führungsteams fast immer gute Erfahrungen gemacht; wo diese Erfahrungen nicht positiv waren, lag es am Umfeld oder an einer oder mehreren der beteiligten Personen und wäre bei einer monokratichen Führungssituation auch nicht besser gelaufen.

Den Hinweis auf die Möglichkeit und Mächtigkeit von „Peer Leadership“ habe ich sonst nirgends in dieser Klarheit gefunden. Das Konzept des „Empowerments“ ist damit sicher eng verwandt, wenn auch nicht identisch. Daher meine ich, es lohnt sich auch heute noch, das schon 50 Jahre alte Führungsmodell von Bowers& Seashore zu kennen.

Inhaltsbefreites Projektmanagement als Tugend?

Ich erinnere mich noch gut, dass ein großes internationales Unternehmen postulierte, dass ein guter Manager alles managen kann. Dementsprechend gab es regelmäßige Jobwechsel in unterschiedlichste Bereiche. Ein Freund von mir war dort nacheinander im Consulting, im Softwarebereich und dann im Sales Management für Hardware tätig. Sicher eine grandiose Erfahrungssammlung für ihn. Ob das aus Sicht des Unternehmens die beste Lösung war, ist zu bezweifeln, auch wenn mein Freund jeden dieser Jobs gut bewältigt hat.

Viele Projektmanager denken immer noch so und sehen daher keine Notwendigkeit, sich mit den spezifischen Projektinhalten vertraut zu machen bzw. sich auf bestimmte Projekttypen zu spezialisieren.

Projektmanagement-Standards adressieren die für alle Projekte geltenden Herausforderungen und Lösungsansätze. Das liegt in der Natur solcher Standards und ist ihnen nicht vorzuwerfen. Jedes Projekt hat allerdings einen ganz spezifischen Inhalt. Es geht z.B. um die Errichtung eines Gebäudes, die Entwicklung und/oder Anpassung von Software, die Reorganisation eines Unternehmens, die Einführung eines Produktes am Markt usw. usw.

Je größer das Projekt, umso weniger werden Projektmanager an der inhaltlichen Arbeit beteiligt sein können. Aber immer gilt die Forderung, die in der Projektarbeit auftauchenden Fragen verstehen und beurteilen zu können, ob etwas eine Antwort auf die gestellte Frage ist oder nicht.

Fehlt das notwendige Minimum an inhaltlichem Verständnis, verkommt Projektmanagement zu einer Aufgaben-, Termin- und Aufwandsbuchhaltung. Unverstandenes wird dokumentiert und kommuniziert. Führung fndet nicht statt und die Ergebnisse sind entsprechend.

Meine Kritik an inhaltsbefreitem Projektmanagement ist nachhaltig, über viele Jahre gewachsen und durch Erfahrungen bestätigt. Ich stehe zu dieser Kritik! Aber ich habe auch Konstruktives dazu geschrieben, ich kann den Download dieses Artikels hier anbieten.