Es gibt zahllose Möglichkeiten, wie Technologieentscheidungen ins Unglück führen können. Lesen Sie, was Sie lassen sollten, wenn Sie das vermeiden wollen. [...]
Sind Sie wie ein Kind im Süßwarenladen, wenn es um neue Technologien geht, und wollen jede Innovation gleich ausprobieren? Hat in Ihrem Unternehmen ein Tech-Hasardeur das Sagen und wählt Anbieter ohne vorherige Analyse und Due-Diligence-Prüfung aus? Oder zerpflücken Beschaffungsmanager, Projektmanagement und Stakeholder jede neue Technologie so gründlich, dass Ihr Unternehmen letzten Endes mit veralteten Plattformen im Schlamm stecken bleibt statt zu innovieren und florieren?
Technologieeinkäufer wie diese sind in vielen Unternehmen anzutreffen. Sie können die Fähigkeit von Technologieentscheidern untergraben, die richtigen Technologien zur richtigen Zeit einzusetzen. Eine willkürliche Technologiewahl führt zu unnötigem Aufwand und technischer Verschuldung – übermäßig methodische Ansätze hingegen verlangsamen das Innovationstempo und behindern Experimentiergeist, intelligente Risikobereitschaft und agile Kultur. Wenn Sie kluge Technologieentscheidungen treffen wollen, sollten Sie die folgenden elf Wege nicht beschreiten.
1. C-Level-Unumstößlichkeiten
Wenn der CEO oder eine andere einflussreiche Führungskraft das Tech-Team bittet, eine bestimmte technische Lösung zu kaufen und zu implementieren, gilt es, die Gründe dafür zu verstehen. Welches Problem versucht der Manager zu lösen und wie gut erfüllt die gewünschte Lösung die Erwartungen? Allzu oft werden Forderungen von Führungskräften unreflektiert akzeptiert und keinerlei Schritte unternommen, um den Ansatz zu rationalisieren oder Alternativen aufzuzeigen.
Lösen lässt sich das Dilemma damit, Vision Statements zu verfassen und zu präsentieren. So lässt sich der Fokus auf ein spezifisches Problem, eine Chance oder eine Value Proposition richten. Gut formulierte Vision Statements definieren Ziele, sind aber nicht von vornherein auf eine bestimmte Lösung oder Implementierung festgelegt.
2. Kunde egal
Technologieentscheider machen manchmal den Fehler, sich in die Umsetzung zu stürzen: Problem erkannt, Lösung bekannt – und ein Gefühl der Dringlichkeit ist der Treiber, die Lösung schnellstmöglich zu implementieren. Wenn der Kunde oder Anwender jedoch nicht in den Entscheidungsprozess einbezogen wird oder die Vorteile der Implementierung nicht nachvollziehen kann, können neue Funktionen leicht das angestrebte Ziel verfehlen. Viele Unternehmen versäumen es sogar, den Kunden für bestimmte Technologieprojekte formell zu definieren.
Wenn Sie Endbenutzeranwendungen entwickeln, ist die Definition des Kunden einfacher, wenn Sie Rollen und Personas definieren. Bei der Entwicklung von Back-End-Funktionen wie Infrastruktur, Sicherheitsfunktionen, Middleware, Bibliotheken oder Webdiensten kann die Bestimmung der Kundenrolle jedoch schwieriger sein.
Architekten, Business-Analysten oder technische Leiter können bei der Implementierung von Back-End-Technologien die Rolle des Kunden übernehmen. Bitten Sie sie, Anforderungen zu stellen, Akzeptanzkriterien zu ermitteln, Entscheidungen über Kompromisse zu treffen und ihre Zufriedenheit mit der implementierten Lösung zu bewerten.
3. Standard-Askese
In der Vergangenheit haben sich Technologie-Abteilungen mit der Erstellung und Pflege von Dokumentationen sowie mit der Kommunikation und Verwaltung von Standards schwergetan. Wenn also eine dringende Anfrage oder eine Top-Anforderung auftaucht, wird eher nach neuen Lösungen gesucht, statt die vorhandenen Möglichkeiten zu nutzen.
Dieser Ansatz führt oft zu Redundanzen, halb entwickelten Lösungen und höheren technischen Schulden. Ein simpler Lösungsansatz: Die „Recherche interner Lösungen“ wird fester Bestandteil der Workflows. Wenn Mitarbeiter dennoch neue Technologien empfehlen, sollten Sie einen Prozess einrichten, um den Aufwand für Upgrades bestehender Plattformen abzuschätzen oder die Konsolidierung von Technologien mit ähnlichen Funktionalitäten anzustoßen.
4. Einbahnstraße
Es ist eine Sache, Standards und bevorzugte Anbieter zu haben. Eine andere ist es, die Möglichkeiten von Drittanbietern außen vor zu lassen und die Diskussion über Alternativen von vornherein zu unterbinden.
Wenn Sie zulassen, dass die Stimme einiger weniger Befürworter (oder ihre eigene) die der experimentierfreudigen Mitarbeiter übertönt, kann das zu kostspieligen Fehlern führen. Ermutigen Sie die Mitarbeiter stattdessen, ihre Perspektive zu teilen und den Status Quo in Frage zu stellen.
5. Nur „Build“ oder „Buy“
Es gibt eine breite Grauzone zwischen selbst gecodeten Lösungen und dem Einkauf von SaaS– oder anderen Technologien, die sofort einsatzfähige Funktionen bieten. In dieser Grauzone liegen zum Beispiel hochgradig konfigurierbare Low-Code– und No-Code-Plattformen, kommerzielle Partnerschaften und Möglichkeiten, Open-Source-Technologien zu nutzen.
„Build“ gegen „Buy“ auszuspielen, ist zu kurz gedacht. Besser: Fragen Sie sich, ob die erforderlichen Funktionen zur Differenzierung des Unternehmens beitragen und welche Arten von Lösungen langfristig mehr Innovation und Flexibilität bieten.
6. API-Selbstverständlichkeit
Die meisten modernen SaaS– und auch viele Unternehmenssysteme bieten APIs und andere Integrationsoptionen. Die Katalogisierung der Integrationsmöglichkeiten sollte jedoch nur der erste Schritt sein, um zu prüfen, ob sie den Geschäftsanforderungen entsprechen. Folgende Fragen sind dabei wichtig:
- Welche Daten stellt die API zur Verfügung?
- Werden die gewünschten Ansichten und Transaktionen unterstützt?
- Können Sie problemlos Datenvisualisierungs- und Machine Leanring Tools verknüpfen?
- Ist die API leistungsfähig genug und gibt es Nutzungskosten, die berücksichtigt werden müssen?
7. Due-Diligence-Versäumnis
Wenn wir mit einer langen Liste möglicher Lösungen konfrontiert werden, können vertrauenswürdige Informationsquellen helfen, das Spielfeld einzugrenzen. Blogs, Whitepaper, Rezensionen und Forschungsberichte sowie Webinare, Keynotes und Online-Tutorials können solche Quellen sein. Ein Instrument, das hierbei oft vernachlässigt wird, ist die Nutzung von sozialen Netzwerken, um sich mit Experten zu beraten.
8. Mut zur PoC-Lücke
Die Kunst bei der Auswahl von Technologien besteht darin, Proof-of-Concept-Lösungen (PoCs) zu entwerfen, die Annahmen zu validieren und die wichtigsten strategischen Anforderungen testen. PoCs sind besonders wichtig bei der Validierung neuer Technologien oder der Bewertung von SaaS-Plattformen. Aber auch die Verwendung von Agile Spikes zur Überprüfung von Technologiekomponenten von Drittanbietern hilft, die Entscheidungsfindung zu beschleunigen und teure Fehler zu vermeiden.
Den Proof of Concept zu überspringen – entweder weil Sie es vermeintlich besser wissen, etwas gelesen haben, unter Zeitdruck stehen oder Ihrem Anbieter blind vertrauen – ist ein gravierender Fehler. Selbst wenn ein PoC grünes Licht für eine Technologie gibt: Was Sie daraus lernen, kann Ihnen helfen, die Priorität auf machbare Implementierungen zu lenken.
9. Keine Entscheidungsmatrizen
Wenn viele Personen an der Prüfung und Bewertung neuer Tools und Technologien beteiligt sind, ist die Entscheidungsmatrix ein gängiger Ansatz, eine datengestützte Entscheidung zu unterstützen. Die Merkmale und Fähigkeiten werden dabei nach ihrer Wichtigkeit priorisiert und dann von einem Prüfungsausschuss bewertet. Die Matrix errechnet die Gesamtpunktzahl.
Wenn zu viele Personen beteiligt sind, zu viele Merkmale ausgewählt werden oder willkürliche Gewichtungen vorgenommen werden, können solche Tools allerdings schnell aus dem Ruder laufen. Die Tabellenkalkulation rückt dann die Präferenzen des Autors in den Vordergrund, während die Mitarbeiter vor lauter Schnickschnack den Blick für das verlieren, was strategisch bewertet werden soll.
Bevor Sie sich an eine Entscheidungsmatrix wagen, sollten Sie in Erwägung ziehen, die Merkmale der Lösungen auf das wesentliche Geschäftsproblem zu reduzieren. Das kann zielführender sein, als lange Funktionslisten zu beauftragen, die von zu vielen Prüfern bewertet werden müssen.
9. Langzeit-Ignoranz
Technologien sollten auf der Grundlage von Benutzerfreundlichkeit und Zeit bis zur Wertschöpfung bewertet werden. Das bedeutet allerdings nicht, dass längerfristige Architektur-, Wartungs- und Supportüberlegungen nicht wichtig sind oder keine Bewertung erfordern.
Der Schlüssel zum Erfolg liegt darin, zu entscheiden, wann sie bewertet werden sollen, welches die wichtigsten Überlegungen sind, wer an der Überprüfung beteiligt sein wird und wie viel Zeit in die Bewertung investiert werden soll. Dazu sollten Bedenken, die die Technologie-Teams zu Beginn einer Bewertung berücksichtigen sollen, von den längerfristigen Faktoren, die in den Entscheidungsprozess einfließen sollen, getrennt werden.
10. Datenschutz-Verzicht
Zeitdruck oder (blindes) Vertrauen in die von Ihnen gewählte Technologie sind keine guten Ausreden, um eine Prüfung der Service Level Agreements (SLA) oder die Bewertung der Sicherheits- und Datenschutzpraktiken des Anbieters zu vernachlässigen. Dazu brauchen Sie die richtigen Fachkenntnisse, Verhandlungsfähigkeiten und Tools – und einen effizienten Bewertungsprozess.
Größere Unternehmen, die SLA-, Datenschutz- und Sicherheitsüberprüfungen intern durchführen, müssen zeitsparend vorgehen und sich darauf konzentrieren, die Bewertung auf die wichtigsten Risiken abzustimmen. Kleinere Unternehmen mit weniger Know-How sollten dafür externen Rat einholen.
11. Finanzielle und rechtliche Verzögerungen
Viele SaaS-Angebote, API-Dienste und Cloud-native Technologien warten mit verbrauchsabhängigen Preismodellen auf. Die Betriebskosten entsprechen möglicherweise nicht dem Budget. Rechtliche Überprüfungen sind besonders wichtig für Unternehmen in regulierten Branchen oder Unternehmen, die weltweit tätig sind. Vorsicht: Die Überprüfung von Compliance-Faktoren kann in beiden Fällen besonders zeitaufwändig sein. Sowohl bei finanziellen als auch bei rechtlichen Prüfungen kosten Verzögerungen viel Geld.
Deshalb sollten Sie nicht bis zum Ende des technologischen Überprüfungsprozesses warten, bis Sie Finanz- und Rechtsexperten hinzuzuziehen. Stattdessen sollten Sie diese möglichst früh miteinbeziehen und sie darum bitten, sich zu äußern, was überprüft werden muss – bevor Entscheidungen zur Technologieauswahl getroffen werden. Außerdem sollten Sie Ihre finanziellen und rechtlichen Ressourcen nicht überstrapazieren, indem Sie zu viele Bewertungen auf einmal durchführen.
Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.
*Isaac Sacolick ist Autor des Amazon-Bestsellers „Diving Digital: The Leader´s Guide to Business Transformation thourh Technology“. Er schreibt als freier Autor unter anderem für unsere US-Schwesterpublikation CIO.com.
Be the first to comment