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. Irgendwann steht ein ERP-Projekt im Raum, das alles ablösen soll — und ein Jahr später läuft trotzdem die halbe Firma auf Excel weiter.

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 bezahlst auch für die Teile, die niemand anfasst. Wenn ein Bereich nicht passt, passt du deinen Betrieb an, nicht die Software — denn das andere wäre ein Änderungsprojekt.

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

Jedes Modul, das wir ausliefern, bringt vier Dinge mit — sonst gilt es bei uns nicht als fertig:

• Rechte. Wer was sehen und tun darf, ist Teil des Moduls, nicht nachträglich drangeschraubt.
• Dokumentation. In der Sprache der Leute, die damit arbeiten — nicht als API-Referenz.
• Migrationen. Das Modul kann in eine bestehende Datenbank einziehen, ohne sie zu beschädigen.
• Eine Oberfläche, die auf dem Handy funktioniert. Nicht „responsive irgendwie", sondern benutzbar mit einer Hand, im Stehen, mit Handschuhen.

Was das für dich ändert

Du startest mit dem, was drückt. Wenn die Auftragsabwicklung das Problem ist, fängst du dort an — und nicht mit einem Einführungsprojekt, das erst in zwölf Monaten den ersten Nutzen zeigt. Kommt später das Lager dazu, kommt es dazu: gleiche Anmeldung, gleiche Stammdaten, gleiche Oberfläche.

Und wenn ein Modul nicht das tut, was du brauchst, ist das eine Frage an uns — kein Grund, deinen Prozess zu verbiegen.