Zum Inhalt springen
DESATIV
Individualsoftware Landkreis München

Eine Anwendung, die an jedem Standort gleich funktioniert

Entwicklung von Fachanwendungen für Unternehmen mit mehreren Betriebsstätten im Ring um München – vom ersten Pilotstandort bis zum vollständigen Rollout.

Rund um die Landeshauptstadt bildet der Landkreis München den wirtschaftsstärksten Kreis Bayerns. Die Struktur reicht von Hightech über Handel bis zum klassischen Handwerk. Für Softwareprojekte entsteht daraus eine eigene Schwierigkeit, die mit dem Fachthema wenig zu tun hat: Unternehmen hier arbeiten selten an einem Ort. Verwaltung in der einen Gemeinde, Lager in der nächsten, Montage im Süden, dazu Mitarbeitende, die zwischen den Standorten pendeln. Eine Anwendung, die nur am Hauptsitz zuverlässig läuft, ist in dieser Konstellation keine Lösung, sondern eine neue Baustelle.

Hände tippen auf einer Tastatur, darüber eingeblendeter Programmcode

Zentral bereitgestellt, überall erreichbar

Eine Installation für alle Standorte statt separater Datenbestände, die sich nach einem halben Jahr unterscheiden.

Standortbezogene Sichten

Jeder Standort sieht seine Vorgänge, die Leitung sieht alle. Die Abgrenzung liegt im Datenmodell, nicht in der Absprache.

Rollout in geplanter Reihenfolge

Ein Pilotstandort geht voran, die übrigen folgen gestaffelt. Erkenntnisse aus dem Piloten fließen vorher ein.

Verträglich mit schwacher Leitung

Nicht jede Gemeinde ist gleich gut angebunden. Die Anwendung wird auf sparsame Datenübertragung ausgelegt.

1 Bestand
gemeinsame Datenhaltung über alle Betriebsstätten
4-6 Wo.
Echtbetrieb im Piloten vor dem weiteren Rollout
2-4 Wo.
Analysephase vor Entwicklungsbeginn

Warum getrennte Datenbestände auseinanderlaufen

Der historisch gewachsene Zustand sieht oft so aus: Jeder Standort hat seine eigene Datei oder seine eigene Installation, und einmal im Monat werden Zahlen zusammengetragen. Das funktioniert, solange die Standorte unabhängig arbeiten. Sobald ein Auftrag beide betrifft, beginnt das Abgleichen.

Schwerer wiegt, dass sich die Handhabung auseinanderentwickelt. Ein Standort führt ein Feld anders, ein anderer legt Vorgänge doppelt an, und die Auswertung über alle hinweg wird zur Interpretationsfrage. Eine gemeinsame Anwendung erzwingt eine gemeinsame Definition – und genau diese Diskussion ist der eigentliche Nutzen.

  • Gemeinsame Begriffe und Felddefinitionen erarbeiten
  • Ein Datenbestand statt monatlicher Zusammenführung
  • Standortübergreifende Vorgänge ohne Abgleich
  • Auswertung über alle Betriebsstätten mit gleicher Grundlage

Mandanten- und Standortstruktur im Datenmodell

Die Zuordnung eines Vorgangs zu einem Standort gehört an die Wurzel des Datenmodells, nicht als nachträgliches Merkmal. Sonst entstehen Auswertungen, die je nach Einstiegspunkt unterschiedliche Summen liefern.

Wir legen früh fest, was standortübergreifend gilt – Kunden, Artikel, Preise – und was strikt lokal bleibt. Berechtigungen werden entlang dieser Struktur vergeben, sodass eine Kraft mit Zuständigkeit für zwei Standorte beide sieht, ohne dafür ein zweites Konto zu brauchen.

  • Standortzuordnung als Bestandteil jedes Vorgangs
  • Abgrenzung gemeinsamer und lokaler Stammdaten
  • Berechtigungen für mehrere Standorte ohne Zweitkonto
  • Konsistente Summen unabhängig vom Einstiegspunkt

Rollout planen statt umschalten

Ein gleichzeitiger Start an allen Standorten überfordert jede Einführungsbegleitung. Wir wählen deshalb einen Pilotstandort, der repräsentativ ist und dessen Leitung das Vorhaben mitträgt – nicht den kleinsten und nicht den kompliziertesten.

Nach vier bis sechs Wochen Echtbetrieb im Piloten sammeln wir die Rückmeldungen ein, passen an und beginnen den gestaffelten Rollout. Jeder weitere Standort bekommt eine Version, die bereits im Alltag bestanden hat, und eine Einweisung, die auf echten Fragen beruht statt auf vermuteten.

  • Auswahl eines repräsentativen Pilotstandorts
  • Echtbetrieb im Piloten vor der Ausweitung
  • Anpassungen aus dem Piloten vor dem Rollout
  • Einweisung anhand tatsächlich aufgetretener Fragen

Ungleiche Anbindung berücksichtigen

Die Anbindungsqualität unterscheidet sich im Landkreis erheblich. Ein Gewerbegebiet mit Glasfaser und ein Lagerstandort am Rand einer Gemeinde stellen völlig unterschiedliche Bedingungen dar. Eine Anwendung, die nur unter guten Bedingungen brauchbar reagiert, wird an den schwächeren Standorten abgelehnt.

Wir prüfen deshalb früh, wie sich die Bedienung bei geringer Bandbreite und hoher Verzögerung anfühlt. Übertragen wird nur, was gebraucht wird, Listen werden abschnittsweise geladen, und Eingaben bleiben bei einem Verbindungsabbruch erhalten, statt verloren zu gehen.

  • Prüfung der Bedienung unter schlechten Verbindungen
  • Sparsame Übertragung und abschnittsweises Laden
  • Eingaben überstehen einen Verbindungsabbruch
  • Erkennbare Anzeige des Verbindungszustands

Vor-Ort-Termine im Ring organisieren

Auch bei überwiegend remote geführten Projekten sind Präsenztermine notwendig: Prozessaufnahme, Einweisung, Begleitung der ersten Produktivtage. Im Ring um München bedeutet das Fahrzeiten, die je nach Verkehrslage stark schwanken.

Wir bündeln solche Termine standortweise zu ganzen Tagen, statt einzelne Stunden anzusetzen, und stimmen sie mit den Schichten vor Ort ab. Zwischen den Terminen läuft die Zusammenarbeit über Bildschirmfreigabe und ein gemeinsames Aufgabenverzeichnis, in dem der Stand jederzeit einsehbar ist.

  • Präsenztermine standortweise zu ganzen Tagen gebündelt
  • Abstimmung mit Schicht- und Betriebszeiten
  • Laufende Zusammenarbeit über Bildschirmfreigabe
  • Gemeinsames Aufgabenverzeichnis mit sichtbarem Stand
IT läuft. Team arbeitet.IT läuft. Team arbeitet.IT läuft. Team arbeitet.IT läuft. Team arbeitet.IT läuft. Team arbeitet.IT läuft. Team arbeitet.
IT läuft. Team arbeitet.IT läuft. Team arbeitet.IT läuft. Team arbeitet.IT läuft. Team arbeitet.IT läuft. Team arbeitet.IT läuft. Team arbeitet.
IT läuft. Team arbeitet.IT läuft. Team arbeitet.IT läuft. Team arbeitet.IT läuft. Team arbeitet.IT läuft. Team arbeitet.IT läuft. Team arbeitet.
IT läuft. Team arbeitet.IT läuft. Team arbeitet.IT läuft. Team arbeitet.IT läuft. Team arbeitet.IT läuft. Team arbeitet.IT läuft. Team arbeitet.

Häufige Fragen

Meistens nicht. Die Bereitstellung erfolgt zentral, entweder in Ihrem Rechenzentrum oder in einer gehosteten Umgebung. Lokale Server an jedem Standort erzeugen Pflegeaufwand und die Gefahr abweichender Stände. Ausnahmen sind Standorte, an denen Geräte wie Waagen oder Etikettendrucker direkt angesprochen werden müssen.

Zuerst prüfen wir, ob der Unterschied fachlich begründet ist oder historisch entstanden. Häufig ist Letzteres der Fall, dann einigen Sie sich auf einen gemeinsamen Ablauf. Echte Unterschiede bilden wir über konfigurierbare Einstellungen je Standort ab, nicht über getrennte Programmversionen.

Ja, das ist während des gestaffelten Rollouts sogar der Normalzustand. Für die Übergangszeit richten wir eine Datenübergabe zwischen alter und neuer Welt ein, damit standortübergreifende Auswertungen weiter möglich bleiben. Diesen Zusatzaufwand begrenzen wir zeitlich, weil er dauerhaft nicht sinnvoll ist.

Üblich ist ein Wartungsvertrag mit Reaktionszeiten, laufender Aktualisierung und einem monatlichen Kontingent für kleine Anpassungen. Ergänzend empfehlen wir, an jedem Standort eine Ansprechperson zu benennen, die Rückfragen sammelt. Das reduziert Einzelanfragen erheblich und macht wiederkehrende Probleme sichtbar.

Quellcode, Repository-Historie, Datenmodell und Bereitstellungsbeschreibung liegen bei Ihnen und sind während der gesamten Entwicklung zugänglich. Wir verwenden verbreitete Technologien, damit ein Wechsel technisch möglich bleibt. Eine Bindung, die nur auf fehlender Dokumentation beruht, halten wir für die schlechteste Form der Kundenbeziehung.

Lass uns über dein Projekt sprechen

Kostenloses Erstgespräch & IT-Bestandsaufnahme – unverbindlich und ohne versteckte Kosten.