MES-Eigenentwicklung ablösen: der Weg vom Inhouse-Tool zur Standardsoftware ohne Bus-Faktor-Risiko
Ein Manufacturing Execution System (MES) erfasst und steuert Fertigungsdaten in Echtzeit auf dem Shopfloor. Viele Fertigungsunternehmen im DACH-Raum betreiben dafür bis heute keine Standardsoftware, sondern eine selbst gebaute Lösung für Maschinenanbindung, Schichtbuch oder Auftragssteuerung, oft entstanden, weil vor Jahren kein passendes Produkt am Markt war oder das Budget fehlte. Laut einer Bitkom-Erhebung aus dem Jahr 2017 entwickelten 33 Prozent der deutschen Unternehmen ab 20 Mitarbeitenden eigene Software. Diese Seite zeigt, woran Sie erkennen, dass die Eigenentwicklung zum Risiko wird, wie der Umstieg auf ein Standard-MES abläuft und was er kostet.
Warum in deutschen Fertigungsbetrieben noch heute Eigenentwicklungen laufen
Die Eigenentwicklung war zum Zeitpunkt ihrer Entstehung meist eine vernünftige Entscheidung. Das Problem entsteht erst Jahre später.
In vielen mittelständischen Fertigungsbetrieben im DACH-Raum entstand die Steuerungssoftware für Schichtbuch, Maschinenanbindung oder Auftragsverfolgung nicht durch den Kauf eines Manufacturing Execution Systems, sondern durch die Eigenleistung eines internen Entwicklers, einer kleinen IT-Abteilung oder einer beauftragten Agentur. Nach der bereits genannten Bitkom-Erhebung aus 2017 programmierten 33 Prozent aller Unternehmen ab 20 Mitarbeitenden eigene Software, bei Unternehmen ab 500 Mitarbeitenden waren es sogar 64 Prozent. Ein Teil dieser Lösungen lief auch in der Fertigung, häufig als Access-Datenbank, Excel-VBA-Werkzeug oder selbst programmierter Client zur Maschinen- und Betriebsdatenerfassung.
Diese Lösungen waren zum Startzeitpunkt oft günstiger als eine Standardsoftware und exakt auf den damaligen Prozess zugeschnitten. Das Problem zeigt sich erst mit der Zeit: Die Fertigung wächst, neue Linien oder Werke kommen hinzu, Kunden verlangen Nachweise, und die Person, die den Code versteht, ist irgendwann nicht mehr im Unternehmen.
Was auf dieser Seite als Eigenentwicklung zählt: selbst oder extern beauftragt programmierte Software für Fertigungssteuerung, Maschinenanbindung oder Betriebsdatenerfassung, die ohne Produktzyklus, ohne Herstellersupport und meist ohne vollständige Dokumentation betrieben wird. Ausdrücklich eingeschlossen sind gewachsene Excel- und Access-Lösungen, wenn sie über reine Auswertung hinaus aktiv zur Produktionssteuerung genutzt werden.
Fünf Anzeichen, dass die Eigenentwicklung zum Risiko wird
Keines dieser Anzeichen bedeutet für sich allein sofortigen Handlungsbedarf. Treffen zwei oder mehr zu, wird die Ablösung zur Frage des Zeitpunkts, nicht mehr des Ob.
Bus-Faktor-Risiko
Eine einzelne Person versteht den Code vollständig, oft der ursprüngliche Entwickler oder eine langjährige IT-Kraft. Fällt diese Person aus oder verlässt das Unternehmen, kann niemand mehr Fehler beheben oder Anpassungen vornehmen.
Laut einer Destatis-Pressemitteilung aus dem Jahr 2026 erreichen bis 2040 rund 13,3 Millionen Erwerbspersonen das gesetzliche Rentenalter, das ist knapp ein Drittel der heutigen Erwerbspersonen. Der Ausfall einer Schlüsselperson ist damit kein Einzelfallrisiko, sondern ein demografisch wachsendes.
- Kein Backup-Wissen im Team
- Keine oder veraltete Code-Dokumentation
- Änderungen dauern Wochen statt Tage
Keine Wartung und Weiterentwicklung mehr
Der ursprüngliche Entwickler ist in eine andere Rolle gewechselt oder die beauftragte Agentur existiert nicht mehr. Fehler werden notdürftig umschifft statt behoben, neue Anforderungen bleiben liegen.
- Bekannte Fehler seit Jahren ungelöst
- Keine Sicherheitsupdates für die verwendeten Frameworks
- Neue Anforderungen landen auf Zuruf bei IT-Generalisten
Fehlende Skalierbarkeit
Die Lösung wurde für eine Linie oder ein Werk gebaut. Beim Rollout auf ein zweites Werk oder bei steigenden Datenmengen zeigen sich Performance-Grenzen, die in der ursprünglichen Architektur nicht vorgesehen waren.
- Manuelle Sonderlösung pro Standort
- Keine Mandantenfähigkeit
- Reporting wird bei wachsender Datenmenge spürbar langsamer
Keine Compliance und keine Standardschnittstellen
Standardisierte Schnittstellen wie OPC UA nach IEC 62541 oder eine Integration nach dem Referenzmodell ISA-95 (IEC 62264) fehlen meist vollständig. Jede neue Maschine oder jedes neue ERP-Modul braucht eine handgestrickte Sonderanbindung.
- Kein durchgängiger Audit-Trail
- Manuelle Doppelerfassung ins ERP
- Jede neue Schnittstelle ist ein Einzelprojekt
Hoher technischer Schuldenberg
Jahre von schnellen Anpassungen unter Zeitdruck summieren sich zu einer Architektur, die niemand mehr vollständig überblickt. Verwendete Programmiersprachen oder Bibliotheken erreichen teils das Ende ihres Supportzyklus.
- Undokumentierte Abhängigkeiten zwischen Modulen
- Veraltete, nicht mehr unterstützte Laufzeitumgebung
- Jede Änderung erhöht das Risiko eines Ausfalls andernorts
Was ein Standard-MES leistet, das die Eigenentwicklung nicht mehr trägt
Der Vergleich zeigt die strukturellen Unterschiede, nicht die Qualität eines einzelnen Anbieters.
| Dimension | Eigenentwicklung | Standard-MES |
|---|---|---|
| Wartung und Support | Abhängig von einer Person oder einem externen Dienstleister ohne SLA | Standard Herstellersupport mit Wartungsvertrag und Patch-Zyklus |
| Wissen und Abhängigkeit | Bus-Faktor 1, Wissen an einzelne Köpfe gebunden | Dokumentierte Architektur, Schulungsmaterial, Partnernetzwerk |
| Schnittstellen-Standards | Individuelle Anbindung je Maschine oder System | OPC UA und ISA-95-Referenzmodell als Standardfunktion |
| Skalierbarkeit | Meist für eine Linie oder ein Werk konzipiert | Mandantenfähig, für mehrere Werke ausgelegt |
| Validierung und Audit-Trail | Selten vollständig, oft nachträglich behelfsmäßig ergänzt | Audit-Trail und Berechtigungskonzept als Kernfunktion |
| Weiterentwicklung | Abhängig von Kapazität der internen IT | Regelmäßige Produktversionen mit neuen Funktionen |
| Sicherheitsupdates | Unregelmäßig, oft ausstehend | Herstellerseitig gepflegter Patch-Zyklus |
| Time-to-Value bei neuen Anforderungen | Abhängig von freien Entwicklerkapazitäten, oft Monate | Konfiguration statt Programmierung, meist Tage bis Wochen |
| Einstiegsaufwand | Gering bis keiner, da bereits vorhanden | Migrationsprojekt mit Datenübernahme und Schulung nötig |
Die letzte Zeile spricht zunächst für die Eigenentwicklung: Sie ist bereits da, ein Wechsel kostet Zeit und Geld. Der Umstieg lohnt sich in der Regel, sobald Wartungssicherheit, Schnittstellen-Standards oder Skalierbarkeit zum limitierenden Faktor für das Unternehmen werden.
Wann die Eigenentwicklung weiterhin die richtige Wahl bleibt
Nicht jede Eigenentwicklung muss abgelöst werden. Diese drei Fälle sprechen dagegen.
Sehr kleiner, hochspezialisierter Prozess
Eine einzelne, stabile Maschine oder ein einzelner Nischenprozess ohne Wachstumsperspektive, bei dem die Eigenentwicklung seit Jahren fehlerfrei läuft und niemand Skalierung oder neue Schnittstellen erwartet.
Wissen ist im Team verteilt
Kein Bus-Faktor-Risiko, weil mehrere Personen den Code aktiv pflegen und verstehen, die Dokumentation aktuell ist und Änderungen routinemäßig ohne Verzögerung umgesetzt werden.
Die Ablösung ist ohnehin schon terminiert
Ein Standard-MES ist bereits budgetiert und für die nächsten Monate geplant. In diesem Zeitfenster lohnt sich keine Investition mehr in die alte Lösung, wohl aber eine saubere Bestandsaufnahme für die Migration.
Der Kipppunkt in einem Satz: Eine Eigenentwicklung bleibt vertretbar, solange ihr Ausfall verkraftbar wäre und mehr als eine Person sie warten kann. Sobald eine dieser beiden Bedingungen nicht mehr gilt, wird aus einer soliden Lösung ein offenes Risiko.
In sechs Schritten von der Eigenentwicklung zum Standard-MES
Der Ablauf orientiert sich an Sectorlens-Begleitungen vergleichbarer Ablöseprojekte seit 2022.
Bestandsaufnahme der Funktionen und Datenmodelle
Alle Module, Tabellen und Schnittstellen der Eigenentwicklung dokumentieren, inklusive der Sonderfälle, für die sie ursprünglich gebaut wurde.
Priorisierung nach Geschäftskritikalität
Festlegen, welche Funktionen am ersten Tag im neuen System stehen müssen und welche in einer späteren Phase folgen können.
Anbieterauswahl und Fit-Check
Anforderungen aus der Bestandsaufnahme in ein Lastenheft überführen und gegen den Anbietermarkt abgleichen.
Parallelbetrieb in einem Pilotbereich
Eine Linie oder ein Bereich läuft testweise im neuen MES, während die Eigenentwicklung dort im Hintergrund als Rückfallebene aktiv bleibt.
Datenübernahme und Schnittstellen
Stammdaten und relevante Historie migrieren, Maschinenanbindung auf Standardprotokolle wie OPC UA umstellen.
Schulung, Abschaltung, Rollout
Key User schulen, Eigenentwicklung Bereich für Bereich abschalten, auf weitere Linien oder Werke ausrollen.
Was die Ablösung realistisch dauert und wer beteiligt ist
Werte für ein Projekt mittlerer Komplexität, ein Werk, eine bis drei Linien. Größere Rollouts über mehrere Werke verlängern vor allem Phase 6.
| Phase | Dauer | Beteiligte Rollen | Worauf zu achten ist |
|---|---|---|---|
| Bestandsaufnahme | 2–4 Wochen | Produktionsleitung, IT, nach Möglichkeit der bisherige Entwickler | Auch selten genutzte Sonderfunktionen dokumentieren, sie fehlen sonst später im Lastenheft |
| Priorisierung | 1–2 Wochen | Produktionsleitung, Qualitätsmanagement, IT | Nicht alles auf einmal wollen, das verzögert den ersten produktiven Nutzen |
| Anbieterauswahl | 4–8 Wochen | Projektteam, Einkauf, IT, Betriebsrat zur Information | Referenzkunden mit vergleichbarem Umstieg von einer Eigenentwicklung gezielt fragen |
| Pilotbetrieb | 6–12 Wochen | Pilotlinie, Schichtleitung, Consultant des Anbieters | Rückfallebene auf die Eigenentwicklung für die ersten Wochen bewusst offenhalten |
| Datenübernahme | 2–6 Wochen, parallel | IT, Anbieter, bei Bedarf externer Migrationsdienstleister | Datenqualität vor der Übernahme prüfen, nicht erst danach |
| Schulung und Rollout | 9–18 Monate gesamt | Alle Schichten, Key User, Change-Management | Genügend Zeit für zweite und dritte Schulungsrunde je Schicht einplanen |
Erfahrungswerte aus Sectorlens-Begleitungen von Ablöseprojekten seit 2022, keine Zusage für den Einzelfall.
Zehn Fragen an den MES-Anbieter, wenn Sie von einer Eigenentwicklung kommen
Diese Fragen unterscheiden sich von einem klassischen Anbietervergleich, weil es nicht um den Wechsel zwischen zwei Standardprodukten geht, sondern um die Ablösung von etwas Individuellem.
Wie übernehmen Sie unsere bestehenden Stamm- und Bewegungsdaten?
Zeigt, ob der Anbieter Migrationswerkzeuge und Erfahrung mit Datenübernahme aus Individualsoftware hat oder ob das Projekt bei Ihnen hängen bleibt.
Wie bilden Sie unsere Sonderprozesse ab, für die die Eigenentwicklung ursprünglich gebaut wurde?
Eine gute Antwort nennt konkrete Konfigurationsoptionen statt pauschal „das geht immer" zu sagen.
Welche Standardschnittstellen unterstützen Sie ab Werk?
Achten Sie konkret auf OPC UA nach IEC 62541 und auf die ISA-95-Ebenen zur ERP-Integration.
Wie läuft ein Parallelbetrieb mit unserer bisherigen Lösung technisch ab?
Ein erfahrener Anbieter beschreibt ein konkretes Vorgehen für den Pilotbetrieb, nicht nur eine grundsätzliche Zusage.
Was passiert bei einem Netzwerk- oder Systemausfall am Terminal?
Prüft, ob Fertigungsdaten bei einer Störung verloren gehen oder zwischengespeichert werden, ein Punkt, den viele Eigenentwicklungen nie sauber gelöst hatten.
Wie granular ist Ihr Berechtigungskonzept?
Eigenentwicklungen haben oft nur grobe Rollen. Fragen Sie nach Rechten auf Feld- oder Funktionsebene, wenn Sie das brauchen.
Wie hoch ist der Schulungsaufwand je Rolle?
Mitarbeitende, die jahrelang nur die Eigenentwicklung kannten, brauchen realistisch geplante Einarbeitungszeit.
Welche Referenzkunden sind von einer vergleichbaren Eigenentwicklung zu Ihnen gewechselt?
Ein Anbieter mit echter Erfahrung in diesem speziellen Szenario kann konkrete Beispiele nennen.
Was können wir selbst konfigurieren, was erfordert Herstellerentwicklung?
Klärt, ob Sie bei künftigen Anpassungen wieder von einer einzelnen externen Stelle abhängig werden.
Wie sieht der Abschaltplan für die Eigenentwicklung Bereich für Bereich aus?
Eine gute Antwort beschreibt einen stufenweisen Plan statt eines harten Umschaltdatums für den gesamten Betrieb.
MES-Eigenentwicklung ablösen: 18 Fragen aus Ablöseprojekten
Antworten aus Sectorlens-Begleitungen vergleichbarer Umstiegsprojekte seit 2022.
Was bedeutet MES-Eigenentwicklung konkret, und wie unterscheidet sie sich von einem Standard-MES?
Eine MES-Eigenentwicklung ist eine selbst oder extern beauftragt programmierte Software für Fertigungssteuerung, Maschinenanbindung oder Betriebsdatenerfassung, die ohne Produktzyklus und ohne Herstellersupport betrieben wird. Ein Standard-MES ist dagegen ein am Markt erhältliches Produkt mit regelmäßigen Updates, Wartungsvertrag und Partnernetzwerk. Der zentrale Unterschied liegt weniger im Funktionsumfang als in der Frage, wer die Software langfristig pflegt und weiterentwickelt.
Woran erkenne ich, dass unsere Eigenentwicklung an ihre Grenzen stößt?
Typische Anzeichen sind ein Bus-Faktor-Risiko durch eine einzelne wissende Person, ausbleibende Wartung und Weiterentwicklung, Probleme beim Rollout auf neue Linien oder Werke, fehlende Standardschnittstellen wie OPC UA und ein wachsender technischer Schuldenberg aus jahrelangen Notlösungen. Jedes dieser Anzeichen lässt sich für sich prüfen, etwa indem Sie zählen, wie viele Personen im Unternehmen den Code tatsächlich verstehen und eigenständig ändern können. Treffen zwei oder mehr dieser Punkte zu, wird der Umstieg zur Frage des Zeitpunkts.
Was ist der Bus-Faktor, und warum ist er bei Eigenentwicklungen so kritisch?
Der Bus-Faktor beschreibt, wie viele Personen ausfallen müssten, damit das Wissen über ein System verloren geht. Bei vielen Eigenentwicklungen liegt er bei eins, oft dem ursprünglichen Entwickler. Fällt diese Person aus oder verlässt das Unternehmen, kann niemand mehr Fehler beheben oder Anpassungen vornehmen. Laut einer Destatis-Pressemitteilung aus dem Jahr 2026 erreichen bis 2040 rund 13,3 Millionen Erwerbspersonen das gesetzliche Rentenalter, das unterstreicht, wie real dieses Risiko in den kommenden Jahren wird.
Wie lange dauert die Ablösung einer Eigenentwicklung durch ein Standard-MES?
Für ein Werk mit ein bis drei Linien liegt die Gesamtdauer von der Bestandsaufnahme bis zum vollständigen Rollout typischerweise bei 9 bis 18 Monaten. Die Bestandsaufnahme selbst dauert 2 bis 4 Wochen, die Anbieterauswahl 4 bis 8 Wochen und der Pilotbetrieb in einem Bereich 6 bis 12 Wochen. Bei mehreren Werken verlängert sich vor allem die abschließende Rollout-Phase.
Was kostet der Wechsel von einer Eigenentwicklung zu einem Standard-MES?
Die Kosten setzen sich aus Lizenz beziehungsweise Subscription, Implementierung und Beratung, Maschinenanbindung, ERP-Schnittstelle, Hardware am Shopfloor sowie Schulung zusammen. Verbindliche Herstellerpreise können nur die Anbieter selbst nennen, da sie stark von Anzahl der Arbeitsplätze, Maschinen und Modulen abhängen. Ein grober Überblick über typische Kostenblöcke bei einem MES-Wechsel steht auf der Seite zu MES-Kosten und TCO.
Können wir die Eigenentwicklung und das neue MES parallel betreiben?
Ja, ein zeitlich begrenzter Parallelbetrieb ist sogar empfehlenswert. In der Praxis läuft dabei ein Pilotbereich bereits produktiv im neuen MES, während die Eigenentwicklung dort im Hintergrund als Rückfallebene aktiv bleibt. Erst nach erfolgreicher Pilotabnahme wird die Eigenentwicklung Bereich für Bereich abgeschaltet, statt an einem einzigen Stichtag für den gesamten Betrieb.
Was passiert mit den historischen Daten aus der Eigenentwicklung?
Relevante Stamm- und Bewegungsdaten werden im Rahmen der Datenübernahme in das neue MES migriert, das betrifft insbesondere Auftrags-, Qualitäts- und Rückverfolgungsdaten, die für Nachweise oder Analysen weiter gebraucht werden. Nicht mehr benötigte Altdaten können archiviert werden, ohne sie in das Produktivsystem zu übernehmen. Die Datenqualität sollte bereits vor der Migration geprüft werden, nicht erst danach.
Muss die komplette Eigenentwicklung auf einmal abgelöst werden, oder geht das schrittweise?
Eine schrittweise Ablösung ist der übliche und risikoärmere Weg. Nach der Priorisierung nach Geschäftskritikalität steht fest, welche Funktionen am ersten Tag im neuen System stehen müssen und welche in einer späteren Phase folgen können. So bleibt der laufende Betrieb während der gesamten Migration abgesichert, statt an einem einzigen Umschalttermin zu hängen.
Welche Rolle spielen OPC UA und ISA-95 bei der Ablösung?
OPC UA, genormt in IEC 62541, ist der gängige Standard für den Datenaustausch zwischen Maschinen und IT-Systemen und ersetzt die individuellen Schnittstellen, die viele Eigenentwicklungen je Maschine einzeln pflegen mussten. ISA-95, international IEC 62264, beschreibt das Referenzmodell für die Integration von Fertigungsebene und Unternehmenssoftware wie ERP. Ein Standard-MES bringt beide Standards meist ab Werk mit, Details erklärt die Seite zu OPC UA im MES.
Was, wenn der ursprüngliche Entwickler das Unternehmen bereits verlassen hat und niemand den Code mehr versteht?
Dieses Szenario ist einer der häufigsten Auslöser für die Ablösung und lässt sich auch ohne den ursprünglichen Entwickler bewältigen. Die Bestandsaufnahme stützt sich dann auf die laufende Beobachtung der Anwendung im Betrieb, auf vorhandene Datenbankstrukturen und auf die Erfahrung der Anwender an den Terminals. Ein erfahrener MES-Anbieter oder Berater kann eine Software auch ohne Quellcode-Dokumentation anhand ihres beobachtbaren Verhaltens rekonstruieren.
Reicht es nicht, die Eigenentwicklung einfach besser zu dokumentieren und weiterzupflegen?
Bei kleinem, stabilem Funktionsumfang und mehreren Personen, die den Code aktiv verstehen, kann das eine vertretbare Zwischenlösung sein. Sobald aber Skalierung auf neue Werke, Standardschnittstellen oder Compliance-Anforderungen wie ein lückenloser Audit-Trail gefragt sind, stößt eine bessere Dokumentation an ihre Grenzen, weil sie die zugrunde liegende Architektur nicht verändert. Dokumentation verringert das Bus-Faktor-Risiko, beseitigt aber nicht die fehlende Skalierbarkeit.
Welche Abteilungen sollten in das Ablöseprojekt eingebunden werden?
Neben Produktionsleitung und IT gehören Qualitätsmanagement, Einkauf und der Betriebsrat von Beginn an ins Projekt, da eine MES-Einführung nach § 87 BetrVG mitbestimmungspflichtig ist. Schichtleitungen und Key User aus dem Pilotbereich sollten spätestens ab der Phase des Parallelbetriebs aktiv eingebunden werden. Details zur Mitbestimmung stehen auf der Seite zu Betriebsrat und MES-Einführung.
Wie gehen wir mit Individualfunktionen um, die kein Standard-MES sofort mitbringt?
Zunächst prüfen, ob die Funktion tatsächlich noch gebraucht wird oder nur historisch gewachsen ist. Für wirklich benötigte Sonderfälle bieten die meisten Standard-MES Konfigurationsmöglichkeiten oder ein Partnernetzwerk für individuelle Erweiterungen, ohne dass Sie erneut bei null anfangen. Diese Frage gehört explizit in das Anbietergespräch, idealerweise mit einem konkreten Beispiel aus Ihrer bisherigen Eigenentwicklung.
Welche Rolle spielt der Betriebsrat bei der Ablösung einer Eigenentwicklung?
Der Betriebsrat hat nach § 87 Abs. 1 Nr. 6 BetrVG ein Mitbestimmungsrecht bei technischen Einrichtungen, die zur Überwachung von Verhalten oder Leistung der Beschäftigten geeignet sind, wozu die meisten MES-Systeme zählen. Das gilt auch dann, wenn bereits eine Eigenentwicklung im Einsatz war, da mit dem neuen System in der Regel neue Auswertungsmöglichkeiten entstehen. Eine frühe Einbindung ab Projektstart vermeidet Verzögerungen in der Einführungsphase.
Wann ist es sinnvoller, die Eigenentwicklung zu behalten statt sie abzulösen?
Bei einem sehr kleinen, hochspezialisierten Prozess ohne Wachstumsperspektive, bei dem mehrere Personen den Code aktiv pflegen und die Dokumentation aktuell ist, bleibt die Eigenentwicklung oft die wirtschaftlichere Wahl. Auch wenn eine Ablösung ohnehin schon budgetiert und terminiert ist, lohnt sich in der Zwischenzeit keine weitere Investition mehr in die alte Lösung. Der Kipppunkt liegt dort, wo ein Ausfall der Software den Betrieb spürbar gefährden würde.
Wie wählen wir aus den vielen MES-Anbietern den passenden aus?
Ausgangspunkt ist ein Lastenheft, das die Funktionen und Sonderfälle Ihrer bisherigen Eigenentwicklung strukturiert erfasst, ergänzt um allgemeine MES-Anforderungen. Darauf aufbauend lässt sich der Anbietermarkt systematisch eingrenzen, etwa über das kostenlose Matching von Find-Your-MES oder eine begleitete Anforderungsanalyse. Allgemeine Kriterien und typische Fehler bei der Auswahl beschreibt die Seite MES auswählen.
Was passiert mit dem internen Entwickler oder der IT-Abteilung, die die Eigenentwicklung bisher gepflegt hat?
Die Person oder das Team, das die Eigenentwicklung bisher betreut hat, verliert durch die Ablösung keine Aufgabe, sondern bekommt eine andere: Statt Code zu pflegen, übernimmt sie im neuen MES typischerweise die Rolle des internen Key Users oder Administrators, der Konfigurationen, Berechtigungen und die Schnittstellen zum ERP betreut. Dieses Wissen über die bisherigen Sonderprozesse ist während der Bestandsaufnahme und der Anbieterauswahl besonders wertvoll, weil es die Anforderungen im Lastenheft konkretisiert. Ist der ursprüngliche Entwickler bereits ausgeschieden, übernimmt diese Rolle meist die IT-Abteilung gemeinsam mit dem Consultant des neuen Anbieters während der Einführungsphase.
Worin unterscheidet sich diese Seite von einem allgemeinen MES-Wechsel zwischen zwei Standardprodukten?
Diese Seite behandelt den spezifischen Fall, dass die bisherige Lösung keine gekaufte Standardsoftware war, sondern eine selbst oder extern programmierte Individuallösung ohne Herstellerstruktur. Ein klassischer MES-Wechsel zwischen zwei Standardprodukten unterscheidet sich davon, weil dort bereits Datenmodelle, Schnittstellenstandards und Ansprechpartner beim bisherigen Hersteller existieren, die bei einer Eigenentwicklung meist fehlen. Allgemeine Grundlagen zu Migration, Datenübernahme und Kosten eines MES-Wechsels zwischen zwei Standardsystemen beschreibt die Seite MES wechseln: Migration und Kosten, die auch für den Umstieg von einer Eigenentwicklung als ergänzende Referenz dient.
Die Eigenentwicklung soll weg.
Unsicher, welches Standard-MES Ihre Sonderfälle abdeckt?
Die Auswahl scheitert selten an der Erkenntnis, sondern daran, die Funktionen der Eigenentwicklung in Anforderungen an den Markt zu übersetzen. Sectorlens unterstützt dabei in drei Tiefen je nach Projektlage.
MES-Matching für Umsteiger von der Eigenentwicklung
URL eingeben, KI analysiert die Fertigung anhand öffentlicher Daten und gleicht sie gegen 64 Kriterien mit dem Anbietermarkt ab.
- Shortlist mit Match-Score statt langer Anbieterliste
- Berücksichtigt Branchen- und Fertigungsart-Fit
- Kein Formular, kein Verkaufsgespräch nötig
Lastenheft aus Ihrer Eigenentwicklung ableiten
Anforderungs-Workshop, in dem Funktionen und Datenmodell der bestehenden Eigenentwicklung strukturiert in ein Lastenheft aus 150+ Anforderungen übersetzt werden.
- Moderierter Anbieter-Dialog statt Kaltakquise
- Entscheidungsmatrix für die Geschäftsführung
- Sonderfälle werden explizit dokumentiert, nicht vergessen
Einschätzung, was aus Ihrer Eigenentwicklung übernommen werden kann
Erfahrung aus über 50 MES-Auswahlprojekten seit 2022, herstellerneutral, keine Provision von Anbietern.
- Ersteinschätzung zum Bus-Faktor-Risiko Ihrer Lösung
- Erste Einordnung des Migrationsaufwands
- 30 Minuten Erstgespräch kostenlos und unverbindlich
Die Eigenentwicklung hat ausgedient.
Bleibt die Frage, welches MES die Lücke schließt.
Sectorlens gleicht Ihre Fertigungsumgebung mit der KI-gestützten Matching-Engine gegen den MES-Anbietermarkt im DACH-Raum ab und liefert eine begründete Shortlist. Herstellerneutral, ohne Provision von Anbietern, ohne Formular.
