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.

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.

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.