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.
Es ist heute keine Seltenheit, dass DevOps-Ingenieure Cloud-native Tools, Open-Source-Lösungen oder andere kostengünstige (oder kostenlose) Ressourcen nutzen, die kaum Investitionen erfordern oder keine Abstimmung mit dem Beschaffungsteam nötig machen. Wie gehen Sie jedoch vor, wenn Sie eine höhere IT-Investition empfehlen müssen, um notwendige Effizienzsteigerungen zu erzielen und zugleich bessere Sicherheit und Leistung für Ihre Anwendungen sicherzustellen?
Hier sind einige Dinge, die DevOps-Experten im Hinterkopf behalten sollten, wenn sie sich in den unbekannten Gewässern des Beschaffungsprozesses bewegen.
Wenn Sie diesen Blog lesen, möchten Sie sich wahrscheinlich lieber auf die technischen Möglichkeiten konzentrieren, kennen sich den ganzen Tag über mit APIs aus und sind von Optimierung begeistert. Doch Ihre Kollegen, die für die großen Ausgaben zuständig sind, kümmern sich vermutlich kaum darum. Deshalb unterstützen Sie die Anschaffung eines neuen Tools oder einer Ressource am besten, indem Sie den geschäftlichen Nutzen klar und verständlich aus ihrer Perspektive darstellen.
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:
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. “
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.
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.
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.
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).
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. “