DIE „AGILE GESCHÄFTSKONTINUITÄT“ SORGFÄLTIG PRÜFEN

Viele Führungskräfte fragen die Verantwortlichen für Business Continuity – und auch die Manager anderer Disziplinen – „Sollten wir Agile in unserem Programm implementieren?“
Das ist eine berechtigte Frage, aber kann ein Unternehmen die agilen Prinzipien vollständig auf Business Continuity anwenden und das richtige Maß an Widerstandsfähigkeit erreichen, während es gleichzeitig ein höheres Maß an Effizienz und Effektivität erzielt?

Wir werden diese Fragen in diesem Blog untersuchen und zeigen, wie Agile das Potenzial hat, die Ergebnisse der Business Continuity zu verbessern. In diesem Sinne soll dieser Artikel lediglich die Diskussion über das Thema Agile außerhalb der Anwendungsentwicklung anregen. Er soll NICHT die endgültige Antwort auf die Frage sein, wie man Agile auf Business Continuity anwendet.
Ich halte es für wichtig, diesen Blog mit einer Einführung in Agile zu beginnen, um sicherzustellen, dass wir alle auf derselben Seite stehen.

Erstens besteht die Absicht von Agile darin, die Arbeit (oft im Zusammenhang mit der Anwendungsentwicklung) an den Geschäftsanforderungen auszurichten. Wenn sie gut gemacht sind, sind agile Projekte kundenorientierter und fördern Feedback und Kundenbeteiligung. Bei Riskonnect setzen wir Agile erfolgreich bei der Entwicklung und kontinuierlichen Verbesserung unseres Software-Systems für Geschäftskontinuität, Riskonnect, ein.

Zweitens gibt es viele verschiedene „Geschmacksrichtungen“ von Agile – Scrum und Kanban sind zwei beliebte Implementierungsmethoden. Aber unabhängig davon, welche Variante ein Unternehmen anwendet, ist Agile im Kern einfach eine Reihe von Werten und Prinzipien – von denen sich einige gut auf die Geschäftskontinuität anwenden lassen, während andere vielleicht etwas weit hergeholt sind. Viele dieser Werte und Prinzipien – die ich gleich vorstellen werde – stimmen mit dem Business Continuity Operating SystemTM (BCOS) von Riskonnect überein. Die Quintessenz ist also, dass Agile für Ihr Unternehmen und sein Business Continuity-Programm von großem Nutzen sein kann (aber lassen Sie mich in diesem Blog erklären, warum). Wenn Sie sich die Liste der Agile-Werte und -Prinzipien unten ansehen, ersetzen Sie einfach das Wort „Software“ durch „Business Continuity“.

Agile Werte Überblick und Schlussfolgerungen

Unabhängig von der „Geschmacksrichtung“ hat Agile vier grundlegende „Werte“, und hier ist meine Interpretation von jedem…

1. Arbeitssoftware statt umfassender DokumentationKümmern Sie sich lieber um den Aufbau von Fähigkeiten als um Designdokumentation und Spezifikationen.
2. Zusammenarbeit mit dem Kunden statt Vertragsverhandlungen – Arbeiten Sie gemeinsam an der besten Lösung, statt sich auf administrative Fragen, politische Hindernisse und Grenzen zu konzentrieren.
3. Auf Veränderungen reagieren statt einem Plan folgen – Ein Konzept zu haben ist großartig, aber Sie sollten in der Lage sein, Ihr Konzept anzupassen, wenn Sie etwas lernen.
4. Individuen und Interaktionen statt Prozesse und Tools – Engagement bei der Lösung eines Problems ist der Schlüssel.

Die folgende Grafik fasst zusammen, wie ich den Nutzen der vier Agile-Werte in Bezug auf die Geschäftskontinuität sehe.

Warum diese Schlussfolgerungen?

Erstens sehe ich bei Working Software Over Comprehensive Documentation einen gewissen Nutzen für den Berufsstand der Business Continuity, aber von den vier ist es wahrscheinlich der am wenigsten einflussreiche. Weiter oben in diesem Blog habe ich bereits erwähnt, dass ich glaube, dass Agile in weiten Teilen mit dem BCOS-Ansatz von Riskonnect übereinstimmt. BCOS befürwortet eine Prozessdokumentation, die „von allen befolgt wird“. Ich gebe zu, dass Prozesse und Prozessdokumentation lediglich ein Mittel zum Zweck sind. Aber ein Prozess, den die wichtigsten Stakeholder verstehen und an dem sie sich beteiligen können, ist notwendig, um das eigentliche Ziel zu erreichen, nämlich eine „funktionierende Reaktions-/Sanierungsfähigkeit“.

Zweitens sehe ich einen besonderen Wert in der Zusammenarbeit mit dem Kunden gegenüber der Vertragsverhandlung. Einige Kritiker von Agile interpretieren diesen Wert oft als Vermeidung von Verpflichtungen, d.h. als fehlende Verpflichtung gegenüber einem Zeitplan, um eine Erwartung zu erfüllen. Genauer gesagt bedeutet dieser Wert jedoch, dass Agile eher auf Innovation und Evolution ausgerichtet sein sollte, um die beste Lösung zu finden. Für mich ist die Zusammenarbeit der Schlüssel und führt zu einer Einigung über Ziele, Prioritäten und Anforderungen. Die „traditionelle“ Business-Continuity-Methodik, wie sie in der ISO 22301 beschrieben ist, befürwortet in vielerlei Hinsicht bereits die Einbeziehung von Führungskräften und Prozessverantwortlichen sowie die Einbeziehung anderer notwendiger Interessengruppen. In der Realität versäumen es viele Programme, einen risikobasierten Schwerpunkt zu setzen und die Stakeholder einzubeziehen, und die Zusammenarbeit mit dem Geschäftskunden ist nicht immer beabsichtigt. Mehr dazu in Kürze, wenn wir uns mit den agilen „Prinzipien“ beschäftigen.

Drittens, spezifisch für die Reaktion auf Veränderungen im Vergleich zur Befolgung eines Plans, sehe ich den Vorteil, wenn wir diesen Wert mit den traditionellen Best Practices der Business Continuity verbinden, indem wir den Reaktions- und Wiederherstellungsplänen „Agilität“ hinzufügen. Meiner Meinung nach sind Pläne ein nützliches Ergebnis des Business-Continuity-Planungsprozesses, da sie Informationen festhalten, die man sich nur schwer merken kann, die vielleicht nicht immer intuitiv sind und die als Anleitung – oder Erinnerung – dienen, wie man auf eine Störung reagiert.

Und schließlich sehe ich in der Tatsache, dass Individuen und Interaktionen Vorrang vor Prozessen und Tools haben, eine Menge Vorteile, denn Engagement ist ein entscheidender Erfolgsfaktor für gut funktionierende Business Continuity-Programme, die Widerstandsfähigkeit bieten. Leider geht es bei der traditionellen Business-Continuity-Planung hauptsächlich um die Ausführung von Methoden, während das Engagement der Teilnehmer eine zweitrangige Rolle spielt. Wie im BCOS-Modell von Riskonnect erwähnt, ist ein „dokumentierter Prozess, der von allen befolgt wird“, äußerst wichtig, aber wenn er mit einem großen Engagement der Programmteilnehmer als Grundlage gepaart ist, ist das Unternehmen viel besser in der Lage, das richtige Maß an Widerstandsfähigkeit zu erreichen. In diesem Sinne würde ich den Titel dieses Wertes in „Individuen und Interaktionen mit Prozessen und Tools“ ändern (wenn ich könnte).

Agile Prinzipien Überblick und Schlussfolgerungen

Agile hat 12 Grundprinzipien, die traditionell Vorteile bei der Softwareentwicklung bieten und von denen einige bei der Anwendung auf die Geschäftskontinuität von Nutzen sein können.

1. Kundenzufriedenheit durch frühzeitige und kontinuierliche Softwarebereitstellung – Liefern, innovieren, liefern, innovieren, liefern, innovieren (und so weiter); schaffen Sie Fähigkeiten, testen Sie sie und verbessern Sie sie (aber warten Sie nicht auf Perfektion, bevor Sie liefern). 2. Passen Sie sich während des gesamten Entwicklungsprozesses an veränderte Anforderungen an – Sammeln Sie ständig Feedback und setzen Sie es nach Prioritäten geordnet um. 3. Häufige Bereitstellung funktionierender Software – Warten Sie beispielsweise nicht auf den Abschluss der „einmal im Jahr“ stattfindenden Strategiephase, bevor Sie die Reaktions- und Wiederherstellungsfähigkeit verbessern, sondern stellen Sie die Geschäftskontinuitätsfähigkeit kontinuierlich bereit.

4. Collaboration between the business stakeholders and developers throughout the project – Bleiben Sie mit dem Unternehmen (einschließlich der Prozess- und Ressourcenverantwortlichen) in Kontakt und arbeiten Sie mit ihnen zusammen, um Reaktions- und Wiederherstellungsfähigkeiten zu entwickeln und zu erhalten. 5. Unterstützen, vertrauen und motivieren Sie die beteiligten Personen – Verstehen Sie, was dem Unternehmen wichtig ist, wenn es um Business Continuity geht, und stellen Sie sicher, dass der Fokus, die Fähigkeiten und das Engagement übereinstimmen (und vertrauen Sie darauf, dass das Unternehmen das Richtige tun wird, wenn es Ihnen bei der Durchführung des Business Continuity-Programms hilft). 6. Ermöglichen Sie persönliche Interaktionen – In einer perfekten Welt, sure…. Siehe unten für weitere Informationen zu diesem Punkt! 7. Funktionierende Software ist der wichtigste Maßstab für den Fortschritt – In der Sprache der Business Continuity ist eine Reaktions- oder Wiederherstellungsfähigkeit wichtiger als Methoden und Pläne. 8. Agile Prozesse zur Unterstützung eines konsistenten EntwicklungstemposEin konsistentes Tempo ist für die Geschäftskontinuität möglicherweise nicht anwendbar oder bringt keinen großen Mehrwert. 9. Aufmerksamkeit für technische Details und Design erhöht die Agilität – Indirekt ist dies ein Schlüsselprinzip, das sicherstellt, dass die Programmteilnehmer die Zeit und die Kompetenzen haben, um ihre Aufgaben zu erfüllen. 10. EinfachheitYES! Halten Sie es einfach (beseitigen Sie unnötige Komplexität) und machen Sie es dem Unternehmen leicht, an dem Business Continuity-Programm teilzunehmen. 11. Selbstorganisierte Teams fördern großartige Architekturen, Anforderungen und Entwürfe – Speziell im Bereich Business Continuity sehe ich dieses Prinzip als Anreiz für risikoarme Experimente, um die Effizienz und Effektivität des Programms zu steigern.

12. Regelmäßige Überlegungen, wie Sie effektiver werden können – Engagement, Bewertung der Leistung, Prozessprobleme und Verbesserung (speziell im Hinblick auf das Business Continuity-Programm und die Reaktions- und Wiederherstellungsfähigkeiten).

Die folgende Grafik fasst zusammen, wie ich den Nutzen der einzelnen Agile-Prinzipien in Bezug auf die Geschäftskontinuität sehe.

Warum diese Schlussfolgerungen?

1. Kundenzufriedenheit durch frühzeitige und kontinuierliche Softwarebereitstellung – Einige Praktiker arbeiten daran, die „niedrig hängenden Früchte“ anzugehen, während sie sich gleichzeitig mit den „wichtigeren“ Problemen befassen, aber viele Programme warten bis zum Abschluss eines Planungszyklus, wenn es an der Zeit ist, Strategien auszuwählen (was im Grunde genommen Methodik statt Risikominderung bedeutet). Durch großes und kontinuierliches Engagement wird die Lösung oft schnell offensichtlich. So wird schnell eine kurzfristige Aufgabe oder eine längerfristige Maßnahme oder ein Ziel festgelegt, um ein höheres Maß an Leistungsfähigkeit zu erreichen. 2. Passen Sie sich während des gesamten Entwicklungsprozesses an die sich ändernden Anforderungen an – Traditionelle Business Continuity ist insofern immergrün, als die Erkenntnis weit verbreitet ist, dass man nie fertig ist und dass sich die Ergebnisse der Business Continuity mit den Veränderungen im Unternehmen ändern werden. Dieser Grundsatz entspricht sicherlich den Best Practices, aber vergessen Sie nicht, sich ständig zu erneuern und weiterzuentwickeln.

3. Frequent delivery of working software – Das hat einen gewissen Wert, und Riskonnect integriert dieses Prinzip in vielerlei Hinsicht in den BCOS. Es beginnt mit der Konzentration auf das Wesentliche und setzt sich dann mit zweiwöchigen, vierteljährlichen, jährlichen und dreijährigen Arbeitszyklen (einschließlich Zielen und Vorgaben) fort, um die Reaktions- und Wiederherstellungsfähigkeit zu verbessern. 4. Zusammenarbeit zwischen den Stakeholdern des Unternehmens und den Entwicklern während des gesamten Projekts – Der Schwerpunkt liegt auf der produktiven Zusammenarbeit mit allen Stakeholdern, einschließlich der Führungsebene und der ausführenden Mitarbeiter, was einen erheblichen Vorteil darstellt. 5. Unterstützen, vertrauen und motivieren Sie die beteiligten PersonenDieser Grundsatz ist so wichtig. Leider wird er in den Business Continuity-Standards und Best Practices nicht wirklich umfassend berücksichtigt. Allzu oft fordern Business Continuity-Experten die Beteiligung der Unternehmen, schränken aber die Teilnehmer ein („sperren sie ein“), weil sie nicht darauf vertrauen, dass sie das Richtige tun werden. Letztendlich sollten Business Continuity-Experten hart daran arbeiten, die Programmteilnehmer zu motivieren (indem sie die Menschen, die teilnehmen möchten, einbeziehen und ihnen helfen, die Bedeutung von Business Continuity zu verstehen), den Programmteilnehmern viel Energie und effektives Engagement zu vermitteln, darauf zu vertrauen, dass sie das Richtige tun werden, wenn sie entsprechend geschult werden, und sich auf die Messung und Verbesserung zu konzentrieren. 6. Ermöglichen Sie persönliche Interaktionen Ganz einfach gesagt, sehe ich dies nicht als „Geschäftsrealität“ in der heutigen globalen und mobilen Arbeitsumgebung. Aber wenn Sie die Möglichkeit haben, sich persönlich zu treffen, ist es einfacher, sich zu engagieren. Und es gibt immer noch Videokonferenzen… 7. Arbeitssoftware ist der primäre Maßstab für den Fortschritt – Zu oft messen und bewerten wir, wie wir zu Business Continuity-Lösungen und -Strategien gelangen, während die eigentliche Resilienzfähigkeit ein nachträglicher Gedanke ist. Das ewige BCOS-Ziel ist „das richtige Maß an Widerstandsfähigkeit“, was im Wesentlichen das Äquivalent zu „funktionierender Software“ ist. Ich halte dieses Prinzip für das wertvollste von allen. 8. Agile Prozesse zur Unterstützung eines konsistenten Entwicklungstempos – Ich denke, wir können dieses Prinzip weglassen; das konsistente Tempo ist nicht so wichtig wie ein risikobasiertes Tempo. 9. Aufmerksamkeit für technische Details und Design erhöht die Agilität – Wie bereits erwähnt, sehe ich diesen Grundsatz in Verbindung mit etwas Wertvollem, nämlich den Kompetenzen und Erfahrungen der Programmteilnehmer, die entscheidend sind.

10. Vereinfachung – Meine häufigste Beobachtung in unserer Disziplin ist eine völlig unnötige Programmkomplexität, weil es vielen traditionellen Praktiken der Business Continuity Planung an Pragmatismus fehlt. 11. Selbstorganisierende Teams fördern großartige Architekturen, Anforderungen und Entwürfe – Hier gibt es einen gewissen Nutzen. Unterdrücken Sie nicht diejenigen, die sich wirklich proaktiv beteiligen wollen, um das Programm und die Reaktions- und Wiederherstellungsfähigkeit des Unternehmens voranzubringen. Denken Sie gleichzeitig daran, dass Sie bei Ihrem Streben nach Verbesserung und Erreichen des richtigen Maßes an Widerstandsfähigkeit den Input und/oder die Zustimmung der richtigen Personen einholen sollten. 12. Regelmäßige Überlegungen darüber, wie Sie effektiver werden können – Das letzte der wertvollen Agile-Prinzipien. Standards und Best Practices befassen sich mit Themen wie Korrekturmaßnahmen, Überprüfungen nach Vorfällen und Management-Reviews, erklären aber oft nicht, wie Sie den maximalen Wert erreichen können. Binden Sie die richtigen Leute in der richtigen Häufigkeit mit Informationen ein, die motivieren. Und in Besprechungen und anderen Interaktionen sollten Sie Leistungsprobleme „bearbeiten“, d.h. nach der Ursache von Leistungsproblemen oder anderen Verbesserungsmöglichkeiten suchen.

Schlussfolgerungen

Wenn Sie jemand bittet, Agile auf Business Continuity anzuwenden, fragen Sie ihn, ob er die Werte und Prinzipien mit einer der oben genannten Varianten von Agile, wie Scrum oder Kanban, verwechselt. Meiner Meinung nach ist der Scrum-Ansatz für die Geschäftskontinuität wertvoller und entspricht vielen der BCOS-Attribute von Riskonnect (z.B. die zweiwöchigen Inkrement-To-Do’s in Evolve), den grundlegenden Bestandteilen (wie Engage) und den Kernprozessen (wie Evolve). Kanban ist im Rahmen der Geschäftskontinuität möglicherweise viel schwieriger zu nutzen, da sein Schwerpunkt auf der Minimierung der laufenden Arbeit liegt.

Alles in allem, hier eine Frage. Werden Buchhalter gebeten, agiles Rechnungswesen zu betreiben? Agile HR? Agile Compliance? Nur weil es in der IT funktioniert, heißt das noch lange nicht, dass es für alle gelten sollte, und es ist sicherlich keine Einheitslösung. Anstatt sich auf eine bestimmte Variante von Agile zu beschränken, sollten Sie sich überlegen, ob Sie nicht stattdessen ausgewählte Agile-Werte und -Prinzipien nutzen sollten, um das richtige Maß an Widerstandsfähigkeit zu erreichen, indem Sie sich auf das Programm konzentrieren und die richtigen Leute in Ihrem Unternehmen einbeziehen.