Wenn dieselbe Firma in drei Systemen drei verschiedene Firmen ist
Für etablierte Mittelständler mit mehreren Gesellschaften und Standorten entwickeln wir Anwendungen, die Mandantenstruktur und gewachsene Zuständigkeiten abbilden statt sie zu ignorieren.
Die Betriebe im Umfeld des Business Campus sind selten jung. Viele sind über Jahrzehnte gewachsen, haben Gesellschaften ausgegründet, Vertriebsgebiete neu geschnitten und dabei jedes Mal Systeme mitgenommen, die eigentlich für eine kleinere Struktur gedacht waren. Das Ergebnis ist eine eigentümliche Unschärfe: Ein Kunde ist in der Warenwirtschaft eine Nummer, im Vertriebssystem eine zweite und in der Verwaltung eine dritte, und ob es sich wirklich um denselben handelt, weiß nur eine erfahrene Kollegin. Software kann diese Frage nicht durch Wollen lösen, sondern nur durch ein Modell, das mehrere Gesellschaften, Standorte und Zuständigkeiten von vornherein kennt. Genau darauf legen wir bei Projekten in Unterschleißheim den Schwerpunkt.

Mandantenfähig von der ersten Zeile an
Gesellschaft und Standort gehören zum Datenmodell, nicht zu einer nachträglichen Filterlogik. Das entscheidet über Auswertbarkeit und Rechtevergabe.
Eine Identität über alle Systeme
Wir führen Kunden- und Lieferantenstämme zusammen und halten die Zuordnung dauerhaft nachvollziehbar, statt sie einmalig zu bereinigen.
Rechte entlang der Organisation
Zuständigkeiten werden über Rollen, Gebiete und Gesellschaften abgebildet und lassen sich bei Umorganisationen anpassen, ohne dass Code geändert wird.
Anbindung entfernter Standorte
Anwendungen werden so entworfen, dass sie auch über eine gesicherte Verbindung von anderen Standorten aus benutzbar bleiben.
Mandantenstruktur ist kein Zusatzfeld
Die häufigste Fehlentscheidung in solchen Projekten ist es, die Gesellschaft als weiteres Merkmal an bestehende Datensätze anzuhängen. Das funktioniert für einfache Listen und bricht, sobald eine Auswertung gesellschaftsübergreifend sein soll, eine Kundenbeziehung mehreren Gesellschaften zugeordnet ist oder Rechte pro Gesellschaft unterschiedlich vergeben werden müssen.
Wir klären deshalb vor dem Entwurf, welche Objekte gesellschaftsgebunden sind, welche geteilt werden und wo Abgrenzungen aus steuerlichen oder vertraglichen Gründen zwingend sind. Diese Festlegung ist die aufwendigste Entscheidung des gesamten Projekts – und die einzige, die sich später kaum noch korrigieren lässt.
- ✓Festlegung geteilter und gesellschaftsgebundener Stammdaten
- ✓Auswertungen wahlweise je Gesellschaft oder konsolidiert
- ✓Rechtevergabe getrennt nach Gesellschaft und Rolle
Doppelte Stammdaten dauerhaft in den Griff bekommen
Eine einmalige Bereinigung der Kundenstämme hält selten länger als ein Jahr. Solange in zwei Systemen unabhängig voneinander neu angelegt werden kann, entstehen neue Dubletten in genau der Geschwindigkeit, in der die alten verschwanden.
Nachhaltig wirkt nur eine festgelegte Reihenfolge: Ein System führt den Stamm, die anderen übernehmen. Wo das organisatorisch nicht durchsetzbar ist, bauen wir eine Abgleichschicht, die Kandidaten für Dubletten erkennt, zur Entscheidung vorlegt und die getroffene Zuordnung dauerhaft speichert. Damit bleibt auch nach Jahren nachvollziehbar, welche Nummern zu welchem Geschäftspartner gehören.
Vertriebs- und Verwaltungsabläufe abbilden
In vertriebsgeprägten Häusern liegt der häufigste Entwicklungsbedarf zwischen den Systemen: Angebotsverfolgung, Provisionsermittlung, Freigaben für Rabatte, Übergabe an die Auftragsbearbeitung. Diese Schritte sind selten in einem Produkt vollständig enthalten und werden deshalb in Tabellen und Postfächern erledigt.
Wir entwickeln dafür Anwendungen, die den Ablauf mit Zuständigkeit, Frist und Zustand führen, und binden sie an die vorhandene Warenwirtschaft an. Der Vorteil gegenüber einer Ablösung ist erheblich: Das Kernsystem bleibt unangetastet, das Projektrisiko sinkt, und die Einführung betrifft nur den Bereich, um den es tatsächlich geht.
- ✓Freigabeschritte mit benannter Zuständigkeit und Frist
- ✓Nachvollziehbare Historie jeder Freigabeentscheidung
Betrieb über mehrere Standorte
Anwendungen, die an mehreren Standorten genutzt werden, müssen mit unterschiedlicher Anbindungsqualität zurechtkommen. Wir entwerfen sie deshalb sparsam im Datenverkehr und vermeiden Oberflächen, die für jede Eingabe mehrfach nachladen. Der Unterschied fällt am Hauptsitz nicht auf, an einer schwächer angebundenen Niederlassung dagegen sofort.
Vom Firmensitz in Neuhausen-Nymphenburg sind es rund 17 km nach Unterschleißheim. Für Aufnahme, Abnahme und Einweisung kommen wir vor Ort und planen die Termine je nach Verkehrslage. Bei mehreren Standorten sehen wir uns mindestens den mit der schwächsten Anbindung an.
Wo ein Standardsystem die bessere Wahl ist
Wenn Ihre Gesellschaften im Kern denselben Geschäftsgang haben, deckt eine mandantenfähige Standardlösung das meist vollständig ab. Eine Eigenentwicklung würde dieselbe Funktion teurer nachbauen und Ihnen zusätzlich die Pflege aufbürden – gerade in Buchhaltung, Lohn und steuerlicher Abgrenzung ist das nicht empfehlenswert.
Für Entwicklung spricht die Lage dort, wo Ihre Organisation von der üblichen Struktur abweicht und diese Abweichung geschäftlich begründet ist. In dem Fall ist eine ergänzende Anwendung rund um das vorhandene Kernsystem fast immer wirtschaftlicher als der Versuch, ein Standardprodukt bis zur Unkenntlichkeit anzupassen.
Häufige Fragen
In den meisten Fällen nicht. Eine mandantenfähig entworfene Anwendung trennt die Daten innerhalb einer Installation und erlaubt trotzdem konsolidierte Auswertungen. Getrennte Installationen sind nur dann sinnvoll, wenn vertragliche oder aufsichtsrechtliche Gründe eine physische Trennung verlangen. Diese Frage klären wir vor dem Entwurf, weil sie sich später nur mit erheblichem Aufwand ändern lässt.
Wir bereinigen sie nicht stillschweigend. Die Anwendung erkennt Dublettenkandidaten anhand von Merkmalen wie Name, Anschrift und Umsatzsteuer-Identifikationsnummer und legt sie zur Entscheidung vor. Bestätigte Zuordnungen werden dauerhaft gespeichert, sodass beide alten Nummern weiterhin auffindbar bleiben und historische Auswertungen nicht ins Leere laufen.
Es ist eine Entwurfsvorgabe. Wir halten den Datenverkehr je Bedienschritt gering und laden Listen seitenweise statt vollständig. Zusätzlich messen wir während der Entwicklung unter absichtlich verschlechterten Bedingungen, weil sich solche Effekte am Hauptsitz sonst nie zeigen.
Meist ja. Wir bevorzugen die dokumentierte Schnittstelle des Herstellers. Fehlt sie, prüfen wir Export- und Berichtsfunktionen oder – nach Abstimmung mit dem Anbieter – einen lesenden Datenbankzugriff. Schreibende Eingriffe an Herstellervorgaben vorbei lehnen wir ab.
Gebiets- und Rollenzuschnitte legen wir bewusst als Konfiguration an, nicht als feste Regel im Code. Eine Neuaufteilung von Gebieten oder eine geänderte Freigabestufe lässt sich damit von Ihren eigenen Verantwortlichen umsetzen. Historische Vorgänge behalten dabei die Zuordnung, die zum Zeitpunkt ihrer Entstehung galt, damit alte Auswertungen weiterhin stimmen.
Lass uns über dein Projekt sprechen
Kostenloses Erstgespräch & IT-Bestandsaufnahme – unverbindlich und ohne versteckte Kosten.