Software muss sich an Benutzer anpassen: Warum gute Unternehmenssoftware Arbeit erleichtert

Software muss sich an den Benutzer anpassen, weil effiziente Arbeit nicht aus der Bedienlogik eines Systems entstehen sollte. Rollenbasierte Oberflächen, kontextbezogene Informationen und passende Eingabewege reduzieren Suchaufwand, Doppelarbeit und Fehlbedienung. Entscheidend ist nicht ein modischer Auftritt, sondern ob Mitarbeiter ihre Aufgaben im realen Arbeitsumfeld zuverlässig erledigen können.

Warum müssen sich Mitarbeiter noch immer an ihre Software anpassen?

In vielen Unternehmen beginnt der Arbeitstag nicht mit der eigentlichen Aufgabe, sondern mit der Suche nach dem richtigen Einstieg. Der Mitarbeiter öffnet das ERP, wechselt in das Dokumentenmanagement, sucht eine E-Mail, prüft eine Excel-Liste und fragt anschließend einen Kollegen, welche Information tatsächlich gilt. Jeder Schritt ist für sich betrachtet überschaubar. In der Summe entsteht ein Arbeitsablauf, der mehr Aufmerksamkeit für die Systemlandschaft als für den Kundenauftrag verlangt.

Dieses Muster ist in mittelständischen Betrieben besonders sichtbar, weil operative Prozesse selten vollständig innerhalb einer einzigen Anwendung stattfinden. Ein Kundendienstmonteur benötigt Auftragsdaten, Anlagenhistorie, technische Unterlagen, frühere Störungsberichte und Informationen zur Materialverfügbarkeit. Die Disposition arbeitet mit Terminen, Qualifikationen, Fahrzeiten und Prioritäten. Der Projektleiter betrachtet Kosten, Fortschritt, Nachträge und Abnahmen. Die Buchhaltung benötigt wiederum prüfbare Leistungsnachweise und vollständige Auftragsdaten.

Trotz dieser unterschiedlichen Aufgaben erhalten alle Benutzer häufig dieselbe Grundoberfläche. Sie sehen dieselben Menüs, dieselben Datensätze und dieselben Funktionsbereiche, obwohl nur ein kleiner Teil davon für ihre momentane Tätigkeit relevant ist. Die eigentliche Arbeit wird dadurch von Navigation, Interpretation und manueller Auswahl überlagert.

Schlechte Bedienbarkeit ist deshalb nicht nur eine Frage persönlicher Vorlieben. Sie verändert den Prozess. Mitarbeiter vermeiden aufwendige Eingaben, legen eigene Nebenlisten an, speichern Dokumente lokal oder verschieben die Nachbereitung auf einen späteren Zeitpunkt. Aus einer unpassenden Benutzeroberfläche entstehen damit Datenlücken, Medienbrüche und zusätzliche Kontrollschritte.

Woran zeigt sich digitale Reibung im betrieblichen Alltag?

Digitale Reibung entsteht überall dort, wo ein System mehr Aufwand erzeugt, als für die fachliche Aufgabe erforderlich wäre. Dazu gehören lange Suchwege, wiederholte Anmeldungen, unverständliche Feldbezeichnungen, doppelte Eingaben, häufige Systemwechsel oder fehlende Informationen über den aktuellen Vorgang.

Ein typisches Beispiel ist die mobile Auftragsbearbeitung. Der Monteur sieht zwar den Auftrag, aber nicht den letzten Servicebericht. Das Dokument liegt in einem anderen System, dessen Anmeldung auf dem Smartphone umständlich ist. Statt weiterzusuchen, ruft er die Disposition an. Die Disponentin unterbricht ihre eigene Arbeit, öffnet mehrere Anwendungen und sendet das Dokument per E-Mail. Formal funktionieren alle beteiligten Systeme. Operativ erzeugen sie dennoch unnötige Arbeit.

Die Folgen solcher Reibung sind messbar. Eine internationale Untersuchung von TeamViewer, https://www.teamviewer.com/, aus dem Jahr 2025 ergab, dass 48 Prozent der Befragten durch technische Reibung Verzögerungen in wichtigen betrieblichen Abläufen oder Projekten erlebt hatten. Durchschnittlich gingen nach Angaben der Teilnehmer 1,3 Arbeitstage pro Monat durch nicht ausreichend funktionierende Arbeitsplatztechnologie verloren.

Nicht jede dieser Störungen ist auf die Benutzeroberfläche zurückzuführen. Verbindungsprobleme, Ausfälle oder Zugriffsfehler spielen ebenfalls eine Rolle. Dennoch zeigt die Untersuchung, dass technische Funktion allein nicht genügt. Eine Anwendung kann verfügbar sein und trotzdem den Arbeitsfluss behindern, weil sie den Benutzer mit unnötigen Schritten, wechselnden Kontexten und unpassenden Informationen belastet.

Warum ist Benutzerfreundlichkeit mehr als ein ansprechendes Design?

Eine moderne Farbwelt, abgerundete Schaltflächen und eine aufgeräumte Startseite können einen guten ersten Eindruck erzeugen. Sie sagen jedoch wenig darüber aus, ob ein Mitarbeiter einen komplexen Auftrag fehlerarm abschließen kann.

Benutzerfreundlichkeit zeigt sich erst im Prozess. Wie schnell erkennt der Mitarbeiter, welcher Vorgang vorliegt? Sind die benötigten Informationen vorhanden? Versteht er, welche Entscheidung als Nächstes erforderlich ist? Kann er einen Fehler korrigieren, ohne den gesamten Vorgang neu zu beginnen? Bleiben Eingaben erhalten, wenn die Verbindung unterbrochen wird? Funktioniert die Anwendung auch unter Zeitdruck, mit Handschuhen oder auf einem kleinen Bildschirm?

Der Ansatz des Human-Centered Design stellt deshalb Benutzer, Aufgaben und Einsatzumgebung in den Mittelpunkt. Das National Institute of Standards and Technology, https://www.nist.gov/, beschreibt dazu einen iterativen Prozess, der den Nutzungskontext untersucht, Anforderungen ableitet, Lösungen entwickelt und diese mit Benutzern bewertet. Zu den relevanten Gestaltungsprinzipien gehören unter anderem Aufgabenangemessenheit, Erwartungskonformität, Fehlertoleranz und individuelle Anpassbarkeit.

Diese Prinzipien sind für Unternehmenssoftware wichtiger als kurzfristige Designtrends. Eine dicht gefüllte Tabelle kann für einen erfahrenen Disponenten besser funktionieren als eine optisch reduzierte Kartenansicht. Ein Monteur benötigt möglicherweise große Bedienelemente und wenige Pflichtangaben. Ein Controller braucht dagegen viele Werte gleichzeitig, Filtermöglichkeiten und einen schnellen Export.

Gutes Design bedeutet deshalb nicht, jede Oberfläche möglichst leer erscheinen zu lassen. Es bedeutet, Informationsmenge, Interaktion und Darstellung an Aufgabe, Rolle und Umgebung auszurichten.

Wie unterscheiden sich systemzentrierte und benutzerzentrierte Software?

Der wesentliche Unterschied liegt nicht in einer einzelnen Funktion. Systemzentrierte Software betrachtet die Anwendung als Ausgangspunkt. Benutzerzentrierte Software betrachtet die betriebliche Aufgabe als Ausgangspunkt und stellt die dafür benötigten Funktionen zusammen.

Warum brauchen unterschiedliche Rollen unterschiedliche Oberflächen?

Ein Geschäftsführer, ein Projektleiter, ein Monteur und ein Mitarbeiter in der Buchhaltung arbeiten möglicherweise mit demselben Kundenauftrag. Sie benötigen aber weder dieselben Informationen noch dieselben Handlungsmöglichkeiten.

Die Geschäftsführung interessiert sich für Auftragsbestand, Marge, Risiken und Kapazität. Der Projektleiter benötigt Termine, offene Entscheidungen, Nachträge und Leistungsstände. Die Disposition muss Qualifikationen, Einsatzorte, Verfügbarkeit und Prioritäten berücksichtigen. Der Monteur braucht technische Informationen, Arbeitsumfang, Ansprechpartner, Material und Dokumentationsanforderungen. Die Buchhaltung prüft Leistungsnachweise, Kontierung, Abrechnungsvoraussetzungen und fehlende Angaben.

Eine rollenbasierte Oberfläche reduziert die Anwendung nicht lediglich auf weniger Menüeinträge. Sie verändert die Reihenfolge und Bedeutung der Informationen. Der Monteur sollte beim Öffnen eines Auftrags nicht zuerst kaufmännische Stammdaten durchsuchen müssen. Die Disposition benötigt nicht jede technische Zeichnung, muss aber erkennen, welche Qualifikation oder welches Messgerät für den Einsatz erforderlich ist.

Rollen allein reichen allerdings nicht aus. Zwei Monteure können im selben Betrieb unterschiedliche Aufgaben haben. Ein Servicetechniker benötigt andere Inhalte als ein Mitarbeiter auf einer Neubauinstallation. Ebenso kann ein Projektleiter bei einem kritischen Auftrag andere Informationen benötigen als bei einem Standardvorgang.

Die Oberfläche sollte deshalb Rolle, aktuellen Vorgang, Prozessphase und Berechtigung miteinander verbinden. Erst diese Kombination verhindert, dass aus rollenbasiertem Design lediglich eine neue Sammlung statischer Benutzerprofile entsteht.

Warum ist Kontext wichtiger als eine immer größere Funktionsauswahl?

Viele Softwareprodukte reagieren auf neue Anforderungen, indem sie zusätzliche Funktionen hinzufügen. Mit jedem Release entstehen weitere Menüs, Optionen und Konfigurationsmöglichkeiten. Der Funktionsumfang wächst, während die Auswahl für den einzelnen Mitarbeiter schwieriger wird.

Kontextbezogene Software verfolgt einen anderen Ansatz. Sie versucht nicht, dem Benutzer jederzeit alles anzubieten. Sie erkennt, woran der Mitarbeiter gerade arbeitet, und stellt die dazu passenden Informationen und Aktionen bereit.

Bei einem Wartungsauftrag können das die Anlagenhistorie, der letzte Messwert, bekannte Störungsmuster, eine gültige Prüfanweisung und die benötigten Dokumentationsfelder sein. Bei einer Reklamation stehen dagegen Kundenkommunikation, frühere Nachbesserungen, Gewährleistungsstatus und Eskalationswege im Vordergrund. Bei einer Angebotsfreigabe benötigt die Führungskraft Kalkulation, Abweichungen, Risiken und Entscheidungsvorlagen.

Der Kontext kann sich aus mehreren Daten ergeben: Benutzerrolle, Auftrag, Kunde, Objekt, Anlage, Standort, Prozessstatus, Termin, Berechtigung oder vorherige Aktion. Die Software muss daraus keine weitreichenden Vermutungen ableiten. Schon eine verlässliche Zusammenführung vorhandener Informationen reduziert viele Such- und Rückfragewege.

Besonders wertvoll ist dies in Betrieben, deren Leistung an wechselnden Einsatzorten erbracht wird. Ein Mitarbeiter vor Ort verfügt nicht über dieselben Möglichkeiten wie ein Kollege am Büroarbeitsplatz. Er benötigt kompakte Informationen, mobile Erfassung und einen definierten Eskalationsweg. Die Anwendung muss diesen Nutzungskontext berücksichtigen, statt lediglich die Desktop-Version auf einen kleineren Bildschirm zu übertragen.

Warum erzeugen digitale Systeme manchmal zusätzliche Aufgaben?

Digitalisierung wird häufig mit Automatisierung und Entlastung verbunden. In der Praxis kann neue Software jedoch zusätzliche Tätigkeiten erzeugen: Daten müssen kategorisiert, Statuswerte gepflegt, Benachrichtigungen bearbeitet, Systemvorschläge kontrolliert und Informationen zwischen Anwendungen abgestimmt werden.

Die European Foundation for the Improvement of Living and Working Conditions, https://www.eurofound.europa.eu/, berichtete auf Basis ihrer europäischen Arbeitsbedingungen-Erhebung, dass digitale Technologien bei 40 Prozent der Beschäftigten zusätzliche Aufgaben geschaffen hatten. Bei 30 Prozent waren Aufgaben entfallen. Die Ergebnisse zeigen, dass Technologie Arbeit nicht automatisch reduziert, sondern häufig neu verteilt.

Für Unternehmen ist diese Unterscheidung wichtig. Eine digitale Lösung kann einen früheren Papierprozess ersetzen und trotzdem mehr Gesamtaufwand erzeugen, wenn neue Kontrollen, Kategorien oder Parallelprozesse hinzukommen. Die Softwareeinführung gilt dann technisch als erfolgreich, während Mitarbeiter im Alltag mehr Schritte bewältigen müssen.

Vor jeder neuen Funktion sollte deshalb geprüft werden, welche bisherige Tätigkeit entfällt. Wird ein zusätzliches Pflichtfeld eingeführt, muss bekannt sein, wer die Information verwendet. Wird eine automatische Benachrichtigung erzeugt, braucht sie einen Empfänger mit einer konkreten Handlungsmöglichkeit. Wird eine KI-Zusammenfassung erstellt, sollte sie eine bestehende Such- oder Dokumentationsarbeit ersetzen und nicht lediglich einen weiteren Text produzieren.

Wie sieht benutzerzentrierte Software im technischen Service aus?

Im technischen Service entscheidet die Vorbereitung häufig darüber, wie effizient ein Einsatz verläuft. Der Monteur benötigt nicht nur Adresse und Fehlerbeschreibung, sondern auch Angaben zur Anlage, zum letzten Einsatz, zu bekannten Besonderheiten und zu vereinbarten Leistungen.

Eine benutzerzentrierte Serviceanwendung öffnet deshalb nicht mit einem allgemeinen Dashboard, sondern mit den anstehenden Einsätzen. Beim Aufruf eines Auftrags zeigt sie die wichtigsten Rahmenbedingungen, warnt vor fehlenden Voraussetzungen und stellt relevante Dokumente bereit. Die Informationen folgen dem tatsächlichen Ablauf: Vorbereitung, Anfahrt, Diagnose, Durchführung, Prüfung, Dokumentation und Übergabe.

Während der Diagnose kann die Anwendung frühere Messwerte, vergleichbare Störungen und Herstellerunterlagen einblenden. Sie sollte diese Inhalte nicht ungefragt über den gesamten Bildschirm verteilen. Der Mitarbeiter benötigt eine kompakte Auswahl und die Möglichkeit, bei Bedarf tiefer einzusteigen.

Bei der Dokumentation kann das System vorhandene Auftrags- und Anlagendaten übernehmen. Messwerte lassen sich strukturiert erfassen, Fotos werden dem richtigen Vorgang zugeordnet und Spracheingaben in einen Berichtsentwurf übertragen. Der Monteur prüft das Ergebnis, ergänzt Besonderheiten und schließt den Auftrag ab.

Der Nutzen entsteht nicht durch eine spektakuläre Einzelfunktion. Er entsteht dadurch, dass der Mitarbeiter nicht mehr zwischen Auftrags-App, Dateispeicher, E-Mail, Herstellerportal und Notizblock wechseln muss.

Wie sollte Software auf Baustellen, in Werkhallen und im Außendienst funktionieren?

Arbeitsumgebungen außerhalb des Büros stellen andere Anforderungen an eine Benutzeroberfläche. Lichtverhältnisse wechseln, Verbindungen brechen ab, Geräte werden mit einer Hand bedient und längere Texteingaben sind unpraktisch. Mitarbeiter arbeiten möglicherweise mit Handschuhen, stehen unter Zeitdruck oder müssen gleichzeitig ihre Umgebung beobachten.

Eine mobile Anwendung sollte deshalb einen eigenständigen Arbeitsablauf besitzen. Große Interaktionsflächen, kurze Auswahlwege, Kamera- und Spracheingabe sowie eine zuverlässige Zwischenspeicherung sind oft wichtiger als umfangreiche Dashboards.

Offline-Fähigkeit muss ebenfalls zum Prozess passen. Ein Auftragspaket kann relevante Stamm- und Objektdaten, Checklisten, Dokumente und Formulare vor dem Einsatz auf das Gerät übertragen. Während der Arbeit werden Eingaben lokal gespeichert und nach Wiederherstellung der Verbindung synchronisiert. Der Benutzer muss erkennen können, welche Informationen bereits übertragen wurden und welche noch auf dem Gerät liegen.

Auch die Informationsdichte muss zur Situation passen. Eine Kontrollfahrt benötigt möglicherweise eine schnelle Folge aus Standort, Prüfpunkt, Abweichung, Foto und Maßnahme. Eine Anlageninbetriebnahme erfordert dagegen längere Prüfsequenzen, Messwerte und Freigaben. Dieselbe mobile Standardmaske kann beiden Vorgängen kaum gerecht werden.

Warum gehört Barrierefreiheit zur praktischen Nutzbarkeit?

Unternehmenssoftware wird von Menschen mit unterschiedlichen körperlichen Voraussetzungen, Erfahrungen und digitalen Fähigkeiten verwendet. Einschränkungen können dauerhaft, vorübergehend oder durch die Arbeitsumgebung verursacht sein. Ein verletzter Arm, blendendes Sonnenlicht, Hintergrundlärm oder ein kleiner Bildschirm können ähnliche Bedienbarrieren erzeugen wie eine dauerhafte Einschränkung.

Barrierefreiheit betrifft deshalb nicht nur öffentliche Webseiten. Sie verbessert häufig die allgemeine Bedienbarkeit von Software: verständliche Beschriftungen, Tastaturbedienung, erkennbare Zustände, ausreichende Kontraste, vorhersehbare Navigation und Alternativen zu rein visuellen oder akustischen Informationen.

Das World Wide Web Consortium, https://www.w3.org/, überträgt mit WCAG2ICT die Grundsätze der Web Content Accessibility Guidelines auf Software, Dokumente und weitere digitale Informations- und Kommunikationstechnologien.

Für den Mittelstand bedeutet das nicht, jede interne Anwendung sofort vollständig neu zu entwickeln. Barrierefreiheit sollte jedoch Teil der Anforderung, Beschaffung und Qualitätssicherung sein. Nachträgliche Korrekturen sind oft aufwendiger, weil Komponenten, Navigation und Datenstrukturen bereits festgelegt wurden.

Wie kann ein Company Brain die Benutzeroberfläche entlasten?

Ein Company Brain verbindet Unternehmenswissen mit Rollen, Aufträgen, Objekten und Prozessen. Dadurch muss eine Anwendung nicht sämtliche Informationen dauerhaft auf der Oberfläche anzeigen. Sie kann bei Bedarf jene Inhalte abrufen, die für den aktuellen Vorgang relevant sind.

Ein Projektleiter sieht beispielsweise nicht nur die gespeicherten Projektdokumente, sondern eine Zusammenfassung offener Entscheidungen, Risiken und Abhängigkeiten. Ein Servicetechniker erhält passende Arbeitsanweisungen, frühere Fehlerfälle und objektspezifische Besonderheiten. Die Disposition kann erkennen, welche Qualifikation oder welches Material für einen Auftrag benötigt wird.

Das Company Brain wird damit zu einer kontextbezogenen Wissensschicht. Es ersetzt weder ERP noch CRM oder Dokumentenmanagement. Diese Systeme bleiben für ihre jeweiligen Daten und Transaktionen verantwortlich. Das Company Brain verbindet ihre Informationen und stellt sie in einer für die aktuelle Aufgabe geeigneten Form bereit.

Dadurch kann die Benutzeroberfläche einfacher werden, ohne fachliche Tiefe zu verlieren. Statt zahlreiche Menüs und Suchmasken anzubieten, zeigt die Anwendung eine Auswahl relevanter Inhalte und ermöglicht den Zugriff auf die zugrunde liegenden Quellen.

Entscheidend bleibt die Nachvollziehbarkeit. Der Benutzer muss erkennen, ob eine Information aus einem freigegebenen Dokument, einem früheren Auftrag, einer internen Arbeitsanweisung oder einer KI-generierten Zusammenfassung stammt. Kontextbezogene Darstellung darf nicht dazu führen, dass Herkunft und Gültigkeit verborgen werden.

Wie verändert KI die Gestaltung von Unternehmenssoftware?

Klassische Unternehmenssoftware verlangt, dass Benutzer die Struktur des Systems kennen. Sie müssen wissen, in welchem Modul, unter welchem Menüpunkt und mit welchem Suchbegriff sich eine Information befindet. KI kann diese starre Beziehung teilweise verändern.

Ein Mitarbeiter kann sein Anliegen in normaler Fachsprache formulieren. Das System erkennt den Bezug zum Auftrag, sucht in freigegebenen Quellen und bereitet eine Antwort oder einen Arbeitsschritt vor. Spracheingaben lassen sich strukturieren, Dokumente zusammenfassen und passende Vorgänge vergleichen.

Die größere Veränderung liegt jedoch nicht im Chatfenster. KI kann Oberflächen dynamischer zusammenstellen. Bei einer Störung werden andere Informationen und Aktionen angezeigt als bei einer regulären Wartung. Fehlen notwendige Daten, kann das System gezielt danach fragen. Wiederholen sich bestimmte Abläufe, lassen sich passende Vorbelegungen anbieten.

Diese Anpassung benötigt Grenzen. Eine Oberfläche darf nicht bei jedem Aufruf vollkommen anders aussehen. Benutzer müssen wiederkehrende Elemente, Zustände und Handlungsmöglichkeiten verlässlich wiederfinden. KI sollte die Arbeitssituation berücksichtigen, aber nicht unvorhersehbar über den Prozess entscheiden.

Gute adaptive Software kombiniert daher stabile Grundstrukturen mit kontextbezogenen Inhalten. Navigation, Berechtigungen und zentrale Aktionen bleiben konsistent. Hinweise, Vorschläge und Informationsauswahl passen sich an Rolle und Vorgang an.

Warum ist vollständige Personalisierung nicht automatisch benutzerfreundlich?

Personalisierung klingt zunächst sinnvoll: Jeder Mitarbeiter richtet sich seine Oberfläche selbst ein. In der Praxis kann eine zu weitgehende Individualisierung jedoch neue Probleme erzeugen.

Support und Schulung werden schwieriger, wenn jeder Benutzer andere Menüs, Felder und Ansichten besitzt. Kollegen können sich gegenseitig weniger gut helfen. Prozessverantwortliche wissen nicht mehr, welche Information ein Mitarbeiter tatsächlich sieht. Änderungen müssen in zahlreichen persönlichen Konfigurationen getestet werden.

Außerdem können Benutzer nicht immer beurteilen, welche Informationen später wichtig werden. Eine selten genutzte Warnung kann in einer kritischen Situation entscheidend sein. Wird sie dauerhaft ausgeblendet, verliert die Personalisierung ihren Nutzen.

Sinnvoller ist eine gestufte Anpassung. Das Unternehmen definiert rollenbasierte Grundansichten und verpflichtende Prozessinformationen. Benutzer können innerhalb dieses Rahmens Favoriten, Filter, Reihenfolgen oder zusätzliche Ansichten einstellen. Kritische Hinweise, Freigaben und Nachweispflichten bleiben jedoch verbindlich.

Personalisierung sollte damit Komfort und Geschwindigkeit unterstützen, ohne den gemeinsamen Prozess aufzulösen.

Was läuft bei benutzerzentrierten Softwareprojekten üblicherweise falsch?

Ein verbreiteter Fehler besteht darin, Benutzer erst am Ende des Projekts einzubeziehen. Dann ist die Architektur bereits festgelegt, und Rückmeldungen können nur noch kosmetische Anpassungen bewirken. Benutzerzentrierte Entwicklung muss vor der Auswahl von Funktionen beginnen.

Ebenso problematisch sind Workshops, in denen Mitarbeiter lediglich nach gewünschten Funktionen gefragt werden. Benutzer beschreiben verständlicherweise Lösungen, die sie aus bestehenden Systemen kennen. Wertvoller ist die Beobachtung des tatsächlichen Ablaufs: Welche Informationen werden gesucht? Wo entstehen Unterbrechungen? Welche Entscheidungen verlangen Erfahrung? Welche Schritte werden unter Zeitdruck ausgelassen?

Der Government Digital Service, https://www.gov.uk/, empfiehlt deshalb, den gesamten Nutzungskontext und das eigentliche Problem zu untersuchen, statt von einer bereits festgelegten Lösung auszugehen. Frühe Prototypen und wiederholte Tests reduzieren das Risiko, einen fachlich ungeeigneten Dienst zu entwickeln.

Auch die Auswahl der Testpersonen kann das Ergebnis verzerren. Werden nur Führungskräfte und besonders technikaffine Key User einbezogen, entsteht eine Oberfläche für Ausnahmebenutzer. Der spätere Alltag umfasst jedoch neue Mitarbeiter, Teilzeitkräfte, Außendienst, Vertretungen und Menschen mit unterschiedlichen digitalen Erfahrungen.

Ein weiterer Fehler ist die ausschließliche Optimierung des Normalfalls. Unternehmensprozesse enthalten Störungen, fehlende Daten, Ausnahmen und Rücksprünge. Eine Anwendung muss auch dann funktionieren, wenn ein Kunde nicht erreichbar ist, ein Bauteil fehlt, eine Freigabe abgelehnt wird oder der Auftrag vor Ort anders aussieht als geplant.

Wie lässt sich ein praxisnaher Anwendungsfall gestalten?

Ein mittelständischer SHK-Betrieb möchte seine Serviceabwicklung verbessern. Im bisherigen System erhält der Monteur eine Auftragsbeschreibung und Kundendaten. Für Anlageninformationen, frühere Berichte und technische Unterlagen muss er mehrere Anwendungen öffnen.

Im neuen Ablauf startet der Monteur mit seiner persönlichen Einsatzliste. Die Anwendung zeigt Termin, Ansprechpartner, Anlage, Störung und besondere Anforderungen. Vor der Abfahrt erkennt er, ob Ersatzteile, Messgeräte oder zusätzliche Qualifikationen benötigt werden.

Beim Kunden öffnet sich eine auf den Auftrag zugeschnittene Ansicht. Frühere Messwerte, bekannte Fehlerbilder und freigegebene Unterlagen werden über das Company Brain bereitgestellt. Der Mitarbeiter kann die Diagnose dokumentieren, ohne den Kontext zu verlassen.

Nach Abschluss erzeugt das System aus Arbeitszeit, Material, Messwerten, Fotos und Spracheingabe einen Berichtsentwurf. Fehlende Pflichtangaben werden gezielt abgefragt. Die geprüften Daten fließen an ERP, Anlagenhistorie und Wissenssystem zurück.

Die kaufmännischen Funktionen des ERP bleiben unverändert. Die neue Oberfläche ersetzt nicht das Kernsystem, sondern übersetzt dessen Daten und Funktionen in einen Arbeitsablauf, der zur Rolle des Monteurs passt.

Wie sollte ein benutzerzentrierter Pilot aufgebaut werden?

Ein Pilot sollte keinen vollständigen Unternehmensprozess mit allen Varianten umfassen. Besser eignet sich ein häufig auftretender Vorgang mit erkennbarem Reibungsverlust, beispielsweise eine Wartung, eine Störungsbearbeitung, eine Qualitätsprüfung oder eine Angebotsfreigabe.

Zunächst wird der heutige Ablauf beobachtet. Dabei zählen nicht nur die im Prozesshandbuch beschriebenen Schritte, sondern auch Telefonate, Notizen, private Vorlagen, Rückfragen und manuelle Übertragungen. Diese Nebenwege zeigen häufig, welche Anforderungen die vorhandene Software nicht erfüllt.

Danach wird ein Prototyp mit realistischen Daten erstellt. Die Benutzer bearbeiten konkrete Aufgaben und sprechen aus, was sie erwarten, suchen oder nicht verstehen. Das Projektteam beobachtet dabei nicht nur die Meinung der Teilnehmer, sondern auch Bearbeitungsweg, Abbrüche, Korrekturen und Umgehungen.

Der Pilot muss unter realen Bedingungen stattfinden. Eine mobile Anwendung sollte nicht ausschließlich im Besprechungsraum getestet werden. Sie gehört auf die Baustelle, in den Technikraum, in das Lager oder in die Kontrollfahrt. Nur dort werden Verbindungsprobleme, Geräuschpegel, Zeitdruck und physische Bedienbedingungen sichtbar.

Welche Kennzahlen zeigen, ob die Software tatsächlich besser funktioniert?

Die wichtigste Messgröße ist der erfolgreiche Abschluss einer Aufgabe. Eine Oberfläche kann von Mitarbeitern positiv bewertet werden und trotzdem viele Nacharbeiten verursachen.

Geeignete betriebliche Kennzahlen sind Bearbeitungsdauer, Zahl der Systemwechsel, Rückfragen, Korrekturen, unvollständige Vorgänge, Nachbearbeitungszeit und Abbruchquote. Im Außendienst können zusätzlich Wiederholungsfahrten, Dauer bis zur Berichtsfreigabe oder fehlende Einsatznachweise relevant sein.

Vor dem Pilot wird ein Ausgangswert erhoben. Anschließend bearbeitet eine vergleichbare Benutzergruppe denselben Vorgang mit der neuen Lösung. Dabei sollte nicht nur der Durchschnitt betrachtet werden. Große Unterschiede zwischen erfahrenen und neuen Mitarbeitern können zeigen, dass die Anwendung weiterhin verborgenes Systemwissen voraussetzt.

Ergänzend sind qualitative Beobachtungen wichtig. Wo stocken Benutzer? Welche Informationen übersehen sie? An welcher Stelle wechseln sie dennoch in eine andere Anwendung? Solche Beobachtungen zeigen oft früher als eine allgemeine Zufriedenheitsbefragung, ob die Software zum Arbeitsablauf passt.

Wie lässt sich benutzerzentrierte Software im Unternehmen skalieren?

Nach einem erfolgreichen Pilot besteht die Versuchung, die Oberfläche unverändert auf weitere Bereiche zu übertragen. Das kann denselben Fehler wiederholen, den das Projekt ursprünglich beheben sollte. Andere Rollen und Prozesse benötigen möglicherweise andere Informationsfolgen und Eingabeformen.

Skalierbar wird die Lösung durch gemeinsame Komponenten und unterschiedliche Fachmodule. Anmeldung, Berechtigungen, Suche, Dokumentanzeige, Spracheingabe, Fotodokumentation und Protokollierung können zentral bereitgestellt werden. Die konkrete Prozessführung bleibt fachlich angepasst.

Ein Designsystem sorgt dafür, dass Schaltflächen, Formulare, Zustände und Fehlermeldungen in allen Modulen ähnlich funktionieren. Benutzer müssen dadurch nicht für jeden Prozess eine vollständig neue Bedienlogik lernen. Gleichzeitig dürfen Fachbereiche jene Informationen und Abläufe erhalten, die sie tatsächlich benötigen.

Auch die Weiterentwicklung benötigt einen festen Prozess. Nutzungsdaten, Supportanfragen und Rückmeldungen aus dem Betrieb werden regelmäßig bewertet. Nicht jeder Wunsch führt zu einer neuen Funktion. Entscheidend ist, ob eine Änderung eine relevante Aufgabe verbessert, Fehler reduziert oder einen bestehenden Umweg beseitigt.

Warum entscheidet praktische Nutzbarkeit über den wirtschaftlichen Erfolg?

Unternehmenssoftware erzeugt ihren Wert nicht bei der Produktpräsentation, sondern bei der täglichen Anwendung. Eine Funktion, die im Verkaufsgespräch beeindruckt, aber im Betrieb kaum verwendet wird, trägt wenig zur Produktivität bei.

Praktische Nutzbarkeit verkürzt Einarbeitung, reduziert Rückfragen und erhöht die Wahrscheinlichkeit vollständiger Daten. Sie unterstützt Mitarbeiter dabei, betriebliche Standards einzuhalten, ohne jeden Schritt auswendig lernen zu müssen. Gleichzeitig bleibt Raum für fachliche Entscheidungen und begründete Ausnahmen.

Das bedeutet nicht, dass Software jeden Wunsch erfüllen oder jede Komplexität verbergen muss. Manche Prozesse sind fachlich anspruchsvoll und bleiben es auch mit einer guten Oberfläche. Die Anwendung sollte diese Komplexität jedoch ordnen, statt zusätzliche Bedienkomplexität darüberzulegen.

Software muss sich an den Benutzer anpassen, indem sie Aufgabe, Rolle, Umgebung und Informationsbedarf berücksichtigt. Der wirtschaftliche Vorteil entsteht nicht aus weniger sichtbaren Funktionen, sondern aus weniger unnötigen Schritten zwischen Auftrag und Ergebnis.

Welche Quellen belegen die verwendeten Kennzahlen?

1. TeamViewer: The Impact of Digital Friction Report 2025
   https://media.teamviewer.com/is/content/teamviewergmbh/teamviewer/central-image-hub/pdf/en/teamviewer-the-impact-of-digital-friction-report-en.pdf
   Verwendete Kennzahlen: Verzögerungen in wichtigen Abläufen und durchschnittlich verlorene Arbeitstage durch digitale Reibung.
2. Eurofound: European Working Conditions Survey 2024
   https://www.eurofound.europa.eu/en/surveys-and-data/surveys/european-working-conditions-survey/ewcs-2024/
   Verwendete Kennzahlen: zusätzliche und entfallene Aufgaben infolge digitaler Technologien.

Welche weiteren Quellen vertiefen benutzerzentrierte Softwaregestaltung?

Interessante Links

1. National Institute of Standards and Technology: Human-Centered Design
   https://www.nist.gov/itl/iad/human-centered-technologies/human-factors-human-centered-design
2. Government Digital Service: Understand Users and Their Needs
   https://www.gov.uk/service-manual/service-standard/point-1-understand-user-needs
3. World Wide Web Consortium: WCAG2ICT für Software und digitale Technologien
   https://www.w3.org/WAI/standards-guidelines/wcag/non-web-ict/

Häufig gestellte Fragen

Was bedeutet benutzerzentrierte Unternehmenssoftware?

Benutzerzentrierte Unternehmenssoftware wird ausgehend von realen Aufgaben, Rollen und Arbeitsumgebungen entwickelt. Sie zwingt Mitarbeiter nicht, die interne Struktur eines Systems zu lernen, bevor sie arbeiten können. Funktionen, Informationen und Eingaben werden so angeordnet, dass Benutzer einen betrieblichen Vorgang mit möglichst wenigen unnötigen Schritten zuverlässig abschließen können.

Sind rollenbasierte Oberflächen nur ein anderes Berechtigungskonzept?

Nein. Berechtigungen bestimmen, welche Daten und Funktionen ein Mitarbeiter verwenden darf. Eine rollenbasierte Oberfläche legt zusätzlich fest, welche Informationen in welcher Reihenfolge und Gewichtung erscheinen. Sie verbindet Zugriffssteuerung mit dem tatsächlichen Arbeitsablauf und berücksichtigt idealerweise auch Auftrag, Prozessphase, Gerät und aktuellen Nutzungskontext.

Muss jeder Mitarbeiter eine vollständig eigene Oberfläche erhalten?

Eine vollständig individuelle Oberfläche ist selten sinnvoll. Besser sind gemeinsame Grundansichten für Rollen und Aufgaben, die innerhalb festgelegter Grenzen angepasst werden können. Benutzer dürfen beispielsweise Favoriten, Filter oder Reihenfolgen verändern. Kritische Hinweise, Pflichtangaben und Freigabeschritte bleiben jedoch einheitlich, damit Support, Schulung und Prozesssicherheit beherrschbar bleiben.

Ist eine einfache Oberfläche immer besser?

Nicht zwangsläufig. Eine stark reduzierte Oberfläche kann wichtige Informationen verstecken und erfahrene Mitarbeiter ausbremsen. Entscheidend ist, ob die dargestellte Informationsmenge zur Aufgabe passt. Ein Servicetechniker benötigt eine andere Darstellung als ein Controller. Gute Software reduziert unnötige Elemente, ohne fachlich relevante Zusammenhänge aus dem Arbeitsablauf zu entfernen.

Wie werden Benutzer richtig in ein Softwareprojekt einbezogen?

Benutzer sollten bereits vor der Festlegung der Lösung beobachtet und befragt werden. Besonders wertvoll sind konkrete Aufgaben, reale Vorgänge und Nutzungstests mit Prototypen. Neben erfahrenen Key Usern gehören neue Mitarbeiter, Vertretungen und weniger technikaffine Benutzer in die Untersuchung. So wird sichtbar, welche Teile des Prozesses tatsächlich Systemwissen voraussetzen.

Kann ein Company Brain eine schlechte Benutzeroberfläche ausgleichen?

Nur teilweise. Ein Company Brain kann relevante Informationen zusammenführen und Suchwege verkürzen. Eine unpassende Prozessführung, überladene Formulare oder schlecht gestaltete mobile Abläufe bleiben jedoch problematisch. Der größte Nutzen entsteht, wenn Wissensschicht und Benutzeroberfläche gemeinsam entwickelt werden und dieselben Rollen, Vorgänge, Berechtigungen und Fachbegriffe verwenden.

Wie viel Personalisierung ist bei Unternehmenssoftware sinnvoll?

Personalisierung ist sinnvoll, wenn sie wiederkehrende Arbeit beschleunigt, ohne gemeinsame Standards aufzulösen. Favoriten, gespeicherte Filter und zusätzliche Ansichten sind häufig hilfreich. Pflichtangaben, Sicherheitsinformationen und Freigabeprozesse sollten dagegen zentral gesteuert werden. Das Unternehmen benötigt weiterhin nachvollziehbare Grundansichten, die für Schulung, Support und Qualitätssicherung reproduzierbar bleiben.

Welche Rolle spielt KI bei adaptiven Benutzeroberflächen?

KI kann Kontext erkennen, Informationen priorisieren, Eingaben strukturieren und passende Handlungsvorschläge vorbereiten. Sie sollte jedoch nicht ständig Aufbau und Navigation verändern. Benutzer benötigen wiedererkennbare Grundstrukturen. Sinnvoll ist eine Kombination aus stabiler Prozessführung und dynamischen Inhalten, deren Herkunft, Gültigkeit und Bedeutung für den Mitarbeiter nachvollziehbar bleiben.

Wie lässt sich Benutzerfreundlichkeit objektiv messen?

Geeignete Messgrößen sind Aufgabenerfolg, Bearbeitungszeit, Korrekturen, Systemwechsel, Rückfragen und Nacharbeit. Ergänzend zeigen Beobachtungen, an welchen Stellen Benutzer zögern oder Umwege wählen. Eine reine Zufriedenheitsbefragung reicht nicht aus, weil Mitarbeiter sich auch an umständliche Prozesse gewöhnen und deren Aufwand als unvermeidbar betrachten können.

Wann sollte ein Unternehmen seine bestehende Softwareoberfläche überarbeiten?

Eine Überarbeitung ist sinnvoll, wenn Workarounds zunehmen, Daten unvollständig bleiben, neue Mitarbeiter lange eingearbeitet werden oder kleine Prozessänderungen umfangreiche Schulungen auslösen. Auch häufige Rückfragen und parallele Excel-Listen sind Warnsignale. Vor einer Neuentwicklung sollte geprüft werden, ob Konfiguration, eine Fachanwendung oder eine kontextbezogene Integrationsschicht ausreicht.

KI-Mitarbeiter Lösungen von KrambergAI

Alle Artikel zu den Themen KI-Mitarbeiter und Automatisierung