Warum wir in HR aufhören können, auf einen freien IT-Slot zu warten – und wo die Sache unbequem wird
Kennt ihr diesen Moment? Man sitzt in einer Runde, jemand hat eine wirklich gute Idee – eine App, die Lernen im Arbeitsalltag anders zugänglich macht, ein Werkzeug, das Skills sichtbar macht, irgendetwas, das man ausprobieren möchte. Wäre da nicht die Technik, die uns im Weg stünde…
Damit ist die Idee nicht abgelehnt. Sie ist auf einer Liste gelandet. Und dort verhungert sie langsam, während wir uns im nächsten Meeting wieder mit dem beschäftigen, was ohnehin schon da ist.
Ich glaube, dieser eine Einwand hat in HR mehr Innovation verhindert als jedes Budget.
Das eigentliche Problem ist nicht Fantasielosigkeit
An Ideen mangelt es uns nämlich nicht. Es mangelt an der Möglichkeit, sie erfahrbar zu machen, bevor sie tot sind. Zwischen dem Gedanken und dem ersten Mal, dass jemand etwas anklicken kann, lagen bisher immer ein Business Case, eine Priorisierungsrunde und ein gewaltiger IT-Backlog. IT-Verantwortliche, mit denen ich oft rede, sagen selbst, dass ihre Rückstände sie an strategischen Projekten hindern. Hier geht es oft schlichtweg um Kapazitätsmangel.
Und was passiert stattdessen? Wir gehen auf Toolsuche. Wir kaufen Systeme, die auf dem Papier passen. Oder, und das passiert uns sogar noch häufiger, ein Anbieter macht uns überhaupt erst auf ein eventuelles Problem aufmerksam, von dem wir annehmen, dass es eines sein könnte. Verliebt aufgrund eines ersten Sales-Gesprächs versuchen wir diese Tools dann dem Business schmackhaft zu machen. Dabei wissen wir noch gar nicht, wo eigentlich der Schuh im Business drückt – wir vermuten es einfach.
Und dann? 82 Prozent der Unternehmen schöpfen ihre HR-Software nicht annähernd aus, die durchschnittliche Nutzungsquote eines HR-Systems liegt bei rund einem Drittel der vorgesehenen Anwender:innen (vgl. SelectSoftwareReviews 2026). Wir kaufen also teuer ein, was wir vorher nie ausprobieren konnten – und bauen dann einen Workaround um den anderen, weil die Tools Limitierungen aufweisen, die wir vorher nicht kennen konnten.
Aber Hand aufs Herz: Wie sollen wir wissen, ob eine Idee trägt, wenn wir sie nie in der Hand hatten?
Was sich gerade tatsächlich verändert hat
Genau hier ist in den letzten Monaten etwas gekippt. Es braucht heute keinen Entwicklungsauftrag mehr, um eine Idee erfahrbar zu machen. Es braucht einen API-Key und etwas freie Zeit.
Und das Beste: Das ist kein Märchen für Technikbegeisterte! Inzwischen sind viele derjenigen, die mit KI Software bauen, keine professionellen Entwickler:innen, sondern Menschen, die ihr Fachproblem am besten kennen. Prototyping-Zeiten schrumpfen von Wochen auf Stunden. Auswertungen von McKinsey weisen bei Routineaufgaben in der Softwareentwicklung rund 46 Prozent Zeitersparnis aus – bei hochkomplexer Arbeit dagegen unter 10 Prozent (vgl. McKinsey & Company 2023).
Genau diese Differenz ist unser Spielfeld. Wir reden nicht davon, dass HR künftig Kernsysteme baut. Wir reden davon, dass der erste, einfache Versuch heute in Stunden möglich ist.
Übersetzt heißt das: Wir können heute ein eigenes Skill-Tool bauen. Eine kleine Lern-App, die genau die Logik hat, die wir uns im Workshop ausgedacht haben. Einen Feedback-Prototypen, um zu sehen, ob unsere schöne Systematik in der Praxis überhaupt jemand versteht. Nicht als fertiges Produkt, sondern als MVP, als kleiner erster Prototyp. So können wir testen, ob die Idee Sinn macht.
„Geht nicht" und „dauert lange" klangen jahrelang gleich
Das ist der entscheidende Punkt. Bisher haben wir beide Sätze als dasselbe behandelt, weil das Ergebnis dasselbe war: Die Idee kam nicht in die Welt. Jetzt sind es zwei verschiedene Dinge. Der produktive Betrieb, das Aufsetzen des Prozesses – ja, das dauert noch. Aber der Versuch dauert nicht mehr lange. Und der Versuch ist der Teil, in dem wir lernen, ob unsere Idee überhaupt eine gute war.
Der Fantasie sind gerade deutlich weniger Grenzen gesetzt als noch vor zwei Jahren. Das ändert, wie mutig wir im Workshop denken dürfen. Wer weiß, dass er das Ergebnis am Freitag ausprobieren kann, denkt anders als jemand, der von vornherein nur das vorschlägt, was budgetierbar klingt.
Und jetzt der Teil, den ich nicht weglassen will
Jedes dieser Experimente kostet Energie, die nicht auf unserer Rechnung erscheint. Die Internationale Energieagentur rechnet damit, dass sich der weltweite Strombedarf von Rechenzentren bis 2030 auf rund 945 Terawattstunden verdoppelt – mehr als der heutige Jahresverbrauch Japans. Bei KI-spezifischer Infrastruktur wird bis dahin mit einer Verdreifachung des Energiebedarfs gerechnet (vgl. IEA 2025).
Ich löse diesen Widerspruch hier nicht auf, weil ich ihn nicht auflösen kann. Wir sollen gleichzeitig explorieren und verantwortungsvoll handeln, und beides zieht in unterschiedliche Richtungen. Wer mithalten will, probiert viel aus. Wer wenig ausprobiert, spart Ressourcen und verliert Anschluss. Diese Ambidextrie sauber zu bedienen, ist ehrlicherweise schwer.
Was ich daraus mitnehme, ist bescheidener: Nicht alles bauen, was baubar ist. Ein Experiment sollte eine Frage beantworten, nicht bloß beeindrucken. Und wenn die Antwort nach zwei Versuchen „nein“ lautet, ist das das Ergebnis, nicht der Anlass für einen dritten Versuch.
Was setzt das konkret voraus?
Nicht Budget, sondern eine andere Bewertung des Ergebnisses.
Ein verworfener Prototyp ist keine Fehlinvestition, sondern eine früh gewonnene Erkenntnis und zwar zu einem Bruchteil der Kosten, die dieselbe Erkenntnis nach einer Ausschreibung verursacht hätte. Solange verworfene Versuche in der Organisation als vergeudete Zeit verbucht werden, entsteht eine stille Selbstzensur: Vorgeschlagen wird nur noch, was mit hinreichender Sicherheit funktioniert. Das ist die teuerste Form von Vorsicht, die wir uns leisten können, weil sie unsichtbar bleibt.
Ein Experiment braucht deshalb eine Fragestellung und eine Frist. Ohne beides wird aus dem Versuch Beschäftigung und irgendwann ein System, das niemand verantwortet. Der Zuschnitt entscheidet über den Erkenntniswert: nicht das umfassende System, sondern der eine Prozessschritt, an dem sich zeigt, ob die zugrunde liegende Annahme überhaupt trägt.
Zwei Grenzen sind dabei nicht verhandelbar. Experimente laufen ohne echte Personendaten, für die Prüfung einer Idee genügen synthetische Profile. Und die IT gehört von Beginn an eingebunden, nicht als Genehmigungsinstanz, sondern als Mitwisserin: Ein Prototyp, der intern nachvollziehbar entstanden ist, hat im Entscheidungsgremium ein anderes Gewicht als einer, der unvermittelt auftaucht.
Bleibt die Frage der Deklaration. Ein Prototyp, der für ein fertiges Produkt gehalten wird, richtet mehr Schaden an als gar keiner, weil er Erwartungen erzeugt, die eine spätere Umsetzung nicht einlösen kann. Was demonstriert, muss als Demonstration kenntlich sei
Worauf noch warten...
Pippi Langstrumpf hat als Kinderfigur überlebt, weil sie die Welt nicht so hingenommen hat, wie sie ihr präsentiert wurde. Wir in HR haben uns lange damit abgefunden, dass die Umsetzung anderen gehört und wir die Anforderungen liefern.
Das stimmt nicht mehr. Nicht weil wir plötzlich so tun könnten, als wären wir die IT, sondern weil der Abstand zwischen einer Idee und etwas Anfassbarem auf einen Nachmittag geschrumpft ist.
