SHIFT to AI
← Blog

KI im Mittelstand: Wer schaut da eigentlich noch drauf?

Angebote, Protokolle, Auswertungen entstehen schneller. Wer prüft sie? Beobachtungen aus einem Vormittag zu KI im Mittelstand.

Am Freitagvormittag saßen beim Arbeitskreis „KI im Mittelstand“ in Ostwestfalen 35 Teilnehmende. Ich hatte für die Gruppenarbeit drei Fragen vorbereitet:

  1. Was entsteht bei dir inzwischen schneller?
  2. Wer prüft es?
  3. Angenommen, du gewinnst vier Stunden pro Woche: Wofür würdest du sie verwenden?

Später habe ich die zurückgelassenen Arbeitsblätter durchgesehen. Heraus stach für mich sinngemäß: Zum Prüfen fehlt die Zeit.

Das beschäftigt mich auch in meiner Arbeit als Entwickler. Ich kann mehr Code erzeugen lassen, als ich sorgfältig beurteilen kann. Fremden Code en masse lesen ist eine Zumutung. Hier stand dasselbe Problem nun neben Angeboten, Protokollen und Präsentationen, am Ende eines produktiven Vormittages, in dem es um aktuelle Sorgen, Strategieänderungen, Change Management und auch Vibe Coding ging. Nach all dem Austausch bleibt also ein Thema prominent: Woher die Zeit für Sorgfalt nehmen?

Das ist aber glücklicherweise nicht alles gewesen – es gab auch Stimmen, die meinten: endlich mehr Zeit zur Weiterbildung, zum Planen neuer Projekte, zum Innovieren. Der Wunsch nach mehr Muße für neue Ideen steht also neben der Gefahr, dass die Zeit für Evaluation fehlt. Im Arbeitsalltag entscheidet sich, ob die schnellere Erstellung Raum dafür schafft oder ob nur noch mehr Arbeit nachrückt.

Beim Lesen der Antworten fällt auf, wie viel zwischen der ersten und der dritten Frage steckt. Erst einmal muss jemand feststellen, ob das schneller erstellte Ergebnis überhaupt brauchbar ist. Wie viel Zeit danach übrig bleibt, weiß man da noch lange nicht.

KI im Mittelstand: Angebote, Protokolle, Nachweise

Erwähnte Artefakte waren beispielsweise Angebote und Berichte, Wissensdokumente, Recherchen, Präsentationen und Texte für die Kommunikation nach außen. Code kam ebenfalls vor.

Aus den Gesprächen sind mir zwei Beispiele geblieben, die ich hier ohne den jeweiligen betrieblichen Kontext wiedergebe. Bei einem ging es um Protokolle aus Fotos: Ergebnisse festhalten, ohne alles von Hand nachzubereiten. Beim anderen um Informationen für Nachweise, die sich jetzt schneller zusammentragen lassen. Wer solche Dokumente regelmäßig zusammenbauen muss, hat damit einen lästigen Teil der Arbeit schneller erledigt.

Die Parallele kenne ich aus meiner Arbeit mit Coding-Agenten: Ich kann mühselige, unliebsame Arbeit abgeben, wenn ich gelernt habe, wie. Und dann hat man Lebenszeit frei für die Dinge, die einen wirklich interessieren oder fordern.

Beim bloßen Prüfen kann dafür etwas fehlen, das vorher nebenbei entstanden ist. Wenn ich Angaben selbst zusammentrage, bemerke ich unterwegs, wo etwas unklar ist. Ich erinnere mich an die widersprüchliche Quelle oder an die Zahl, die ich noch nachfragen wollte. Bekomme ich ein fertiges Dokument, muss ich diese Stellen erst finden.

Beim Code ist es ähnlich: Wenn ich ihn über Tage hinweg schreibe, kenne ich die Entscheidungen und Umwege, die zum Ergebnis geführt haben. Das macht ihn nicht automatisch richtig, aber ich weiß, wo ich genauer hinsehen muss. Wenn ich Code, schnipp!, so schnell generiert bekomme, dann fehlt das. Jede Zeile eine mögliche Falle, ein Einfallstor für Bugs.

Ein Beispiel dafür wäre ein Gesprächsprotokoll, in dem ein Termin steht. Wurde der zugesagt oder nur vorgeschlagen? Der Satz kann in beiden Fällen tadellos formuliert sein. Für die Prüfung brauche ich das Gespräch oder jemanden, der dabei war. Im fertigen Text steht dieser Kontext nicht automatisch mit drin. Ohne Quellen oder ergänzende Notizen muss ich ihn für die Prüfung erst wieder beschaffen.

Was nicht geschrieben steht, existiert nicht.

Eine Folge, die ich daraus für Trainings weitergebe: Wenn beim Delegieren dieser Kontext verloren geht, muss man zweierlei anfertigen. Ein Logbuch der Arbeit und Entscheidungen und ein Endprodukt. Das Logbuch muss die überprüfbaren Grundlagen festhalten: verwendete Quellen, getroffene Annahmen, Entscheidungen und offene Fragen. Fehlt diese Grundlage, ist das Ergebnis für mich unverwertbar. Ich kann dann nicht unterscheiden, was nachvollziehbar erarbeitet wurde und was bloß plausibel klingt oder halluziniert ist.

Bei Code frage ich entsprechend nach den Annahmen hinter einer Änderung. Das ist auch ein Teil meiner Checkliste für KI-Code-Reviews. Im Protokoll wäre die Annahme vielleicht ein verbindlicher Termin. In einem Angebot könnte es eine Leistung sein, die so noch niemand abgestimmt hat.

Wer hat Zeit zum Prüfen?

Genannt wurde die Prüfung durch den Verfasser selbst oder durch das Team. Das kann ein funktionierender Ablauf sein. Ich würde dann gern wissen, wie er beim letzten Ergebnis aussah: Wer hat tatsächlich draufgeschaut, und was musste danach noch geändert werden?

Genannt wurde auch die Prüfung durch Vertrieb und Geschäftsführung, etwa bei Präsentationen und Gesprächsnotizen. Mich würde interessieren, welche Vorprüfung stattfindet, bevor diese Ergebnisse zur Freigabe vorliegen.

Zur Kundenprojektleitung kam die Rückmeldung, dass sie prüft, aber dafür eigentlich keine Zeit hat.

Kommt die zusätzliche Prüfarbeit bei Menschen an, deren Kalender bereits voll ist? Welche Kapazität ist dafür vorgesehen?

Die Angabe einer zuständigen Person allein reicht mir nicht. Wenn sie das Prüfen irgendwo zwischen ihre anderen Aufgaben schieben muss, möchte ich wissen, was liegen bleibt. Ein schneller geschriebenes Angebot kann tagelang auf Freigabe warten. Dann kommt die Zeitersparnis beim Kunden womöglich gar nicht an. Ein interner Bericht kann schon als Entscheidungsgrundlage benutzt werden, obwohl noch Fragen offen sind, weil der fertige Bericht den Eindruck vermittelt, die offenen Fragen seien bereits geklärt.

Ich würde deshalb beim Prüfen auch über den Umfang reden. Muss wirklich das ganze Dokument fertig sein, bevor jemand die entscheidende Annahme abklärt? Bei Code arbeite ich dafür mit kleinen, reviewbaren Änderungen. Bei einem Angebot würde ich die fragliche Leistung klären, bevor ich die übrigen Seiten darauf aufbaue.

Was mit der freien Zeit passieren sollte

Für die gedachten vier Stunden gab es reichlich Verwendung. Genannt wurden Akquise, Kundenkommunikation, Wissensmanagement und Prozessverbesserungen. Andere wollten mehr planen, reflektieren, lernen oder neue Projekte beginnen. Eine Antwort sah auch vor, einen Teil der Zeit tatsächlich freizunehmen.

Personalabbau stand in den ausgewerteten Antworten nicht.

Das sagt etwas über diese Antworten; was im Unternehmen darüber diskutiert wird, weiß ich damit nicht. Gefragt hatte ich nach der Verwendung freier Zeit.

Aus dem Raum kam außerdem der Gedanke, KI als Lernpartner zu nutzen. Die gewonnene Zeit könnte also dazu dienen, selbst mehr zu verstehen. Das passt für mich zu der Frage nach dem Prüfen: Wer dazulernt, kann beim nächsten Ergebnis womöglich besser beurteilen, ob es taugt.

Planung und Reflexion als Antworten finde ich besonders aufschlussreich. Dafür müsste im Arbeitsalltag eigentlich schon Platz sein. Wenn das erst mit erhoffter Zeitersparnis möglich wird, würde ich im Team genauer nachfragen, was diese Zeit bisher beansprucht. Und ich würde die nötige Prüfung mitrechnen, bevor die nächsten Projekte den Kalender füllen.

Dort, wo ich in Unternehmen war, war ganz selbstverständlich, dass der Arbeitsalltag 100% der Zeit frisst. Man hat keine freie Kapazität. Nicht zum Lernen, nicht für KI, nicht für neue Tools. Das hindert Adoption, das macht vielleicht auch die Vorgehensweise unzuverlässiger, weil man sich die Zeit für Sorgfalt nicht nimmt.

Und die Kreativität?

Zum Ende kam im Plenum die Sorge auf, dass mit immer reproduzierbareren Ergebnissen der Raum für Kreativität kleiner werden könnte. Wo kommen dann neue Ideen her, wenn KI alles mit einem Trend zur Perfektion hin macht? Ob KI tatsächlich in Richtung Perfektion führt, sehe ich anders. Die Sorge, beim Delegieren Gelegenheiten für eigene Entdeckungen zu verlieren, kann ich trotzdem nachvollziehen.

Ich sehe den Zusammenhang in meiner eigenen Arbeit anders. Ich brauche keine mühsame Umsetzung, um auf eine Idee zu kommen. Häufig bin ich froh, wenn ich schneller ausprobieren kann, ob sie funktioniert. Ich habe noch nie einen einzigartigen Algorithmus formuliert, weil die Codebase danach gefragt hat. Ich hatte eher zu viel Druck, um mich in bestehende Lösungen richtig einzulesen, und stattdessen das alte Mantra bedient: zwei Tage Programmieren ersparen einem fünf Minuten Nachdenken.

Trotzdem würde ich gern genauer verstehen, welche Erfahrung hinter der Frage steckt. Geht beim Abgeben einer Aufgabe auch etwas verloren, das bisher zum Entdecken beigetragen hat? Das lässt sich für mich nicht pauschal beantworten. Es hängt daran, welche Arbeit jemand abgibt und was er dabei bisher gelernt hat.

Nimm ein Ergebnis mit ins nächste Teamgespräch

Such dir etwas aus, das bei euch inzwischen schneller entsteht.

Nimm das letzte fertige Exemplar und frag die Person, die es geprüft hat, ob sie genug Zeit und die nötigen Informationen hatte.

Falls etwas gefehlt hat, setzt dort an. Vielleicht braucht die Prüfung einen festen Platz im Ablauf. Vielleicht fehlt die Quelle zu einer Angabe. Vielleicht könnt ihr eine offene Frage früher klären, bevor weitere Arbeit darauf aufbaut.

Beim nächsten Exemplar könnt ihr dann sehen, ob es auch früher verwendbar ist.