Was hilft bei immer kürzeren (Investitions-) Planungszyklen?

Neben kürzeren Technologie- und Produktlebenszyklen führen marktbedingte Trends – sei es durch die Coronapandemie oder wirtschaftspolitische Verwerfungen innerhalb der globalen Supply Chain – aktuell dazu, dass die (Investitions-) Planungszyklen für die Produktion in immer kürzeren Intervallen durchgeführt werden müssen.

Lösung: Evidenzbasierte Erzeugung von Referenzproduktionsprogrammen

Die bis dato gelebte Praxis – der unternehmerischen Vorsicht Rechnung tragend – eine Anpassung von Ressourcen erst bei einem sich tatsächlich ändernden Produktionsprogramm durchzuführen, führt nicht nur direkt zu Engpässen und damit entgangenem Ergebnis, sondern kann gerade bei den aktuellen Lieferzeiten für Maschinen und Anlagen einfach zu spät erfolgen; wertvolle Amortisationszeiten bleiben ungenutzt.

Entsprechend gilt es, die Simulation von Szenarien in der Produktion – hinsichtlich sich verändernder Absatzzahlen einerseits aber auch hinsichtlich sich verändernder Wertschöpfungsumfänge (Leistungsbreite und -tiefe) andererseits unter Nutzung neuer, datengetriebener Ansätze effektiver (Agieren statt Reagieren) und effizienter (Ressourcen schonend und schnell) umzusetzen.

Da die Komplexität des realen Produktionsprogramms (Produktspektrum, Mengengerüst, variierende Fertigungstiefen) i.d.R. zu hoch ist, gilt es, dieses in Form eines aggregierten, vereinfachten Referenzproduktionsprogramms nachzubilden, um die Wechselwirkungen zwischen Wertschöpfungsumfängen und Kapazitäten analysieren und verstehen zu können.

Das Referenzproduktionsprogramm als Planungsgrundlage

Die aktuellen Herangehensweisen sind heuristischer Natur: Es wird das implizite Wissen der Verantwortlichen aus Produktion und Arbeitsvorbereitung bzgl. Mengen und Ähnlichkeiten von Produkten genutzt. Dabei sind jedoch die kognitiven Fähigkeiten des Menschen stark limitiert: (Produkt-) Differenzierungsmerkmale werden häufig überbewertet und als Entscheidungskriterium herangezogen. Bezogen auf die Fertigungsprozesse kommt es hierdurch dazu, dass vermeintlich verschiedene Produkte eine hohe Übereinstimmung von Prozessen und Prozessfolgen aufweisen, während andere, als ähnlich erachtete Produkte am Ende doch gänzlich unterschiedliche Maschinen erfordern.

Dies ist verständlich, denn es ist für einen Menschen unmöglich, schon bei Produkten mit relativ einfachen Stücklistenstrukturen alle damit verbundenen Arbeitspläne der für das Endprodukt erforderlichen Fertigungsteile zu vergleichen. Schon bei vier zu vergleichenden Produkten mit jeweils acht Baugruppen, die wiederum aus nur vier Fertigungsteilen bestehen, sind 164 Arbeitsgangfolgen mit i.d.R. unterschiedlichen Bearbeitungszeiten in Betracht zu ziehen.

Die Möglichkeiten einer ex ante Nutzung des ERP-Systems (in dem Mengengerüste und Arbeitspläne hinterlegt sind) ist dabei nicht möglich. Die Systeme erkennen keine Muster und Ähnlichkeiten von Prozessfolgen – insbesondere nicht aggregiert auf der obersten Stücklistenebene (also das Produkt).

Ein Lösungsansatz liegt in der Nutzung der Fortschritte auf den Gebieten Digitalisierung und Künstliche Intelligenz, um den heuristischen Ansatz durch einen evidenzbasierten Ansatz zu ersetzen. Hierbei werden die erforderlichen Daten (Stücklistenstruktur, Arbeitspläne, Mengen) exportiert bzw. ausgelesen und dann in einem ersten Schritt für jedes einzelne Produkt (oberste Stücklistenebene) die summierte/ aggregierte Maschinenbelastungen aus den unteren Stücklistenebenen (Fertigungsteile) dargestellt. Hieran anknüpfend können ähnlich Produkte (ggf. in zuvor festgelegten vertriebsorientierten Gruppen) mithilfe von Machine-Learning-Algorithmen der Muster- bzw. Ähnlichkeitserkennung und des Clusterings (i.S. des Nearest Neighbour Algorithmus) identifiziert werden und zu Referenzproduktgruppen zusammengefasst werden. Nach Vorgabe von Anzahl und/ oder Ähnlichkeitsausprägung kann entsprechend das Referenzproduktionsprogramm aufgebaut und im weiteren Verlauf für Analysen genutzt werden.

Umgesetzt werden konnte dieser Ansatz mit der Firma HUPFER Metallwerke GmbH & Co. KG. Als Hersteller von Produkten und Systemen im Bereich der Küchen- und Krankenhauslogistik mit einer hohen Wertschöpfungstiefe ist die Fertigung nicht nur mit einer hohen Variantenvielfalt konfrontiert, sondern muss gleichzeitig bei immer kürzer werdenden Innovationszyklen schnell auf Änderungen des Produktspektrums reagieren. In den folgenden Kapiteln wird der entwickelte Lösungsansatz detailliert beschrieben sowie seine Anwendung exemplarisch dargestellt.

Datenextraktion und -speicherung zur lokalen Prozessierung

Da die zumeist genutzten ERP (Enterprise-Resource-Planning )-Systeme für die individuelle Prozessierung der Daten i.d.R. (noch) keine integrierte Plattform zur Verfügung stellen, sind zuvorderst geeignete Formate zum Datenexport aus dem ERP-System zu validieren, um die für die Referenzproduktionsprogrammerstellung erforderlichen Informationen zu speichern (Auswahl Datenstruktur) und weiterzuverarbeiten (z.B. Anwendung von Programm-Skripten). Der Vorteil einer externen Weiterverarbeitung der Daten liegt darüber hinaus in der Minimierung technischer Limits, der Vermeidung von Anbieter- bzw. Versionsabhängigkeit sowie der Integrierbarkeit anderer Datenquellen, ohne die Integrität des ERP-Systems zu gefährden.

Bei den ERP-Daten handelt es sich um die Stücklistenstruktur, Mengengerüste, Arbeitspläne (inkl. Bearbeitungs- und Rüstzeiten), Maschinen, Maschinengruppen, Material, Produktlisten – kaufmännisch gruppiert z.B. nach Warenerlösgruppe, technisch gruppiert z.B. nach Artikelgruppen.

Zur initialen Analyse reicht als Schnittstelle zum ERP-System bereits ein einfacher Datenexport in Textform, welcher durch die meisten ERP-Systeme standardmäßig angeboten wird. Bei sehr großen Datensätzen lohnt sich ggf. auch ein relationaler Datenbank-Server für Speicher- und Laufzeitoptimierung. Abhängig vom ERP-System werden die Daten i.d.R. in zweidimensionalen Tabellen mit Spalten und Zeilen ausgegeben und können später logisch verknüpft werden.

Ermittlung der Belastungssituation für jedes Einzelprodukt

Die Berechnung der Gesamtbelastung der Anlagen ist bereits bei wenigen Stücklistenebenen kaum noch manuell durchführbar, da jedes Produkt aus mehreren Fertigungsteilen bestehen kann, welche ihrerseits erneut aus mehreren Fertigungsteilen bestehen können.

Zur Aggregierung der Fertigungszeiten je Anlage empfiehlt sich daher die Verwendung passender Programmiersprachen. Als anfängerfreundliche Programmiersprache mit kurzen Entwicklungszeiten bietet sich für diese Aufgabe zum Beispiel Python an. Bei größeren Produktsortimenten kann die exponentiell ansteigende Rechenlaufzeit jedoch problematisch werden, weshalb sich alternativ auch schnellere Sprachen wie C++ oder Julia anbieten.

Folgende Arbeitsschritte sind für jedes Endprodukt durchzuführen:

• (1) Positionen eines Arbeitsplans zur Fertigung des Produktes iterativ analysieren und die belegten Anlagen mit Fertigungszeiten dokumentieren;
• (2) Produkte auf Kaufteile und Fertigungsteile prüfen; für jedes Fertigungsteil Schritt (1) und (2) wiederholen, bis die unterste Stücklistenebene erreicht wird;
• (3) Auslastungszeiten für jede belegte Anlage summieren.

Anschließend werden die summierten Auslastungen je Anlage und Endprodukt für die nächsten Schritte zwischengespeichert. Das Datenformat kann z.B. eine einfache Textdatei in Matrixschreibweise sein. Sind die Daten aber für eine weiterführende Analyse interessant oder sollen langfristig archiviert werden, lohnt sich der zusätzliche Aufwand zum Einrichten einer Datenbank. Gängige relationale Datenbanken sind z.B. MySQL, Microsoft SQL-Server, Oracle oder PostgreSQL. Ferner ist bei der Auswahl darauf zu achten, dass diese mit einer eventuell geplanten Visualisierungs-Software kompatibel ist.

Visualisierung der Belastungssituation je Produkt in der Fertigung

Bereits die kompakte Darstellung der Anlagenauslastungen (explorative Visualisierung) kann zu Erkenntnisgewinnen führen, Bild 1. Oftmals belegen Produkte mit komplexen Stücklisten unerwartet Anlagen, belasten diese stärker als gedacht oder aber lassen erwartete Anlagen außen vor. Eine passende Visualisierung ist hier der Schlüssel zu einem qualitativ hochwertigen Erkenntnisgewinn. Aktuell gibt es eine ganze Reihe namhafter Anbieter am Markt, wie z.B. Microsoft Power BI, Tableau oder Qlik Sense.

Aufteilung des realen Produktprogramms auf Referenzprodukte

Basis für die Bildung eines (teil-) automatisch erstellten Referenzproduktionsprogramms ist die Bildung geeigneter Produktgruppen, für die die Ähnlichkeitsalgorithmen angewandt werden können. Hierzu eigenen sich bereits vorhandene Gruppierungen im ERP-System, wie Vertriebs- oder Warenerlösgruppen. Eine Anwendung von Cluster-Algorithmen auf das gesamte Produktportfolio ist auch denkbar, führt jedoch zu einer gröberen und ungenaueren Zuordnung von ähnlichen Produkten.

Durch den späteren Anwender ist im ersten Schritt eine Mindest- bzw. Maximalanzahl an Referenzprodukten festzulegen. Die Anzahl der Produkte muss hoch genug sein, um das Gesamtportfolio akkurat abzubilden, aber niedrig genug, um einen verringerten Planungsaufwand zu gewährleisten.

Die Clusterung folgt schließlich in zwei Schritten: Zunächst sind innerhalb einer Produktgruppe die Cluster zu bilden, die durch Referenzprodukte repräsentiert werden sollen. Ähnlichkeitsvorgabe hierbei sind die im vorherigen Kapitel beschriebenen Prozessfolgen und Auslastungsverteilungen. Für jedes identifizierte Cluster werden reale (oder künstlich angelegte) Produkte bestimmt, die schließlich die Repräsentanten des Clusters und damit die Referenzprodukte bilden. Diese werden nach zu definierenden Vorgaben wie z.B. einer mittleren Stückzahl, mittleren Beanspruchungen der Maschinen oder der Beanspruchung möglichst repräsentativer Maschinentypen ausgewählt. In einem zweiten Schritt folgt schließlich die finale Zuordnung der Produkte einer Produktgruppe auf die Referenzprodukte (auf der Basis der bereits in Schritt 1 angewandten Ähnlichkeitsvorgaben), Bild 2.

Die Ähnlichkeitszuordnung auf Cluster je Produktgruppe in Schritt 1 kann auf drei verschiedene Arten ablaufen:

• (1) Die Anzahl der Cluster wird ausschließlich durch einen Cluster-Algorithmus festgelegt.
• (2) Die Anzahl der Cluster wird durch einen Cluster-Algorithmus vorgeschlagen und durch den Menschen nachkorrigiert.
• (3) Die Anzahl der Cluster wird durch den Menschen vorgeschlagen und durch den Cluster-Algorithmus nachkorrigiert.

Im Falle (1) und (2) wird ein Algorithmus benötigt, welcher selbst die Anzahl der Cluster ermittelt. Dies gewährleistet zum Beispiel der „DBSCAN“-Algorithmus (Density-Based Spatial Clustering of Applications with Noise), welcher über eine dichtebasierte räumliche Clusteranalyse Cluster festlegt und Ausreißer erkennt.

Für den Fall (3) wird durch den Menschen eine Anzahl Cluster vorgeschlagen bzw. vorgegeben. Diese heuristische Herangehensweise kann sich durch das Prozesswissen der Beteiligten ergeben oder durch klar erkennbare Unterschiede in der Fertigung innerhalb einer Referenzproduktgruppe. In diesem Fall bietet sich zum Beispiel der „k-means“-Algorithmus an, welcher eine vorgegebene Anzahl an Clustern als Parameter übergeben bekommt. Da dieser Algorithmus alle Elemente ungeachtet der Ausreißer in k-Cluster aufteilen wird, ist es wichtig, die Anzahl der Cluster korrekt zu bestimmen – ansonsten leidet die Qualität der Zuordnung.

Optional kann auch hier der DBSCAN-Algorithmus eingesetzt werden, indem die Eingabeparameter so angepasst werden, dass ungefähr die gewünschte Anzahl Cluster entsteht. Dies hat den Vorteil, dass beim heuristischen Variieren der Eingabeparameter durch die Qualität der Zuordnung und die Anzahl klassifizierter Ausreißer ein indirektes Feedback gegeben wird, ob die Anzahl der Cluster (aus Sicht des Algorithmus) optimal ist.

Nach der Ernennung eines Repräsentanten je Cluster erfolgt in Schritt 2 die Aufteilung des Produktportfolios auf die Referenzprodukte. Bei einer korrekten Auswahl der Referenzprodukte soll die gleiche oder eine vergleichbare Produktaufteilung wie in Schritt 1 entstehen. Dazu muss die Methode zur Berechnung der Ähnlichkeit zwischen zwei Elementen in Schritt 1 und Schritt 2 natürlich die gleiche sein. Bei der Verwendung des eben genannten DBSCAN-Algorithmus bietet sich daher für Schritt 2 die Berechnung der „euklidischen Distanz“ zwischen den Produkten und den Referenzprodukten an, da diese auch im Rahmen des Cluster-Algorithmus zur Berechnung der räumlichen Entfernung zwischen den Elementen verwendet wird.

Die euklidische Distanz zwischen zwei Elementen kann mithilfe einer Formel für einen n-dimensionalen Raum berechnet werden, wobei die Anzahl der Dimensionen in diesem Anwendungsfall durch die Anzahl der verschiedenen Anlagen der Auslastungsprofile bestimmt wird. Die räumliche Distanz zwischen einem Produkt und einem Referenzprodukt errechnet sich daher durch die absolute Differenz der Auslastungszeiten der jeweiligen Anlagen. Jedes Produkt kann auf diese Weise dem Referenzprodukt mit der niedrigsten euklidischen Distanz klar zugeordnet werden.

Durch die Aufteilung des Produktportfolios in Schritt 2 kann die Auswahl der Referenzprodukte validiert sowie historische Anlagenbelegungen durch die Verwendung vergangener Stückzahlen modelliert werden. Da die Gruppierung stark von den verwendeten Cluster-Algorithmen und ihren Einstellparametern abhängt, werden die vorgeschlagenen Algorithmen im nachfolgenden Kapitel näher erläutert.

Geeignete Clusteralgorithmen auswählen: DBSCAN-Algorithmus

Der DBSCAN-Algorithmus ist ein unüberwachter Machine-Learning Algorithmus aus der Kategorie dichtebasierter Cluster-Algorithmen. Für eine Gruppierung ähnlicher Objekte wird die räumliche Entfernung zueinander innerhalb eines mehrdimensionalen Raumes berechnet und Ausreißer entfernt. Dadurch benötigt der Algorithmus keine Vorgabe bezüglich der Anzahl der Cluster, lässt sich nicht von Ausreißern „aus der Ruhe bringen“ und kann auch Cluster mit irregulären Formen erkennen.

Als Schwellwert zur Clustererkennung benötigt der Algorithmus zwei Parameter:

• ε als Maximallänge zwischen zwei Elementen, die als Nachbarn erkannt werden sollen,
• minPts als Mindestanzahl an Nachbarn zur Bildung eines Clusters, Bild 3.

Um zu bestimmen, kann die euklidische Distanz zwischen allen Elementen berechnet und aufsteigend sortiert werden. Steigt die Entfernung nach einem bestimmten Punkt drastisch an, ist dies ein potenziell optimaler Wert für ε. In der beispielhaften Abbildung 4 könnte dieser Wert zum Beispiel bei etwa 1.0 angesetzt werden. Für minPts ist die Anzahl der Elemente, der Ausreißer und die Anzahl der gewünschten Cluster entscheidend. Steht der Parameter auf eins, kann der Algorithmus einzelne Objekte als Cluster definieren und wird dies auch tun. Aus der Anwendung in der Praxis empfiehlt sich erfahrungsgemäß ein Wert von minPts >= 3.

k-means

Der k-means-Clustering Algorithmus gehört auch zu den unüberwachten Machine-Learning-Algorithmen und teilt eine Anzahl von n Elementen auf eine Anzahl vorgegebene Cluster k auf, indem die räumliche Entfernung zu den Clustermittelpunkten für alle Elemente minimiert wird. Dazu werden für jedes Cluster initiale Koordinaten übergeben und folgende Schritte iterativ durchgeführt:

• Jedes Element wird dem räumlich nächsten Clustermittelpunkt zugeordnet,
• der Clustermittelpunkt wird neu zentriert, indem die Entfernung zu den zugeordneten Elementen minimiert wird.

Diese Schritte wiederholen sich so lange, bis sich die Clustermittelpunkte nicht mehr verändern – wobei in der Praxis eine weniger strenge Abbruchbedingung üblich ist, z.B. eine Veränderung in der Clusterzuordnung von weniger als einem Prozent aller Elemente, Bild 5.

Ein Nachteil dieser Methode ist, dass die korrekte Gruppierung von den Startparametern abhängig ist. Werden die Clustermittelpunkte initial ungünstig gesetzt (also die Referenzprodukte in diesem Fall ungünstig durch den Menschen vorgeschlagen), kann der iterative Prozess kein korrektes Ergebnis garantieren.

Bei diesem Algorithmus entsteht als Resultat ein theoretisch optimaler Clustermittelpunkt, der optional auch als „künstliches Referenzprodukt“ im System zur Planung hinterlegt werden kann.

Auswahl von Cluster-Algorithmen

In einer stets wachsenden Vielfalt von überwachten und unüberwachten Maschine-Learning Algorithmen scheitert die Suche nach dem perfekten Cluster-Algorithmus bereits an der Definition einer optimalen Lösung für das jeweilige Aufteilungsproblem. Verschiedene Algorithmen haben verschiedene Vor- und Nachteile und die Verwendung im Unternehmen hängt zuletzt auch von der vorhandenen Expertise im eigenen Unternehmen ab.

Folgende Auswahlkriterien helfen bei der Auswahl eines Algorithmus zur Clusterbildung im Kontext eines Referenzproduktionsprogramms:

• Expertise mit einzelnen Algorithmen im eigenen Unternehmen,
• Existenz von unterstützenden Bibliotheken in der ausgewählten Programmiersprache,
• Anzahl der gewünschten Cluster bekannt oder nicht bekannt,
• Homogenität und Verteilung des Produktportfolios.

Im Falle der vorgestellten Algorithmen lohnt sich der k-means-Algorithmus bei einem homogenen Produktportfolio mit vorgeschlagenen Referenzprodukten. Als Resultat kann außerdem optional ein künstliches Referenzprodukt zu Planungszwecken im System hinterlegt werden. Der DBSCAN-Algorithmus trifft keine Entscheidung über ein optimales Referenzprodukt, kommt aber auch mit besonders heterogenen Produktportfolios klar, indem Ausreißer aussortiert werden. Für beide Algorithmen gibt es beliebte unterstützende Bibliotheken in den Programmiersprachen Python oder R.

Die resultierende Gruppierung durch die jeweiligen Cluster-Algorithmen kann mit Microsoft Excel tabellarisch durch Angabe von Clusterzugehörigkeit, beschreibende Produktinformationen und Auslastungsprofilen aufgelistet werden. Dadurch werden die Entscheidungsgrundlagen der Clustering-Algorithmen im Nachhinein nachvollzierbar und erleichtern somit den Direktvergleich zwischen verschiedenen Parameterkonfigurationen oder Algorithmen. Auch eine Visualisierung der gruppierten Auslastungsprofile mit den bereits benannten Visualisierungstools wie MS Power BI oder Tableau können dabei behilflich sein.

Implementierung in den Planungsprozess

Die Implementierung eines (teil-) automatisch erstellten Referenzproduktionsprogramms in den Planungsprozess für eine Produktion kann in zwei Phasen unterteilt werden: Die Initialisierungsphase und die (kontinuierlich durchzuführende) Anpassungsphase.

Die Initialisierungsphase umfasst maßgeblich die Anwendung der oben beschriebenen technischen Aktivitäten auf eine initiale Planungsgrundlage, welche i.d.R. das zuletzt erbrachte Produktionsprogramm darstellt. Basierend hierauf können die Referenzprodukte ermittelt sowie die Top-Line-Auslastung mithilfe von historischen Produktionsstückzahlen berechnet werden. Da sich mit jedem neuen Planungs-Szenario ein sich wiederkehrender Initialaufwand ergibt, bietet es sich an, die in Bild 2 dargestellten Schritte in Form einer in die IT-Systemlandschaft integrierten Daten-Pipeline (definierte Datenextraktion, -prozessierung und -sicherung) fest zu verankern. Das (zukünftige) Referenzproduktionsprogramm ergibt sich aus der Festlegung der Stückzahlen je Referenzprodukt seitens des Vertriebs, entweder durch

• (1) die Budgetierung aller einzelnen Produkte, die im Weiteren per Algorithmus eindeutig den Referenzprodukten zugeordnet werden und damit die Zielstückzahlen ergeben, oder
• (2) durch Budgetierung der Referenzprodukte an sich.

Ergebnis ist schließlich die Visualisierung der Maschinenauslastungen (analog zu der oben beschriebenen Visualisierung der Belastungssituation je Produkt in der Fertigung) in dem gewählten BI-Tool und damit die Ableitung der Investitionsbedarfe, Bild 6.

Für die Erfassung neuer Produkte und die damit verbundene kontinuierliche Anpassung des Modells an sich verändernde produkt-, prozess- und marktseitige Einflüsse ist schließlich ein Skript zu implementieren, welches in regelmäßigen Abständen (z.B. wöchentlich) die Daten aus dem ERP-System abfragt und hinsichtlich neu angelegter Produkte analysiert: Sofern keine neuen Referenzprodukte dazukommen, erfolgt die Zuordnung der neuen Produkte nach bestehendem Muster. Sind die Veränderungen in der Zusammensetzung des Absatzprogramms hingegen größer, bietet sich eine erneute Iteration zur Bestimmung des Referenzproduktionsprogramms an, um hier mögliche Veränderungen zum Status Quo aufzuzeigen und bewerten zu können.

Ausblick

Das vorliegende Beispiel zeigt deutlich, wie datengetriebene Ansätze mehr und mehr heuristische Ansätze ablösen – nicht zuletzt auch durch die immer besser werdende Datenbasis in den Unternehmen. Der Bedarf nach unternehmensspezifischen bzw. individuellen Analysen abseits der herkömmlichen Softwarelösungen steigt stetig. Software-Komplettlösungen inklusive Suiten zur individuellen Anpassung sind eine Möglichkeit, dies umzusetzen. Im Mittelstand hingegen geht der Trend mehr dazu, solche Prozesse nicht im Framework vordefinierter Software abzubilden, sondern selbst durch das Aufsetzen von Daten-Pipelines einschließlich der zugehörigen ML-Skripte umzusetzen und die Auswertung auf einer Meta-Ebene durch herkömmliche BI-Tools vorzunehmen. Um den hieraus resultierenden ökonomischen Vorteil gegenüber teuren Anpassungen durch Softwareanbieter für sich nutzen zu können, ist gerade im Bereich der Erstellung von Skripten (z.B. in Python) sowie dem Aufbau von Datenpipelines eigenes Know-how aufzubauen, oder entsprechende Partnerschaften mit unterstützenden Dienstleistern („verlängerte Werkbank“) einzugehen. Damit wird letztendlich auch der Kompetenzverlagerung in den Unternehmen entsprochen: Den Produktionsleiter mit 30-jähriger Erfahrung, der in der Lage ist, heuristische Modelle zu „füttern“, wird es zukünftig nur noch sehr selten geben. Resultierende Erfahrungsdefizite werden durch universelle Analytics-Fähigkeiten kompensiert.

Literatur

1. [1] Mark Lutz: Learning Python. powerful object-oriented programming. O‘Reilly Media, 2013.
2. [2] Borağan Aruoba, S. u. Fernández-Villaverde, J.: A comparison of programming languages in macroeconomics. Journal of Economic Dynamics & Control 58 (2015), S. 265–273.
3. [3] Wierzchoń, S. u. Kłopotek, M.: Modern Algorithms of Cluster Analysis. Springer International Publishing, 2018.
4. [4] Aggarwal, C. C. u. Reddy, C. K.: Data Clustering. Algorithms and Applications. Chapman and Hall/CRC, 2013.
5. [5] Tabak, J.: Geometry. The language of space and form. The history of mathematics. New York: Facts On File, 2004.

Das könnte Sie auch interessieren:

Wie KI Lieferbereitschaft und Fabrikeffizienz optimiert

Oft vernachlässigt: Digitale Identitäten in der Betriebstechnik

Sechs Tipps für digitales Produktionsmanagement in der Industrie