Actas de la Conferencia de Simulación de Invierno de 2009
M. D. Rossetti, R. R. Hill, B. Johansson, A. Dunkin y R. G. Ingalls, eds.
David T. Sturrock
Simio LLC
504 Beaver St
Sewickley, PA 15143, EE.UU.
RESUMEN
Un proyecto de simulación es mucho más que construir un modelo. Y las habilidades necesarias van mucho más allá de conocer una herramienta de simulación concreta. En este artículo se analizan algunos pasos importantes para el éxito de un proyecto, así como algunas precauciones y consejos para evitar las trampas más comunes.
1. INTRODUCCIÓN
En este documento se analizan algunos aspectos de la modelización que suelen pasar desapercibidos para los simuladores noveles y aspirantes. En concreto, se ofrecen consejos y sugerencias para evitar algunas trampas comunes y garantizar el éxito del primer proyecto. Los modeladores principiantes no suelen prestar la debida atención a los cuatro primeros temas: definición de los objetivos del proyecto, comprensión del sistema, creación de una especificación funcional y gestión del proyecto. Las últimas secciones, dedicadas a la construcción, verificación, validación y presentación del modelo, ofrecen algunas ideas sobre enfoques de probada eficacia.
2. DEFINIR LOS OBJETIVOS DEL ESTUDIO
Cuando se piensa por primera vez en realizar un estudio de simulación, una de las primeras cosas que hay que tener en cuenta son los objetivos del proyecto. ¿Por qué alguien quiere simular este sistema y qué espera obtener de ello? Para ser más concretos, hay que determinar quiénes son las partes interesadas y cómo definen el éxito.
2.1 ¿Quiénes son las partes interesadas?
Una parte interesada es alguien que tiene un interés en el resultado del proyecto, alguien a quien le importa. Parece que "¿Quiénes son sus partes interesadas?" tiene una respuesta obvia: su gestor o su cliente. Pero si explora por qué alguien querría ver los resultados de este estudio, probablemente descubrirá otras partes interesadas. ¿Está intentando mejorar la productividad de la planta? Si es así, el responsable de las operaciones diarias del sistema querrá estar seguro de su exactitud. Los ejecutivos responsables de la cuenta de resultados querrán ver los resultados financieros. Los representantes de los trabajadores pueden estar interesados en los cambios en el contenido del trabajo. Si es probable que se produzcan cambios de personal, el personal de recursos humanos puede estar interesado en el estudio. Otras funciones operativas (mantenimiento) y de personal (ingeniería de procesos) también pueden estar interesadas. Incluso el departamento de marketing puede estar interesado en utilizar la animación para la promoción.
Cada proyecto tendrá diferentes partes interesadas y, obviamente, algunas estarán más interesadas que otras. Y algunas partes interesadas pueden ser más importantes que otras. Aunque es obvio que hay que satisfacer a los más importantes, no hay que ignorar a los demás. Muchas veces, la cooperación y satisfacción de las partes interesadas menos importantes puede hacer que su proyecto sea un éxito o un fracaso.
2.2 ¿Cómo definen el éxito las partes interesadas?
El grupo Pragmatic Marketing ha acuñado una frase: "Tu opinión, aunque interesante, es irrelevante". Básicamente viene a decir que la opinión del cliente (o, en este caso, de sus partes interesadas) sobre el éxito del proyecto cuenta mucho más que la suya propia. Aunque personalmente consideres que el proyecto ha sido un éxito abrumador, si tus partes interesadas más importantes lo consideran un fracaso, tu proyecto es un fracaso.
Es importante sondear a los interesados para averiguar cuáles son realmente sus necesidades y expectativas. ¿Quieren reducir personal o gastos? ¿Mejorar los beneficios? ¿Mejorar la previsibilidad o fiabilidad del sistema? ¿Aumentar la producción? ¿Mejorar el servicio al cliente? En todos los casos, debe averiguar no sólo qué valoran, sino cómo lo miden.
También conviene ser consciente de las "agendas ocultas". ¿La verdadera razón para realizar un análisis de simulación es que alguien les exigió construir un modelo? A veces, un cliente o una fuente de financiación exigirá que se construya un modelo de simulación como condición de un contrato. En este caso, el objetivo principal de la parte interesada puede ser disponer de un modelo que respalde lo que pretenden hacer de todos modos. Citando a un popular robot... "¡Peligro, Will Robinson!". Empezar con la respuesta que debes "demostrar" es una situación que hay que evitar a toda costa.
Ahora que ya sabe cómo definen (y, con suerte, miden) el éxito las partes interesadas más importantes, está listo para redactar sus objetivos de alto nivel. Este será el punto de partida para posteriores debates sobre el proyecto, de modo que todo el mundo tenga una visión compartida. Esta información también es un buen punto de partida para la especificación funcional detallada que realizará más adelante.
3. ENTENDER EL SISTEMA
Si tiene suerte, el sistema que está modelando es suyo y lo conoce bien. Lo más habitual es que, aunque el sistema pertenezca a su empresa, no lo conozca lo suficientemente bien como para modelarlo con precisión. Todos los sistemas tienen sutilezas que suelen ser importantes. Aunque no es razonable esperar que un simulador conozca todos los sistemas, un buen simulador debe conocer las preguntas importantes y ser capaz de entender las respuestas.
Una buena forma de empezar es revisar el proceso para comprender los aspectos clave. ¿Cuáles son las entidades? ¿Cómo se transforman? ¿Cuáles son las limitaciones? Si es posible, aproveche la oportunidad de recorrer literalmente las instalaciones reales o similares para descubrir cosas que podrían pasarse por alto en una discusión o revisión de diagramas.
Haga preguntas. Haga más preguntas. Haga las mismas preguntas a distintas personas y no se sorprenda si obtiene respuestas diferentes. El objetivo en esta fase no es resolver el problema, sino comprenderlo y entender el sistema lo suficiente como para poder describir y estimar el trabajo. Parte de esta fase consiste en identificar lo que no se sabe para poder dedicar tiempo y riesgo al proyecto.
4. CREAR UNA ESPECIFICACIÓN FUNCIONAL
Hay un viejo adagio que dice: "Si no sabes adónde vas, ¿cómo vas a saber cuándo llegas?". Esto es especialmente cierto en los proyectos de simulación. Una especificación funcional aclara el alcance y el nivel de detalle del modelo. Y, lo que es más importante, define claramente los entregables. Define tanto los objetivos como los entregables y determina cómo sabrá todo el mundo cuándo se ha terminado.
Una especificación funcional debe aclarar el proyecto y hacer que todo el mundo tenga un entendimiento común de los entregables. Los temas deben incluir:
- Objetivos: resuma a partir de sus objetivos iniciales de alto nivel lo que pretende resolver y lo que no.
- Nivel de detalle -Un modelo es siempre sólo una aproximación a la realidad y siempre puede mejorarse. Es importante definir los límites de este modelo. Por ejemplo, el nivel de detalle de un modelo concreto puede ser adecuado para comparar la productividad relativa de diseños alternativos, pero puede tener un nivel de detalle insuficiente para ofrecer una predicción fiable de la productividad absoluta del sistema.
- Datos necesarios: determine qué datos serán necesarios para respaldar el nivel de detalle acordado. ¿De dónde procederán estos datos? ¿Quién se encargará de proporcionarlos? ¿Cuándo se facilitarán?
- Supuestos y lógica de control -Resuma su comprensión de la lógica en varios puntos del sistema. Enumere todas las suposiciones que vaya a hacer para que usted y todas las partes interesadas tengan un entendimiento común del grado de detalle que se modelará para cada parte del sistema. Por ejemplo, antes de empezar a modelar deben acordarse los detalles del despacho, la prioridad de las colas y la asignación de recursos.
- Análisis e informes- Determine quién participará en la fase de análisis del proyecto. Defina la forma y el contenido de los resultados. La maqueta de un informe final es una parte importante de la especificación funcional. Al revisar la maqueta, es casi seguro que las partes interesadas identifiquen los elementos que faltan y los que son innecesarios. Es mucho mejor identificar estos elementos en este momento que en la presentación final del proyecto.
- Animaciones: suele ser necesario cierto nivel de animación para el desarrollo y la validación del modelo. ¿Qué importancia tiene la animación para las partes interesadas? En muchos casos, los interesados pueden indicar inicialmente que la animación tiene poca importancia para ellos. Mi experiencia general es que una vez que las partes interesadas han visto la animación 2D o 3D realizada en el desarrollo, aprecian su valor para la comunicación y más tarde la exigen como parte del entregable.
- Fecha de entrega y agilidad- La simulación suele ser un proceso de descubrimiento. A medida que modele y aprenda sobre el sistema, encontrará nuevas alternativas que explorar y, posiblemente, áreas del modelo que requieran más detalle. Explorar adecuadamente esas áreas puede hacer que el proyecto sea potencialmente mucho más valioso. Pero los mejores resultados posibles no tienen ningún valor si se obtienen después de haber tomado la decisión. ¿Cuándo se esperan los resultados? ¿Cuál es la fecha límite absoluta a partir de la cual los resultados carecerán de valor? Puede que piense que su proyecto no necesita una especificación funcional o que es demasiado formal para un proyecto pequeño o un proyecto interno. No tiene por qué ser necesariamente formal. Pero todos los proyectos necesitan una especificación funcional y finalizarla debería llevar entre un 5 y un 10% del tiempo total del proyecto. Incluso un proyecto que se espera completar en un solo día debería dedicar entre 30 y 60 minutos a definir el alcance y los detalles. Este tiempo dedicado a pensar en el futuro se amortizará con creces más adelante en el proyecto.
Desarrollar un prototipo durante la fase de especificación funcional puede ser esclarecedor para todas las partes. Puede que descubra que es más fácil o más difícil de lo que pensaba. Incluso en los proyectos más pequeños suele merecer la pena mostrar un modelo rápido y plantearse la pregunta: ¿Es esto lo que quiere decir? Puede que descubras que tienes una idea totalmente distinta a la de las partes interesadas. A menudo se puede hacer un modelo prototipo que responda a un gran porcentaje de lo que los interesados dicen que necesitan. Pero en cuanto ven el prototipo, recuerdan las situaciones complejas y todas las demás necesidades que no identificaron antes.
La parte final de la fase de especificación funcional es la aprobación. Debe quedar claro para todos que esta especificación funcional define el proyecto y que éste se considerará completo y satisfactorio cuando se hayan cumplido todos los aspectos de la especificación funcional. Lo ideal es que la especificación final sea aprobada formalmente al menos por los principales interesados para evitar controversias posteriores.
5. GESTIONAR EL PROYECTO
Aunque el mejor momento para iniciar un estudio de simulación es muy al principio del ciclo de vida del proyecto asociado, lamentablemente esa no es la situación más habitual. Es mucho más habitual que la simulación se considere por primera vez cuando los problemas se plantean en una fase avanzada del ciclo; quizás poco antes de que deban tomarse las decisiones finales. En ese momento, todo se vuelve urgente, y puede que incluso se llegue "tarde" antes de haber empezado.
En una situación así, la tentación es entrar en modo reactivo, dejando que la urgencia te arrastre primero en una dirección y luego en otra. Y siempre existe la presión de saltarse pasos importantes como decidir exactamente lo que se quiere conseguir (la fase de especificación funcional). Esto suele dar lugar a un flujo de trabajo menos que óptimo e incluso a un proyecto incompleto.
Gestiona el proyecto, no dejes que él te gestione a ti. Un proyecto que se termina justo después de tomar la decisión tiene poco valor. Parte de su trabajo consiste en gestionar el proyecto de simulación de modo que aporte información valiosa en el momento oportuno. Fíjese en las palabras "información valiosa". Todas las simulaciones son aproximaciones. Aunque una aproximación cercana tiene más valor, una aproximación más aproximada también puede aportar información valiosa. Si no hay tiempo suficiente para hacer bien todo el proyecto, seleccione un subconjunto o una aproximación más aproximada que pueda hacer bien en el tiempo asignado. Esto debe reflejarse en las hipótesis de la especificación funcional.
La simulación suele ser un proceso de descubrimiento. Irá adquiriendo conocimientos a medida que pase del esfuerzo por describir con precisión el sistema a los primeros resultados de la simulación. A menudo, esta nueva información puede mover el estudio en nuevas direcciones. Una cierta agilidad es apropiada para responder a tales necesidades; sin embargo, demasiada agilidad puede impedir la finalización del proyecto. En esos momentos, hay que dar el difícil paso de decir "no" a los interesados y aplazar esas peticiones a una fase posterior del proyecto. Aunque a nadie le gusta oír la palabra "no", la mayoría de los interesados preferirían un "no" sincero a un "sí" engañoso que básicamente dice: "Sí, haré lo que me pides, pero como resultado puede que el proyecto no arroje ningún resultado útil dentro de tu plazo". Presupueste su tiempo de modo que se completen las tareas importantes y sólo entonces permita que el proyecto explore algunas direcciones imprevistas.
6. RECOPILAR DATOS DE ENTRADA
El tema de los datos de entrada suele pillar por sorpresa a los simuladores. Y puede ser fácilmente causa de fracaso del proyecto. Antes de que aparecieran los ordenadores y la automatización, los datos disponibles eran escasos o inexistentes. Ahora, es mucho más probable que nos veamos desbordados por los datos. Organizar y dar sentido a esos datos suele ser el reto.
El primer reto es conocer los datos. He aquí un ejemplo sencillo, pero bastante común: Tal vez recopile datos sobre el tiempo de inactividad de una máquina y al analizarlos descubra que tiene un tiempo de reparación mínimo de 8 minutos, un modo de 32 minutos y un máximo de 9,5 horas. Sin un estudio adicional, es posible que no descubra que el tiempo máximo de reparación también incluía un tiempo fuera de turno de 8 horas cuando la reparación se iniciaba cerca del final de un turno. Sería fácil utilizar estos datos incorrectamente en el modelo y generar malos resultados. Es importante conocer los datos y saber hasta qué punto son buenos, "limpiarlos" de cualquier dato no válido y realizar un análisis de entrada adecuado.
Dado que la recopilación de datos puede ser costosa, deben evaluarse los objetivos del estudio de simulación para determinar dónde se necesitan los datos más precisos. Por ejemplo, si se está evaluando la utilización de los operarios, es importante disponer de suficientes datos relacionados con las tareas específicas de las que son responsables los operarios. Sin embargo, los datos relacionados con otra área del sistema sin impacto en los operarios pueden poder aproximarse.
También puede utilizar su modelo y algunas ejecuciones piloto para ayudar a determinar dónde necesita mejores datos determinando lo sensible que es el modelo a diferentes valores de datos. Debe comprobar la sensibilidad tanto a la magnitud (p. ej., la media) como a la variabilidad (p. ej., el intervalo): si los resultados del modelo apenas varían cuando se utilizan otros datos de entrada razonables, es posible que sus cifras actuales sean suficientemente buenas. Sin embargo, si observa un cambio significativo en los resultados, con un cambio relativamente menor en la magnitud o la variabilidad, puede ser una indicación de que debería dedicar más tiempo y esfuerzo a asegurarse de que dispone de los mejores datos posibles para ese parámetro.
Ya ha especificado en su pliego de condiciones quién es responsable de proporcionar los datos y cuándo. Es prudente avisar con suficiente antelación de cuándo se necesitan los datos y en qué momento se retrasará el proyecto sin ellos. Aunque usted pueda culpar a otra persona de que el proyecto se retrase, es mucho mejor trabajar juntos para que el proyecto llegue a tiempo y tenga éxito.
7. CONSTRUIR Y VERIFICAR EL MODELO (ITERATIVO)
Construir un modelo es el proceso de crear una representación del sistema real adecuada para cumplir los objetivos establecidos. Verificar el modelo es el proceso de asegurarse de que el modelo hace realmente lo que se cree que hace. Aunque la construcción y la verificación del modelo son dos tareas diferentes, se tratan en un único tema para subrayar la importancia de realizarlas siempre de forma iterativa.
7.1 Construcción del modelo
Los novatos a veces construyen una gran parte del modelo, o incluso todo el modelo, antes de empezar la verificación. Esta es una causa importante de fracaso del proyecto. Cuando se empieza a verificar un modelo grande, pasan tantas cosas que resulta difícil o imposible comprender las interacciones detalladas. Es mucho más eficaz adoptar un enfoque iterativo: construir una parte del modelo, verificarla y, a continuación, seguir añadiendo piezas adicionales de lógica al modelo. Dos enfoques muy eficaces para la construcción de modelos pueden resumirse como "primero la amplitud" o "primero la profundidad".
En la primera, se construye todo el modelo o una parte importante con un nivel mínimo de detalle. A continuación, puede comprobar que el modelo funciona antes de continuar. Esto tiene la ventaja de generar inmediatamente un modelo potencialmente útil. De hecho, la primera pasada podría ser el prototipo utilizado en la especificación funcional. Otra ventaja es que se puede obtener más fácilmente la opinión de las partes interesadas a partir de un modelo completo (aunque no totalmente detallado), así como información periódica sobre los aspectos que requieren más detalle. A veces incluso se puede realizar algún tipo de validación (que se analiza más adelante) como parte del ciclo iterativo.
En la modelización "en profundidad", se selecciona una pequeña sección del sistema y se modela con todo el detalle necesario. Esta sección del modelo se puede verificar por completo y, en el caso extremo, no hay que volver a revisarla. Una ventaja de este enfoque es la posibilidad de modular el modelo, especialmente importante si varias personas pueden trabajar en él a la vez. Un principiante puede optar por construir primero una sección sencilla del modelo para adquirir experiencia. Un simulador con más experiencia podría implementar primero las secciones más difíciles o complicadas para eliminar algunos riesgos del proyecto desde el principio. Un modelador con cierta formación "ágil" podría realizar primero las secciones más prioritarias o importantes. Con este último enfoque, en cualquier fase se habrán completado los aspectos más importantes del modelo. Esto ayuda a reducir el riesgo de agotar el tiempo o el presupuesto sin poder producir ningún resultado significativo.
Los enfoques de "primero la amplitud" y "primero la profundidad" también pueden combinarse añadiendo alternativamente algunos detalles a todo el nivel del modelo y, a continuación, añadiendo algunos detalles a (o completando) una subsección concreta. Pero lo más importante es añadir secciones relativamente pequeñas de la lógica del modelo y luego verificar cada sección antes de añadir más lógica.
En cada ciclo de verificación, hay que responder definitivamente a dos preguntas. ¿La sección del modelo que acabo de construir funciona como pretendía (por ejemplo, hay errores en la lógica de esta nueva sección)? Cuando esta nueva sección interactúa con las secciones del modelo construidas anteriormente, ¿sigue funcionando todo el modelo según lo previsto (por ejemplo, hay errores en las interacciones entre secciones)? A medida que aumente el tamaño del modelo, es posible que desee reducir el tamaño de las nuevas secciones para facilitar la respuesta a la segunda pregunta.
7.2 ¿Cómo se verifica un modelo y cómo se aísla un problema cuando se encuentra?
Las formas más obvias de encontrar y diagnosticar problemas en el modelo son observar la animación y examinar los resultados de salida. Los resultados inesperados no son un problema - son una razón principal para hacer una simulación. Los resultados inexplicables son un problema. Cuando el modelo genera un resultado inesperado, hay que utilizar todas las herramientas disponibles para encontrar la explicación. En algunos casos, esto puede llevar a descubrir un error que hay que corregir. En otros casos, se trata de un momento de iluminación sobre el funcionamiento de un sistema complejo.
La mayoría de los productos disponen de diversas herramientas de verificación de modelos. A menudo se dispone de un rastreo del modelo que puede proporcionar gran detalle sobre lo que ocurre exactamente paso a paso en su modelo. Es posible que desee comenzar observando a una sola entidad pasar por todo el proceso. Normalmente habrá controles en el software que le permitirán avanzar por el modelo o "interrumpir" la ejecución en un lugar, momento o condición determinados. A menudo habrá una ventana de observación que le permitirá explorar el estado detallado del sistema en cualquier momento o para cualquier objeto para ayudar a aclarar lo que está sucediendo. Y, por supuesto, aproveche cualquier cuadro de mando u otras estadísticas y gráficos interactivos que ofrezca su software. El proceso de verificación será sin duda una parte esclarecedora y bastante necesaria del proyecto.
7.3 La ayuda de un buen oyente
Incluso con todo lo anterior, es posible que se encuentre con una situación que no le parece correcta, pero no puede explicar por qué. Es el momento de hacer un recorrido por el modelo.
Busque un buen oyente, idealmente un simulador o una de las partes interesadas, y repase todas las secciones relevantes del modelo y explíquele lo que está pasando. Si tu oyente es capaz de entender lo que le estás explicando, es una ventaja.
Pero en un gran porcentaje de las ocasiones, encontrará su propio problema recorriendo metódicamente las interacciones. Tener esto en cuenta abre amplias posibilidades para un candidato a oyente. Un compañero de trabajo no implicado, un cónyuge o incluso una mascota son buenos candidatos. Aunque a veces los perros y los gatos pueden ser buenos oyentes, no hay nada mejor que un pececito de colores para tener una audiencia cautiva. La clave está en que explicar tu modelo en voz alta parece abrir una parte diferente de tu cerebro y te permite resolver tu propio problema.
7.4 ¿Cómo sabe cuándo ha terminado?
Como ya se ha dicho, un modelo no es más que una aproximación a un sistema real. Por lo general, el modelador y las partes interesadas desean que el modelo sea lo más preciso y exhaustivo posible. Para evitar proyectos interminables, tardíos y con un presupuesto excesivo, hay que volver al documento de especificaciones funcionales. Su objetivo es construir un modelo con los detalles suficientes para cumplir los objetivos establecidos, ¡y nada más!
La animación es un área en la que es fácil "perderse". La animación puede ser el trabajo más divertido y gratificante del proyecto. Es fácil que nos lleve más tiempo del debido. La mayoría de los paquetes tienen algún nivel de animación automática. Esto suele ser suficiente para la verificación del modelo. Del mismo modo, muchos paquetes tienen algún nivel de animación 2D o 3D que es muy fácil de generar. Esto puede facilitar la validación al proporcionar una medida adicional de realidad y reconocimiento por parte de los interesados. Pero, de nuevo, hay que volver a esa sección de la especificación funcional. La animación final debe ser lo suficientemente buena como para cumplir los objetivos del cliente previamente identificados, ¡y nada más!
8. VALIDAR LOS RESULTADOS
Es necesario validar el modelo para determinar si representa la realidad en la medida necesaria para cumplir los objetivos. A veces se puede llevar a cabo algún tipo de validación mientras se realizan las iteraciones de construcción y verificación del modelo, y se deben aprovechar todas las oportunidades que se presenten. Pero, aun así, tendrá que realizar una validación adicional del modelo terminado. La verificación y validación perfectas suelen ser imposibles porque el único modelo perfecto es el sistema real. Pero hay algunas formas de intentar demostrar que el modelo es suficientemente válido para los fines del proyecto.
Una técnica de validación habitual consiste en empezar con un modelo del sistema existente (suponiendo que el sistema real exista). Compare los resultados del modelo "tal cual" con el rendimiento del sistema real. Una comparación estocástica podría tomar un periodo representativo (por ejemplo, 30 días o 30 semanas) y comparar los resultados medios durante ese periodo. Otro enfoque consiste en hacer el modelo tan determinista como sea posible (por ejemplo, utilizar tiempos exactos de llegada de entidades, datos exactos de fallos, etc.) y comparar los resultados de ese periodo más corto. Cada uno de estos enfoques es valioso a su manera. En ambos casos, hay que esforzarse por identificar y explicar las diferencias significativas.
Otra técnica de validación consiste en recurrir a la experiencia de las partes interesadas. Conocen bien el sistema y deberían ser capaces de ver una animación y proporcionar cierta medida de confianza. También hay que darles la oportunidad de ver cómo funciona el modelo en una amplia variedad de situaciones, como gran volumen, poco volumen o recuperación tras un fallo. Lo ideal sería que los interesados pudieran incluso crear ellos mismos esas situaciones, por ejemplo: "Quiero ver cómo falla la máquina A... ahora".
Aunque una sola parte interesada puede aportar información valiosa, un grupo de partes interesadas de distintos ámbitos puede aportar un valor aún mayor. Un ingeniero puede decir: "Sí, has captado el diseño exactamente como lo describí", a lo que un operario puede responder: "Puede ser, pero en realidad nunca lo haríamos así. Así es como lo haríamos...". En ese momento, la simulación ya aporta un valor significativo como herramienta de comunicación. Tu papel en el resto de la reunión es facilitar el debate y tomar notas.
9. EXPERIMENTAR, ANALIZAR Y PRESENTAR LOS RESULTADOS
Durante la fase de experimentación generará los escenarios identificados en la especificación funcional. Lo más probable es que también necesite algunos escenarios adicionales basados en lo que ha ido aprendiendo a medida que avanzaba el proyecto. Los detalles del análisis estadístico quedan fuera del alcance de este documento, pero un análisis estadístico adecuado es fundamental. Consulte la sección de lecturas adicionales para obtener información detallada sobre la experimentación y el análisis estadístico adecuados.
Al igual que con todas las demás partes del proyecto, asegúrese de que dispone de tiempo suficiente en el calendario para la experimentación y el análisis. Muchas veces, si se retrasa en las fases de construcción del modelo, verificación o validación del proyecto, puede verse en apuros de tiempo para el análisis. Tenga en cuenta que la razón para realizar el proyecto de simulación suele ser analizar varios escenarios, así que asegúrese de planificar en consecuencia y dejar suficiente tiempo programado para la fase de análisis final.
Su objetivo principal debe ser ayudar a las partes interesadas a tomar la mejor decisión posible teniendo en cuenta el tiempo y los recursos asignados. Aunque pueda tener otros objetivos personales, como ganar credibilidad u obtener beneficios, es probable que esos objetivos se cumplan si se concentra en ayudar a las partes interesadas.
Considera los antecedentes y las necesidades particulares de cada parte interesada antes de crear tu informe. Aunque probablemente esté orgulloso de su modelo y de la forma detallada en que resolvió problemas complejos, pocas partes interesadas compartirán ese interés. A la mayoría le interesan tres cosas. En primer lugar, qué alternativas se consideraron. En segundo lugar, cuáles son sus conclusiones o recomendaciones. En tercer lugar, qué información de apoyo puede aportar para que confíen en su análisis.
Aunque debe disponer de datos que respalden sus conclusiones, no abrume a los interesados con demasiados detalles. Intente proporcionar la información en el contexto necesario. Por ejemplo, en lugar de limitarse a decir "La utilización media de los conductores fue del 76%", podría decir "Dado que la utilización media de los conductores es alta (76%), no hay tiempo de holgura suficiente para recuperar el tiempo perdido durante los periodos punta sin provocar retrasos en la línea".
No exagere la exactitud de los datos de salida. Reconozca e incluso recalque a las partes interesadas que el modelo es una aproximación y que no generará respuestas exactas. Muestra los datos con la precisión adecuada en función de la exactitud de los datos y los supuestos de modelización (por ejemplo, 76,2%, no 76,2315738%). Y muestre la exactitud de sus cifras siempre que sea posible. La mayoría de las partes interesadas pueden entender un intervalo de confianza del tipo 76,2% ± 1,3%.
10. RESUMEN
A pesar de lo que pueda haber oído, hacer bien los proyectos de simulación no es fácil. Incluso un simulador experimentado puede fracasar de muchas maneras. En este documento hemos analizado algunas trampas comunes y las formas de evitarlas. Aunque seguir estas sugerencias no le garantizará dar en el blanco, sin duda mejorará sus posibilidades de dar en la diana.
LECTURAS ADICIONALES
Banks, J., J. S. Carson, B. L. Nelson y D. M. Nicol. 2010. Simulación de sistemas de eventos discretos. 5th ed. Upper Saddle River, Nueva Jersey: Prentice-Hall, Inc.
Law, A. M. 2007. Simulation modeling & analysis. 4th ed. New York: McGraw-Hill, Inc.
Sadowski, D. A. y M. R. Grabau. 1999. Consejos para practicar con éxito la simulación. En Proceedings of the 1999 Winter Simulation Conference, ed. P. A. Farrington, H. B. Nembhard y M. R. Grabau. P. A. Farrington, H. B. Nembhard, D. T. Sturrock, y G. W. Evans, 60-66. Piscataway, Nueva Jersey. Piscataway, Nueva Jersey: Instituto de Ingenieros Eléctricos y Electrónicos, Inc.
Sturrock, D. T., Success in Simulation, Blog y debate en curso en .
Descargar versión PDF