Individuelle Softwareentwicklung: 7 Anzeichen dafür, dass Ihr aktuelles System die Produktion ausbremst

Individuelle Softwareentwicklung sollten Sie in Betracht ziehen, wenn Ihre bestehenden Tools einen wichtigen Teil des Prozesses nicht mehr ausreichend unterstützen und Ihr Team die Lücken mit Tabellen, manueller Dateneingabe oder zusätzlichen Abläufen kompensiert. Das bedeutet nicht automatisch, dass ein komplett neues System gebaut werden muss. Nach diesem Leitfaden können Sie besser einschätzen, ob Ihr Problem eine Integration, eine Erweiterung der bestehenden Umgebung, individuelle Anwendungsentwicklung oder ein vollständig auf Ihren Prozess zugeschnittenes System erfordert.

Wenn Sie für Produktion, operative Prozesse oder die Digitalisierung eines Werks verantwortlich sind, fällt die wichtigste Entscheidung noch vor der Auswahl einer Technologie. Stellen Sie zunächst fest, an welcher Stelle der Prozess nicht mehr so funktioniert, wie er sollte. Dann lässt sich individuelle Softwareentwicklung als Antwort auf einen konkreten Zeitverlust, ein Fehlerrisiko oder fehlende Informationen für Entscheidungen betrachten.

In einem Produktionsbetrieb kann individuelle Software eine kleine Bedieneranwendung, ein ERP-Erweiterungsmodul, eine Integration zwischen MES und einem übergeordneten System oder ein separates System für einen Prozess sein, den Standardlösungen nicht ausreichend abbilden können.

Individuelle Softwareentwicklung umfasst deutlich mehr als den Aufbau eines vollständigen Systems. Im Bereich der Programmierung für die Produktion gehören dazu sowohl die Entwicklung neuer Anwendungen als auch die Weiterentwicklung bestehender Plattformen, zusätzliche Module und Integrationen zwischen ERP, MES, SCADA, Maschinen und Datenbanken. Wenn die Ursache des Problems im Informationsfluss zwischen bereits funktionierenden Systemen liegt, kann eine weitere Anwendung lediglich die Zahl der zu wartenden Komponenten erhöhen.

Ein guter Orientierungspunkt bei der Strukturierung der Systemarchitektur ist ISA-95. Der Standard beschreibt Modelle und den Informationsaustausch zwischen Geschäfts- und Produktionsfunktionen, einschließlich der Schnittstelle zwischen den Ebenen 3 und 4. Weitere Informationen finden Sie in der offiziellen Beschreibung des ISA-95-Standards. Für ein Projekt bedeutet das vor allem eines: Bevor Sie sich für eine Technologie entscheiden, sollten Sie festlegen, wo Daten entstehen, welches System ihre führende Quelle ist und wohin sie übertragen werden müssen.

Eine Tabellenkalkulation ist an sich noch kein Problem. Zum Warnsignal wird sie dann, wenn sie die Logik eines wichtigen Prozesses übernimmt. Ein Schichtleiter führt darin den aktuellen Auftragsstatus, die Qualitätsabteilung dokumentiert Ergebnisse außerhalb des Systems und die Produktionsplanung kombiniert mehrere Exporte, um sich einen Überblick über den Produktionsstand zu verschaffen.

Individuelle Softwareentwicklung sollte analysiert werden, wenn eine solche Datei faktisch zu einer inoffiziellen Geschäftsanwendung geworden ist: Sie wird für Entscheidungen benötigt, enthält eigene Regeln und lässt sich ohne das Wissen einzelner Mitarbeiter kaum ersetzen. Erfassen Sie zunächst, welche Daten in die Tabelle eingehen, wer sie einträgt, was daraus berechnet wird und wo das Ergebnis anschließend genutzt wird. Diese Prozesskarte zeigt, ob eine Anwendung, eine Integration oder lediglich eine Änderung der Konfiguration des bestehenden Systems erforderlich ist.

Ein Produktionsauftrag entsteht im ERP-System, anschließend wird seine Nummer in eine Tabelle übertragen, der Bediener gibt sie am Arbeitsplatz erneut ein und nach Abschluss überträgt jemand das Produktionsergebnis zurück in das übergeordnete System. Jede manuelle Übergabe schafft einen weiteren Punkt, an dem Informationen unterschiedlich eingegeben werden, verspätet ankommen oder überhaupt nicht zurückfließen können.

Hier sollte individuelle Softwareentwicklung häufig mit einer Integration und nicht mit einer neuen Anwendung beginnen. Wenn beide Systeme bereits über die erforderlichen Daten verfügen und deren Bedeutung eindeutig festgelegt werden kann, können individuelle Softwarelösungen einfach den Datenfluss automatisieren. Bei der Datensynchronisation mit ERP können beispielsweise Informationen über Aufträge und Arbeitsgänge an die Produktion übertragen werden. An das ERP können wiederum produzierte Mengen, Statusinformationen, Materialverbrauch, Ausschuss, Stillstände oder Ergebnisse von Qualitätsprüfungen zurückgemeldet werden.

Das ERP kann Planung und Abrechnung korrekt abwickeln, SCADA Signale von Maschinen erfassen und MES die Produktionsausführung dokumentieren. Schwierigkeiten entstehen, wenn jedes System einen Teil derselben Produktion beschreibt, zwischen diesen Teilen jedoch kein abgestimmter Datenaustausch stattfindet. Der Status aus der Fertigung erreicht die Produktionsplanung nicht, eine Chargen-ID hat in zwei Systemen unterschiedliche Formate oder ein Bericht muss manuell aus mehreren Quellen zusammengesetzt werden.

In dieser Situation sollte individuelle Softwareentwicklung mit der Klärung der Datenverantwortung beginnen. Für Auftrag, Produkt, Charge, Arbeitsgang, Qualitätsergebnis oder Stillstandszeit müssen jeweils das führende Quellsystem und die Regeln für den Datenaustausch bestimmt werden. Eine sinnvoll definierte individuelle Softwareentwicklungbeginnt deshalb bei Verantwortlichkeiten und Datenflüssen und nicht bei einzelnen Bildschirmen oder Funktionen.

Eine API allein löst das Problem der Datenbedeutung nicht. Mehr dazu erfahren Sie in unserem Beitrag über APIs in der Industrie und die Verbindung von ERP, MES und SCADA. Ein technisch korrekt übertragener Wert kann weiterhin falsch interpretiert werden, wenn Systeme einen Status, eine Maßeinheit oder ein Ereignis unterschiedlich verstehen.

Nicht immer fehlen Daten. Manchmal sind sie vorhanden, müssen jedoch aus mehreren Quellen zusammengetragen, geprüft und manuell berechnet werden. Ein Produktionsleiter erhält die Zusammenfassung erst nach Ende der Schicht, obwohl die Information über eine Abweichung bereits während der laufenden Schicht benötigt wurde. Die Produktionsplanung sieht den tatsächlichen Fortschritt erst, nachdem eine Datei aktualisiert wurde.

Individuelle Softwareentwicklung ist hier sinnvoll, wenn sie einen konkreten Weg vom Ereignis bis zur Reaktion verkürzt. Der Umfang kann eine automatische Datenerfassung, Validierung, Alarmregeln und einen Bildschirm umfassen, der einer bestimmten Rolle ausschließlich die für ihre Entscheidung relevanten Informationen zeigt.

Bewerten Sie individuelle Softwarelösungen danach, ob sie Informationsverzögerungen reduzieren, und nicht danach, wie viele Funktionen in der Spezifikation aufgeführt sind. Bei individueller Softwareentwicklung zählt vor allem, ob eine relevante Information schneller zu der Person gelangt, die auf ihrer Grundlage handeln muss.

Viele Prozesse lassen sich standardisieren. Wenn eine bestimmte Arbeitsweise jedoch aus der Produktionstechnologie, Kundenanforderungen, der Rückverfolgbarkeit, Qualitätskontrolle oder einer bestimmten Planungslogik resultiert, kann die Anpassung des Prozesses an die Grenzen einer Software ein neues Problem erzeugen.

Individuelle Softwareentwicklung ist eine Analyse wert, wenn sich eine für den korrekten Ablauf notwendige Regel mit der Standardkonfiguration nicht abbilden lässt. Dabei muss zwischen einer tatsächlichen Anforderung und einer organisatorischen Gewohnheit unterschieden werden. Die Aussage „Das haben wir schon immer anders gemacht“ reicht nicht aus. Eine gute Bewertung sollte stattdessen die Konsequenzen benennen: Was passiert mit Qualität, Liefertermin, Produktrückverfolgbarkeit, Abrechnung oder der Arbeit eines Bedieners, wenn diese Regel weggelassen wird?

An dieser Stelle kann individuelle Unternehmenssoftware die für den Prozess tatsächlich notwendige Logik schützen, während standardisierbare Elemente weiterhin von Standardlösungen übernommen werden. Gute individuelle Softwareentwicklung bildet das ab, was wirklich unternehmensspezifisch ist, ohne Funktionen neu zu entwickeln, die vorhandene Systeme bereits zuverlässig übernehmen.

Eine neue Produktvariante, eine Änderung des Arbeitsplans, eine zusätzliche Qualitätskontrolle oder die Inbetriebnahme eines weiteren Arbeitsplatzes erfordert Anpassungen in mehreren Systemen und Dateien. Einen Teil übernimmt die IT, einen weiteren die Automatisierungstechnik und andere Änderungen verteilen sich auf lokale Tabellen. Selbst eine kleine fachliche Änderung beginnt dadurch wie ein eigenes Projekt zu wirken.

Bevor individuelle Softwareentwicklung gestartet wird, sollte die Ursache dieser Starrheit untersucht werden. Sie kann in der Architektur eines Altsystems, der mehrfachen Speicherung derselben Daten oder einer unklaren Verantwortung für die Konfiguration liegen.

Individuelle Softwareentwicklung sollte genau die auf diese Weise identifizierte Einschränkung beseitigen. Wenn ein Unternehmen bestimmen kann, welcher Teil des Prozesses regelmäßig verändert wird und wer ihn verwalten können sollte, lässt sich beispielsweise ein Modul entwickeln, das die variable Geschäftslogik vom restlichen Systemumfeld trennt.

Ein Prozess, der auf einer einzelnen Tabelle basiert, kann auf einer Produktionslinie funktionieren. Bei weiteren Fertigungszellen entstehen Kopien der Datei, lokale Versionen von Arbeitsanweisungen und unterschiedliche Methoden zur Erfassung derselben Information. Ein ähnlicher Effekt tritt auf, wenn ein weiteres Werk eröffnet oder die Produktion um neue Produktgruppen erweitert wird.

Berechnen Sie hier nicht nur die Kosten des aktuellen Workarounds, sondern auch die Kosten seiner Vervielfältigung. Individuelle Softwareentwicklung kann den Prozess vereinheitlichen und ermöglichen, ihn nach denselben Grundsätzen in weiteren Bereichen einzuführen.

Individuelle Softwarelösungen lassen sich sinnvoll skalieren, wenn bekannt ist, welche Prozesselemente überall gleich sind und an welchen Stellen eine eigene Konfiguration erforderlich ist. Bevor individuelle Softwareentwicklung skaliert wird, sollten deshalb gemeinsame Prozessregeln klar von werk-, linien- oder produktspezifischen Einstellungen getrennt werden.

Der teuerste konzeptionelle Fehler entsteht, wenn ein Unternehmen das falsche Problem löst. Individuelle Softwareentwicklung repariert keinen Prozess mit unklar verteilten Verantwortlichkeiten. Eine Integration hilft nicht, wenn zwei Systeme widersprüchliche Daten speichern. Ein vollständiges maßgeschneidertes System ist überdimensioniert, wenn lediglich eine klar definierte Funktion fehlt.

Der Umfang der individuellen Softwareentwicklung sollte deshalb immer zur tatsächlichen Ursache und Größe der Einschränkung passen.

Wenn Ihre Entscheidung zwischen einer Standardlösung und einer eigenen Lösung liegt, finden Sie weitere Informationen auf unserer Seite über maßgeschneiderte Software für die Industrie. Dieser Leitfaden setzt jedoch einen Schritt früher an: Er hilft Ihnen zu beurteilen, ob individuelle Softwareentwicklung überhaupt die richtige Richtung ist.

Zu Beginn benötigen Sie kein Dokument mit hundert Anforderungen. Viel hilfreicher ist ein gut beschriebener Ablauf eines tatsächlichen Auftrags oder eines konkreten Arbeitsgangs. Markieren Sie, wo eine Information entsteht, wer sie eingibt, wer sie später nutzt, wo sie erneut übertragen werden muss und an welcher Stelle auf eine Bestätigung gewartet wird.

Ergänzen Sie eine Liste der Systeme und Geräte, die am Prozess beteiligt sind, sowie der verfügbaren Kommunikationsmöglichkeiten. Bei einer Integration reicht es nicht aus, dass eine API existiert. Datenmodell, Übertragungsrichtung, Identifikatoren, Fehlerbehandlung und das Verhalten der Systeme bei einer vorübergehenden Nichtverfügbarkeit müssen gemeinsam definiert werden.

ISA-95 strukturiert den Informationsaustausch zwischen Unternehmensfunktionen und der Produktionssteuerung.

Für individuelle Softwareentwicklung sind messbare Erfolgskriterien besonders wichtig. Statt „Reporting verbessern“ festzuhalten, definieren Sie beispielsweise, wer einen Bericht künftig nicht mehr manuell erstellen soll, welche Information früher verfügbar sein muss, welche Daten automatisch an das ERP zurückgemeldet werden sollen oder welcher Fehler bereits vor der Bestätigung eines Arbeitsgangs erkannt werden muss.

An einem solchen Gespräch sollten der fachlich verantwortliche Prozesseigner, eine Person mit Kenntnissen der IT-/OT-Umgebung sowie die Anwender beteiligt sein, die die betreffende Arbeit tatsächlich ausführen. Bei Qualitäts-, Lager- oder Instandhaltungsprozessen sollte zusätzlich ein Vertreter des jeweiligen Bereichs teilnehmen. So lassen sich geschäftliche Anforderungen mit technischen Einschränkungen und den Details der täglichen Arbeit verbinden.

Wenn die Diagnose jedes Problems automatisch zum Vorschlag führt, ein neues System zu entwickeln, sollten Sie zum Anfang der Analyse zurückkehren. Auf unserer Seite zur Programmierung für die Produktion sehen Sie, dass zunächst die vorhandenen Systeme geprüft werden sollten. Die Lösung kann ein separates Modul, die Weiterentwicklung der bestehenden Umgebung oder eine neue Anwendung sein.

Individuelle Softwareentwicklung ist sinnvoll, wenn ihr Umfang aus einer konkreten Prozesseinschränkung folgt und sich das Ergebnis anschließend überprüfen lässt. Wenn Sie vor einer Entscheidung zunächst Prozesse, Datenquellen, Verluste und Abhängigkeiten zwischen Systemen strukturieren möchten, kann der 360°-Workshop von explitia der passende erste Schritt sein. Er beginnt mit der Analyse der tatsächlichen Arbeit im Produktionsbetrieb, bevor ein System oder Modul ausgewählt wird.

Die sicherste Regel lautet: Benennen Sie zuerst das Problem und bestimmen Sie die Daten, die es bestätigen. Wählen Sie erst danach die Technologie. Individuelle Softwareentwicklung sollte das Ergebnis dieser Diagnose sein und nicht deren Ersatz.

Nein. Individuelle Softwareentwicklung kann eine neue Anwendung, ein zusätzliches Modul, eine Erweiterung eines bestehenden Systems oder eine Integration zwischen bereits genutzten Tools umfassen. Diesen Umfang beschreiben wir ebenfalls im Bereich Programmierung für die Produktion.

Nein. In der ersten Phase ist eine Beschreibung des Prozesses, der Benutzer, Datenquellen, Ausnahmen und des erwarteten Ergebnisses deutlich hilfreicher. Auf dieser Grundlage können die Anforderungen ermittelt werden. Erst danach muss die Architektur der Lösung definiert werden.

Wenn die benötigten Daten bereits in funktionierenden Systemen vorhanden sind und das Hauptproblem in der manuellen Übertragung oder dem verzögerten Datenaustausch liegt. Dann sollte zunächst geprüft werden, ob sich die Systeme miteinander verbinden und die Bedeutung der ausgetauschten Daten eindeutig festlegen lässt, bevor eine weitere Anwendung entwickelt wird.

Die Person, die fachlich für den Prozess verantwortlich ist, der verändert werden soll. Bei individueller Softwareentwicklung sollten IT beziehungsweise IT/OT wegen Architektur, Integrationen, Sicherheit und Wartung beteiligt sein. Der Erfolg des Projekts sollte jedoch am verbesserten Prozess und nicht allein an der technischen Implementierung gemessen werden.