- IT&Production - https://www.it-production.com -

Drum teste, wer sich ewig bindet

Ein Vorprojekt für Planungssoftware

Drum teste, wer sich ewig bindet

Erweist sich eine Industrieanwendung erst nach ihrer Einführung als unpassend, ist der Schaden immens. Doch bei nur wenigen Systemen ist das so schwierig im Vorfeld zu bestimmen, wie bei einem Expertensystem zur Produktionsfeinplanung. Ein Proof of Concept vor der Integration ist zwar aufwendig, senkt aber das Risiko einer Fehlinvestition.

(Bild: ©maslakhatul/stock.adobe.com) [1]

(Bild: ©maslakhatul/stock.adobe.com)

Ein Advanced Planning and Scheduling (APS)-System ist oft integraler Bestandteil von MES-und ERP-Lösungen. Die Programme dienen der Planung von Produktions- und Logistikprozessen. Sie ermöglichen unter Beachtung der Produktionsrestriktionen, Auf­träge und die dafür benötigten Ressour­cen auf­einander abzu­stimmen.

Vorsicht bei der Auswahl

Da es bei den APS-Lösungen im Markt große Unterschiede hinsichtlich Funktions­umfang und Modellierungsmöglichkeiten von Restriktionen gibt, sollte die Auswahl gut überlegt sein. Ein Vorprojekt, auch Proof of Concept (PoC) genannt, ist spätestens dann dringend angeraten, wenn die APS-Software über verschie­dene Schnittstellen mit bereits bestehenden Systemen interagieren soll. Auf Basis einer definierten Zielvorstellung und eines überschau­baren Budgets können so in kurzer Zeit sowohl die technische Machbar­keit, die Integration in die Systemlandschaft sowie der vielversprechendste Umsetzungspfad ermittelt und mit den späteren Anwendern besprochen werden.

Umsetzbarkeit prüfen

Das Ziel eines Proof of Concept-Projektes ist es, typische Use Cases auf deren Umsetzbarkeit zu unter­suchen. Im Falle der Einführung eines Planungstools sollte im Rahmen solchen PoCs zunächst die aktuelle Datenlage und -qualität gegen die definierten Planungsziele geprüft werden. Dabei werden alle benötigten Parameter zur Abbildung der Planungsrestriktionen sowie bereits bestehende Systeme oder Schnittstellen berücksichtigt und einkalkuliert. Auf Basis dieser Parameter wird ein Testmodell entwickelt, das bereits einige der später benötigten Kernfunktionen aufweist. Innerhalb weniger Wochen werden so ein tieferer Einblick sowie der Test des Produktions­planungssystems möglich. Dadurch lassen sich Ziele konkreter abschätzen und die Verant­wortlichen gewinnen Klarheit über den Aufwand zur Einführung eines Feinplanungstools, beispielsweise zur Aufbereitung oder Korrektur notwendiger Stammdaten. Ein wichtiges Ergebnis eines PoC ist der Überblick über den aktuellen Status der im Unternehmen vorhandenen Datenqualität. Außerdem werden alle für das Projekt vorgesehenen Personen bereits in der frühen Projektphase einbezogen.

Die verschiedenen Phasen

Ein PoC-Projekt besteht typischerweise aus mehreren Phasen. Zunächst sollte es einen Kickoff-Workshop geben, der die Ziele und relevante Informationen für das Projektteam definiert. Dazu lernt der jeweilige Anbieter das Anwenderunternehmen besser kennen und verschafft sich einen Überblick über die verschiedenen Fertigungs- und Geschäftsprozesse sowie typischen Anwendungsfälle und Herausforderungen in der Planung. Während des Workshops lassen sich weitere Fragen klären: Welche Systeme werden genutzt? Wie ist der heutige Pro­zess der Produktions­planung und Ergebniskommunikation in Richtung Produktion? Welche Schnittstellen sind vorhanden? Wie viele Personen sind für die Produktions­planung verantwortlich? Wie viele Maschinen werden aktuell und sollen künftig beplant werden? Danach beginnt die Modellierung der Use Cases und die Abstimmung möglicher Lösungs­ansätze. Um die Use Cases zu untersuchen, lässt sich im APS-System ein Modell erstellen, das auf den Daten des späteren Anwenderunternehmens basiert. Diese können über verschiedene Wege importieren werden: Excel-Import-Dokument, Schnittstelle, ein Datenbank-Dump oder durch manu­elle Eingabe. Anhand des Modells wird anschließend die Umsetzbarkeit der Use Cases geprüft. Oft ist jedoch der Datenstand im aktuell genutzten System nicht aktuell. Das kommt beispielsweise vor, wenn es noch alte Auftragsdaten im Bestand gibt oder veraltete Test-Daten im System schlummern. Die Prüfung der Datenqualität ist erforderlich, um einzuschätzen, welcher Aufwand für die Datenpflege künftig auf das Projektteam zukommt. In einem weiteren Workshop werden dann die Erkenntnisse präsentiert. Nicht selten gibt es für einen Anwendungsfall gleich mehrere Lösungsansätze, sodass das der Anwender die für ihn passende Lösung auswählen kann. Erhält der Softwareanbieter dann den Zuschlag, beginnt die eigentliche Projektarbeit.

Anbindung an ein ERP-System

Ein PoC kann sowohl bei der Einführung einer Software als auch für verschiedene Use Cases im Betrieb geführt werden. Typische Anwendungsfälle eines PoC für ein APS sind beispielsweise die Planung von Auftragsnetzen, die Darstellung von Reportfunktionen oder die Umplanung wegen Störungen. Auch für die Anbindung an ein ERP-System empfiehlt sich ein Proof of Concept. Neue APS-Systeme sind in der Lage, mit verschiedenen ERP-Lösungen über Standard-Konnectoren zusammenzuspielen. Ein solcher Use Case kann wie folgt aus­sehen: Nach dem Workshop zur Ermittlung des Status-quo und aller wichtigen Para­meter setzt der IT-Anbieter ein ERP-Testsystem auf, in das Daten mittels Schnittstelle eingespielt werden. Das APS verplant die geforderten Aufträge anschließend gegen begrenzte Ressourcen, prüft dazu alle Restriktionen und ermittelt, wann ein Auftrag auf welchen Ressourcen eingeplant werden kann. Die Planungsergebnisse werden in diesem Status aber noch nicht an das ERP-System zurückgegeben. Trotzdem liefert auch diese rudimentäre Anbindung bereits Erkenntnisse darüber, wie die beiden Systeme im Live-Betrieb miteinander funktionieren.

Mehr Sicherheit

Mit dem Proof of Concept ist ein wichtiger Meilenstein eines IT-Projektes erreicht. Die Beteiligten verfügen nun über das Wissen, um Chancen, Risiken und Einführungsaufwand realistisch abzuschätzen. Firmen können informiert entscheiden, welches System zu ihnen passt und ob ihre Anfor­derungen sowohl erkannt wurden als auch umsetzbar sind. Was sich selbstverständlich anhören mag, hat in der Praxis schon für viele gescheiterte IT-Initiativen gesorgt.