Die drei coolstenifactory-installationen

Transkript

1 Die drei coolstenifactory-installationen Teil 2 ifactory Integration von TECHSOFT wird mittlerweile von mehr als 100 Kunden produktiv eingesetzt. Bei allen diesen Kunden regelt die bewährte Interface Engine unternehmenswichtige Prozesse und Schnittstellen von Administratoren geschätzt, für Endanwender oftmals unbemerkt und daher auch manchmal unbekannt. In diesem Teil unserer Serie geht es darum zu zeigen, wie eine unternehmenskritische Installation optimiert werden kann. Auf die Kundeninstallation, die diesmal im Mittelpunkt steht, wird daher primär aus planerischer Sicht eingegangen, die inhaltlichen Aspekte spielen nur eine untergeordnete Rolle. Schnittstellen Wesentliche Komponente eines IT-Konzeptes Effiziente Schnittstellen wie ifactory Integration ermöglichen einen performanten, stabilen und verlässlichen Austausch geschäftsrelevanter Daten über Systemgrenzen hinweg. In vielen Fällen zwischen unternehmenskritischen Bereichen angesiedelt, sind Schnittstellen daher ein zentrales und wesentliches Element eines unternehmensweiten IT-Konzepts. Entscheidend ist die richtige Dimensionierung und Strukturierung der technologischen Basis, die anhand verschiedener Faktoren ermittelt werden kann. Was dabei zu berücksichtigen ist, wird im Folgenden am Beispiel einer realen Kundenumgebung erläutert. Faktor: Anzahl Transaktionen Jobs und Job Arten Ein wichtiger Parameter zur Dimensionierung einer Schnittstelle ist die Anzahl der zu bewältigenden Transaktionen, die im Kontext von ifactory Integration auch kurz als Jobs bezeichnet werden. Diese Jobs lassen sich wiederum in mehrere unterschiedliche Schnittstellenfunktionen unterteilen, in ifactory Job Arten oder Formate genannt Grafik 1 zeigt die unterschiedlichen Job Arten sowie deren Häufigkeiten in der ifactory Installation des Kunden im Juni 2010.

2 Da wir uns nicht mit den Inhalten der Schnittstelle beschäftigen wollen, nachfolgend zum besseren Verständnis nur eine kurze Erläuterung der wichtigsten Job Arten: ARTIKELSTAMM Übertragung von Artikelstamm-Daten aus dem ERP- an das PLM-System PDF PDF-Erstellung von Zeichnungen und Übertragung an das ERP-System STÜCKLISTE Übergabe der Stückliste vom PLM- an das ERP-System So wurden, wie in der Grafik ersichtlich, ca Artikel vom ERP- an das PLM-System übergeben (1), knapp Zeichnungen wurden als PDF vom PLM- an das ERP-System übertragen (2) und insgesamt Mal wurden bereits übergebene Zeichnungen als (zwischenzeitlich) ungültig im ERP gekennzeichnet (3) und das Ganze in nur einem Monat. Auch wenn man bedenkt, dass ca. 70 Konstrukteure in diesem Unternehmen für Sondermaschinenbau produktiv tätig sind die absoluten Zahlen bleiben trotzdem beeindruckend. Faktor: Laufzeiten und ihre Ursachen TECHSOFT Datenverarbeitung GmbH Die Anzahl der Jobs ist aber nur ein Aspekt, den es einzukalkulieren gilt. Ebenso wichtig ist es zu beachten, dass die verschiedenen Job Arten auch unterschiedliche Laufzeiten nach sich ziehen, je nachdem, welche Aufgabe bewerkstelligt wird In der Grafik 2 wird das Phänomen der unterschiedlichen Laufzeiten, die dieses über einen längeren Zeitraum von knapp 2 Jahren nachvollzieht, sehr deutlich aufgezeigt. Im Durchschnitt dauert ein Job ARTIKELSTAMM (grüne Linie) (4) um die Millisekunden, also eine gute halbe Sekunde. Innerhalb dieser Zeitspanne wird durch die ifactory ein aus dem ERP-System übergebener Artikel samt seiner Daten im PLM- System angelegt bzw. geändert, falls dieser schon vorhanden ist. Im Gegensatz dazu sieht man am Beispiel des PDF-Jobs (rote Linie) (5) eine durchschnittliche Job Dauer von 13 Sekunden und mehr. Außerdem erkennt man, dass die Streuung der PDF-Job Dauer wesentlich größer ist als bei ARTIKELSTAMM.

3 Die generell höhere Laufzeit ist anhand der Funktionalität leicht erklärbar: Ein PDF-Job lädt zuerst die Zeichnung aus dem PLM- System, dazu ist das CAD-Programm im Hintergrund erforderlich. Dann müssen Zeichnungskopf und die auf der Zeichnung angedruckten Stücklisten aktualisiert werden, um anschließend die Zeichnung in ein PDF zu konvertieren das alles erfordert eine gewisse Zeit. Die breitere Streuung ist damit zu erklären, dass die Dauer eines PDF-Jobs abhängig von der Zeichnungsgröße ist. Einzelteil- Zeichnungen lassen sich rasch generieren, große Baugruppen-Zeichnungen dauern wesentlich länger. Summiert sich die Anzahl der erstellten Baugruppen-Zeichnungen zum Beispiel gegen Ende eines größeren Kundenauftrags, dann steigt die durchschnittliche Dauer der PDF-Jobs. Am dritten Job STÜCKLISTE (blaue Linie) (6) kann man einen signifikanten Anstieg der Job Dauer in der zweiten Jahreshälfte 2010 erkennen. Dies führte seinerzeit zu einer nachteiligen Beeinflussung des gesamten Organisationsablaufes. Etablierte Durchlaufzeiten vom Engineering über die AV bis zur Fertigung konnten nicht mehr eingehalten werden, so dass Handlungsbedarf bestand. Durch geeignete Gegenmaßnahmen im PLM-System sowie in der ifactory konnte die Dauer der STÜCKLISTEN-Jobs wie auch optisch verdeutlich wird (7) ab Jänner 2011 wieder drastisch gesenkt werden. Integrierte Analyse von Jobs und Laufzeit Grundlage systematischer Schnittstellenplanung TECHSOFT Datenverarbeitung GmbH Es ist also nicht nur die Anzahl der Jobs für die Dimensionierung einer Schnittstelle mit ifactory zu berücksichtigen, sondern auch die Laufzeit der einzelnen Job Arten. In der folgenden Grafik sind beide Informationen verknüpft, man sieht die Summe der Laufzeiten für die einzelnen Job Arten: Grafik 3 zeigt anschaulich, dass die Gesamtbelastung der Schnittstelle durch den Job ARTIKELSTAMM in Wirklichkeit sehr gering ist (8), obwohl die Anzahl dieser Jobart lt. Grafik 1 am höchsten ist. Als Ressourcenfresser erweist sich der Job PDF, der durch eine hohe Anzahl gepaart mit hoher Laufzeit mit 80 Stunden CPU-Zeit im Juni 2010 eindeutig als Spitzenreiter gilt (9).

4 Die Gesamtlaufzeit des Jobs STÜCKLISTE liegt im Juni 2010 ebenfalls relativ hoch (10), was durch die zum damaligen Zeitpunkt hohe durchschnittliche Job Dauer von knapp 20 Sekunden (Grafik 2) zu erklären ist. Analyseergebnisse und Schlussfolgerungen Aus diesem durchaus typischen Verhalten und einigen logischen Randbedingungen lassen sich folgende Schlüsse ziehen: Aufgrund der hohen Jobanzahl und der unterschiedlichen Laufzeitverhalten der Job Arten ist es zu empfehlen, die Schnittstellenlast auf mehrere Instanzen zu verteilen. Artikelbezogene Job Arten (wie ARTIKELSTAMM und STÜCKLISTE) sollten möglichst schnell abgearbeitet werden, da in der Regel der Benutzer das Ergebnis sofort benötigt. Job Arten mit CAD-Anteil (wie PDF, DXF,CAM, ) dauern länger und sind im Regelfall weniger zeitkritisch als artikelbezogene. Daraus ergibt sich die folgende Dimensionierung bzw. Verteilung der Schnittstellen: Die gesamte Schnittstellenlast wird auf drei Instanzen aufgeteilt (hier IF_ERP, IF_3D, IF_2D), d.h. ifactory Integration läuft mit einer zentralen Job Queue auf drei Rechnern parallel. 1. Dem Rechner IF_ERP werden die artikelbezogenen Job Arten ARTIKELSTAMM und STÜCKLISTE zugeordnet (blau) (11) zusätzlich auch noch INVALID. Die Job Art ARTIKELSTAMM erhält dabei die höchste Job Priorität und wird vorrangig vor den beiden anderen abgearbeitet. Alle drei Job Arten zeichnen sich durch eine kurze Job Dauer aus (STÜCKLISTE erst seit 2011) und können sich dadurch gegenseitig nicht behindern. Dieser Teil der Schnittstelle ist also auf eine hohe Job Anzahl bei kurzer Laufzeit ausgerichtet. 2. Der Rechner IF_3D erhält allejob Arten mit CAD-Anteil (rot) (12), bis auf die Jobart PDF. 3. Der Rechner IF_2D erhält ausschließlich die Job Art PDF (grün) (13), da diese sowohl die unternehmenskritischste CAD-Jobart ist als auch diejenige, die das System am stärksten belastet. Engpässe lokalisieren und beheben Obwohl die getroffene Aufteilung der Job Arten auf in Summe drei Instanzen aus Unternehmenssicht bereits eine erhebliche Optimierung des Gesamtverhaltens der Schnittstelle darstellt, kann es dennoch zu Engpässen innerhalb der jeweiligen Instanzen selbst kommen. Naturgemäß werden Engpässe eher auf den beiden Instanzen mit CAD-Jobs auftreten, also bei IF_3D und IF_2D. Bei IF_ERP ist ein derartiges Verhalten nur bei einer Massendatenänderung im ERP-System zu erwarten. Es ist relativ aufwendig, derartige Engpässe aufzuspüren. Vor allem durch die oben angesprochene höhere Streuung der Job Dauer bei CAD-Jobs können sich kurzzeitige Spitzenbelastungen einstellen. Diese bringen unangenehme Verzögerungen mit sich und können die betroffenen Abteilungen mitunter auch erheblich behindern.

5 Es gilt zu ermitteln, ob derartige Verzögerungen nur sporadisch auftreten oder ob eine generelle Überlastung vorliegt, der nur durch eine weitere Parallelisierung entgegengewirkt werden kann. Das subjektive Empfinden der Abteilungen kann erfahrungsgemäß nicht als alleinige Grundlage herangezogen werden. Für die Analyse ist die grafische Darstellung des Schnittstellenverhaltens äußerst hilfreich Grafik 4 zeigt für den Monat Juni 2010 den Verlauf der PDF-Jobs hinsichtlich seiner verzögerten Abarbeitung. Man erkennt im letzten Fünftel des Monats zwei starke Spitzenbelastungen von 270 Minuten (14) und 100 Minuten (15) Verzögerung, die sich jedoch sehr schnell wieder gegen 0 wenden. Hier kann davon ausgegangen werden, dass dieser Teil der Schnittstelle nicht permanent überlastet ist. Eine weitere Parallelisierung dass also zwei oder mehr Rechner die PDF-Jobs parallel ausführen ist hier nicht zielführend. Die gleiche Auswertung auf der IF_3D Maschine, die hauptsächlich 3D-Formate erzeugt, ergibt ein etwas anderes Bild: Grafk 5 lässt deutlich mehr Verzögerungen erkennen. Der klassische Fall einer Aufschaukelung ist im zweiten Monatsdrittel (15) auszumachen. Die Verzögerung erhöht sich mit jedem neu dazugekommenen enen Job. Da über einen längeren Zeitraum mehr Jobs angelegt werden, als abgearbeitet werden können, ergibt sich dieses anwachsende treppenförmige Gebilde.

6 Eine massive Überbelastung wird im letzten Fünftel des Monats (16) ersichtlich. Die Ursachen hierfür sind aber nicht immer eindeutig. Man muss berücksichtigen, in welcher Form die Jobs angelegt werden. In diesem Fall wird der Großteil der Konvertierungsjobs automatisiert durch ERP-Prozesse Prozesse erstellt. Im Gegensatz zu rein interaktiv angelegten Jobs kann eine Massen-Joberstellung durch gewollte oder ungewollte ERP-Massentransaktionen durchaus als mögliche Ursache für die Überlast angesehen werden. Meistens aber deutet ein derartiger Block darauf hin, dass es der ifactory nicht möglich war, die Jobs abzuarbeiten, weil dieser Teil der Schnittstelle über eine gewisse Zeitspanne nicht aktiv war (in diesem Fall 1000 Minuten = 16 Stunden). Nach Behebung des Problemes nimmt die Abarbeitung der zwischenzeitlich erstellten Jobs durch die ifactory längere Zeit ( = Breite des Balken) in Anspruch. Unvermeidbare Engpässe Anhand eines Ausschnitts (17) aus Grafik 5 wird veranschaulicht, dass speziell die automatisierte CAD-Daten-Konvertierung stets mit einem gewissen Grundrauschen an Zeitverlust verknüpft ist. 17 Auch hier kann auf eine weitere Parallelisierung verzichtet werden. Die für sich aufschaukelnde Verzögerungen typischen Sägezahn-Profile bleiben auf erträglichen Spitzenwerten von weniger als 10 Minuten. Derartige Entscheidungen sind jedoch im Kontext der jeweiligen inhaltlichen Bedeutung und Anforderungen an spezifische Job Arten zu treffen. Für die richtige Dimensionierung und Strukturierung einer Schnittstelle gibt es keine Standardlösung. Die inhaltliche Bedeutung der einzelnen Job Arten für das Unternehmen, die Kritikalität der Aufgaben und die Konsequenzen für die internen Abläufe bei Engpässen sind die Grundlagen, anhand derer entschieden werden muss, welche Maßnahmen erforderlich bzw. wirtschaftlich sinnvoll erscheinen.