Conseils pour une pratique réussie de la simulation

Actes de la Conférence sur la simulation hivernale 2009

M. D. Rossetti, R. R. Hill, B. Johansson, A. Dunkin et R. G. Ingalls, eds.
David T. Sturrock

Simio LLC
504 Beaver St
Sewickley, PA 15143, USA

RÉSUMÉ

Un projet de simulation est bien plus que la construction d'un modèle. Les compétences requises vont bien au-delà de la connaissance d'un outil de simulation particulier. Cet article présente quelques étapes importantes pour la réussite d'un projet, ainsi que des mises en garde et des conseils pour éviter les pièges les plus fréquents.

1. INTRODUCTION

Ce document aborde certains aspects de la modélisation qui échappent souvent aux nouveaux simulateurs et à ceux qui aspirent à le devenir. En particulier, des astuces et des conseils sont fournis pour vous aider à éviter certains pièges courants et à faire en sorte que votre premier projet soit couronné de succès. Les quatre premiers sujets traitant de la définition des objectifs du projet, de la compréhension du système, de la création d'une spécification fonctionnelle et de la gestion du projet reçoivent souvent une attention insuffisante de la part des modélisateurs débutants. Les dernières sections, qui traitent de la construction, de la vérification, de la validation et de la présentation du modèle, offrent un aperçu de certaines approches éprouvées.

2. DÉFINIR LES OBJECTIFS DE L'ÉTUDE

Lorsque vous envisagez pour la première fois de réaliser une étude de simulation, l'une des premières choses à prendre en compte est l'objectif du projet. Pourquoi quelqu'un veut-il simuler ce système et qu'attend-il de cette simulation ? Pour être plus précis, vous devez déterminer qui sont vos parties prenantes et comment elles définissent le succès.

2.1 Qui sont les parties prenantes ?

Une partie prenante est une personne intéressée par le résultat du projet, une personne qui s'en préoccupe. La réponse à la question "Qui sont vos parties prenantes ?" semble évidente : votre directeur ou votre client. Mais si vous cherchez à savoir pourquoi quelqu'un voudrait voir les résultats de cette étude, vous découvrirez probablement d'autres parties prenantes. Essayez-vous d'améliorer la productivité de votre usine ? Si c'est le cas, le responsable des opérations quotidiennes du système voudra s'assurer que les données sont exactes. Les cadres responsables des résultats financiers voudront voir les résultats financiers. Les représentants des travailleurs peuvent être intéressés par les modifications du contenu du travail. Si des changements de personnel sont probables, le personnel des ressources humaines peut être intéressé par l'étude. Diverses autres fonctions d'exploitation (maintenance) et de personnel (ingénierie des procédés) peuvent également être intéressées. Même le service marketing peut être intéressé par l'utilisation de l'animation à des fins de promotion.

Chaque projet a des parties prenantes différentes et il est évident que certaines parties prenantes seront plus intéressées que d'autres. Et certaines parties prenantes peuvent être plus importantes que d'autres. S'il est évident que les parties prenantes les plus importantes doivent être satisfaites, il ne faut pas pour autant ignorer les autres. Souvent, la coopération et la satisfaction des parties prenantes les moins importantes peuvent faire de votre projet un succès ou un échec.

2.2 Comment vos parties prenantes définissent-elles la réussite ?

Le groupe Pragmatic Marketing a inventé une expression : "Votre opinion, bien qu'intéressante, n'est pas pertinente". Cela revient à dire que l'opinion du client (ou, dans le cas présent, de votre partie prenante) sur la réussite du projet compte beaucoup plus que la vôtre. Même si vous considérez personnellement que le projet a été un succès retentissant, si vos parties prenantes les plus importantes le considèrent comme un échec, votre projet est un échec.

Il est important de sonder les parties prenantes pour connaître leurs besoins et leurs attentes. Veulent-ils réduire les effectifs ou les dépenses ? Améliorer les bénéfices ? Améliorer la prévisibilité ou la fiabilité du système ? Augmenter la production ? Améliorer le service à la clientèle ? Dans tous les cas, vous devez découvrir non seulement ce qu'ils apprécient, mais aussi comment ils le mesurent.

Il est également judicieux d'être attentif aux "intentions cachées". La véritable raison pour laquelle une analyse de simulation est effectuée est-elle que quelqu'un a exigé que l'on construise un modèle ? Il arrive qu'un client ou une source de financement exige la construction d'un modèle de simulation dans le cadre d'un contrat. Dans ce cas, l'objectif principal de la partie prenante peut être de disposer d'un modèle qui appuie ce qu'elle a l'intention de faire de toute façon. Pour citer un robot populaire... "Danger, Will Robinson !" Commencer par la réponse que vous devez "prouver" est une situation à éviter à tout prix.

Sachant comment vos principales parties prenantes définissent (et, espérons-le, mesurent) le succès, vous êtes maintenant prêt à rédiger vos objectifs de haut niveau. Ce sera le point de départ des discussions ultérieures sur le projet, afin que tout le monde ait une vision commune. Ces informations constituent également un bon point de départ pour la spécification fonctionnelle détaillée que vous réaliserez ultérieurement.

3. COMPRENDRE LE SYSTÈME

Si vous avez de la chance, c'est votre système que vous modélisez et vous le connaissez bien. Plus généralement, même si le système appartient à votre entreprise, vous ne le connaissez pas suffisamment bien pour le modéliser avec précision. Chaque système présente des subtilités qui sont souvent importantes. S'il n'est pas raisonnable d'attendre d'un simulateur qu'il connaisse tous les systèmes, un bon simulateur doit savoir quelles sont les questions importantes à poser et être capable de comprendre les réponses.

Une bonne façon de commencer est de passer en revue le processus afin d'en comprendre les principaux aspects. Quelles sont les entités ? Comment sont-elles transformées ? Quelles sont les contraintes ? Si possible, profitez de l'occasion pour vous promener littéralement dans l'installation réelle ou similaire afin de découvrir des éléments qui pourraient être oubliés lors d'une discussion ou de l'examen d'un diagramme.

Posez des questions. Posez encore plus de questions. Posez les mêmes questions à différentes personnes et ne soyez pas surpris d'obtenir des réponses différentes. À ce stade, votre objectif n'est pas de résoudre le problème, mais de comprendre le problème et le système suffisamment bien pour pouvoir décrire et estimer le travail. Une partie de cette étape consiste à identifier ce que vous ne savez pas afin de prévoir du temps et des risques dans le projet pour cette découverte.

4. CRÉER UNE SPÉCIFICATION FONCTIONNELLE

Un vieil adage dit : "Si vous ne savez pas où vous allez, comment saurez-vous quand vous y serez ?". C'est particulièrement vrai dans les projets de simulation. Une spécification fonctionnelle clarifie la portée du modèle et le niveau de détail. Et surtout, il définit clairement les produits à livrer. Elle définit les objectifs ainsi que les produits à livrer et détermine comment tout le monde saura que vous avez terminé.

Une spécification fonctionnelle doit clarifier le projet et amener tout le monde à une compréhension commune des résultats attendus. Les sujets abordés doivent inclure

• Objectifs- Résumez, à partir de vos objectifs initiaux de haut niveau, ce que vous avez l'intention de résoudre et ce que vous n'avez pas l'intention de résoudre.
• Niveau de détail -Un modèle n'est jamais qu'une approximation de la réalité et peut toujours être amélioré. Il est important de définir les limites de ce modèle. Par exemple, le niveau de détail d'un modèle particulier peut convenir pour comparer la productivité relative de conceptions alternatives, mais peut être insuffisant pour fournir une prédiction fiable de la productivité absolue du système.
• Exigences en matière de données- Identifier les données qui seront nécessaires pour soutenir le niveau de détail convenu. D'où viendront ces données ? Qui sera chargé de les fournir ? Quand seront-elles fournies ?
• Hypothèses et logique de contrôle -Résumez votre compréhension de la logique en divers points du système. Dressez la liste de toutes les hypothèses que vous ferez afin que vous et toutes les parties prenantes ayez une compréhension commune de la quantité de détails qui seront modélisés pour chaque partie du système. Par exemple, les détails de la répartition, de la priorité des files d'attente et de l'allocation des ressources doivent être convenus avant le début de la modélisation.
• Analyse et rapports- Déterminer qui sera impliqué dans la phase d'analyse du projet. Définir la forme et le contenu des résultats à fournir. Une maquette du rapport final est un élément important de la spécification fonctionnelle. Lors de l'examen de la maquette, les parties prenantes identifieront presque certainement des éléments manquants et des éléments inutiles. Il est préférable d'identifier ces éléments à ce stade plutôt que lors de la présentation finale du projet.
• Animations- Un certain niveau d'animation est généralement nécessaire pour le développement et la validation du modèle. Quelle est l'importance de l'animation pour les parties prenantes ? Dans de nombreux cas, les parties prenantes peuvent initialement indiquer que l'animation n'a que peu d'importance pour elles. D'après mon expérience, une fois que les parties prenantes ont vu l'animation 2D ou 3D réalisée au cours du développement, elles apprécient sa valeur en termes de communication et l'exigent par la suite comme faisant partie du produit à livrer.
• Date d'échéance et souplesse- La simulation est souvent un processus de découverte. Au fur et à mesure que vous modélisez et apprenez à connaître le système, vous trouverez de nouvelles alternatives à explorer et peut-être des zones du modèle nécessitant plus de détails. L'exploration adéquate de ces domaines peut potentiellement rendre le projet beaucoup plus utile. Mais les meilleurs résultats possibles n'ont aucune valeur s'ils sont fournis après que la décision a été prise. Quand les résultats sont-ils attendus ? Quelle est la date butoir au-delà de laquelle les résultats n'auront plus aucune valeur ? Vous pensez peut-être que votre projet n'a pas besoin d'une spécification fonctionnelle ou qu'il s'agit d'une formalité trop lourde pour un petit projet ou un projet interne. Le cahier des charges ne doit pas nécessairement être formel. Mais chaque projet a besoin d'un cahier des charges fonctionnel et sa finalisation devrait prendre environ 5 à 10 % du temps total du projet. Même un projet qui devrait être achevé en une seule journée devrait consacrer environ 30 à 60 minutes à la définition du champ d'application et des détails. Ce temps passé à réfléchir à l'avance sera largement rentabilisé à un stade ultérieur du projet.

Le développement d'un prototype au cours de la phase de spécification fonctionnelle peut s'avérer instructif pour toutes les parties. Vous découvrirez peut-être que c'est plus facile ou plus difficile que vous ne le pensiez. Même pour les projets les plus modestes, il vaut généralement la peine de montrer un modèle rapide et de poser la question suivante : "Est-ce bien ce que vous voulez dire ? Est-ce bien ce que vous voulez dire ? Vous pourriez découvrir que vous avez une compréhension totalement différente de celle des parties prenantes. Il est souvent possible de créer un prototype qui répond à un grand pourcentage des besoins exprimés par les parties prenantes. Mais dès qu'ils voient le prototype, ils se souviennent des situations complexes et de tous les autres besoins qu'ils ont négligé d'identifier auparavant.

La dernière partie de la phase de spécification fonctionnelle est l'approbation. Il doit être clair pour tout le monde que cette spécification fonctionnelle définit le projet et que le projet sera considéré comme achevé et réussi lorsque tous les aspects de la spécification fonctionnelle auront été fournis. Idéalement, la spécification finale devrait être formellement approuvée par au moins les principales parties prenantes afin d'éviter toute controverse ultérieure.

5. GÉRER LE PROJET

Bien que le meilleur moment pour commencer une étude de simulation soit très tôt dans le cycle de vie du projet associé, ce n'est malheureusement pas la situation la plus courante. Il est beaucoup plus fréquent que la simulation soit envisagée pour la première fois lorsque des problèmes sont rencontrés à la fin du cycle, peut-être peu de temps avant que les décisions finales ne soient prises. À ce stade, tout devient urgent, et il se peut même que vous soyez "en retard" avant d'avoir commencé.

Dans une telle situation, la tentation est grande de passer en mode réactif, en se laissant entraîner par l'urgence dans une direction, puis dans une autre. Et il y a toujours une pression pour sauter des étapes importantes comme décider exactement ce que l'on veut accomplir (la phase de spécification fonctionnelle). Il en résulte un flux de travail qui n'est pas optimal, voire un projet incomplet.

Gérez le projet, ne vous laissez pas gérer par lui. Un projet qui s'achève juste après que la décision a été prise n'a que peu de valeur. Il vous incombe de gérer le projet de simulation de manière à fournir des informations précieuses en temps utile. Notez les mots "informations précieuses". Toutes les simulations sont des approximations. Bien qu'une approximation proche ait plus de valeur, une approximation plus grossière peut toujours fournir des informations utiles. Si vous ne disposez pas de suffisamment de temps pour mener à bien l'ensemble du projet, sélectionnez un sous-ensemble ou une approximation plus grossière que vous pouvez mener à bien dans le temps imparti. Cela doit se refléter dans les hypothèses de la spécification fonctionnelle.

La simulation est souvent un processus de découverte. Vous acquerrez des connaissances au fur et à mesure que vous passerez de la description précise du système aux premiers résultats de la simulation. Souvent, ces nouvelles informations peuvent orienter l'étude dans de nouvelles directions. Il convient de faire preuve d'une certaine souplesse pour répondre à ces besoins ; toutefois, une trop grande souplesse peut empêcher l'achèvement du projet. Dans de tels cas, vous devez prendre la décision difficile de dire "non" à vos parties prenantes et de reporter ces demandes à une phase ultérieure du projet. Bien que personne n'aime entendre le mot "non", la plupart des parties prenantes préfèrent un "non" honnête à un "oui" trompeur qui dit en substance : "Oui, je ferai ce que vous demandez, mais il se peut que le projet ne produise pas de résultats utiles dans les délais impartis". Budgétez votre temps de manière à ce que les tâches importantes soient achevées et que le projet puisse ensuite explorer des directions imprévues.

6. COLLECTER LES DONNÉES D'ENTRÉE

La question des données d'entrée prend souvent les simulationnistes par surprise. Et il peut facilement être à l'origine de l'échec d'un projet. Avant l'avènement des ordinateurs et de l'automatisation, les données disponibles étaient généralement peu nombreuses, voire inexistantes. Aujourd'hui, il est beaucoup plus probable que vous soyez submergé par les données. Le défi consiste souvent à organiser ces données et à leur donner un sens.

Le premier défi consiste à connaître ses données. Voici un exemple simple, mais assez courant : Vous recueillez des données sur les temps d'arrêt des machines et, lorsque vous les analysez, vous constatez que le temps de réparation minimal est de 8 minutes, le temps moyen de 32 minutes et le temps maximal de 9,5 heures. Sans étude complémentaire, vous ne découvrirez peut-être pas que le temps de réparation maximal comprend également une période de 8 heures hors équipe lorsque la réparation a commencé vers la fin d'une équipe. Il serait facile d'utiliser ces données de manière incorrecte dans le modèle et de générer de mauvais résultats. Il est important de connaître vos données et leur qualité, de les débarrasser de toute donnée non valide et d'effectuer une analyse appropriée des données d'entrée.

La collecte de données pouvant être coûteuse, il convient d'évaluer les objectifs de votre étude de simulation afin de déterminer où vous avez besoin des données les plus précises. Par exemple, si vous évaluez l'utilisation des opérateurs, il est important de disposer de suffisamment de données relatives aux tâches spécifiques dont les opérateurs sont responsables. Toutefois, les données relatives à une autre partie du système n'ayant pas d'impact sur les opérateurs peuvent être approximées.

Vous pouvez également utiliser votre modèle et quelques essais pilotes pour déterminer où vous avez besoin de meilleures données en déterminant la sensibilité du modèle à différentes valeurs de données. Vous devez vérifier la sensibilité à la fois à l'ampleur (par exemple, la moyenne) et à la variabilité (par exemple, la fourchette) - si les résultats du modèle changent peu lorsque vous utilisez d'autres données d'entrée raisonnables, alors vos chiffres actuels sont peut-être suffisants. Cependant, si vous remarquez un changement significatif dans les résultats, avec un changement relativement mineur de l'ampleur ou de la variabilité, cela peut indiquer que vous devriez consacrer plus de temps et d'efforts à vous assurer que vous disposez des meilleures données possibles pour ce paramètre.

Vous avez déjà spécifié dans votre cahier des charges fonctionnel qui est responsable de la fourniture des données et quand. Il est prudent de faire savoir bien à l'avance quand vous avez besoin des données et à quel moment le projet sera retardé sans elles. Bien que vous puissiez reprocher à quelqu'un d'autre d'être à l'origine d'un projet en retard, il est de loin préférable de travailler ensemble pour garantir le respect des délais et la réussite du projet.

7. CONSTRUIRE ET VÉRIFIER LE MODÈLE (ITÉRATIF)

La construction d'un modèle est le processus de création d'une représentation du système réel qui permet d'atteindre les objectifs fixés. La vérification du modèle consiste à s'assurer que le modèle fait réellement ce que vous pensez qu'il fait. Bien que la construction et la vérification du modèle soient deux tâches différentes, elles sont couvertes par un seul sujet afin de souligner l'importance de toujours les réaliser de manière itérative.

7.1 Construction du modèle

Les novices construisent parfois une grande partie du modèle, voire le modèle entier, avant de commencer la vérification. C'est une cause importante d'échec du projet. Lorsque vous commencez à vérifier un grand modèle, il se passe tellement de choses qu'il devient difficile, voire impossible, de comprendre les interactions détaillées. Il est beaucoup plus efficace d'adopter une approche itérative : construire un élément du modèle, le vérifier, puis continuer à ajouter des éléments logiques supplémentaires au modèle. Deux approches très efficaces de la construction d'un modèle peuvent être résumées par "l'étendue d'abord" ou "la profondeur d'abord".

Dans le cas de la modélisation "en profondeur", vous pouvez construire l'ensemble du modèle ou une partie importante de celui-ci avec un niveau de détail minimal. Vous pouvez ensuite vérifier que le modèle fonctionne avant de continuer. Cette méthode présente l'avantage de générer immédiatement un modèle potentiellement utile. Votre premier essai pourrait en fait être le prototype utilisé dans la spécification fonctionnelle. Un autre avantage est que vous pouvez plus facilement obtenir les réactions des parties prenantes à partir d'un modèle complet (même s'il n'est pas entièrement détaillé), et obtenir des réactions régulières sur les points qui nécessitent plus de détails. Vous pouvez même parfois procéder à une certaine validation (dont il sera question plus loin) dans le cadre du cycle itératif.

Dans la modélisation "en profondeur d'abord", vous sélectionnez une petite section du système et la modélisez avec tous les détails requis. Vous pouvez vérifier complètement cette section du modèle et, dans le cas extrême, ne plus jamais avoir à la réviser. L'un des avantages de cette approche est la possibilité de modulariser le modèle, ce qui est particulièrement important si plusieurs personnes peuvent travailler sur le modèle en même temps. Un novice peut choisir de construire d'abord une section facile du modèle pour acquérir de l'expérience. Un simulateur plus expérimenté pourrait mettre en œuvre les sections les plus difficiles ou les plus délicates en premier lieu afin d'éliminer certains risques du projet dès le début. Un modélisateur ayant une certaine expérience "agile" pourrait commencer par les sections les plus prioritaires ou les plus importantes. Avec cette dernière approche, les aspects les plus importants du modèle sont terminés à tout moment. Cela permet de réduire le risque de manquer de temps ou de budget sans pouvoir produire de résultats significatifs.

Il est également possible de combiner les deux approches en ajoutant alternativement des détails à l'ensemble du modèle, puis en ajoutant des détails à une sous-section particulière (ou en la complétant). Mais l'aspect le plus important est d'ajouter des sections relativement petites de la logique du modèle et de vérifier chaque section avant d'en ajouter d'autres.

Dans chaque cycle de vérification, vous voulez répondre définitivement à deux questions. La section du modèle que je viens de construire fonctionne-t-elle comme je l'avais prévu (par exemple, y a-t-il des bogues dans la logique de cette nouvelle section) ? Lorsque cette nouvelle section interagit avec des sections du modèle construites précédemment, le modèle entier fonctionne-t-il toujours comme prévu (par exemple, y a-t-il des bogues dans les interactions entre les sections) ? Au fur et à mesure que votre modèle s'agrandit, vous pouvez réduire la taille de vos nouvelles sections afin de répondre plus facilement à la deuxième question.

7.2 Comment vérifier un modèle et comment isoler un problème lorsque vous en trouvez un ?

Les moyens les plus évidents de trouver et de diagnostiquer les problèmes d'un modèle sont de regarder l'animation et d'examiner les résultats de sortie. Les résultats inattendus ne sont pas un problème - ils constituent l'une des principales raisons d'effectuer une simulation. Les résultats inexplicables sont un problème. Lorsque le modèle génère un résultat inattendu, vous devez utiliser tous les outils à votre disposition pour en trouver l'explication. Dans certains cas, cela peut conduire à la découverte d'un bogue qui doit être corrigé. Dans d'autres cas, cela conduit à un moment "ah-ha" - un éclair de lumière sur le fonctionnement d'un système complexe.

La plupart des produits disposent d'une variété d'outils pour soutenir la vérification du modèle. Une trace du modèle est souvent disponible et peut fournir de nombreux détails sur ce qui se passe exactement, étape par étape, dans votre modèle. Vous pouvez commencer par observer une seule entité tout au long du processus. En règle générale, votre logiciel comporte des commandes qui vous permettent de parcourir un modèle ou d'"interrompre" l'exécution à un endroit, un moment ou une condition donnés. Il existe souvent une fenêtre de surveillance qui vous permet d'explorer l'état détaillé du système à tout moment ou pour n'importe quel objet afin de mieux comprendre ce qui se passe. Ne manquez pas non plus de tirer parti des tableaux de bord ou autres statistiques et graphiques interactifs proposés par votre logiciel. Le processus de vérification sera certainement une partie instructive et nécessaire du projet.

7.3 L'aide d'un bon auditeur

Malgré tout ce qui précède, il se peut que vous soyez confronté à une situation qui ne vous semble pas correcte, sans que vous puissiez en expliquer la raison. Il est temps de procéder à une visite guidée du modèle.

Trouvez un bon auditeur, idéalement un simulateur ou l'une de vos parties prenantes, et passez en revue toutes les sections pertinentes du modèle en lui expliquant ce qui se passe. Si votre interlocuteur est capable de comprendre ce que vous lui expliquez, c'est un plus.

Mais dans la plupart des cas, vous trouverez votre propre problème en parcourant méthodiquement les interactions. Garder cela à l'esprit ouvre de vastes possibilités pour un candidat-auditeur. Un collègue non impliqué, un conjoint ou même un animal de compagnie sont de bons candidats. Si les chiens et les chats peuvent parfois être de bons auditeurs, rien ne vaut un poisson rouge pour un auditoire captif. L'essentiel est que le fait d'expliquer votre modèle à voix haute semble ouvrir une autre partie de votre cerveau et vous permet de résoudre votre propre problème.

7.4 Comment savoir si vous avez terminé ?

Comme indiqué précédemment, un modèle n'est qu'une approximation d'un système réel. En général, le modélisateur et les parties prenantes souhaitent que le modèle soit aussi précis et complet que possible. Pour éviter les projets interminables, les retards et les dépassements de budget, vous devez revenir à votre document de spécification fonctionnelle. Votre but est de construire un modèle avec juste assez de détails pour atteindre les objectifs fixés, et pas plus !

L'animation est un domaine où il est facile de se "perdre". L'animation peut être le travail le plus amusant et le plus gratifiant du projet. Il est facile de la laisser prendre plus de temps qu'elle ne devrait. La plupart des logiciels disposent d'un certain niveau d'animation automatique. Ce niveau est généralement suffisant pour la vérification du modèle. De même, de nombreux logiciels disposent d'un certain niveau d'animation 2D ou 3D très facile à générer. Une partie de ces animations peut faciliter la validation en apportant une mesure supplémentaire de réalité et de reconnaissance par les parties prenantes. Mais là encore, il faut revenir à la section de la spécification fonctionnelle. Votre animation finale doit être juste assez bonne pour répondre aux objectifs du client identifiés précédemment, et pas plus !

8. VALIDER LES RÉSULTATS

La validation du modèle doit être effectuée pour déterminer si le modèle représente la réalité dans la mesure nécessaire pour atteindre les objectifs. Il est parfois possible de procéder à une certaine validation au cours des itérations de construction et de vérification du modèle, et il convient de profiter de chaque occasion pour le faire. Mais vous devrez toujours procéder à une validation supplémentaire du modèle achevé. Une vérification et une validation parfaites sont généralement impossibles, car le seul modèle parfait est le système réel. Il existe cependant des moyens de démontrer que le modèle est suffisamment valide pour les besoins du projet.

Une technique de validation courante consiste à commencer par un modèle du système existant (en supposant que le système réel existe). Comparez les résultats du modèle "tel quel" aux performances du système réel. Une comparaison stochastique peut prendre une période représentative (par exemple 30 jours ou 30 semaines) et comparer les résultats moyens sur cette période. Une autre approche consiste à rendre le modèle aussi déterministe que possible (par exemple, en utilisant des heures d'arrivée exactes des entités, des données exactes sur les défaillances, etc. Chacune de ces approches est utile à sa manière. Dans les deux cas, vous vous efforcerez d'identifier et d'expliquer toute différence significative.

Une autre technique de validation consiste à faire appel à l'expérience des parties prenantes. Ils connaissent bien le système et devraient être en mesure de regarder une animation et d'apporter un certain degré de confiance. Vous devez également leur donner l'occasion de voir le modèle fonctionner dans une grande variété de situations, telles qu'un volume élevé, un volume faible ou la récupération d'une panne. Idéalement, les parties prenantes devraient même être en mesure de créer elles-mêmes de telles situations, par exemple : "Je veux voir la machine A tomber en panne ... maintenant".

Si une seule partie prenante peut fournir des informations précieuses, un groupe de parties prenantes issues d'horizons différents peut apporter une valeur encore plus grande. Un ingénieur pourrait dire "Oui, vous avez saisi la conception exactement comme je l'ai décrite", ce à quoi un opérateur pourrait répondre "Peut-être, mais nous ne le ferions jamais de cette façon. Voici comment nous l'exécuterions...". À ce stade, la simulation a déjà une valeur significative en tant qu'outil de communication. Votre rôle pendant le reste de la réunion consiste à faciliter la discussion et à prendre des notes.

9. EXPÉRIMENTER, ANALYSER ET PRÉSENTER LES RÉSULTATS

Au cours de la phase d'expérimentation, vous générerez les scénarios identifiés dans le cahier des charges. Très probablement, vous aurez également besoin de quelques scénarios supplémentaires basés sur ce que vous avez appris au fur et à mesure de l'avancement du projet. Les détails de l'analyse statistique dépassent le cadre de ce document, mais une analyse statistique correcte est essentielle. Voir la section "lectures complémentaires" pour un traitement approfondi de l'expérimentation et de l'analyse statistique appropriées.

Comme pour toutes les autres parties du projet, veillez à prévoir suffisamment de temps dans le calendrier pour l'expérimentation et l'analyse. Souvent, si vous prenez du retard dans les phases de construction, de vérification ou de validation du modèle, vous risquez d'être confronté à un manque de temps pour l'analyse. Gardez à l'esprit que la raison d'être d'un projet de simulation est généralement d'analyser différents scénarios. Veillez donc à planifier en conséquence et à prévoir suffisamment de temps pour la phase d'analyse finale.

Votre objectif principal doit être d'aider les parties prenantes à prendre la meilleure décision possible compte tenu du temps et des ressources alloués. Bien que vous puissiez avoir d'autres objectifs personnels, tels que renforcer votre crédibilité ou réaliser des bénéfices, il est probable que ces objectifs seront atteints si vous vous concentrez sur l'aide à apporter aux parties prenantes.

Tenez compte des antécédents et des besoins particuliers de chaque partie prenante avant de rédiger votre rapport. Bien que vous soyez probablement fier de votre modèle et de la manière détaillée dont vous avez résolu des problèmes complexes, peu de parties prenantes partagent cet intérêt. La plupart des parties prenantes s'intéressent à trois choses. Premièrement, quelles alternatives ont été envisagées. Deuxièmement, quelles sont vos conclusions ou recommandations. Troisièmement, quelles informations complémentaires pouvez-vous fournir pour mériter leur confiance dans votre analyse.

Bien que vous deviez disposer de données pour étayer vos conclusions, ne submergez pas vos parties prenantes avec trop de détails. Essayez de fournir des informations dans le contexte nécessaire. Par exemple, au lieu de dire simplement "L'utilisation moyenne des conducteurs était de 76 %", vous pourriez dire "Étant donné que l'utilisation moyenne des conducteurs est élevée (76 %), il n'y a pas assez de temps libre pour rattraper les périodes de pointe sans causer de retards sur la ligne".

N'exagérez pas la précision des données de sortie. Reconnaissez et insistez même auprès des parties prenantes sur le fait que le modèle est une approximation et qu'il ne produira pas de réponses exactes. Affichez vos données avec une précision appropriée en fonction de la précision de vos données et des hypothèses de modélisation (par exemple, 76,2 % et non 76,2315738 %). Affichez également la précision de vos chiffres lorsque c'est possible. La plupart des parties prenantes peuvent se référer à un intervalle de confiance tel que 76,2 % ± 1,3 %.

10. RÉSUMÉ

En dépit de ce que vous avez pu entendre, il n'est pas facile de mener à bien des projets de simulation. Il existe de nombreuses façons d'échouer, même pour un simulateur expérimenté. Dans ce document, nous avons examiné certains pièges courants et les moyens de les éviter. Même si le fait de suivre ces suggestions ne vous garantira pas de faire mouche, vous aurez certainement plus de chances d'atteindre la cible.

LECTURES COMPLÉMENTAIRES

Banks, J., J. S. Carson, B. L. Nelson et D. M. Nicol. 2010. Discrete-event system simulation. 5th ed. Upper Saddle River, New Jersey : Prentice-Hall, Inc.

Law, A. M. 2007. Simulation modeling & analysis. 4e éd. New York : McGraw-Hill, Inc.

Sadowski, D. A. et M. R. Grabau. 1999. Tips for Successful Practice of Simulation. Dans Proceedings of the 1999 Winter Simulation Conference, ed. P. A. Farrington, H. B. Nembhard, D. T. Sturrock, et G. W. Evans, 60-66. Piscataway, New Jersey : Institute of Electrical and Electronics Engineers, Inc.

Sturrock, D. T., Success in Simulation, blog et discussion en cours sur .