Proceedings der Wintersimulationskonferenz 2009
M. D. Rossetti, R. R. Hill, B. Johansson, A. Dunkin und R. G. Ingalls, Herausgeber.
David T. Sturrock
Simio LLC
504 Beaver St
Sewickley, PA 15143, USA
Ein Simulationsprojekt ist viel mehr als die Erstellung eines Modells. Und die erforderlichen Fähigkeiten gehen weit über die Kenntnis eines bestimmten Simulationstools hinaus. In diesem Beitrag werden einige wichtige Schritte für den Projekterfolg sowie einige Vorsichtsmaßnahmen und Tipps zur Vermeidung häufiger Fallen erörtert.
In diesem Papier werden einige Aspekte der Modellierung erörtert, die von neuen und angehenden Simulanten oft übersehen werden. Es werden insbesondere Tipps und Ratschläge gegeben, die Ihnen helfen sollen, einige häufige Fallen zu vermeiden und sicherzustellen, dass Ihr erstes Projekt erfolgreich ist. Die ersten vier Themen, die sich mit der Definition von Projektzielen, dem Verständnis des Systems, der Erstellung einer funktionalen Spezifikation und dem Management des Projekts befassen, werden von angehenden Modellierern oft nicht ausreichend beachtet. Die letzten Abschnitte, die sich mit dem Aufbau, der Verifizierung, der Validierung und der Präsentation des Modells befassen, bieten einen Einblick in einige bewährte Ansätze.
Wenn Sie zum ersten Mal über die Durchführung einer Simulationsstudie nachdenken, sollten Sie sich als Erstes Gedanken über die Projektziele machen. Warum will jemand dieses System simulieren und was erwartet er sich davon? Um genauer zu sein, müssen Sie herausfinden, wer Ihre Stakeholder sind und wie sie Erfolg definieren.
Ein Stakeholder ist jemand, der ein Interesse am Ergebnis des Projekts hat, jemand, der sich dafür interessiert. Auf die Frage "Wer sind Ihre Stakeholder?" scheint es eine eindeutige Antwort zu geben - Ihr Manager oder Ihr Kunde. Wenn Sie jedoch untersuchen, warum jemand die Ergebnisse dieser Studie sehen möchte, werden Sie wahrscheinlich weitere Interessengruppen entdecken. Versuchen Sie, die Produktivität Ihrer Anlage zu verbessern? Wenn ja, wird der für den täglichen Betrieb des Systems verantwortliche Manager sicher sein wollen, dass die Ergebnisse korrekt sind. Führungskräfte, die für das Endergebnis verantwortlich sind, werden die finanziellen Ergebnisse sehen wollen. Die Arbeitnehmervertreter sind möglicherweise an Änderungen der Arbeitsinhalte interessiert. Wenn mit Personalveränderungen zu rechnen ist, sind die Personalverantwortlichen möglicherweise an der Studie interessiert. Verschiedene andere Betriebs- (Instandhaltung) und Personalfunktionen (Verfahrenstechnik) könnten ebenfalls interessiert sein. Sogar die Marketingabteilung könnte daran interessiert sein, die Animation für die Werbung zu nutzen.
Bei jedem Projekt gibt es unterschiedliche Interessengruppen, und natürlich sind einige interessierter als andere. Und einige Stakeholder sind vielleicht wichtiger als andere. Es liegt auf der Hand, dass die wichtigsten Interessengruppen zufrieden gestellt werden müssen, doch sollten Sie die anderen nicht außer Acht lassen. In vielen Fällen kann die Zusammenarbeit und Zufriedenheit der weniger wichtigen Interessengruppen über Erfolg oder Misserfolg Ihres Projekts entscheiden.
Die Gruppe Pragmatic Marketing hat den Ausdruck "Ihre Meinung ist zwar interessant, aber irrelevant" geprägt. Das bedeutet im Grunde, dass die Meinung des Kunden (oder in diesem Fall Ihres Stakeholders) über den Projekterfolg viel mehr zählt als Ihre eigene. Selbst wenn Sie persönlich das Projekt für einen überwältigenden Erfolg halten, wenn Ihre wichtigsten Stakeholder es für einen Misserfolg halten, ist Ihr Projekt ein Misserfolg.
Es ist wichtig, Ihre Stakeholder zu befragen, um herauszufinden, was ihre Bedürfnisse und Erwartungen wirklich sind. Wollen sie den Personalbestand oder die Kosten senken? Den Gewinn steigern? Die Vorhersagbarkeit oder Zuverlässigkeit des Systems verbessern? Den Output erhöhen? Verbesserung des Kundendienstes? In allen Fällen müssen Sie nicht nur herausfinden, worauf sie Wert legen, sondern auch, wie sie es messen.
Es ist ratsam, sich auch über "versteckte Absichten" im Klaren zu sein. Liegt der wahre Grund für die Durchführung einer Simulationsanalyse darin, dass jemand von ihnen verlangt hat, ein Modell zu erstellen? Manchmal verlangt ein Kunde oder ein Geldgeber die Erstellung eines Simulationsmodells als Bedingung für einen Vertrag. In diesem Fall kann das Hauptziel des Interessenvertreters darin bestehen, ein Modell zu haben, das das unterstützt, was er ohnehin zu tun beabsichtigt. Um einen beliebten Roboter zu zitieren... "Gefahr, Will Robinson!" Wenn man mit der Antwort beginnt, die man "beweisen" muss, ist das eine Situation, die man um jeden Preis vermeiden sollte.
Wenn Sie wissen, wie Ihre wichtigsten Interessengruppen den Erfolg definieren (und hoffentlich auch messen), können Sie nun Ihre übergeordneten Ziele formulieren. Dies wird der Ausgangspunkt für weitere Projektdiskussionen sein, damit alle Beteiligten eine gemeinsame Vision haben. Diese Informationen sind auch ein guter Ausgangspunkt für die detaillierte funktionale Spezifikation, die Sie zu einem späteren Zeitpunkt vornehmen werden.
Wenn Sie Glück haben, ist es Ihr System, das Sie modellieren, und Sie kennen es gut. In der Regel, selbst wenn das System Ihrem Unternehmen gehört, kennen Sie es nicht gut genug, um es genau zu modellieren. Jedes System hat Feinheiten, die oft wichtig sind. Man kann zwar nicht erwarten, dass ein Simulationsexperte jedes System kennt, aber ein guter Simulationsexperte sollte die wichtigen Fragen kennen, die er stellen muss, und in der Lage sein, die Antworten zu verstehen.
Eine gute Möglichkeit, damit zu beginnen, ist die Überprüfung des Prozesses, damit Sie die wichtigsten Aspekte verstehen. Was sind die Entitäten? Wie werden sie transformiert? Was sind die Zwänge? Wenn möglich, sollten Sie die Gelegenheit nutzen, buchstäblich durch die tatsächliche oder eine ähnliche Einrichtung zu gehen, um Dinge zu entdecken, die in einer Diskussion oder bei der Durchsicht eines Diagramms übersehen werden könnten.
Stellen Sie Fragen. Stellen Sie noch mehr Fragen. Stellen Sie verschiedenen Personen dieselben Fragen und wundern Sie sich nicht, wenn Sie unterschiedliche Antworten erhalten. Ihr Ziel in dieser Phase ist es nicht, das Problem zu lösen, sondern das Problem und das System so gut zu verstehen, dass Sie die Arbeit beschreiben und schätzen können. Ein Teil dieser Phase besteht darin, herauszufinden, was Sie nicht wissen, damit Sie im Projekt Zeit und Risiko für diese Aufklärung einplanen können.
Es gibt ein altes Sprichwort, das besagt: "Wenn du nicht weißt, wohin du gehst, wie willst du dann wissen, wann du ankommst? Das gilt besonders für Simulationsprojekte. Eine funktionale Spezifikation verdeutlicht den Modellumfang und den Detaillierungsgrad. Und, was am wichtigsten ist, es definiert eindeutig die zu erbringenden Leistungen. Es definiert sowohl die Ziele als auch die Ergebnisse und legt fest, wie jeder wissen wird, wann man fertig ist.
Eine funktionale Spezifikation sollte das Projekt klären und alle Beteiligten zu einem gemeinsamen Verständnis der zu erbringenden Leistungen bringen. Die Themen sollten umfassen:
Die Entwicklung eines Prototyps während der Pflichtenheftphase kann für alle Beteiligten aufschlussreich sein. Vielleicht stellen Sie fest, dass es einfacher oder schwieriger ist, als Sie dachten. Selbst bei einem kleinen Projekt lohnt es sich in der Regel, ein schnelles Modell zu zeigen und die Frage zu stellen: Ist es das, was Sie meinen? Vielleicht stellen Sie fest, dass Sie ein völlig anderes Verständnis haben als die Beteiligten. Oft lässt sich ein Prototyp anfertigen, der einen großen Teil der von den Beteiligten geäußerten Wünsche erfüllt. Aber sobald sie den Prototyp sehen, erinnern sie sich an die komplexen Situationen und all die anderen Bedürfnisse, die sie vorher nicht erkannt haben.
Der letzte Teil der Funktionsspezifikationsphase ist die Freigabe. Es sollte allen Beteiligten klar sein, dass diese funktionale Spezifikation das Projekt definiert und dass das Projekt als abgeschlossen und erfolgreich gilt, wenn alle Aspekte der funktionalen Spezifikation erfüllt sind. Idealerweise sollte die endgültige Spezifikation zumindest von den Hauptbeteiligten formell genehmigt werden, um spätere Kontroversen zu vermeiden.
Der beste Zeitpunkt für den Beginn einer Simulationsstudie ist zwar sehr früh im Lebenszyklus des betreffenden Projekts, aber das ist leider nicht die häufigste Situation. Viel häufiger wird die Simulation erst dann in Erwägung gezogen, wenn Probleme in einem späten Stadium des Zyklus auftauchen, vielleicht kurz bevor die endgültigen Entscheidungen getroffen werden müssen. Zu diesem Zeitpunkt wird alles dringlich, und man ist vielleicht sogar "spät dran", bevor man überhaupt angefangen hat.
In einer solchen Situation ist die Versuchung groß, reaktiv zu werden und sich von der Dringlichkeit erst in die eine und dann in die andere Richtung ziehen zu lassen. Und es besteht immer der Druck, wichtige Schritte zu überspringen, z. B. zu entscheiden, was genau man erreichen will (die Phase der funktionalen Spezifikation). Dies führt in der Regel zu einem suboptimalen Arbeitsablauf und sogar zu einem unvollständigen Projekt.
Managen Sie das Projekt, lassen Sie sich nicht vom Projekt managen. Ein Projekt, das kurz nach der Entscheidungsfindung abgeschlossen wird, ist von geringem Wert. Es gehört zu Ihren Aufgaben, das Simulationsprojekt so zu steuern, dass Sie rechtzeitig wertvolle Erkenntnisse liefern. Beachten Sie die Worte "wertvolle Erkenntnisse". Alle Simulationen sind eine Annäherung. Obwohl eine genaue Annäherung mehr Wert hat, kann auch eine gröbere Annäherung wertvolle Erkenntnisse liefern. Wenn die Zeit nicht ausreicht, um das gesamte Projekt gut durchzuführen, wählen Sie eine Teilmenge oder eine grobe Annäherung aus, die Sie in der zur Verfügung stehenden Zeit gut durchführen können. Dies sollte sich in den Annahmen des Pflichtenheftes widerspiegeln.
Simulation ist oft ein Prozess der Entdeckung. Auf dem Weg von der genauen Beschreibung des Systems zu den ersten Simulationsergebnissen werden Sie neue Erkenntnisse gewinnen. Oft können diese neuen Informationen die Studie in eine neue Richtung lenken. Ein gewisses Maß an Flexibilität ist angebracht, um auf solche Anforderungen zu reagieren; ein Zuviel an Flexibilität kann jedoch den Abschluss des Projekts verhindern. In solchen Fällen müssen Sie den schwierigen Schritt wagen, Ihren Stakeholdern "Nein" zu sagen und solche Anfragen auf eine spätere Projektphase zu verschieben. Zwar hört niemand gerne das Wort "Nein", aber die meisten Stakeholder würden ein ehrliches "Nein" einem irreführenden "Ja" vorziehen, das im Grunde besagt: "Ja, ich werde tun, was Sie verlangen, aber deshalb wird das Projekt möglicherweise keine brauchbaren Ergebnisse innerhalb der von Ihnen gesetzten Frist liefern." Planen Sie Ihre Zeit so ein, dass die wichtigen Aufgaben erledigt werden, und erlauben Sie dem Projekt erst dann, unvorhergesehene Richtungen einzuschlagen.
Das Thema Eingabedaten kommt für Simulanten oft überraschend. Und es kann leicht ein Grund für das Scheitern eines Projekts sein. In den Tagen vor der Verbreitung von Computern und Automatisierung war es typischerweise so, dass nur wenige oder gar keine Daten vorhanden waren. Heute ist es viel wahrscheinlicher, dass Sie von Daten überschwemmt werden. Die Herausforderung besteht oft darin, diese Daten zu organisieren und sinnvoll zu nutzen.
Die erste Herausforderung besteht darin, seine Daten zu kennen. Hier ist ein einfaches, aber ziemlich häufiges Beispiel: Sie sammeln Daten über Maschinenausfallzeiten und stellen bei der Analyse fest, dass die minimale Reparaturzeit 8 Minuten, die mittlere 32 Minuten und die maximale 9,5 Stunden beträgt. Ohne zusätzliche Untersuchungen entdecken Sie vielleicht nicht, dass die maximale Reparaturzeit auch eine 8-stündige schichtfremde Zeit beinhaltet, wenn die Reparatur gegen Ende einer Schicht begann. Es wäre leicht, solche Daten falsch in das Modell einzubringen und schlechte Ergebnisse zu erzielen. Es ist wichtig, dass Sie Ihre Daten kennen und wissen, wie gut sie sind, dass Sie sie von ungültigen Daten "säubern" und eine angemessene Eingabeanalyse durchführen.
Da das Sammeln von Daten teuer sein kann, sollten die Ziele Ihrer Simulationsstudie bewertet werden, um festzustellen, wo Sie die genauesten Daten benötigen. Wenn Sie z. B. die Auslastung der Bediener bewerten, ist es wichtig, dass Sie genügend Daten zu den spezifischen Aufgaben haben, für die die Bediener verantwortlich sind. Die Daten, die sich auf einen anderen Bereich des Systems beziehen, der keinen Einfluss auf die Bediener hat, können jedoch auch angenähert werden.
Sie können Ihr Modell und einige Pilotläufe auch dazu verwenden, um festzustellen, wo Sie bessere Daten benötigen, indem Sie ermitteln, wie empfindlich das Modell auf verschiedene Datenwerte reagiert. Sie sollten die Empfindlichkeit sowohl für die Größenordnung (z. B. den Mittelwert) als auch für die Variabilität (z. B. die Spanne) prüfen - wenn sich die Modellergebnisse kaum ändern, wenn Sie andere vernünftige Eingabedaten verwenden, dann sind Ihre derzeitigen Zahlen möglicherweise gut genug. Wenn Sie jedoch eine signifikante Änderung der Ergebnisse bei einer relativ geringen Änderung der Größenordnung oder der Variabilität feststellen, kann dies ein Hinweis darauf sein, dass Sie mehr Zeit und Mühe darauf verwenden sollten, sicherzustellen, dass Sie die bestmöglichen Daten für diesen Parameter haben.
Sie haben in Ihrem Pflichtenheft bereits festgelegt, wer wann für die Bereitstellung der Daten verantwortlich ist. Es ist ratsam, den Beteiligten frühzeitig mitzuteilen, wann Sie die Daten benötigen und ab wann sich das Projekt ohne sie verzögern wird. Auch wenn Sie vielleicht jemand anderem die Schuld für eine Projektverzögerung geben können, ist es weitaus besser, zusammenzuarbeiten, um sicherzustellen, dass das Projekt pünktlich und erfolgreich abgeschlossen wird.
Der Aufbau eines Modells ist der Prozess, bei dem eine Darstellung des realen Systems erstellt wird, die geeignet ist, die festgelegten Ziele zu erreichen. Die Verifizierung des Modells ist der Prozess, der sicherstellt, dass das Modell wirklich das tut, was Sie glauben, dass es tut. Obwohl der Aufbau und die Überprüfung des Modells zwei unterschiedliche Aufgaben sind, werden sie unter einem einzigen Thema behandelt, um die Wichtigkeit zu betonen, sie immer iterativ durchzuführen.
Anfänger bauen manchmal einen großen Teil des Modells oder vielleicht sogar das gesamte Modell, bevor sie mit der Verifikation beginnen. Dies ist eine der Hauptursachen für das Scheitern von Projekten. Wenn Sie mit der Verifikation eines großen Modells beginnen, passiert so viel, dass es schwierig oder unmöglich wird, die detaillierten Wechselwirkungen zu verstehen. Es ist viel effektiver, stattdessen einen iterativen Ansatz zu wählen - einen Teil des Modells zu erstellen, ihn zu verifizieren und dann weitere Teile der Logik zum Modell hinzuzufügen. Zwei sehr effektive Ansätze für die Modellerstellung lassen sich als "zuerst die Breite" oder "zuerst die Tiefe" zusammenfassen.
Bei der Modellierung nach dem Prinzip "Breite zuerst" können Sie das gesamte Modell oder einen großen Teil davon mit einem minimalen Detaillierungsgrad erstellen. Sie können dann überprüfen, ob das Modell funktioniert, bevor Sie fortfahren. Dies hat den Vorteil, dass Sie sofort ein potenziell nützliches Modell erstellen können. Ihr erster Durchlauf könnte sogar der Prototyp sein, der in der funktionalen Spezifikation verwendet wird. Ein weiterer Vorteil besteht darin, dass Sie anhand eines vollständigen (wenn auch nicht vollständig detaillierten) Modells leichter das Feedback der Interessengruppen einholen können und regelmäßig Rückmeldung darüber erhalten, wo mehr Details erforderlich sind. Manchmal können Sie im Rahmen des iterativen Zyklus sogar ein gewisses Maß an Validierung durchführen (siehe unten).
Bei der Modellierung in der Tiefe wählen Sie einen kleinen Teil des Systems aus und modellieren ihn in der erforderlichen Detailtiefe. Sie können diesen Modellabschnitt vollständig verifizieren und müssen ihn im Extremfall nie wieder überprüfen. Ein Vorteil dieses Ansatzes ist die Möglichkeit, das Modell zu modularisieren - besonders wichtig, wenn mehrere Personen gleichzeitig an dem Modell arbeiten könnten. Ein Anfänger könnte sich dafür entscheiden, zunächst einen einfachen Abschnitt des Modells zu erstellen, um Erfahrungen zu sammeln. Ein erfahrener Simulationswissenschaftler könnte die schwierigsten oder kniffligsten Abschnitte zuerst implementieren, um ein gewisses Projektrisiko von vornherein auszuschließen. Ein Modellierer mit einem gewissen "agilen" Hintergrund könnte die Abschnitte mit der höchsten Priorität oder die wichtigsten Abschnitte zuerst umsetzen. Bei diesem Ansatz sind zu jedem Zeitpunkt die wichtigsten Aspekte des Modells abgeschlossen. Dadurch wird das Risiko verringert, dass die Zeit oder das Budget nicht ausreicht, um aussagekräftige Ergebnisse zu erzielen.
Die Ansätze "Breite zuerst" und "Tiefe zuerst" können auch kombiniert werden, indem man abwechselnd einige Details auf der gesamten Modellebene hinzufügt und dann einige Details zu einem bestimmten Teilbereich hinzufügt (oder diesen vervollständigt). Der wichtigste Aspekt ist jedoch, relativ kleine Abschnitte der Modelllogik hinzuzufügen und dann jeden Abschnitt zu überprüfen, bevor weitere Logik hinzugefügt wird.
In jedem Verifikationszyklus wollen Sie zwei Fragen definitiv beantworten. Funktioniert der Abschnitt des Modells, den ich gerade erstellt habe, so wie ich es beabsichtigt habe (z. B. gibt es Fehler in der Logik dieses neuen Abschnitts)? Wenn dieser neue Abschnitt mit zuvor erstellten Abschnitten des Modells interagiert, funktioniert das gesamte Modell dann noch wie beabsichtigt (z. B. gibt es Fehler in den Interaktionen zwischen den Abschnitten)? Wenn Ihr Modell größer wird, sollten Sie die neuen Abschnitte verkleinern, um die Beantwortung der zweiten Frage zu erleichtern.
Die naheliegendsten Möglichkeiten, Modellprobleme zu finden und zu diagnostizieren, bestehen darin, die Animation zu beobachten und die Ausgabeergebnisse zu untersuchen. Unerwartete Ergebnisse sind kein Problem - sie sind ein Hauptgrund für die Durchführung einer Simulation. Unerklärliche Ergebnisse sind ein Problem. Wenn das Modell ein unerwartetes Ergebnis erzeugt, müssen Sie alle Ihnen zur Verfügung stehenden Mittel einsetzen, um die Erklärung zu finden. In einigen Fällen kann dies zur Entdeckung eines Fehlers führen, der behoben werden muss. In anderen Fällen führt es zu einem "Aha"-Moment - einem Blitz der Erleuchtung darüber, wie ein komplexes System funktioniert.
Die meisten Produkte verfügen über eine Vielzahl von Werkzeugen zur Unterstützung der Modellüberprüfung. Oft ist eine Modellverfolgung verfügbar, die sehr detailliert aufzeigt, was genau in Ihrem Modell Schritt für Schritt passiert. Sie können damit beginnen, eine einzelne Entität beim Durchlaufen des gesamten Prozesses zu beobachten. In der Regel verfügt Ihre Software über Steuerelemente, die es Ihnen ermöglichen, ein Modell schrittweise zu durchlaufen oder die Ausführung an einer bestimmten Stelle, zu einem bestimmten Zeitpunkt oder unter einer bestimmten Bedingung zu "unterbrechen". Oft gibt es ein Überwachungsfenster, das es Ihnen ermöglicht, den detaillierten Systemzustand zu jedem Zeitpunkt oder für jedes Objekt zu untersuchen, um zu klären, was vor sich geht. Nutzen Sie auch die Dashboards oder andere interaktive Statistiken und Grafiken, die Ihre Software bietet. Der Überprüfungsprozess ist mit Sicherheit ein aufschlussreicher und notwendiger Teil des Projekts.
Auch wenn Sie alle oben genannten Punkte beachtet haben, kann es vorkommen, dass Sie eine Situation vorfinden, die einfach nicht richtig aussieht, Sie aber nicht erklären können, warum. Dann ist es Zeit für eine Modellbegehung.
Suchen Sie sich einen guten Zuhörer, idealerweise einen Simulationsexperten oder einen Ihrer Stakeholder, und gehen Sie alle relevanten Modellabschnitte durch und erklären Sie ihm, was vor sich geht. Wenn Ihr Zuhörer in der Lage ist zu verstehen, was Sie erklären, ist das ein Bonus.
Aber in den meisten Fällen werden Sie Ihr eigenes Problem finden, wenn Sie methodisch durch die Interaktionen gehen. Wenn Sie dies bedenken, eröffnen sich für einen Zuhörerkandidaten vielfältige Möglichkeiten. Ein unbeteiligter Kollege, ein Ehepartner oder sogar ein Haustier sind gute Kandidaten. Hunde und Katzen können zwar manchmal gute Zuhörer sein, aber nichts ist besser als ein Goldfisch, wenn es um die Zuhörerschaft geht. Der Schlüssel ist, dass das laute Erklären Ihres Modells einen anderen Teil Ihres Gehirns zu öffnen scheint und es Ihnen ermöglicht, Ihr eigenes Problem zu lösen.
Wie bereits erwähnt, ist ein Modell nur eine Annäherung an ein reales System. Normalerweise wollen der Modellierer und die Beteiligten, dass das Modell so genau und umfassend wie möglich ist. Um endlose, verspätete und überteuerte Projekte zu vermeiden, müssen Sie auf Ihr Pflichtenheft zurückgreifen. Ihr Ziel ist es, ein Modell zu erstellen, das gerade so detailliert ist, dass die angegebenen Ziele erreicht werden, und nicht mehr!
Animation ist ein Bereich, in dem man sich leicht "verirren" kann. Die Animation kann die Arbeit sein, die am meisten Spaß macht und sofort Freude bereitet. Es kann leicht passieren, dass sie mehr Zeit in Anspruch nimmt, als sie sollte. Die meisten Pakete verfügen über ein gewisses Maß an automatischer Animation. Dies ist in der Regel gut genug für die Modellüberprüfung. Ebenso verfügen viele Pakete über ein gewisses Maß an 2D- oder 3D-Animation, die sehr einfach zu erstellen ist. In gewissem Umfang kann dies die Validierung erleichtern, indem es ein zusätzliches Maß an Realität und Anerkennung durch die Beteiligten schafft. Aber auch hier müssen Sie auf den Abschnitt der funktionalen Spezifikation zurückkommen. Ihre endgültige Animation sollte gerade gut genug sein, um die zuvor identifizierten Kundenziele zu erfüllen, und nicht mehr!
Die Modellvalidierung muss durchgeführt werden, um festzustellen, ob das Modell die Realität in dem Maße abbildet, wie es zur Erreichung der Ziele erforderlich ist. In manchen Fällen können Sie die Validierung bereits während der Erstellung und Überprüfung des Modells durchführen und sollten jede Gelegenheit dazu nutzen. Allerdings müssen Sie das fertige Modell noch zusätzlich validieren. Eine perfekte Verifizierung und Validierung ist in der Regel nicht möglich, denn das einzige perfekte Modell ist das reale System. Es gibt jedoch einige Möglichkeiten, mit denen Sie versuchen können, nachzuweisen, dass das Modell für die Zwecke des Projekts gültig genug ist.
Eine gängige Validierungstechnik besteht darin, mit einem Modell des bestehenden Systems zu beginnen (unter der Annahme, dass das reale System existiert). Vergleichen Sie die Ergebnisse des "Ist"-Modells mit der Leistung des realen Systems. Bei einem stochastischen Vergleich könnte man einen repräsentativen Zeitraum (z. B. 30 Tage oder 30 Wochen) nehmen und die durchschnittlichen Ergebnisse über diesen Zeitraum vergleichen. Ein anderer Ansatz besteht darin, das Modell so deterministisch wie möglich zu gestalten (z. B. Verwendung exakter Ankunftszeiten von Entitäten, exakter Fehlerdaten usw.) und die Ergebnisse für diesen kürzeren Zeitraum zu vergleichen. Jeder dieser Ansätze ist auf seine eigene Weise wertvoll. In beiden Fällen sollten Sie sich bemühen, alle signifikanten Unterschiede zu identifizieren und zu erklären.
Eine weitere Validierungstechnik besteht darin, die Erfahrung der Beteiligten zu nutzen. Sie kennen das System gut und sollten in der Lage sein, sich eine Animation anzusehen und ein gewisses Maß an Vertrauen zu vermitteln. Sie sollten ihnen auch die Möglichkeit geben, die Leistung des Modells in einer Vielzahl von Situationen zu sehen, z. B. bei hohem oder geringem Datenaufkommen oder bei der Wiederherstellung nach einem Ausfall. Idealerweise sollten die Beteiligten sogar in der Lage sein, solche Situationen selbst zu erzeugen, z. B. "Ich möchte sehen, wie Maschine A ausfällt ... jetzt."
Während ein einzelner Stakeholder wertvolle Erkenntnisse liefern kann, kann eine Gruppe von Stakeholdern mit unterschiedlichem Hintergrund einen noch größeren Wert darstellen. So könnte ein Ingenieur sagen: "Ja, Sie haben den Entwurf genau so erfasst, wie ich ihn beschrieben habe", worauf ein Bediener antworten könnte: "Das mag sein, aber wir würden es nie so machen. So würden wir es machen...". Zu diesem Zeitpunkt bietet die Simulation bereits einen erheblichen Wert als Kommunikationsinstrument. Ihre Aufgabe im weiteren Verlauf der Sitzung besteht darin, die Diskussion zu moderieren und Notizen zu machen.
Während der Experimentierphase werden Sie die in der funktionalen Spezifikation festgelegten Szenarien erstellen. Höchstwahrscheinlich werden Sie auch einige zusätzliche Szenarien benötigen, die auf dem basieren, was Sie im Laufe des Projekts gelernt haben. Die Einzelheiten der statistischen Analyse würden den Rahmen dieses Papiers sprengen, aber eine angemessene statistische Analyse ist von entscheidender Bedeutung. Im Abschnitt "Zusätzliche Lektüre" finden Sie eine gründliche Behandlung geeigneter Experimente und statistischer Analysen.
Wie bei allen anderen Teilen des Projekts sollten Sie auch hier genügend Zeit für Experimente und Analysen einplanen. Wenn Sie bei der Modellerstellung, der Verifizierung oder der Validierung des Projekts in Verzug geraten, kann es passieren, dass Sie bei der Analyse in Zeitnot geraten. Denken Sie daran, dass der Grund für die Durchführung eines Simulationsprojekts in der Regel darin besteht, verschiedene Szenarien zu analysieren; planen Sie also entsprechend und lassen Sie genügend Zeit für die abschließende Analysephase.
Ihr vorrangiges Ziel sollte es sein, Ihren Stakeholdern dabei zu helfen, die bestmögliche Entscheidung in Anbetracht der zur Verfügung stehenden Zeit und Ressourcen zu treffen. Auch wenn Sie andere persönliche Ziele verfolgen, wie z. B. den Aufbau von Glaubwürdigkeit oder die Erzielung von Gewinn, werden diese Ziele wahrscheinlich erreicht, wenn Sie sich darauf konzentrieren, den Beteiligten zu helfen.
Berücksichtigen Sie den Hintergrund und die besonderen Bedürfnisse der einzelnen Stakeholder, bevor Sie Ihren Bericht erstellen. Obwohl Sie wahrscheinlich stolz auf Ihr Modell und die detaillierte Art und Weise sind, in der Sie komplexe Probleme gelöst haben, werden nur wenige Interessengruppen dieses Interesse teilen. Die meisten Interessengruppen sind an drei Dingen interessiert. Erstens, welche Alternativen in Betracht gezogen wurden. Zweitens, wie lauten Ihre Schlussfolgerungen oder Empfehlungen. Drittens, welche unterstützenden Informationen können Sie bereitstellen, um ihr Vertrauen in Ihre Analyse zu rechtfertigen.
Obwohl Sie Daten benötigen, um Ihre Schlussfolgerungen zu untermauern, sollten Sie Ihre Interessenvertreter nicht mit zu vielen Details überfordern. Versuchen Sie, die Informationen in dem erforderlichen Kontext bereitzustellen. Anstatt einfach zu sagen: "Die durchschnittliche Fahrerauslastung lag bei 76 %", könnten Sie zum Beispiel sagen: "Da die durchschnittliche Fahrerauslastung hoch ist (76 %), gibt es nicht genügend Pufferzeit, um Spitzenzeiten aufzuholen, ohne dass es zu Verspätungen kommt."
Übertreiben Sie es nicht mit der Genauigkeit der Ausgabedaten. Weisen Sie die Beteiligten darauf hin, dass es sich bei dem Modell um einen Näherungswert handelt, der keine exakten Antworten liefert, und betonen Sie dies sogar. Geben Sie Ihre Daten mit einer angemessenen Genauigkeit an, die auf der Genauigkeit Ihrer Daten und Modellierungsannahmen beruht (z. B. 76,2 % und nicht 76,2315738 %). Und zeigen Sie die Genauigkeit Ihrer Zahlen, wenn möglich. Die meisten Interessengruppen können sich mit einem Konfidenzintervall wie 76,2 % ± 1,3 % identifizieren.
Trotz allem, was Sie vielleicht schon gehört haben, ist es nicht einfach, Simulationsprojekte gut durchzuführen. Es gibt viele Möglichkeiten, wie selbst ein erfahrener Simulationsexperte scheitern kann. In diesem Beitrag haben wir einige häufige Fallen und Möglichkeiten zu deren Vermeidung erörtert. Die Befolgung dieser Vorschläge ist zwar keine Garantie für einen Volltreffer, erhöht aber mit Sicherheit Ihre Chancen, das Ziel zu erreichen.
WEITERE LEKTÜRE
Banks, J., J. S. Carson, B. L. Nelson, und D. M. Nicol. 2010. Diskrete Ereignissystem-Simulation. 5th ed. Upper Saddle River, New Jersey: Prentice-Hall, Inc.
Law, A. M. 2007. Simulationsmodellierung und -analyse. 4th ed. New York: McGraw-Hill, Inc.
Sadowski, D. A. und M. R. Grabau. 1999. Tipps für die erfolgreiche Praxis der Simulation. In Proceedings of the 1999 Winter Simulation Conference, ed. P. A. Farrington, H. B. Nembhard, D. T. Sturrock, und G. W. Evans, 60-66. Piscataway, New Jersey: Institute of Electrical and Electronics Engineers, Inc.
Sturrock, D. T., Erfolg in der Simulation, Fortlaufender Blog und Diskussion unter .
PDF-Version herunterladen