Ein maßgeschneidertes internes System ist sinnvoll, wenn sich ein spezifischer und häufig genutzter Prozess mit einem fertigen Tool nicht vernünftig abdecken lässt und das Unternehmen bereit ist, dessen Daten, Regeln und Betrieb selbst zu verantworten. Vor der Entwicklung sollte der Prozess vereinheitlicht, von unnötigen Schritten befreit und das eigene System mit der Konfiguration verfügbarer Produkte verglichen werden.
Ein internes Unternehmenssystem verbindet Menschen, Daten und Entscheidungen in einem Prozess, den ein universelles Tool nicht ausreichend abdeckt. Es kann eine Kette aus E-Mails, geteilten Tabellen und manuellen Übertragungen bei Aufträgen, Produktion, Freigaben oder Service ersetzen. Eine Eigenentwicklung ist jedoch nicht automatisch besser als ein fertiger Dienst; sie bringt auch eine langfristige Verantwortung für den Betrieb mit sich.
Die Entscheidung sollte sich am Wert eines abweichenden Prozesses orientieren, nicht an der fehlenden Bereitschaft, sich einem Standard anzupassen. Ist eine Tätigkeit üblich und deckt ein fertiges Produkt sie ab, kann die Konfiguration schneller sein. Ein maßgeschneidertes System ist bei spezifischen Regeln, mehreren Anbindungen und wiederkehrender Arbeit sinnvoller, wo ein präziser Ablauf einen nachhaltigen Vorteil bringt.
Praxisbeispiel: Systemanforderungen anhand eines Arbeitsablaufs
Statt der Vorgabe „Wir brauchen ein CRM“ beschreiben Sie einen Weg von der Eingabe bis zum Ergebnis. Das folgende Beispiel einer Anfrageverwaltung ist eine Modellvorgabe, keine Angabe zu Ergebnissen eines bestimmten Kunden. Ziel ist es, Verantwortlichkeiten, Status und Situationen festzulegen, in denen der Prozess das Eingreifen eines Menschen erfordert.
| Schritt | Angabe oder Entscheidung | Ergebnis |
|---|---|---|
| Eingegangene Anfrage | Kontakt, Quelle, gewünschte Leistung und Datum | Ein Datensatz mit interner ID |
| Duplikatprüfung | Gibt es bereits dieselbe Anfrage oder denselben Kunden? | Zuordnung zu einem bestehenden Datensatz oder neue ID |
| Zuweisung | Verantwortliche Person und Reaktionsfrist | Aufgabe mit Verantwortlichem |
| Angebot | Umfang, Preis und Version der Unterlagen | Angebot bereit zur Freigabe |
| Abschluss | Angenommen, abgelehnt oder zurückgestellt | Ergebnis mit Datum und Begründung |
Legen Sie für jeden Zustand den zulässigen nächsten Schritt und die Person fest, die ihn ausführen darf. Beispielsweise erstellt der Vertrieb ein Angebot, ein Freigeber bestätigt es und erst dann wird es an den Kunden gesendet. Ändern sich Preis oder Umfang, muss die Freigabe zur neuen Version gehören. Es genügt nicht, ein Kennzeichen „freigegeben“ ohne Historie zu speichern.
Was am Prototyp zu prüfen ist
- Eine Anfrage ohne Pflichtkontakt kann nicht an den nächsten Schritt übergeben werden.
- Mitarbeitende sehen nur Datensätze, für die sie berechtigt sind.
- Ein wiederholter Import erzeugt keine zweite Anfrage.
- Der Verlauf zeigt, wer den Status geändert hat und auf welcher Angebotsversion dies beruhte.
- Ein fehlgeschlagener E-Mail-Versand erzeugt eine wiederholbare Aufgabe und markiert die Nachricht nicht als zugestellt.
Als kleineres reales Beispiel für die Trennung von Inhalt und Prozess dient diese Website: Artikel, Themen und Einstellungen sind eigenständige Daten in WordPress. Ein internes Geschäftssystem benötigt jedoch ein eigenes Konzept für Berechtigungen und Arbeitsabläufe. Bereiten Sie vor der Implementierung Beispieldatensätze und Abnahmetests vor; das weitere Vorgehen finden Sie unter maßgeschneiderten Webanwendungen.
Audit des aktuellen Prozesses und versteckter Kosten
Bilden Sie einen konkreten Fall von der Entgegennahme der Eingabe bis zum Abschluss ab. Achten Sie auf Abtippen, die Suche nach der richtigen Version, Wartezeiten auf Freigaben, Korrekturen und die manuelle Erstellung von Berichten. Beziffern Sie Volumen und Zeitaufwand, halten Sie aber auch das Fehlerrisiko und die Abhängigkeit von einem einzelnen Mitarbeiter fest. Diese Daten bilden die Grundlage für den Vergleich mit den Entwicklungs- und Betriebskosten.
Unterscheiden Sie ein Problem des Werkzeugs von einem Problem der Regeln. Wenn niemand weiß, wer eine Ausnahme genehmigen soll, löst ein neues System diese Unklarheit nicht. Vereinheitlichen Sie vor dem Entwurf Begriffe, Zuständigkeiten und Entscheidungspunkte. Entfernen Sie unproduktive Schritte, statt sie zu digitalisieren. Erst dann zeigt sich, welche Funktionen Sie tatsächlich benötigen.
Fertiges Produkt, Low-Code oder Eigenentwicklung
Vergleichen Sie Lösungen danach, wie gut sie den Kernprozess abdecken, sowie nach Integrationsmöglichkeiten, Berechtigungen, Datenexport, Sicherheit und Gesamtkosten über mehrere Jahre. Eine Demo mit einem hübschen Dashboard reicht nicht aus. Erstellen Sie ein Testszenario mit realen Rollen und Ausnahmen. Prüfen Sie, ob sich das Produkt ohne fragile Workarounds und zahlreiche manuelle Schritte anpassen lässt.
Low-Code kann ein internes Tool beschleunigen, wenn die Grenzen der Plattform zu den Daten und Integrationen passen. Eine eigene Entwicklung bietet mehr Kontrolle, erfordert aber ein Team für die Wartung. Erwägen Sie auch einen hybriden Ansatz: Das fertige System bleibt die Single Source of Truth, und eine eigene Anwendung deckt eine spezifische Oberfläche oder einen Workflow über eine unterstützte API ab.
- Abdeckung der entscheidenden Regeln und Ausnahmen
- Dateneigentum, Export und Datenportabilität
- Sicherheit, Audit und Berechtigungsverwaltung
- Lizenzen, Entwicklung, Support und Änderungskosten
Rollen, Daten und Auditierbarkeit
Jede Rolle benötigt genau festgelegte Ansichten und Aktionen. Eine Führungskraft kann freigeben, ein Mitarbeiter eigene Fälle bearbeiten und ein Auditor nur den Verlauf lesen. Prüfen Sie Berechtigungen bei jeder Anfrage auf dem Server. Speichern Sie wichtige Änderungen mit Zeitpunkt, Nutzer und ursprünglichem Wert, damit sie sich nachvollziehen und in angemessenem Umfang rückgängig machen lassen.
Legen Sie die maßgebliche Datenquelle für Kunde, Projekt, Status und Finanzangaben fest. Existiert dasselbe Feld sowohl im CRM als auch im internen System, bestimmen Sie die Synchronisationsrichtung und die Konfliktlösung. Minimieren Sie personenbezogene Daten und sensible Anhänge. Aufbewahrung, Zugriffe und rechtliche Pflichten sollten Sie je nach konkretem Einsatz mit den zuständigen Fachleuten prüfen.
Migration aus Tabellen und dem Altsystem
Profilieren Sie die Daten vor dem Import: Finden Sie Duplikate, fehlende Werte, ungültige Datumsangaben und abweichende Bezeichnungen. Erstellen Sie eine Feldzuordnung und Transformationsregeln. Testen Sie jeden Import zuerst in einer Testumgebung und vergleichen Sie sowohl die Anzahl als auch ausgewählte Datensätze. Bewahren Sie die Originaldateien als kontrollierte Sicherung mit eingeschränktem Zugriff auf.
Der Umstieg kann schrittweise nach Teams oder Fallarten erfolgen. Legen Sie den Zeitpunkt fest, ab dem das alte System nur noch lesend genutzt wird, damit nicht zwei Wahrheiten entstehen. Bereiten Sie Support und einen Kommunikationskanal für Fehler vor. Eine kurze Schulung, die auf alltäglichen Aufgaben aufbaut, ist wirksamer als ein allgemeiner Rundgang durch alle Möglichkeiten.
Betrieb und Weiterentwicklung nach tatsächlicher Nutzung
Überwachen Sie nach dem Deployment den Abschluss von Prozessen, offene Fälle, Fehler, Performance und die Nutzung zentraler Funktionen. Verknüpfen Sie das Feedback des Supports mit den Daten. Die Funktion, über die gesprochen wird, ist nicht unbedingt die, an der die Arbeit tatsächlich ins Stocken gerät. Priorisieren Sie nach Auswirkung auf den Prozess und nach Risiko.
Das System braucht einen Product Owner, technische Wartung, Updates, Backups und einen Incident-Plan. Dokumentieren Sie Geschäftsregeln ebenso wie Integrationsabhängigkeiten. Überprüfen Sie regelmäßig Konten und Lizenzen. So wird die interne Anwendung nicht zu einem neuen Altsystem, das sich nach Jahren niemand mehr zu ändern traut.
Steuerung des organisatorischen Wandels und der Akzeptanz
Ein neues System verändert Zuständigkeiten, die Sichtbarkeit der Arbeit und oft auch die gewohnte Verfügungsmacht über Informationen. Widerstand muss nicht Unwillen zum Lernen bedeuten; er kann auf eine fehlende Ausnahme, die Sorge vor Kontrolle oder eine tatsächliche Verlangsamung einer Aufgabe hinweisen. Erklären Sie den Grund der Änderung, beziehen Sie Vertreter der Rollen ein und zeigen Sie, welche alten Schritte nach der Einführung entfallen. Wenn Sie von Mitarbeitenden verlangen, das neue System und parallel eine Tabelle ohne Enddatum zu nutzen, werden sie es naturgemäß als zusätzliche Verwaltungsarbeit wahrnehmen. Führungskräfte sollten die neuen Quellen bei ihren eigenen Entscheidungen nutzen.
Messen Sie die Akzeptanz anhand abgeschlossener Arbeitsvorgänge, der Datenqualität und des Supportbedarfs, nicht nur anhand der Anzahl der Anmeldungen. Bauen Sie ein Netzwerk interner Botschafter auf, die den Prozess verstehen und wiederkehrende Fragen sammeln können. Gliedern Sie kurze Anleitungen nach Aufgaben und pflegen Sie sie zusammen mit den Releases. Teilen Sie bei einer Regeländerung den Grund, das Datum und die betroffenen Rollen mit. Honorieren Sie Hinweise auf mangelhafte Daten und Fehler, denn deren frühes Eingestehen schützt das System. Bewerten Sie nach der Pilotphase, ob sich der ursprüngliche Prozess tatsächlich vereinfacht hat und welche alten Werkzeuge sicher abgeschaltet werden können. Achten Sie auch auf inoffizielle Exporte und Hilfstabellen. Sie können eine fehlende Funktion aufdecken, aber auch eine unkontrollierte Kopie sensibler Daten erzeugen, die sowohl organisatorisch als auch technisch behandelt werden muss.
- klarer Grund und sichtbarer Verantwortlicher der Änderung
- Abschaffung doppelter alter Verzeichnisse
- Anleitungen nach realen Arbeitsaufgaben
- Nutzung, gemessen an Ergebnis und Datenqualität
Häufige Fragen
Wann lohnt sich ein individuelles System?
Wenn ein häufig genutzter spezifischer Prozess erhebliche manuelle Kosten oder Fehler verursacht und fertige Lösungen ihn nicht ohne unpraktische Umwege abdecken.
Lässt sich ein internes System an bestehende Tools anbinden?
In der Regel ja, wenn sie eine stabile API oder einen anderen unterstützten Austauschweg bieten. Eine Integration erfordert klare Datenverantwortung, Validierung, Monitoring und Fehlerbehandlung.
Wie bindet man Mitarbeitende in den Entwurf ein?
Beobachten Sie ihre aktuelle Arbeit, testen Sie mit ihnen Prototyp und Pilot und sammeln Sie konkrete Beispiele für Probleme. Die endgültigen Prioritäten sollten sich jedoch an den Prozesszielen orientieren.
Quellen und weiterführende Lektüre
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
