Warum wir Software in Module schneiden

Die meisten Betriebe, mit denen wir sprechen, haben dieselbe Geschichte hinter sich. Erst ein paar Tabellen. Dann eine Insellösung für die Zeiterfassung, eine zweite für die Aufträge, eine dritte für das Lager. Jede für sich sinnvoll, zusammen ein Flickenteppich, den niemand mehr überblickt. Irgendwann steht das große ERP-Projekt im Raum, das alles ablösen soll — und ein Jahr später läuft trotzdem die halbe Firma auf Excel weiter, weil das ERP an genau der Stelle nicht passt, an der es drauf ankommt.

Das Problem ist nicht die Software. Es ist der Zuschnitt.

Ein ERP ist ein Block. Du kaufst alles auf einmal, du führst alles auf einmal ein, und du pflegst auch die Teile, die niemand anfasst. Das ist kein Versehen, das ist die Bauform: Ein ERP will das ganze Unternehmen abbilden, also muss es überall ein bisschen zuständig sein — und ist deshalb nirgends ganz deins.

Wo dieser Unterschied konkret zuschlägt, lässt sich auflisten:

Wenn ein Bereich nicht passt, hast du zwei Möglichkeiten. Entweder du biegst deinen Prozess so lange, bis er in die Software passt. Oder du startest ein Änderungsprojekt, das Monate dauert. Beides kostet — nur zahlst du das erste mit der Zeit deiner Leute, und das taucht in keiner Rechnung auf.

Genau da setzen wir an. Usable ist ein Baukasten: Du nimmst die Module, die dein Betrieb heute braucht, und steckst später weitere dazu. Ein Modul ist dabei kein Häkchen in einer Preisliste, sondern ein abgeschlossenes Stück Software mit eigener Datenhaltung, eigenen Rechten und eigener Dokumentation.

Was ein Modul mitbringt

„Modul" klingt nach Baukasten-Marketing, deshalb ist uns wichtig, was wir damit meinen. Jedes Modul, das wir ausliefern, bringt vier Dinge mit — sonst gilt es bei uns nicht als fertig und geht nicht raus:

• Rechte. Wer was sehen und tun darf, ist Teil des Moduls, nicht nachträglich drangeschraubt. Die Lagerkraft sieht das Lager, nicht die Löhne. Das ist keine Einstellung, die man vergessen kann.
• Dokumentation. In der Sprache der Leute, die damit arbeiten — nicht als API-Referenz. Die Hilfe steht dort, wo die Arbeit passiert.
• Migration. Das Modul kann in eine bestehende Datenbank einziehen, ohne sie zu beschädigen. Deine Daten von gestern sind morgen noch da — und passen ins neue Modul, statt daneben zu liegen.
• Eine Oberfläche, die auf dem Handy funktioniert. Nicht „responsive irgendwie", sondern benutzbar mit einer Hand, im Stehen, mit Handschuhen. Wer draußen arbeitet, tippt nicht am Schreibtisch nach.

Was das für dich ändert

Du startest mit dem, was drückt. Wenn die Auftragsabwicklung das Problem ist, fängst du dort an — nicht mit einem Einführungsprojekt, das erst in zwölf Monaten den ersten Nutzen zeigt. Ein Bereich, sauber gelöst, ist mehr wert als zehn, die halb laufen.

Kommt später das Lager dazu, kommt es dazu: gleiche Anmeldung, gleiche Stammdaten, gleiche Oberfläche. Deine Leute lernen nicht ein zweites Programm, sie bekommen einen zweiten Bereich in demselben. Und was du im ersten Modul über Rollen und Rechte entschieden hast, gilt weiter — du fängst nicht bei null an.

Wächst dein Betrieb, wächst das System mit, in der Reihenfolge, die deine Realität vorgibt — nicht in der, die ein Einführungsplan vorschreibt.

Wo ein Baukasten schlechter ist

Damit das keine Verkaufsprosa bleibt: Es gibt Fälle, in denen ein Block die bessere Antwort ist.

• Wenn ein Betrieb schon alles in einem System hat und zufrieden ist. Dann ist der Wechsel ein Risiko ohne Gegenwert. Der Baukasten lohnt sich, wo etwas fehlt oder klemmt — nicht als Selbstzweck.
• Wenn die Fachprozesse extrem standardisiert sind. Es gibt Branchen, für die es fertige Systeme gibt, die genau diesen einen Ablauf perfekt abbilden. Dagegen baut man nicht sinnvoll an.
• Wenn niemand im Betrieb Entscheidungen treffen will. Ein Baukasten setzt voraus, dass jemand sagt, womit angefangen wird. Wer diese Entscheidung nicht treffen möchte, kauft lieber einen Block und lässt sich den Ablauf vorgeben.

Der ehrliche Satz dazu lautet: Ein Baukasten verlagert Entscheidungen zu dir. Das ist der Preis für den Zuschnitt, der zu dir passt.

Ein Beispiel, wie es tatsächlich läuft

Ein Betrieb mit 30 Leuten, Instandhaltung im Anlagenbau. Der Ausgangspunkt ist nie „wir brauchen ein System", sondern ein konkreter Ärger — hier: zwei verpasste Prüffristen innerhalb eines Jahres.

1. Erster Schritt: Anlagen & Geräte und Prüfungen. Der Bestand kommt aus einer Tabelle, die Fristen hängen ab jetzt am Gerät. Aufwand: ein Nachmittag Import, eine Woche Nacharbeit.
2. Nach sechs Wochen: Schäden kommt dazu, weil auffällt, dass Defekte weiterhin per Nachricht gemeldet werden — und damit nicht in der Fehlerquote landen, aus der sich die nächste Frist ergibt.
3. Nach einem Quartal: Wartung und Benachrichtigungen. Erst jetzt, weil vorher niemand gesagt hätte, wer welche Meldung bekommen soll.
4. Später: Zeiterfassung, weil dieselben Leute ihre Stunden ohnehin an denselben Anlagen buchen.

Kein Schritt davon ist ein Projekt. Jeder einzelne ist rückabwickelbar, und nach jedem steht etwas, das funktioniert.

Und wenn ein Modul nicht passt?

Dann ist das eine Frage an uns, kein Grund, deinen Prozess zu verbiegen. Ein Modul, das an einer Stelle klemmt, ist ein Auftrag für uns — nicht dein Problem, mit dem du dich arrangierst.

Das ist der eigentliche Unterschied zum Block: Beim ERP bist du der, der sich anpasst. Beim Baukasten bleibt der Zuschnitt verhandelbar — so lange, bis er zu deinem Betrieb passt und nicht umgekehrt.

Wenn du wissen willst, wie das bei dir aussähe: Im Konfigurator stellst du deinen Bereich und deine Module zusammen und siehst sofort, was daraus wird. Und falls du gerade noch überlegst, ob es bei euch überhaupt so weit ist — die fünf Anzeichen dafür stehen im Beitrag Wann Excel im Betrieb kippt.