DevOps-Kompetenzen fürs Leben: Den Beschaffungsprozess verstehen und verwalten

In einem früheren Blog habe ich darüber gesprochen, warum es wichtig ist, bei der Anwendungsbereitstellung einen systemorientierten Ansatz zu verfolgen, der eher wie eine gut abgestimmte Fabrik funktioniert, die für eine effiziente Wertschöpfung optimiert ist. Um dieses Ziel zu erreichen, müssen Sie die Werkzeuge, auf die Sie angewiesen sind, sowie den Prozess, mit dem Sie diese auswählen und beschaffen, bewerten. Um die Effizienz zu steigern, müssen möglichst wiederverwendbare Muster priorisiert und Tools und Prozesse ausgewählt werden, die in allen Teams und Umgebungen konsistent sind. Theoretisch erscheint das den meisten Leuten sinnvoll, insbesondere wenn es sich bei den betreffenden Tools um Infrastruktur- oder Sicherheitstools handelt – mit minimalen Auswirkungen auf die Anwendungsfunktion. Dem Aufbau solcher Muster steht jedoch oft eine unterschätzte Barriere im Weg: Der Lieferanten- und Beschaffungsprozess.

Derzeit ist es für DevOps-Ingenieure nicht ungewöhnlich, Cloud-native Tools, Open-Source-Lösungen oder andere Arten kostengünstiger (oder kostenloser) Ressourcen zu verwenden, die keine erheblichen Investitionen oder Interaktion mit dem Beschaffungsteam erfordern. Aber was, wenn Sie sich für eine umfangreichere IT-Investition einsetzen müssen, um die erforderliche Effizienz zu steigern und gleichzeitig eine bessere Sicherheit und Leistung für Ihre Apps zu gewährleisten? 

Argumente für IT-Investitionen

Hier sind einige Dinge, die DevOps-Experten im Hinterkopf behalten sollten, wenn sie sich in den unbekannten Gewässern des Beschaffungsprozesses bewegen.

1. Konzentrieren Sie sich auf den Wert

   Wenn Sie diesen Blog lesen, konzentrieren Sie sich wahrscheinlich lieber auf die erforderlichen technologischen Möglichkeiten, können den ganzen Tag über APIs reden und sind von Optimierung besessen. Aber raten Sie mal – Ihre Kollegen, die für das Unterschreiben der großen Schecks verantwortlich sind, interessiert das alles wahrscheinlich völlig völlig. Aus diesem Grund besteht das Wichtigste, was Sie tun können, um den Kauf eines neuen Werkzeugs oder einer neuen Ressource zu unterstützen, darin, den geschäftlichen Nutzen, den es bringt, in den Worten der Kunden zu artikulieren.

   Dies beginnt oft mit der Feststellung, was derzeit fehlt oder mangelt. Die Aufforderung, ein neues Tool zu kaufen, nur weil es jetzt verfügbar ist, ist bei weitem nicht so überzeugend, wie auf einen erheblichen Fehler oder eine erhebliche Schwachstelle hinzuweisen, darzulegen, wie dieser Fehler Probleme verursacht (die Produktion verlangsamt, Schwachstellen offenlegt usw.) und dann ein neues Tool vorzuschlagen, das alle Probleme löst.

   Die drei Schlüsselelemente, auf die Sie sich konzentrieren sollten, sind Kosten, Wert und Risiko. Es ist wichtig, in Geschäftsbegriffen darüber zu sprechen – wie eine bestimmte Lösung das identifizierte Problem löst durch:

   • Kostensenkung über einen kurzen, mittleren oder langfristigen Zeitraum
   • Wie das Unternehmen seine Agilität steigern, die Markteinführungszeit verkürzen oder neue Kunden gewinnen kann
   • Wie das Geschäftsrisiko durch eine verbesserte Einhaltung gesetzlicher Vorschriften, ein geringeres Angriffsrisiko oder sogar durch Maßnahmen zur Verringerung der Wettbewerbsbelastung verringert wird

   Bei all dem ist es sehr wichtig, jeden einzelnen Aspekt so gut wie möglich zu quantifizieren. Niemand möchte rein qualitative Meinungen. Auf harte Daten kommt es an.

   Für Ihre Kollegen im Einkauf (und allgemeiner in den Finanzteams) hat alles seinen Preis und seinen Wert. Hierzu zählen die Kosten des Nichtstuns (angesichts bekannter Probleme) sowie der Wert, der entsteht, wenn die Arbeitnehmer von der Auseinandersetzung mit diesen Problemen befreit werden. Bedenken Sie jedoch, dass NetOps die Eliminierung banaler Aufgaben möglicherweise einfach deshalb sinnvoll findet, weil die Arbeit dadurch weniger mühsam wird, während Finanzteams es für sinnvoll erachten, denselben Ingenieuren Freiraum zu geben, damit sie sich auf strategische, umsatzgenerierende Initiativen konzentrieren können.

   Will Marken, Technical Solutions Manager bei F5, schlägt vor, dass Sie sich „als Problemlöser positionieren. Während Sie sich auf die Wertschöpfung konzentrieren, verknüpfen Sie die vorgeschlagene Lösung mit den Unternehmenszielen. Dadurch zeigen Sie, dass Sie mit dem Management auf dessen Art und Weise interagieren und auf seine Bedürfnisse eingehen können. “

2. Kennen Sie den Jargon: Investitionsausgaben vs. Abonnements

Ihr Team möchte eine Lösung möglicherweise ganz über ein Abonnementmodell erwerben, stellt dann aber fest, dass Ihr Unternehmen auf hohe Investitionsausgaben ausgerichtet ist und ein Prozess zur Finanzierung von IT-Investitionen auf Abonnementbasis fehlt. In diesem Fall erwartet Sie zusätzliche Arbeit. Möglicherweise fällt es Ihnen leichter, auf eine Investitionsbudgetanforderung umzusteigen (z. B. eine einzelne große Anschaffung, die sich über einen bestimmten Zeitraum amortisiert). Andererseits finden selbst Unternehmen, die Abonnementmodelle bisher nur zögerlich angenommen haben, heraus, wie sie diese unterstützen können. Möglicherweise müssen Sie einfach etwas mehr Zeit einplanen, während Ihre Kollegen aus der Finanzabteilung ihre eigenen organisatorischen Prozessherausforderungen bewältigen.

3. Seien Sie hartnäckig

So klischeehaft es auch klingen mag, dies ist wirklich einer der Fälle, in denen es um die Reise geht, nicht um das Ziel. Die Rechtfertigung großer Anschaffungen erfordert oft mehrere Anläufe. Tatsächlich kann es durchaus sein, dass Ihr Anliegen mit anderen Anfragen konkurriert, die bereits zwei oder drei Haushaltsphasen durchlaufen haben und dabei ihren Fokus verfeinert und Unterstützung gesammelt haben. Geben Sie nicht auf, wenn Sie „Nein“ hören. Planen Sie stattdessen darauf ein, akzeptieren Sie es, wenn es eintritt, und nehmen Sie von dort aus Anpassungen vor.

Gehen Sie die Beschaffung wie jede andere Aufgabe in Ihrem Agile-Workflow an. Identifizieren Sie die Probleme, lösen Sie sie eins nach dem anderen und wiederholen Sie, iterieren Sie, iterieren Sie.

4. Zerlege es in Stücke

Bei großen Budgetanfragen ist es oft hilfreich, Ihr Projekt in überschaubarere Teile aufzuteilen. Dies kann aus zwei Gründen sinnvoll sein: a) Bei stärkerer Fokussierung ist es einfacher, einen plausiblen POC (Proof of Concept) zu erstellen und den tatsächlichen Nutzen zu ermitteln. Außerdem ist es für die Verantwortlichen einfacher, kleinere Anfragen zu genehmigen.

5. Bilden Sie ein Team

Es gibt viele Gründe, warum es eine gute Idee ist, andere in der Organisation um Hilfe zu bitten. Zunächst einmal sind Ihre direkten oder teamübergreifenden Kollegen möglicherweise besser mit dem Beschaffungsprozess im Allgemeinen und mit dem Wert der F5-Lösungen im Besonderen vertraut und können Ihnen daher dabei helfen, die Anfrage zu formulieren (und bekannte Gefahren zu vermeiden). Sie können das wahrgenommene Risiko auch verringern, indem Sie zeigen, wie sich Ihre vorgeschlagene Lösung positiv auf mehrere Abteilungen auswirkt. Und schließlich kommt es nicht selten vor (vor allem in sehr großen Organisationen), dass man feststellt, dass eine andere Gruppe bereits eine ähnliche Anfrage wie die Ihre in Angriff genommen hat (in diesem Fall können Sie von ihr lernen) oder vielleicht sogar mit der Implementierung einer ähnlichen Lösung begonnen hat (in diesem Fall können Sie eine Partnerschaft mit ihr eingehen).   

Eine Anmerkung zur Struktur

Wenn Sie einen Haushaltsantrag erstellen, können Sie viele der gleichen Taktiken anwenden, die Sie auch zum Erstellen typischerer Dokumente in Ihrem Bereich verwenden würden, z. B. Whitepaper und Datenblätter. Dies beginnt mit der Suche nach der geeigneten Vorlage, damit Sie wissen, dass Ihre Anfrage in Aussehen und Leseweite denen anderer Anfragen ähnelt, mit denen der Manager vertraut ist. Dazu gehört auch, dass es während des gesamten Prozesses mehreren Kollegen vorgelegt wird, um Input und Feedback einzuholen. Jon Gross, Produktentwicklungsmanager bei F5, fügt hinzu: „ Wie bei Datenblättern und Whitepapers hängt der Erfolg oft von der Beschreibung oder dem einleitenden Absatz ab. “ Er schlägt vor, dass Sie „ nach vorhandenen Referenzarchitekturen und Anwendungsfällen suchen, die Ihren Implementierungsfahrplan mit realen Datenpunkten untermauern können. “