Wenn Sie auf schlechte Technologieentscheidungen verzichten können, sollten Sie diese 11 Wege nicht beschreiten. Foto: GaudiLab – shutterstock.comSind 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ößlichkeitenWenn 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 egalTechnologieentscheider 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-AskeseIn 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ßeEs 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ändlichkeitDie 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äumnisWenn 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ückeDie 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 EntscheidungsmatrizenWenn 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-IgnoranzTechnologien 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-VerzichtZeitdruck 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ögerungenViele 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. (fm)Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.8 Fehler in der KommunikationDiese Kommunikationsfehler sollten Sie vermeiden Foto: Sergey Nivens – shutterstock.comWas Sie in Gesprächen und Debatten tunlichst unterlassen sollten, um Fehlinformationen, Konflikte und Imageschäden zu vermeiden.Fachchinesisch benutzen Foto: Gearstd – shutterstock.comMit technischem Fachjargon um sich zu werfen, ist der größte Fehler, den IT-Verantwortliche in Gesprächen mit Nicht-IT’lern machen können. Viele Experten können nicht richtig einschätzen, wie tief das eigene Fachwissen geht und wo im Gegenzug das Fachwissen des Gegenübers endet. Hier kann es schnell zu Missverständnissen und Kommunikationsstörungen kommen.Technische Probleme beklagen Foto: Stokkete – shutterstock.comWer in der Team- oder Vorstandssitzung über technische Probleme im Rechenzentrum oder anderen Unternehmensstellen klagt, darf sich nicht wundern, wenn diese Beschwerden Irritation und Unsicherheit auslösen. Kollegen, die nicht mit den beschriebenen Interna vertraut sind, verstehen in einem solchen Fall oft nur “Der hat massive Probleme, die er nicht in den Griff bekommt.” Natürlich müssen IT-Probleme auch im großen Kreis thematisiert werden dürfen, das jedoch besser in einer sachlichen Art und Weise, die jeder verstehen und nachvollziehen kann.Wie ein Verkäufer reden Foto: Evan El-Amin – shutterstock.comManager, die bislang mit einem Business-Hintergrund tätig waren, und IT-Führungspositionen übernehmen, sprechen ihre neuen Untergebenen in einem aufgeblasenen Ton an und wirken dabei häufig wie Verkäufer, die die neueste Kollektion heiße Luft präsentieren.Keine Fragen stellen Foto: ra2studio – shutterstock.comGute CIOs stellen sinnvolle Fragen und hören auf die Antworten. So gelangen oft neue Aspekte in die Diskussion. Dazu werden die Kollegen eingebunden und die Beziehung zwischen Manager und Team gestärkt. Warum viele IT-Verantwortliche anders vorgehen? Sie haben (meist unbegründet) Angst, als unwissend und inkompetent dazustehen.Niemanden einbinden Foto: Syda Productions – shutterstock.comGut ausgebildete CIOs sind überzeugt von ihren eigenen Ideen, welche Techniken sich wie am besten implementieren lassen. Viele vergessen darüber jedoch, dass auch die gesamte IT-Abteilung und der Vorstand womöglich noch eigene Ideen haben. Wenn CIOs ihre eigenen Vorstellungen ohne Rückfrage durchdrücken, verärgern sie deshalb viele Kollegen – selbst, wenn es die beste und richtige Wahl war.Ängste schüren Foto: Tyler Olson – shutterstock.comWenn der Vorstand überzeugt werden muss, das IT-Budget aufzustocken, diese oder jene Anschaffung oder Migration vorzunehmen, neigen manche CIOs dazu, in ihrer Argumentation zu übertreiben oder zu simplifizieren. Wenn neue Server angeschafft werden sollen, hört sich das dann so an: “Wenn wir bis kommende Woche nicht zehn neue Server im Schrank stehen haben, bricht der ganze Laden zusammen!”Den Wertbeitrag nicht herausstellen Foto: Sergey Nivens – shutterstock.comViele CIOs betonen, wie wichtig die Unternehmens-IT ist. Die Vorstände verstehen aber häufig nicht, was die IT konkret zum unternehmerischen Erfolg beiträgt. Deshalb sollten IT-Verantwortliche in Präsentationen und Diskussionen immer noch einen Schritt weitergehen, als nur in den eigenen Grenzen zu argumentieren.Mit PowerPoint einschläfern Foto: Matej Kastelic – shutterstock.comZu viele Folien, zu viele Nichtigkeiten. Effiziente Präsentationen zeichnen sich dadurch aus, dass sie sich auf die wichtigsten Infos konzentrieren, die das zuhörende Publikum direkt betreffen. Im besten Fall kann gänzlich auf PowerPoint verzichtet werden – gute Präsentationen zeichnen sich dadurch aus, dass sie von selbst im Gedächtnis haften bleiben und nicht durch eine Armada von Aufzählungspunkten.
11 Wege: So geht schlechte Technologieentscheidung
Wenn Sie auf schlechte Technologieentscheidungen verzichten können, sollten Sie diese 11 Wege nicht beschreiten. Foto: GaudiLab – shutterstock.comSind 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ößlichkeitenWenn 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 egalTechnologieentscheider 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-AskeseIn 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ßeEs 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ändlichkeitDie 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äumnisWenn 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ückeDie 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 EntscheidungsmatrizenWenn 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-IgnoranzTechnologien 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-VerzichtZeitdruck 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ögerungenViele 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. (fm)Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.8 Fehler in der KommunikationDiese Kommunikationsfehler sollten Sie vermeiden Foto: Sergey Nivens – shutterstock.comWas Sie in Gesprächen und Debatten tunlichst unterlassen sollten, um Fehlinformationen, Konflikte und Imageschäden zu vermeiden.Fachchinesisch benutzen Foto: Gearstd – shutterstock.comMit technischem Fachjargon um sich zu werfen, ist der größte Fehler, den IT-Verantwortliche in Gesprächen mit Nicht-IT’lern machen können. Viele Experten können nicht richtig einschätzen, wie tief das eigene Fachwissen geht und wo im Gegenzug das Fachwissen des Gegenübers endet. Hier kann es schnell zu Missverständnissen und Kommunikationsstörungen kommen.Technische Probleme beklagen Foto: Stokkete – shutterstock.comWer in der Team- oder Vorstandssitzung über technische Probleme im Rechenzentrum oder anderen Unternehmensstellen klagt, darf sich nicht wundern, wenn diese Beschwerden Irritation und Unsicherheit auslösen. Kollegen, die nicht mit den beschriebenen Interna vertraut sind, verstehen in einem solchen Fall oft nur “Der hat massive Probleme, die er nicht in den Griff bekommt.” Natürlich müssen IT-Probleme auch im großen Kreis thematisiert werden dürfen, das jedoch besser in einer sachlichen Art und Weise, die jeder verstehen und nachvollziehen kann.Wie ein Verkäufer reden Foto: Evan El-Amin – shutterstock.comManager, die bislang mit einem Business-Hintergrund tätig waren, und IT-Führungspositionen übernehmen, sprechen ihre neuen Untergebenen in einem aufgeblasenen Ton an und wirken dabei häufig wie Verkäufer, die die neueste Kollektion heiße Luft präsentieren.Keine Fragen stellen Foto: ra2studio – shutterstock.comGute CIOs stellen sinnvolle Fragen und hören auf die Antworten. So gelangen oft neue Aspekte in die Diskussion. Dazu werden die Kollegen eingebunden und die Beziehung zwischen Manager und Team gestärkt. Warum viele IT-Verantwortliche anders vorgehen? Sie haben (meist unbegründet) Angst, als unwissend und inkompetent dazustehen.Niemanden einbinden Foto: Syda Productions – shutterstock.comGut ausgebildete CIOs sind überzeugt von ihren eigenen Ideen, welche Techniken sich wie am besten implementieren lassen. Viele vergessen darüber jedoch, dass auch die gesamte IT-Abteilung und der Vorstand womöglich noch eigene Ideen haben. Wenn CIOs ihre eigenen Vorstellungen ohne Rückfrage durchdrücken, verärgern sie deshalb viele Kollegen – selbst, wenn es die beste und richtige Wahl war.Ängste schüren Foto: Tyler Olson – shutterstock.comWenn der Vorstand überzeugt werden muss, das IT-Budget aufzustocken, diese oder jene Anschaffung oder Migration vorzunehmen, neigen manche CIOs dazu, in ihrer Argumentation zu übertreiben oder zu simplifizieren. Wenn neue Server angeschafft werden sollen, hört sich das dann so an: “Wenn wir bis kommende Woche nicht zehn neue Server im Schrank stehen haben, bricht der ganze Laden zusammen!”Den Wertbeitrag nicht herausstellen Foto: Sergey Nivens – shutterstock.comViele CIOs betonen, wie wichtig die Unternehmens-IT ist. Die Vorstände verstehen aber häufig nicht, was die IT konkret zum unternehmerischen Erfolg beiträgt. Deshalb sollten IT-Verantwortliche in Präsentationen und Diskussionen immer noch einen Schritt weitergehen, als nur in den eigenen Grenzen zu argumentieren.Mit PowerPoint einschläfern Foto: Matej Kastelic – shutterstock.comZu viele Folien, zu viele Nichtigkeiten. Effiziente Präsentationen zeichnen sich dadurch aus, dass sie sich auf die wichtigsten Infos konzentrieren, die das zuhörende Publikum direkt betreffen. Im besten Fall kann gänzlich auf PowerPoint verzichtet werden – gute Präsentationen zeichnen sich dadurch aus, dass sie von selbst im Gedächtnis haften bleiben und nicht durch eine Armada von Aufzählungspunkten.
11 Wege: So geht schlechte Technologieentscheidung Wenn Sie auf schlechte Technologieentscheidungen verzichten können, sollten Sie diese 11 Wege nicht beschreiten. Foto: GaudiLab – shutterstock.comSind 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ößlichkeitenWenn 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 egalTechnologieentscheider 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-AskeseIn 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ßeEs 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ändlichkeitDie 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äumnisWenn 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ückeDie 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 EntscheidungsmatrizenWenn 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-IgnoranzTechnologien 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-VerzichtZeitdruck 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ögerungenViele 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. (fm)Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.8 Fehler in der KommunikationDiese Kommunikationsfehler sollten Sie vermeiden Foto: Sergey Nivens – shutterstock.comWas Sie in Gesprächen und Debatten tunlichst unterlassen sollten, um Fehlinformationen, Konflikte und Imageschäden zu vermeiden.Fachchinesisch benutzen Foto: Gearstd – shutterstock.comMit technischem Fachjargon um sich zu werfen, ist der größte Fehler, den IT-Verantwortliche in Gesprächen mit Nicht-IT’lern machen können. Viele Experten können nicht richtig einschätzen, wie tief das eigene Fachwissen geht und wo im Gegenzug das Fachwissen des Gegenübers endet. Hier kann es schnell zu Missverständnissen und Kommunikationsstörungen kommen.Technische Probleme beklagen Foto: Stokkete – shutterstock.comWer in der Team- oder Vorstandssitzung über technische Probleme im Rechenzentrum oder anderen Unternehmensstellen klagt, darf sich nicht wundern, wenn diese Beschwerden Irritation und Unsicherheit auslösen. Kollegen, die nicht mit den beschriebenen Interna vertraut sind, verstehen in einem solchen Fall oft nur “Der hat massive Probleme, die er nicht in den Griff bekommt.” Natürlich müssen IT-Probleme auch im großen Kreis thematisiert werden dürfen, das jedoch besser in einer sachlichen Art und Weise, die jeder verstehen und nachvollziehen kann.Wie ein Verkäufer reden Foto: Evan El-Amin – shutterstock.comManager, die bislang mit einem Business-Hintergrund tätig waren, und IT-Führungspositionen übernehmen, sprechen ihre neuen Untergebenen in einem aufgeblasenen Ton an und wirken dabei häufig wie Verkäufer, die die neueste Kollektion heiße Luft präsentieren.Keine Fragen stellen Foto: ra2studio – shutterstock.comGute CIOs stellen sinnvolle Fragen und hören auf die Antworten. So gelangen oft neue Aspekte in die Diskussion. Dazu werden die Kollegen eingebunden und die Beziehung zwischen Manager und Team gestärkt. Warum viele IT-Verantwortliche anders vorgehen? Sie haben (meist unbegründet) Angst, als unwissend und inkompetent dazustehen.Niemanden einbinden Foto: Syda Productions – shutterstock.comGut ausgebildete CIOs sind überzeugt von ihren eigenen Ideen, welche Techniken sich wie am besten implementieren lassen. Viele vergessen darüber jedoch, dass auch die gesamte IT-Abteilung und der Vorstand womöglich noch eigene Ideen haben. Wenn CIOs ihre eigenen Vorstellungen ohne Rückfrage durchdrücken, verärgern sie deshalb viele Kollegen – selbst, wenn es die beste und richtige Wahl war.Ängste schüren Foto: Tyler Olson – shutterstock.comWenn der Vorstand überzeugt werden muss, das IT-Budget aufzustocken, diese oder jene Anschaffung oder Migration vorzunehmen, neigen manche CIOs dazu, in ihrer Argumentation zu übertreiben oder zu simplifizieren. Wenn neue Server angeschafft werden sollen, hört sich das dann so an: “Wenn wir bis kommende Woche nicht zehn neue Server im Schrank stehen haben, bricht der ganze Laden zusammen!”Den Wertbeitrag nicht herausstellen Foto: Sergey Nivens – shutterstock.comViele CIOs betonen, wie wichtig die Unternehmens-IT ist. Die Vorstände verstehen aber häufig nicht, was die IT konkret zum unternehmerischen Erfolg beiträgt. Deshalb sollten IT-Verantwortliche in Präsentationen und Diskussionen immer noch einen Schritt weitergehen, als nur in den eigenen Grenzen zu argumentieren.Mit PowerPoint einschläfern Foto: Matej Kastelic – shutterstock.comZu viele Folien, zu viele Nichtigkeiten. Effiziente Präsentationen zeichnen sich dadurch aus, dass sie sich auf die wichtigsten Infos konzentrieren, die das zuhörende Publikum direkt betreffen. Im besten Fall kann gänzlich auf PowerPoint verzichtet werden – gute Präsentationen zeichnen sich dadurch aus, dass sie von selbst im Gedächtnis haften bleiben und nicht durch eine Armada von Aufzählungspunkten.