Tutorial: Consejos para una práctica exitosa de la simulación

El desafío

por David Sturrock (Simio LLC)

Tal y como se presentó en la Conferencia de simulación de invierno de 2015

Un proyecto de simulación es mucho más que construir un modelo y las habilidades necesarias para el éxito van mucho más allá de conocer una herramienta de simulación concreta. Un veterano de 30 años analiza algunos pasos importantes para permitir el éxito del proyecto y algunas precauciones y consejos para ayudar a evitar trampas comunes. Este contenido es similar a las presentaciones realizadas en anteriores conferencias del WSC.

Introducción

En esta ponencia 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 de su 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 una visión de algunos enfoques probados.

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 específico, debe determinar quiénes son las partes interesadas y cómo definen el éxito.

¿Quiénes son las partes interesadas?

Unaparte interesada es alguien que tiene un interés en el resultado del proyecto, alguien a quien le importa. Parece que "¿Quiénes son tus partes interesadas?" tiene una respuesta obvia: tu jefe o tu 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 la satisfacción de las partes interesadas menos importantes pueden hacer que su proyecto sea un éxito o un fracaso.

¿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 tus partes interesadas) sobre el éxito del proyecto cuenta mucho más que la tuya. Aunque tú personalmente consideres que el proyecto ha sido un éxito rotundo, 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, hay que averiguar no sólo qué valoran, sino cómo lo miden y cómo quieren ver los resultados.

También conviene ser consciente de cualquier "agenda oculta". ¿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.

Sabiendo cómo definen (y, con suerte, miden) el éxito las partes interesadas más importantes, ya 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.

La solución

Comprender 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 suficiente 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 manera 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 etapa consiste en identificar lo que no se sabe para poder dedicar tiempo y riesgo al proyecto.

Crear una especificación funcional

Hay un viejo adagio que dice: "Si no sabes adónde vas, ¿cómo vas a saberlo cuando llegues?". Esto es especialmente cierto en los proyectos de simulación. Una especificación funcional aclara el alcance del modelo y el nivel de detalle. 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 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 proporcionar una predicción fiable de la productividad absoluta del sistema.
• Requisitos de datos: 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 de la cantidad de detalles que se modelarán para cada parte del sistema. Por ejemplo, los detalles de despacho, prioridad de colas y asignación de recursos deben acordarse antes de empezar a modelar.
• Análisis e informes - Determine quién participará en la fase de análisis del proyecto. Determine la forma y el contenido de los resultados que se entregarán. La maqueta del 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 los interesados 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 unos 30-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. De hecho, es mejor no pensar que se trata de tiempoextradedicado al principio del proyecto, sino detrasladartareas seleccionadas de la fase final del proyecto a la fase inicial. Por ejemplo, en algún momento habrá que determinar qué datos se necesitan y de dónde van a proceder, por lo que trasladar ese paso al principio del proyecto tiene importantes ventajas.

Desarrollar un prototipo durante la fase de especificación funcional puede ser instructivo 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 plantear 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 interesadosdicenque necesitan. En cuanto ven el prototipo, recuerdan las situaciones complejas y todas lasdemásnecesidades que no identificaron antes.

La parte final de la fase de especificación funcional es la aprobación. Hay que dejar claro a todo el mundo 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.

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, desgraciadamente esa no es la situación más habitual. Es mucho más común que la simulación se considere por primera vez cuando los problemas se plantean tarde en el 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 justodespués detomar 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 puede proporcionar una visió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 las partes interesadas 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.

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 algunos datos sobre tiempos de inactividad de las máquinas y, al analizarlos, descubra que tienen 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 datos no válidos y realizar un análisis adecuado de los datos de entrada.

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 ser aproximados. Algunos programas informáticos contienen funciones que le ayudan a evaluar el impacto de los parámetros de entrada en las respuestas de salida y le recomiendan dónde realizar esfuerzos adicionales de recopilación de datos.

También puede utilizar su modelo y algunas ejecuciones piloto para determinar dónde necesita mejores datos, determinando la sensibilidad del 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 cambian poco cuando utiliza otros datos de entrada razonables, puede 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 debe 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 se pueda culpar a otra persona por el retraso del proyecto, es mucho mejor trabajar juntos para garantizar que el proyecto llegue a tiempo y tenga éxito.

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 realmente hace 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.

Construcción del modelo

Los principiantes 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 laprimera, 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 más experimentado 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 verificar cada sección antes de añadir más lógica.

En cada ciclo de verificación, se quiere responder definitivamente a dos preguntas: ¿La sección del mod- el 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.

Esto es difícil...

A muchos proveedores de simulación les gustaría que pensaras que modelar es fácil, si sólo eliges sus productos. Para ser justos, algunas herramientas son más fáciles de usar que otras, y algunas herramientas son más fáciles de usar en aplicaciones específicas que otras. Pero rara vezes fácilconstruir un modelo complejo con el detalle adecuado para resolver eficazmente el problema. Incluso el simulador más experimentado suele tener dificultades para resolver algunos problemas. Una parte importante del esfuerzo de modelización suele dedicarse a resolver problemas de modelización.Pero por eso los modelizadores están tan bien pagados (o al menos los modelizadores desearíamos que lo estuvieran).

Pero "quien avisa, vale por dos". Planifique con tiempo las cosas que pueden ir mal durante el modelado, porque a menudo lo harán. Una ventaja obvia de un usuario experto es el conocimiento de las herramientas: la capacidad de construir un modelo con rapidez y precisión. Una ventaja relacionada, más sutil, es saber utilizar las herramientas para identificar, aislar y erradicar los errores del modelo. La mayoría de los productos tienen algún nivel de herramientas de depuración. Cuando pueda elegir, elija un producto con las mejores herramientas de depuración posibles. A continuación, tómese el tiempo necesario para aprender a utilizar esas herramientas de forma eficaz (consulte la siguiente sección).

¿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 de modelo sonobservar la animaciónyexaminar cuidadosamente los resultados de salida. La mayoría de los productos también disponen de otras herramientas de ayuda para la verificación del modelo. A menudo se dispone deun seguimiento del modeloque puede proporcionar gran detalle sobre lo que ocurre exactamente paso a paso en su modelo. Es posible que desee empezar por ver una sola entidad pasar por todo el proceso. Normalmente, habrá controles en el software que le permitiránrecorrerun modelo ointerrumpir la ejecuciónen un lugar, momento o condición determinados. A menudo habrá una ventana deobservaciónque 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 cualquiercuadro de mandou otrasestadísticas y gráficos interactivosque ofrezca su software.

El proceso de verificación será sin duda una parte esclarecedora y bastante necesaria del proyecto. Los resultados inesperados no son un problema: indican el aprendizaje, que es la 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, eso puede llevar a descubrir un error del modelo que hay que corregir. En otros casos, se trata de un momento "ah-ha", un rayo de luz sobre el funcionamiento de un sistema complejo.

La ayuda de un buen oyente

Incluso con todo lo anterior, es posible que se encuentre con una situación que no parece correcta, pero no puede explicar por qué. Es hora 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 y hacer preguntas, eso es una ventaja. Pero en un gran porcentaje de las ocasiones,encontrará su propio problemarecorriendo 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 es que explicar tu modelo en voz alta parece abrir una parte diferente de tu cerebro y te permite resolver tu propio problema.

¿Cómo se sabe cuándo se 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 lo suficientemente bueno 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!

El impacto en la empresa

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 realizar algún tipo de validación durante la construcción del modelo y las iteraciones de verificación, y hay que aprovechar todas las oportunidades que se presenten para ello, pero aún así habrá 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 maneras de 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) y comparar 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 un gran volumen, un bajo volumen o la recuperación de 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".

Si bien una sola parte interesada puede aportar información valiosa, un grupo de partes interesadas de distintos ámbitos puede aportar un valor aún mayor. Quizá un ingeniero diga: "Sí, has captado el diseño exactamente como lo describí", a lo que un operario podría 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.

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. No es raro empezar con el objetivo de evaluar cuatro escenarios, pero descubrir por el camino que uno de ellos ya no tiene sentido, pero que dos escenarios adicionales son ahora dignos de con- tendencia. Se trata de un resultado natural del aprendizaje y la mejora de la comprensión que son el resultado de la mayoría de los estudios de simulación.
Los detalles del análisis estadístico quedan fuera del alcance de este documento, pero un análisis estadístico adecuado es fundamental. Es lamentable, pero cierto, que los modelos de simulación se basen a menudo en estimaciones de los datos de entrada (por ejemplo, "creo que suele requerir entre 5 y 9 minutos") y en muestras inadecuadas ("basándonos en los 12 casos que observamos..."). Busque funciones de software que le ayuden a comprender cómo influyen estas estimaciones en la precisión de sus resultados. En la sección de lecturas adicionales encontrará un tratamiento exhaustivo de 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 ponerse al día 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. Presenta los datos con la precisión adecuada en función de la exactitud de los datos y los supuestos del modelo (por ejemplo, 76,2%, no 76,2315738%). La mayoría de las partes interesadas pueden entender un intervalo de confianza del tipo 76,2% ± 1,3%.

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.