Stack-Modernisierung

Was ist Stack-Modernisierung?

Ein strukturierter Durchgang durch Ihren aktuellen Technologie-Stack: was installiert ist, was tatsächlich genutzt wird, was es Sie kostet, was es tun sollte und nicht tut, und was zu behalten, zu streichen oder zu ersetzen ist. Das Ergebnis ist ein funktionierender Stack, keine Liste von Empfehlungen, die in einer Präsentation liegt.

Die Arbeit wird oft mit der Umsatzdiagnostik gepaart. Die Diagnostik sagt Ihnen, dass Ihre Attribution falsch ist oder Ihre Kanalrechnung nicht aufgeht. Stack-Modernisierung ist dort, wo die zugrunde liegenden Tools, die diese kaputten Zahlen produzieren, neu gebaut werden. Die beiden lassen sich auch getrennt durchführen.

Zwei Mandatsformen. Ein Stack-Audit (4 bis 6 Wochen) produziert einen schriftlichen Befund zum aktuellen Stack und eine priorisierte Streichen/Behalten/Neubauen-Liste. Eine vollständige Stack-Modernisierung (3 bis 6 Monate) setzt die Streich- und Neubauarbeit an der Seite des internen Teams um, wobei die Integrationsarbeit zu zweit erfolgt, damit das Team sie nach unserem Abgang trägt.

Warum häufen sich Tech-Stacks so an, wie sie es tun?

Vier Muster erklären das meiste davon.

Tools, die mehr für das gewählt werden, was sie über das Unternehmen aussagen, als für das, was sie für das Unternehmen tun. Ein bestimmtes CRM, eine Marketing-Automation-Plattform oder ein Finanzsystem signalisiert eine Reifestufe des Unternehmens, und es zu kaufen fühlt sich an, als kaufe man die Stufe. Manchmal erweist sich das Tool auch als die richtige Passung für die tatsächlichen Workflows. Oft tut es das nicht, und die falsche Passung wird erst sichtbar, nachdem der mehrjährige Vertrag unterschrieben ist und das Team Workflows darum herum gebaut hat.

Entscheidungen, eine Ebene über dem getroffen, wo die Arbeit tatsächlich passiert. Eine Führungskraft hat das Tool in einem früheren Unternehmen genutzt und drängt aufgrund dieser Erfahrung darauf. Die Menschen, die es täglich nutzen werden, werden nicht gefragt, oder erst gefragt, nachdem die Entscheidung faktisch gefallen ist. Sechs Monate später haben die Operatoren Schatten-Tools um das offizielle Tool herum gebaut, weil das offizielle Tool nicht dazu passt, wie sie tatsächlich arbeiten.

Tools, die das Arbeitsvolumen deutlich übersteigen. Das Team brauchte ein 30-Platz-Tool für einen definierten Prozess und kaufte ein 500-Platz-Tool mit der passenden Funktionsbreite. Der Preis skaliert mit der Funktionsbreite, die Sie nicht brauchten. Die Implementierung dauert dreimal so lang wie die leichtere Alternative. Der tägliche Operator verbringt die meiste Zeit damit, an Funktionen vorbeizuklicken, die er nie anrührt.

Implementierungen, verwaist durch die Person, die sie vorangetrieben hat. Jemand im Unternehmen trieb den ursprünglichen Kauf und das Rollout an. Diese Person ging. Niemand sonst versteht wirklich, wie es konfiguriert ist, wohin die Integrationen zeigen oder was kaputtginge, wenn man es abschaltete. Die Rechnung kommt weiter. Das Tool tauchte längst in niemandes Workflow mehr auf.

Keine davon ist eine Schurkengeschichte. Es sind vorhersehbare Ergebnisse davon, wie Tool-Entscheidungen unter Zeitdruck tatsächlich getroffen werden. Der Sinn eines Audits ist, sie ehrlich ans Licht zu bringen, damit die nächste Entscheidungsrunde anders aufgebaut wird.

Was tun Sie in einem Mandat konkret?

Die Arbeit hat drei Phasen.

Audit. Wir kartieren, was installiert ist, wer es tatsächlich nutzt, wie oft, wofür, und was es an Lizenzgebühren, Implementierungsaufwand und Operator-Zeit kostet. Wir setzen uns mit den Operatoren (nicht nur den Budgetverantwortlichen) zusammen und schauen den realen Workflows zu. Wir vergleichen, was jedes Tool tut, mit dem, wofür es ursprünglich gekauft wurde.

Streichen und richtig dimensionieren. Für Tools, bei denen das Audit zeigt, dass sie ihre Kosten nicht einspielen, erstellen wir eine dokumentierte Streichliste: was ausgemustert wird, was durch etwas Leichteres ersetzt wird, was in ein bereits im Stack vorhandenes Tool konsolidiert wird. Wir streichen nichts ohne einen niedergeschriebenen Plan für die Workflows, die es getragen hat.

Integrationen neu bauen. Die meisten Legacy-Stacks haben Daten in Silos sitzen, die eigentlich geteilt werden sollten. Die Marketingplattform weiss nicht, was die Finanzabteilung über Retouren weiss. Das CRM weiss nicht, was der Support über das Beschwerdeaufkommen weiss. Die Produktanalytik weiss nicht, was das CRM über die Kundenstufe weiss. Wir bauen die Verbindungen neu, die längst da sein sollten, mit vorhandenen Tools, wo sie passen, und leichtgewichtiger Middleware, wo nicht.

Wir arbeiten mit Ihrem Team, nicht an ihm vorbei. Alles, was wir konfigurieren, wird in klarer Sprache dokumentiert, damit es unseren Abgang überlebt.

Wie entscheiden Sie, was zu behalten, zu streichen oder zu ersetzen ist?

Drei Fragen pro Tool.

Wer nutzt es tatsächlich? Lautet die Antwort "niemand", ist es ein Streichen. Lautet sie "eine Person, die kurz vor dem Gehen ist", ist es ein Streichen mit Dokumentation. Lautet sie "das Team nutzt es täglich für einen definierten Workflow", gehen wir zu Frage zwei.

Spielt es seine Kosten ein? Kosten sind die Lizenzgebühr plus die Operator-Zeit, die es verbraucht, plus die Integrationslast plus die Opportunitätskosten der Workflows, die es prägt. Tools, die auf der Rechnung billig aussehen, sind es oft nicht, sobald die Vollkosten eingerechnet sind. Tools, die teuer aussehen, spielen es oft ein.

Kann die Arbeit, die es tut, von etwas bereits im Stack Vorhandenem erledigt werden? Wenn ja, ist das Tool ein Kandidat für Konsolidierung. Unternehmen zahlen routinemässig für drei Tools, die sich überschneidende Arbeit tun, weil jedes von einem anderen Team zu einem anderen Zeitpunkt gekauft wurde und niemand sich hingesetzt und die Überschneidung in Einklang gebracht hat.

Das richtige Tool für ein Unternehmen ist selten das mit dem besten Vertriebsteam. Es ist das, das der Operator tatsächlich nutzen kann, das sich das Unternehmen im Dauerbetrieb leisten kann und das das spezifische Problem löst, das Sie haben, statt eines beeindruckender klingenden allgemeinen Problems.

Wie verhindern Sie, dass die nächste Tool-Entscheidung derselbe Fehler wird?

Das ist der Teil, den die meisten Mandate überspringen, und der Grund, weshalb dieselben Stack-Probleme alle drei oder vier Jahre wiederkehren.

Zwei Praktiken, angewandt auf jede bedeutsame Tool-Entscheidung in der Zukunft.

Der Operator ist im Raum, bevor die Entscheidung fällt, nicht danach. Die Person, in deren Workflow das Tool leben wird, hat eine echte Stimme auf der engeren Auswahl. Die Führung verantwortet weiterhin die Freigabe bei Kosten und strategischer Passung. Die Asymmetrie, bei der Käufer und täglicher Nutzer verschiedene Menschen sind, ist es, die die meisten verwaisten Implementierungen und die meisten Operator-baut-Schatten-Tool-Ergebnisse produziert.

Eine Schätzung der Gesamtbetriebskosten über 12 Monate ist vor der Vertragsunterschrift erforderlich. Lizenz, Implementierungsstunden, Integrationsaufbau, laufende Operator-Zeit, erwartete Migrationskosten am Vertragsende. Der Listenpreis im Vertrag ist fast nie der reale Preis. Unternehmen, die die Vollkosten im Voraus schätzen, kaufen deutlich anders als Unternehmen, die nur die Lizenz schätzen.

Keine davon ist eine neue Idee. Es sind die Praktiken, die die Muster aus der zweiten Frage verhindern, und die meisten Unternehmen haben sie nirgends niedergeschrieben.

Für wen ist das nichts?

Drei Ausschlusskriterien.

Unternehmen, deren grosse Lieferantenbeziehungen politisch unantastbar sind. Manchmal tut der Vertrag mit einem strategischen Lieferanten mehr für das Verwaltungsrats-Reporting des Führungsteams als für die Operatoren, und ihn zu ändern steht gar nicht zur Debatte. Das ist eine valide Geschäftsentscheidung, aber sie macht die Empfehlungen eines Stack-Audits in diesem Bereich unbrauchbar. Besser, ein Audit zu fassen, das diese Lieferanten ausdrücklich ausnimmt, oder zu warten, bis sich die Bedingungen ändern.

Unternehmen, die Bestätigung statt ehrlicher Einschätzung suchen. Lautet der Auftrag "sagt uns, dass unser aktueller Stack in Ordnung ist, wir müssen ihn nur besser nutzen", und das Audit kommt anders zurück, wird das Mandat schnell unangenehm. Wir machen das Audit gleich, unabhängig davon, welche Antwort das Unternehmen erhofft hat, und wir prüfen im ersten Gespräch, ob das Führungsteam für beide Ergebnisse offen ist.

Unternehmen, in denen das Daten-, IT- oder Betriebsteam während des Mandats nicht im Raum sein wird. Die Integrations-Neubauarbeit hängt davon ab, dass das Team, das die Systeme verantwortet, Teil der Arbeit ist, nicht davon, dass wir sie ihm aufdrücken. Ist dieses Team zu dünn besetzt oder zu defensiv, um sich einzubringen, wird der Neubau unseren Abgang nicht überleben.

Was passiert nach dem Mandat?

Drei Dinge landen.

Eine Ist-Karte des Stacks. Was läuft, wofür jedes Tool da ist, wie die Integrationen aussehen, was jedes Tool real kostet. Das Dokument ist für den Operator geschrieben, der es übernimmt, nicht für ein Audit. Wir hinterlassen eine Vorlage, wie es zu aktualisieren ist, während sich der Stack weiterentwickelt.

Ein Runbook für die nächste Tool-Entscheidung. Wer im Raum sein sollte, was die Bewertungskriterien sind, was Gesamtbetriebskosten für ein Tool in Ihrem Stack tatsächlich bedeuten, was die Erfolgskennzahlen der Testphase sein sollten. Das Runbook ist, was verhindert, dass der nächste Kauf derselbe Fehler wird.

Geschulte Verantwortung im Team. Jemand verantwortet jeden Teil des neu gebauten Stacks, bevor wir gehen, und wir arbeiten die letzten 30 Tage zu zweit, damit das Wissen in Echtzeit übergeht, nicht in einem Schwall in der letzten Woche.

Wir stehen nach dem Abgang für beratende Check-ins zur Verfügung, meist einer im zweiten und einer im sechsten Monat. Danach betreiben Sie es selbst.