(6 votes, average: 2,83 out of 5)
Loading...

DevOps – ein offener Brief des Business

30.11.2016 | Kommentare
2

Sorry liebe IT,

die Lösung für ein Problem, das Ihr Euch selbst geschaffen habt, ist kein Mehrwert sondern eine zwingend notwendige Korrektur. Wenn für Euch DevOps bedeutet, dass endlich die Entwicklung (Development) und der Betrieb (Operations) miteinander reden, es weniger Fehler in der Zusammenarbeit gibt und Ihr dafür mehr Zeit für unsere Business-Anforderungen habt, dann dürfen wir das einfach erwarten.

Für uns als Business- oder Fachabteilung einer Organisation resultiert der eigentliche Mehrwert von DevOps aus den folgenden Punkten:


1. Time To Market

Ihr seid in der IT schneller, was die Umsetzung einer Idee anbelangt. Wir nennen das Time To Market (T2M). Wenn wir mit einer Idee zu Euch kommen, gehen wir davon aus, Ihr habt eine funktionierende Werkbank zur Umsetzung parat. Dabei bedient Ihr Euch für allgemeine Funktionen aus einer Sammlung von bereits vorhandenen Lösungen. Ihr müsst kein CMS, keinen Shop oder Collaboration-Tool neu erfinden. Die vorhandene Software ergänzt Ihr intelligent mit den notwendigen individuellen Teilen. Diese sind es, die unsere Firma im Wettbewerb von der Konkurrenz abheben und uns einen Vorsprung ermöglichen.

Weil Ihr die gesamte Werkbank möglichst weit automatisiert habt, gehen Umsetzung und bitte auch die Tests für die Qualität zügig voran. In kürzester Zeit – und damit meinen wir nicht Wochen und Monate – können unsere Kunden die neue Funktion nutzen. Zudem soll Automatisierung auch bedeuten, dass wir mit den bestehenden Ressourcen mehr erreichen können.

2. Zusammenarbeit und Transparenz

Für uns ist nachvollziehbar, wie aus unserer Idee bei Euch ein Konzept wird, wie dieses programmiert und konfiguriert wird, ob die Qualität stimmt und auch, wann es zum Einsatz kommt. Im Idealfall ist das eine ständige Zusammenarbeit zwischen Euch – der IT – und uns, dem Business. Deshalb wäre es gut, ein Dashboard zur Verfügung zu haben, auf dem wir den aktuellen Status und eure Empfehlungen sehen, und über das wir unsere Beiträge – z. B. eine Freigabe – durchführen können. Natürlich tragen wir die Verantwortung für die Funktion. Deshalb sind wir hier in den Test eingebunden und bestimmen darüber, ob wir mit der Funktion endgültig an den Start gehen.

Selbstverständlich ist klar, dass wir auch gemeinsam die Aufgaben priorisieren müssen. Wir haben durch DevOps nicht beliebig viele Ressourcen verfügbar. In dem Dashboard können wir den Überblick behalten und die Reihenfolge der Bearbeitung festlegen.

3. Feedback und Bewertung

Spannend wird es, wenn die neue Business-Funktion in der Praxis zum Einsatz kommt und wir gemeinsam auswerten, wie erfolgreich sie ist. Wir fragen dann beispielsweise danach: „Wie viele Klicks gab es? Wurden die zusammengestellten Warenkörbe auch bestellt? Waren es für den Kunde zu viele oder zu wenigen Informationen?“
Diese Daten, ihre Ermittlung und ihre Bewertung müssen wir gemeinsam erarbeiten und justieren. Sie sollten deshalb auch in unserem gemeinsamen Dashboard ersichtlich sein. Daraus leiten wir ab, welche nächste Entwicklung sinnvoll ist oder wo wir etwas korrigieren wollen.



Als gemeinsame Aufgabe zu DevOps sehen wir für uns beide – IT und Business – einen Kulturwandel in zwei Bereichen:

→ Unsere Zusammenarbeit
Die IT wird immer weiter integraler Bestandteil unserer Geschäftsprozesse sein. Von beiden Seiten aus müssen wir deshalb daran interessiert sein, partnerschaftlich Hand-in-Hand zu arbeiten.

→ „Releases“
Bisher haben wir unsere Ideen meist in großen Projekten entwickelt und umgesetzt. In der Zukunft glauben wir, wird es mehr – aber deutlich kleinere – Verbesserungen geben. Diese Form der Arbeit müssen wir uns beide noch angewöhnen.

In diesem Sinne: Lasst es uns gemeinsam angehen.
Eure Business-/ Fachabteilung

(6 votes, average: 2,83 out of 5)
Loading...
  1. André Welling am 1.12.2016

    Liebes Business,
    inwiefern ist eine lukrative Korrektur kein Mehrwert zum unkorrigierten Zustand? Und sind dann auch alle neuen Business-Making-Paradigmata nur Korrekturen selbstverschuldeter Unzulänglichkeiten statt echte Mehrwert-Innovation? Ja? Dann ist gut. Allerdings weiß ich gar nicht, womit ich dich so aufgeregt habe, sorry, daß du derart klarmachst, wer hier bestellt und erwarten kann und somit die Hosen anhat – bei aller (oder gegen alle) partnerschaftlichen Hand-in-Hand-Vertrautheit. Wenn ich irgendwo den Mund zu voll genommen habe, tut es mir leid. Aber ist es erlaubt zu sagen, dass auch wir Dinge erwarten, nicht weil wir annehmen, dass ihr euren Laden optimal im Griff habt ohne jeden Korrekturbedarf, nein, sonden damit wir planmäßig arbeiten können und es hinterher kein Blame-Game gibt? Du sagst z.B. „Natürlich tragen wir die Verantwortung für die Funktion. Deshalb sind wir hier in den Test eingebunden (…)“, aber wie oft wird diese Natürlichkeit missachtet? Fachtester, Abnahme der Testspec – Pustekuchen. Wir sind ja schon froh, wenn eure Funktion konsistent und vollständig beschrieben ist und sich bei den allfälligen Lücken und Widersprüchen schnell ein Entscheider findet, um das glattzuziehen. Das lässt sich wohl kaum automatisieren, obwohl so ein Business Stakeholder-Bot viele praktische Vorteile hätte. Anyways, lass uns gemeinam schneller, partnerschaftlicher, kleinteilig-iterativer werden. Und sprich doch bitte erst mal persönlich mit mir, bevor du so ein öffentliches „Internet Shaming“ betreibst.
    Alles Liebe
    Deine IT

    Reply
  2. The Expert am 13.12.2016

    Besten Dank für die treffende Replik, André. Einzig gefehlt hat mir noch der Aspekt, dass nicht die IT für den Überblick des Business verantwortlich ist, sondern das Business. Für jedes Projekt ein eigenes Dashboard zu haben, macht die Sache nicht übersichtlicher. Die IT klinkt sich gerne in bestehende Prozess-Tools ein, die aber in der Regel über Excel hinaus nicht existieren.

    Reply

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*