Auswahl eines CMMS nach einer gescheiterten Implementierung: Leitfaden 2026

Wesentliche Erkenntnisse - Ein gescheiterter CMMS-Rollout ist fast nie ein Softwareversagen. In der großen Mehrheit der Fälle handelt es sich um eines von vier Problemen: niemand hat die Verantwortung übernommen, die Daten wurden nie bereinigt, die Techniker hatten keinen Grund, es zu nutzen, oder der Umfang war für die erste Freigabe zu groß. - Erst diagnostizieren, dann einkaufen. Wenn Sie das Tool ersetzen, ohne die Ursache zu ändern, reproduzieren Sie den Fehler zu höheren Kosten, und das zweite Scheitern ist politisch viel schwerer zu beheben. - Der stärkste Prädiktor für Akzeptanz ist, ob ein Techniker einen Auftrag auf dem Telefon in unter einer Minute abschließen kann, ohne eine Anlagennummer einzutippen. Testen Sie das in der Demo, auf einem realen Telefon, mit Ihrer eigenen Anlagenliste. - Migrieren Sie nicht die alten Daten im Ganzen. Migrieren Sie das Anlagenverzeichnis und offene Arbeiten und archivieren Sie den Rest. Den Import eines Jahrzehnts schlechter Datensätze kann einem Neuanfang den Ruf des alten Systems vererben. - Fragen Sie jeden Anbieter, was in Woche fünf passiert, nicht in Woche eins. Implementierungen werden unterstützt; in der fünften Woche, wenn der Berater weg ist und sich der erste Rückstau bildet, werden Systeme tatsächlich aufgegeben. Unser letztes CMMS-Projekt ist gescheitert. Was sollten wir bei der Auswahl des nächsten anders machen? Beginnen Sie damit, das Scheitern genau zu benennen, denn die Lösung ist für jede Ursache eine andere. Wenn Techniker es nie genutzt haben, entscheidet die nächste Auswahl über mobile Bedienbarkeit und Scannen, und Sie testen beides mit echten Technikern, bevor Sie unterschreiben. Wenn die Daten falsch waren, beheben Sie das Anlagenverzeichnis und die Namenskonvention, bevor ein System ausgewählt wird, denn schlechte Daten zerstören das zweite System genauso wie das erste. Wenn niemand die Verantwortung hatte, benennen Sie eine Systemverantwortliche oder einen Systemverantwortlichen mit zugeteilten Stunden, und kein Kauf erfolgt, bis diese Person existiert. War der Umfang zu groß, kürzen Sie die erste Version auf reaktive Arbeitsaufträge plus die Top‑20‑Anlagen und fügen den Rest später hinzu. Ändern Sie dann die Kriterien, nach denen Sie bewerten. Beurteilen Sie Kandidaten nach der Zeit, um einen Auftrag auf dem Telefon abzuschließen, danach, ob eine Anlage per QR‑Code‑Scan gefunden werden kann statt durch Eintippen, und danach, wie schnell ein realer Techniker aus Ihrem Team eine Aufgabe ohne Hilfe erledigen kann. Fabrico liefert native iOS‑ und Android‑Apps mit QR‑Scannern für Maschinen und Ersatzteile, eine persönliche Arbeitskarte für jeden Techniker und einen Autotimer, sodass die Dauer erfasst wird, ohne dass jemand sie eingibt. Die Einrichtung wird mit 3 Tagen Fabrico‑seitiger Arbeit angegeben, einschließlich Massenimport, und die Supportreaktionszeit ist vertraglich unter 2 Stunden. Die vier Ursachen und wie man erkennt, welche bei Ihnen vorlag Ursache 1: kein Eigentümer. Das Kennzeichen ist, dass nach dem Go‑live niemand sagen kann, wer nachträglich Entscheidungen getroffen hat. Ein System braucht eine Person, deren Aufgabe es ist: doppelte Anlagen zu schließen, einen zu häufig auslösenden Plan zu korrigieren und die Frage eines Technikers am gleichen Tag zu beantworten. Wo diese Rolle angenommen statt zugewiesen wurde, verrottet das System stillschweigend, und nach sechs Monaten ist das Whiteboard wieder in Gebrauch. Ursache 2: schmutzige Daten. Das Kennzeichen ist, dass die Leute der Suche nicht mehr vertrauen. Wenn eine Anlage unter drei Namen dreimal auftaucht oder die Hälfte des Registers ein Standort und die andere Hälfte eine Maschine ist, umgehen Techniker das System lieber, als sich damit herumzuschlagen. Das ist kein Softwareproblem und anderes Softwarekaufen wird es nicht lösen. Unser Leitfaden zur Gestaltung der Anlagenhierarchie beschreibt die Struktur, auf die man sich vor einem Import einigen sollte. Ursache 3: kein Grund für den Techniker, es zu nutzen. Das Kennzeichen ist, dass Daten eingegeben werden und nichts zurückkommt. Wenn das System nur nimmt, Einträge verlangt und nichts Nützliches liefert, schließen Techniker zu Recht, dass es ein Reporting‑Tool für das Management ist. Gegenmaßnahme: Es muss etwas zurückgeben: das Handbuch auf dem Telefon an der Maschine, die Historie dessen, was beim letzten Mal versucht wurde, die Teilenummer ohne Gang zum Lager. Ursache 4: zu großer Umfang. Das Kennzeichen ist, dass das Go‑live gleichzeitig präventive Pläne, Inventar, Beschaffung, Condition‑Monitoring und Dashboards umfasste. Alles ist halb konfiguriert, also ist alles ein bisschen falsch, also wird nichts vertraut. Eine Erstversion, die reaktive Arbeitsaufträge gut abwickelt, schlägt immer eine, die sechs Module schlecht abdeckt. Es gibt eine fünfte, seltenere Ursache, die es wert ist, benannt zu werden: die Software konnte die Aufgabe tatsächlich nicht erfüllen, meist weil sie für eine andere Branche gekauft wurde. War das bei Ihnen der Fall, ist die Diagnose einfach und der Rest dieses Artikels gilt weiterhin für den Wiederaufbau. Was Sie tun sollten, bevor Sie sich einen Anbieter ansehen - Schreiben Sie das Scheitern in einem Absatz nieder und geben Sie es zur Kenntnis. Das ist unangenehm und es ist die Stunde mit dem höchsten Wert im Projekt. Ein zweiter Versuch, der so tut, als sei der erste nie passiert, übernimmt den ganzen Skeptizismus und keines der Lern‑Ergebnisse. Ein zweiter Versuch, der mit „Das ist schiefgelaufen und das ändern wir“ beginnt, wird Gehör finden. - Bereinigen Sie das Anlagenverzeichnis offline. Eine Namenskonvention, eine Hierarchie, entfernte Duplikate, zugewiesene Kritikalität. Machen Sie es ruhig in einer Tabelle; wichtig ist, dass es vor dem Import vereinbart ist. Diese Arbeit ist zwischen allen Anbietern übertragbar, die Sie später wählen, also geht sie nie verloren. - Benennen Sie den Verantwortlichen und geben Sie ihm die Stunden. Ein Prozentsatz der Arbeitszeit einer realen Person, schriftlich festgehalten. Wenn die Organisation das nicht finanzieren will, ist die ehrliche Schlussfolgerung, dass sie noch nicht bereit ist, wieder zu kaufen, das jetzt zu sagen ist günstiger als es in einem Jahr zu erfahren. - Schneiden Sie die erste Freigabe zurück. Reaktive Arbeitsaufträge, das Anlagenverzeichnis und präventive Pläne für die wichtigsten Anlagen nach Kritikalität. Inventar, Beschaffung und Analytik folgen, wenn die erste Version tatsächlich genutzt wird. Widerstehen Sie dem Drang, alles einzuschließen, weil „wir ja sowieso dafür zahlen“. Zehn Fragen an Anbieter, wenn eine Vorgeschichte des Scheiterns besteht 1. Geben Sie einem meiner Techniker ein Telefon und lassen Sie ihn einen Auftrag eigenständig abschließen. Wie lange dauert das und wie viele Taps sind nötig? 2. Kann eine Anlage per Scan eines Codes an der Maschine gefunden werden, und was passiert, wenn der Code beschädigt ist? 3. Was bekommt ein Techniker am Gerät aus dem System heraus, nicht nur was er hineingibt? 4. Wer ist auf Ihrer Seite nach dem Go‑live beteiligt, wie lange, und was passiert in Woche fünf? 5. Können wir mit reaktiven Arbeiten live gehen und präventive Pläne später ohne Re‑Implementierung hinzufügen? 6. Was erwartet Ihr Import und helfen Sie uns, das Register zu bereinigen oder laden Sie es nur? 7. Wie ändern wir selbst einen präventiven Plan, ohne ein Support‑Ticket zu eröffnen? 8. Wie sieht das System für einen Techniker aus, der nicht softwareaffin ist, und ist die Oberfläche in seiner Sprache verfügbar? 9. Können wir vor der Verpflichtung einen zweiwöchigen Test an einer Linie mit unseren Anlagen und unserem Personal durchführen? 10. Wie ist Ihre vertragliche Supportreaktionszeit und zu welchen Stunden? Frage 1 ist keine Formalität. Führen Sie den Test mit einem tatsächlichen Techniker aus Ihrer Anlage durch, nicht mit einem Vorarbeiter, und beobachten Sie, wo er zögert. Jedes Zögern, das Sie in einer Demo sehen, wird im dritten Monat zur Aufgabe. Der Akzeptanztest, der alles vorhersagt Wenn Sie dieses Mal nur eine Sache anders machen, dann diese: Nehmen Sie zwei Techniker, einen technikaffinen und einen weniger technikaffinen. Geben Sie jedem ein Telefon mit der Kandidaten‑App und keine Schulung außer einer einminütigen Einweisung. Bitten Sie sie, drei Dinge zu tun: eine bestimmte Maschine finden, sehen, was zuletzt an ihr gemacht wurde, und einen abgeschlossenen Auftrag mit einer Notiz und einem Foto erfassen. Messen Sie die Zeit und zählen Sie die Momente, in denen sie um Hilfe bitten. Alles, was einen Techniker länger als etwa eine Minute dauert oder das Eintippen eines Anlagenkennzeichens aus dem Gedächtnis verlangt, überlebt den Kontakt mit einer nassen, lauten, mit Handschuhen arbeitenden Schicht nicht. Dieser Test kostet eine Stunde und ist prädiktiver als jeder Feature‑Vergleich, weil Features zeigen, was ein System kann, und Akzeptanz zeigt, wozu es tatsächlich eingesetzt wird. Sprache ist Teil davon. Wenn die Hälfte Ihres Teams in einer Sprache arbeitet, die die Oberfläche nicht anbietet, ist die Akzeptanz von vornherein begrenzt. Fabricos Oberfläche ist in Englisch, Bulgarisch, Deutsch, Französisch und Polnisch verfügbar; weitere Sprachen lassen sich problemlos hinzufügen. Wo Fabrico einordnet Gegenüber den vier oben genannten Ursachen sind die relevanten Fähigkeiten: native iOS‑, Android‑ und Web‑Clients mit QR‑Scannern für Maschinen und Teile, sodass die Identifikation per Scan erfolgt; eine persönliche Arbeitskarte pro Techniker, damit jede Person ihre eigenen Aufgaben sieht statt einer gemeinsamen Warteschlange; ein Autotimer, damit die Dauer ohne Dateneingabe erfasst wird; ein Maschinenregister, das Handbücher, Dateien und die vollständige Historie hält, sodass das System an der Maschine etwas zurückgibt; Kalender‑ und Drag‑and‑Drop‑Terminierung, die ein Wartungsplaner ohne Support‑Ticket ändern kann; sowie wiederkehrende Vorlagen, bedingte Aufgaben und Genehmigungsworkflows für den Fall, dass Sie bereit sind, Struktur hinzuzufügen. Auf der Implementierungsseite wird die CMMS‑Ebene mit 3 Tagen Fabrico‑seitiger Einrichtung angegeben, die Konfiguration, Benutzer, Rollen und Massenimport abdeckt, mit Unterstützung beim Massenimport, Live‑ und Vor‑Ort‑Schulungen und einer Operational Assessment‑Leistung als kostenpflichtiges Add‑on, wenn der zugrunde liegende Prozess Arbeit braucht und nicht nur das Tool. Die Supportreaktionszeit ist vertraglich unter 2 Stunden per E‑Mail und Rückruf, mit einer Wissensdatenbank in Bulgarisch, Englisch und Deutsch. Wo OEE im Umfang liegt, kommen Verfügbarkeit, Performance und Qualität aus der SPS, mit IoT‑Sensoren oder KI‑Kameras dort, wo kein brauchbares Signal existiert. Das ist für einen zweiten Versuch wichtig, weil maschinell aufgezeichnete Stillstandszeiten überhaupt nicht von der Akzeptanz abhängen und somit bereits in den Wochen Wert erzeugen, in denen die Disziplin bei Arbeitsaufträgen noch aufgebaut wird. Beachten Sie, dass die Anbindung von Maschinen eine eigene Aufgabe ist, getrennt vom CMMS‑Setup und abhängig von Ihrem Equipment und Zugang zur Linie, planen Sie sie also als zwei Zeitpläne. Beispiel: der zweite Versuch, der gelang Eine Anlage mit 300 Anlagen kaufte ein angesehenes CMMS, verbrachte vier Monate mit der Konfiguration von sechs Modulen, ging am ganzen Standort an einem Datum live und hatte nach sieben Monaten 11 Prozent der Arbeitsaufträge im System geschlossen. Die Wartung lief wieder über das Whiteboard. Das System blieb noch zwei Jahre auf der Rechnung. Die Nachuntersuchung fand alle vier Ursachen. Es gab keinen Eigentümer, nur eine Projektmanagerin bzw. einen Projektmanager, die/der nach dem Go‑live wieder in den Tagesjob zurückkehrte. Das Register hatte 340 Einträge für 300 Anlagen. Techniker bekamen nichts aus der App zurück und mussten Anlagencodes eintippen. Und der Umfang hatte die Beschaffung umfasst, die in der Wartung nie gewünscht worden war. Der zweite Versuch kehrte die Reihenfolge um. Sechs Wochen wurden vor jeglichem Anbietergespräch am Register gearbeitet, mit dem Ergebnis: 300 saubere Anlagen, eine Konvention und zugewiesene Kritikalität. Ein Planer erhielt schriftlich einen Tag pro Woche als Systemverantwortlichen. Die Auswahl wurde durch einen Telefon‑Test mit zwei Technikern auf dem Shopfloor entschieden. Das Go‑live deckte nur reaktive Arbeiten und das Anlagenverzeichnis ab, auf einer Linie; der Rest des Werks folgte vier Wochen später. Präventive Pläne wurden im dritten Monat hinzugefügt, Inventar im sechsten Monat, Beschaffung nie. Die Lehre ist nicht, dass die zweite Software besser war. Sie ist, dass der erste Versuch ein Werkzeug kaufte und der zweite Versuch ein System reparierte. Reihenfolge schlug Auswahl, und die günstigsten sechs Wochen im Projekt waren die, die man vor dem Besuch einer Anbieterwebsite verbrachte. Häufig gestellte Fragen Sollten wir den Anbietern sagen, dass unsere letzte Implementierung gescheitert ist? Ja, und zwar detailliert. Ein Anbieter, der die wahre Geschichte hört, kann Ihnen sagen, ob sein Ansatz das angesprochene Problem adressiert oder nicht, und diejenigen, die es abtun, sagen Ihnen etwas Nützliches darüber, wie die nächsten zwölf Monate verlaufen werden. Wenn Sie es verschweigen, pitcht jeder Anbieter die Standardimplementierung, genau das, was beim letzten Mal nicht funktionierte. Wie viel der alten Daten sollten wir migrieren? Das Anlagenverzeichnis, offene Arbeitsaufträge und alle gesetzlich oder garantierelevanten Historien. Archivieren Sie den Rest als schreibgeschützten Export, den Sie durchsuchen können, falls Sie ihn jemals brauchen. Der Impuls, alles mitzunehmen, ist stark und meist falsch: Die alte Historie ist größtenteils unvollständig, und ihr Import rekonstruiert das Misstrauen, das die Leute dazu brachte, das alte System nicht mehr zu nutzen. Lohnt es sich, das bestehende System zu reparieren statt es zu ersetzen? Oft ja, und es lohnt sich, eine ehrliche Stunde zu investieren, bevor Sie einen Haushaltszyklus aufwenden. Wenn das Scheitern in Ownership, Daten oder Umfang lag, reisen diese Ursachen mit, und das bestehende Tool kann nach ihrer Behebung völlig ausreichen. Ersetzen Sie, wenn das Tool die Aufgabe wirklich nicht erledigen kann, wenn die mobile Erfahrung nicht verbessert werden kann, weil es nicht die Priorität des Anbieters ist, oder wenn das System intern so diskreditiert ist, dass ein neuer Name mehr wert ist als die Migrationskosten. Letzterer Grund ist weich, aber real. Wie lange sollte die zweite Implementierung dauern? Die Softwarekonfiguration ist nicht der lange Engpass und war es nie. Anbieterseitige Einrichtung für eine CMMS‑Ebene wird in Tagen gemessen. Der realistische Weg sind ein paar Wochen Datenvorbereitung, die Sie selbst leisten, eine kurze Konfiguration, ein Pilot an einer Linie, dann ein Rollout im Werk, mit nachträglicher Schichtung präventiver Pläne. Wer ein vollständiges Multi‑Modul‑Go‑live in zwei Wochen verspricht, beschreibt die Softwareinstallation, nicht den Veränderungsprozess. Welche einzelne Kennzahl sagt uns, dass es dieses Mal funktioniert? Der Anteil der Arbeit, der über das System läuft, wöchentlich gemessen und in den ersten zwei Monaten beobachtet. Nicht Compliance, nicht MTTR, nicht Kosten. Wenn reaktive Jobs im System erstellt und abgeschlossen werden statt in einem Gespräch, wird alles andere möglich. Wenn nicht, haben keine anderen Kennzahlen Bedeutung, weil die zugrundeliegenden Daten eine Stichprobe der Arbeit statt der Arbeit selbst sind. Weiterführende Lektüre: how to switch CMMS software für die Mechanik eines Wechsels, der Data Migration Guide dafür, was zu übernehmen ist, und der OEE‑Leitfaden, falls Maschinendaten Teil des zweiten Versuchs sind. Wenn Sie den Telefon‑Test mit Ihren eigenen Anlagen und Ihren eigenen Technikern durchführen möchten, buchen Sie eine Demo und sagen Sie, dass Sie genau das testen möchten. Zuletzt aktualisiert: 7. August 2026.