Ja. Ein zweiter Betrieb, ein zweiter Laden, mehrere Baustellen: Der Standort ist eine DATENENTITÄT, die Sie zum Zeitpunkt der Generierung beschreiben – nicht eine zu kaufende Software-Edition. Jeder Datensatz ist seinem Standort zugeordnet, Listen werden gefiltert, Kennzahlen berechnen sich ausschließlich auf Basis Ihres definierten Rahmens – und keinerlei Preisposition hängt von der Anzahl der Standorte ab. Zwei Grenzen sollten Sie vorab kennen – sie sind entscheidend: Es gibt keinen GLOBALEN Standort-Selektor, der die gesamte Anwendung mit einem Klick umschaltet; zudem unterliegen Benutzerkonten keiner standortspezifischen Einschränkung – ein Konto mit Lesezugriff kann alles lesen. Auf dieser Seite erfahren Sie, was funktioniert, welche Struktur Sie je nach Ihren Standorten wählen sollten – und was zusätzliche Entwicklung erfordern würde.
Die Falle liegt nicht im Preis, sondern in der Duplizierung
Branchenvergleiche zeigen immer wieder dasselbe: Öffnet ein kleines Unternehmen einen zweiten Verkaufsstandort, ohne dafür geeignetes Werkzeug zu nutzen, installiert es einfach eine KOPIE der bestehenden Lösung. Das Ergebnis: zwei unabhängige Dateien, zwei getrennte Rechnungsstellungen – und keine Gesamtübersicht ohne manuelle Monatsabschluss-Kompilation. Hinzu kommt eine subtilere Frustration: Viele Tools werben mit „Mehrfachfilialen“, bieten aber keine echte zentrale Steuerung – Sie haben lediglich Kassen addiert, keinen vernetzten Verbund geschaffen.
Die entscheidende Frage lautet daher nicht „Bietet diese Software eine Mehrstandort-Option?“, sondern „Wie wird der Standort in meinen Daten modelliert?“. Hier geht es um ein MODELLIERUNGS-Problem – und genau hier unterscheidet sich eine beschriebene und dann generierte Anwendung fundamental von einem Standardprodukt aus dem Regal: Es gibt keine höhere Edition, die Sie freischalten müssten – sondern eine Beschreibung, die Sie einmal korrekt formulieren müssen.
Der Standort ist eine Datenentität – nicht eine Software-Edition
Konkret beschreiben Sie ihn wie alle anderen Daten: „Ich betreibe zwei Werkstätten, Nord und Süd; jeder Auftrag, jedes Lagerartikel und jeder Kunde gehört einer davon an – und ich möchte meine Kennzahlen pro Werkstatt sehen.“ Der Generator erstellt daraufhin die passende Struktur: die entsprechende Entität oder Werteliste, die Zuordnung jedes Datensatzes, die entsprechenden Filterfunktionen auf den Bildschirmen. Nichts wird erraten: Was Sie nicht beschreiben, existiert nicht; was Sie beschreiben, wird deterministisch umgesetzt.
Ein Punkt verdient besondere Klarheit – weil er ungewöhnlich ist: Keine Position der Preisliste hängt von der Anzahl der Standorte ab. Die Tarifmodelle unterscheiden sich nach der Anzahl aktiver Anwendungen und nach dem Umfang der Generierung – nicht nach der Zahl der Filialen, Werkstätten oder Baustellen, die Ihre Anwendung verfolgt. Ein dritter Standort ist kein neues Tarifstufen-Kriterium, sondern einfach ein weiterer Wert in einer Liste.
Welche Struktur passt zu Ihren Standorten?
Es gibt zwei mögliche Strukturen – mit unterschiedlichen Auswirkungen. Entscheiden Sie also bewusst: Wenn Ihre Standorte wenige und stabil sind – etwa zwei Werkstätten oder drei Filialen – definieren Sie sie als WERTELISTE. Das ist die leistungsfähigste Variante: Das Filterfeld enthält dann neben der Suchfunktion auch einen Standort-Selektor; der gewählte Filter bleibt in der Seiten-URL erhalten – ein Link wie „Überfällige Aufträge in der Werkstatt Süd“ lässt sich also direkt an Kolleg:innen weiterleiten – und Ansichten, die nach Status gruppieren, können zusätzlich nach Standort gruppieren.
Wenn Ihre Standorte dagegen vollwertige Datensätze sind – mit Adresse, Verantwortlichem, Öffnungszeiten, Kontakt – dann handelt es sich um eigenständige DATENSÄTZE, die mit Ihren anderen Daten verknüpft werden. Sie gewinnen damit die komplette Standort-Detailansicht – verzichten aber auf den direkten Selektor: Das Filterfeld fügt nur für Wertelisten ein dediziertes Kriterium hinzu; andere Felder werden in die Volltextsuche integriert – die sie bereits abdeckt. In beiden Fällen lässt sich ein Dashboard-Kennzahl jedoch stets auf einen einzelnen Standort eingrenzen: Ein Klick führt direkt zur entsprechenden Liste – bereits gefiltert.
Die beiden Grenzen, die Sie vorab kennen sollten
Erstens: Es gibt keinen GLOBALEN Standort-Selektor. Das Filtern findet jeweils innerhalb einer Liste statt – es gibt keinen Schalter oben auf dem Bildschirm, der die gesamte Anwendung für die aktuelle Sitzung in den „Werkstatt-Süd-Modus“ versetzt. Für kleine Strukturen, die gerade eine Gesamtübersicht brauchen, ist das kein Hindernis – im Gegenteil: Es löst genau das Problem, das oben beschrieben wurde. Für Nutzer:innen, die den ganzen Tag an einem einzigen Standort arbeiten und niemals etwas anderes sehen möchten, ist es jedoch eine echte Einschränkung – und besser, man weiß das vorher.
Zweitens ist die Einschränkung gravierender: Benutzerkonten unterliegen keiner standortspezifischen Zugriffsbeschränkung. Eine Anwendung mit Login-Funktion bietet echtes Benutzermanagement – mit individuellen Zugangsdaten, Lesezugriff oder Bearbeitungsrechten. Doch dieses Recht gilt für die gesamte Anwendung – nicht für einen Teilbereich. Ein Konto mit Lesezugriff kann alles lesen. Ist die Vertraulichkeit zwischen Standorten zwingend erforderlich, gibt es zwei Wege: Diese Trennung in den Code einbauen – Ihr Code gehört Ihnen und ist exportierbar – oder pro Standort eine eigene Anwendung generieren. Letzteres bedeutet allerdings, genau das ursprüngliche Problem zurückzubekommen: die fehlende Gesamtübersicht. Das im Vorfeld zu wissen, ist besser, als es später festzustellen.