NO APLIQUE LA SIMULACIN CUANDO...

10 reglas para determinar cuando la simulacin no es apropiada.

Los modelos de simulacin se han convertido en un herramienta para analizar anticipadamente

lo que se va a ejecutar , validar diseos, demostrar y visualizar operaciones, prueba de hiptesis

y realizar muchos otros anlisis. La simulacin es la herramienta preferida en una variedad de

industrias y en algunas la simulacin es requerida primeramente para las inversiones de gran

capital. En algunos artculos previos hemos discutido el como de los modelos de simulacin,

como iniciarse en la simulacin, como seleccionar software, como administrar un proyecto

exitoso entre otras cosas. Las suposiciones de estos anteriores artculos, son que los modelos de

simulacin son la herramienta correcta para el problema que se quiera resolver.

Una pregunta que varias veces pasa desapercibida pero que debe realizarse es la siguiente: Es

la simulacin la herramienta correcta para el problema? Este artculo presenta casos en que la

simulacin es inapropiada. En el pasado, los modelos de simulacin se reservaban solo para

proyectos muy largos o especializados que requeran uno o ms programadores o analistas con

entrenamiento especializado y mucha experiencia. La reciente proliferacin de software para

simulacin ha guiado a un incremento significante en las aplicaciones, muchas por usuarios sin

un entrenamiento apropiado o experiencia. Tambin ha guiado a una creciente dependencia

sobre la simulacin para resolver una variedad de problemas.

Aunque muchos de estos proyectos son exitosos, la herramienta puede ser y a veces es aplicada

errneamente. Nos preocupa que esto nos pueda llevar hacia un proyecto no exitoso y ese

modelo de simulacin o el software pueden estar siendo aplicados errneamente. Una

conciencia para cuando los requerimientos de problemas cuantitativos o cuando las dinmicas

de problemas cualitativos indican que la simulacin no es la apropiada puede ayudar a evitar

este error. En este artculo presentamos algunos puntos a considerar antes de seleccionar la

herramienta de anlisis para su siguiente proyecto.

1. EL PROBLEMA PUEDE SER SOLUCIONADO UTILIZANDO EL SENTIDO COMN.

Considere el siguiente ejemplo:

Una unidad etiquetadora de automviles est siendo diseada, los clientes llegan aleatoriamente

para comprar sus etiqueta de automvil a un ritmo de 100 por hora. El tiempo promedio de una

cajera para atender a un cliente es de 5 minutos. Cul es el nmero mnimo de cajeras

requeridas?

El rango de utilizacin r = 1/cm, donde:

l = tasa de llegada (100 hr)

= tasa de servicio ( 12 hr)

c = Servidores (la cantidad desconocida)

Para evitar condiciones de explosin, P>1. Por lo tanto es menor que c * : c > / c > 100/

12 = 8.3 por lo tanto al menos 9 empleados sern necesario para evitar una situacin de

explosin. Mientras ms empleados haya menos ser el tiempo promedio de espera. Este

problema pudo haber sido analizado por simulacin, pero es innecesario y tomara ms tiempo

programar y llevar a cabo que la solucin anterior.

2. EL PROBLEMA PUEDE SER SOLUCIONADO ANALTICAMENTE.

Existen modelos de colas estables, modelos de inventarios probabilsticas, y otros que pueden

ser resueltos usando ecuaciones, por ejemplo, en una forma cerrada, y este es un mtodo mucho

ms barato comparado con la simulacin. Este mtodo es llamado M/M/S donde la primera M

indica que las llegadas son de tipo Markovi, la segunda M indica que los servidores son de tipo

Markovi. Markovi es otra manera de decir que los valores estn exponencialmente distribuidos.

Se puede usar una ecuacin para determinar la probabilidad de que el sistema est vaco, del

cul se puede obtener el nmero promedio en el sistema. F. S. Hillier y G.J. Liberman

desarrollaron una grfica para sacar los mismos resultados. Usando esa grfica, el nmero

promedio en el sistema, L es 10.77. Las siguientes ecuaciones relacionan L y W, que

determinan el tiempo en el sistema:

L = W W = L / W = 10.77 / 100 W = 0.1077 horas.

Los clientes tienen que esperar tanto haciendo fila como durante el servicio. Esto es:

Wq = W 1/

Donde:

1/ es el tiempo promedio de servicio, o 1/12 horas.

Entonces Wq = 0.1077 0.0833 Wq = 0.02444 horas.

Esto es ciertamente un anlisis ms rpido que la simulacin.

3. ES MS FACIL CAMBIAR O REALIZAR EXPERIMENTOS DIRECTOS EN LA

REALIDAD.

Esto puede parecer obvio, pero no siempre, Hemos visto casos en el que un modelo ser

comisionado para resolver un problema, y de hecho se necesita ms tiempo y dinero para

realizarlo que un experimento hubiera requerido. Considere el caso ( uno verdadero ) en el que

un modelo detallado de un restaurante de autoservicio de comida rpida que fue construido y

usado para probar mejoras en el tiempo de servicio al cliente aadiendo una segunda ventanilla

de servicio. El modelo tom semanas para completarse. Nosotros observamos a otro

competidor con el mismo concepto. Estando otra persona con control manual y un altavoz a un

lado de la lnea de la ventanilla de servicio, el competidor complet el estudio en pocos das.

La regla en esta ocasin es que si el problema envuelve al sistema existente el cual puede ser

observado o medido sin ninguna secuencia. Primero, hay que ver directamente los

experimentos para contestar las preguntas, por lo siguiente los experimentos directos nos

previenen de todas las preguntas, por lo siguiente los experimentos directos nos previenen de

todas las preguntas relacionadas de cmo el modelo fue detallado o positivamente validado, etc.

4.EL COSTO DE SIMULACIN EXCEDE LOS POSIBLES AHORROS.

Por eso casi todos los proyectos de simulacin tienen muchas cualidades benficas, gastos de

modelos, coleccin de datos el anlisis es usualmente justificado por lo esperado en las

cantidades de la prueba, el desarrollo estimado del total de los costos del proyecto de simulacin

requiere algunas experiencias. Factores que se deben considerar:

Planeacin de proyectos, definicin de problemas y documentos de proceso.

Desarrollo de modelos y pruebas.

Coleccin de datos.

Repasos de formatos.

Validacin de modelos.

Experimentos y anlisis.

Posibles fechas/mejoramiento del modelo, y nuevas pruebas, etc.

Documentacin del proyecto y presentacin.

Tambin se deben de considerar los costos de simulacin de software y recursos de

computadora, la simulacin de problemas complejos pueden estar fcilmente dentro de

miles de dlares. Modelos largos, con operaciones complejas de procedimientos lentos y

de control logstico ( como un centro de distribucin grande ) o con la necesidad de usar

datos reales ( histricos ) o de actual localizacin de productos y cantidades, pueden

elevar el costo aun

ms alto. Generalmente el costo de los proyectos de simulacin es comparado

potencialmente como ahorros o en costos de prevencin. Si los ahorros potenciales no son

claramente ms grandes que los costos de simulacin estimados, el modelo no se puede

justificar. Por lo tanto algunos modelos de simulacin son descartados por el riesgo

percibido por sistemas que son demasiado complejos de entender. El modelo provee un

nivel de seguridad para ver si y cuando los posibles problemas surgen. Puede un precio

ser calculado para esta reduccin de riesgo?

5. NO EXISTEN RECURSOS PROPIOS DISPONIBLES PARA EL PROYECTO.

Los recursos requeridos para completar una simulacin exitosa incluye gente, software,

hardware y dinero, el componente ms crtico para la simulacin es la gente, analistas

experimentados que entienden el problema, el nivel adecuado de detalle traducirlo a un

modelo de simulacin requerido y programar el modelo.

Simulacin es un arte y una ciencia, entendindose por arte la experiencia obtenida y por

ciencia lo obtenido por un entrenamiento apropiado. El software de simulacin, ahora

ampliamente existente, realmente ayuda, pero no es un sustituto para los recursos humanos

adecuados para un proyecto. Si no se cuenta con un modelador de simulacin con

experiencia es ms recomendable buscarlo en una empresa externa, ya que se pone en

riesgo monetario el proyecto, debido a la incapacidad del modelo de proveer los resultados

requeridos.

6. NO HAY SUFICIENTE TIEMPO PARA QUE EL MODELO RESULTE TIL.

Otra clase de recursos insuficientes es el tiempo. Este es usualmente causado por una de

las siguientes tres razones:

El horario del proyecto es demasiado corte.

El desarrollo del modelo y las pruebas toman demasiado tiempo.

La ventana es demasiado angosta.

Esto es muy frustrante, pero es un problema muy comn: Has trabajado mucho para

completar un modelo, verificado cuidadosamente o validado, y se esta en medio d varios

experimentos cuando te dicen Se a tomado una decisin para seguir con las instalaciones

porque no tuvimos tiempo para esperar los resultados de la simulacin. Los estudios de

simulacin tienen hacer de ultimo minuto. Muy seguido el programa ese poco realista va a

hacer muchas asunciones, brincarse detalles o hacer cortes de proceso para alcanzar al

horario. Como sabes si un detalle critico fue dejado y los resultados no son significativos?

Ningn libro de texto puede definir el nivel de detalle que se de llevar, esto esta basado en la

experiencia.

Seguid, cuando vemos un proyecto de simulacin pasarse del programa destinado

podemos culpar a un analista con poco experiencia trabajando en la solucin. Un modelo de

simulacin debe ser lo suficientemente detallado para que las cuestiones puedan ser

contestadas, pero no demasiado detalladas. Un error tpico para una persona sin experiencia

es empezar con muchos detalles, lo cual invariablemente toma ms para desarrollar y probar

de las mximas de la simulacin: si los resultados no son usados el proyecto puede ser

considerado como un error. Seria mejor no usar la simulacin si no hay suficiente tiempo

para producir resultados y ponerlos en practica.

7. NO HAY INFORMACIN- NI SIQUIERA ESTIMADOS.

Durante la fase del diseo de una simulacin de proyectos, una de las tareas ms crticas es

determinar si la informacin requerida para alcanzar las expectativas del proyecto y soportar el

nivel de detalle planeado para el modelo estn disponibles si no como pueden ser obtenidas, en

algunos casos la informacin puede que no este disponible o ser imposible, impractica o

demasiado cara para obtener, no cometa el error de empezar a construir un modelo antes de

checar si la informacin necesaria esta disponible, la tentacin ser seguir con el anlisis de

cualquier forma, si ya se gasto en construir un modelo y ya se tiene a la gente. Es posible

realizar pruebas de sensibilidad, utilizando informacin estimada, pero se requieren

estimaciones muy apegadas a la realidad.

7. EL MODELO NO PUEDE SER VERIFICADO O VALIDADO.

Este problema es usualmente ( otra vez ) por la falta de uno de uno de los tres ingredientes

crticos: gente, informacin y tiempo.

El analista del proyecto puede no entender como verificar el modelo (ya que requiere

entrenamiento y/o experiencia).

No tiene informacin para comparar con los resultados para validarlo.

El programa del proyecto no tiene suficiente tiempo para pruebas y/o actividades de

validacin.

El procedimiento correcto es primero completar el escenario del caso base, comparando los

resultados del modelo contra aquellos del sistema real ( o lo esperado del sistema real), despus

hay que usar ste caso para comparar futuras pruebas. Hay muchos otros mtodos que pueden

ser utilizados an si no tenemos datos para el caso base; unos pocos son como sigue:

La prueba de decadencia. Esta prueba se utiliza para ver si el comportamiento del

modelo es apropiado para usos extremos. Qu pasa cuando los limites son realmente

altos?, Cmo responde el modelo?, Descubrieron lo que esperan?.

La prueba de validacin de fase. Esta prueba simplemente se aplica el sentido comn

para analizar las salidas del modelo para el caso base. Es la salida razonable?,

Podemos explicar la conducta del modelo basada en experiencias con sistemas

similares?.

La prueba de anlisis de sensibilidad. Para casos de prueba repetitivas con diferentes

valores de entrada. Cambian las salidas en la direccin anticipada? Estos

procedimientos de prueba pueden ayudar a construir confianza en el modelo. Si el

modelo no propiamente verificado y validado, los resultados sern cuestionados y

pueden no ser aceptados.

9. LAS EXPECTATIVAS DEL PROYECTO NO SE PUEDEN CONOCER.

Con 9 de 10 fallas fuera, pueden conocer las expectativas del proyecto dos de las fallas que

harn la decisin acerca de cual es la realidad y posiblemente cuando se resuelva el problema

con un modelo de simulacin. Puede tener el controlador expectativas sin razones?

Usualmente ellos tambin esperan mucho y tambin rpido, cuando esto no puede ser entregado

ellos pueden equivocarse con la tecnologa de simulacin o del analista. Aqu esta otra versin

del problema:

La gente que no tiene experiencia en simulacin antes de concluir una vez el sistema es

modelado, el modelo puede responder cualquier pregunta que ellos hagan esto puede ser difcil

de explicar especialmente en un proyecto, despus estos modelos son capaces de responder solo

preguntas explcitas que sean designadas con direccin. Recordando una de las 10 veces, el

analista sobrestima en su propia capacidad la capacidad del software.

10. EL COMPORTAMIENTO DEL SISTEMA ES TAMBIN COMPLICADO O NO PUEDE SER DEFINIDO.

El sistema a simularse debe ser minuciosamente entendido antes de la simulacin, o el analista

ser forzado a analizar o a ser creativo. Algunos sistemas son tan complicados, que construir

un modelo un modelo preciso o exacto ( entre un horario y presupuesto aceptable ), no es

posible. Esto pasa regularmente cuando la conducta humana es una presente crtica del sistema

simulado. Por ejemplo, debido a que los centros de distribucin automtica moderna son

complicados, son frecuentemente simulados dando prioridad a la implementacin o

modificacin. Muchos son manejados por el sistema de manejo computarizado warehouse (

MMS ) software, la cul selecciona y combina rdenes al proceso, casi todas las rdenes de

proceso actual (recolectando), es perfeccionada manualmente y las personas tienen la facilidad

para ello an si son facilidades automticas.

Comnmente el escenario simulado es un da promedio, y los resultados del modelo pueden ser

muy precisos o exactos. Pero en una facilidad real cuando un evento inusual ocurre y las

rdenes empiezan a caer detrs de los horarios, las personas cambiarn su conducta normal o

sus actividades para encontrar un camino alrededor del sistema, concentradamente en un intento

de conocer los horarios. sta conducta puede ser muy variada y virtualmente imposible

describirla completamente y simularla para todos los escenarios posibles.

Los resultados del modelo para stos escenarios, casos de caos, casi nunca combinan con lo que

ocurre en el sistema real, y simplemente son no realizables.

CONCLUSIONES

La simulacin puede ser una poderosa herramienta de anlisis que intenta ser reconocida en

algunas industrias como una solucin universal. Cada problema no es como un clavo con

simulacin del martillo! Tal vez por la variedad de historias exitosas en aos recientes ( de otra

forma problemas impalpables ), o tal vez por la disponibilidad de los paquetes de software

simulados con la ventaje de que cualquiera puede usarlos. La simulacin es frecuentemente la

nica herramienta considerada . No todos stos proyectos tienen una conclusin exitosa. La

simulacin es a menudo culpada, cuando de hecho fue slo mal aplicada.

Los proyectos de simulacin cuestan dinero y pueden producir una significante devolucin de

inversin cuando es conducida adecuadamente. Si el proyecto es exitoso, entonces el dinero es

bien gastado y promover la tecnologa. Si el proyecto no es exitoso, lastimara la reputacin de

la simulacin y asociado con esto, afecta a cada uno de nosotros. No te comprometas a un

proyecto de simulacin si no se necesita o si hay una posibilidad real de que no pueda ser

completado propiamente, no puede ser conocido el objetivo del proyecto y expectativas, o los

resultados no estarn disponibles en el tiempo de uso. Cada analista tiene una responsabilidad

de hacer cada proyecto exitoso, para ayudar a continuar con el uso y aceptacin del modelo de

simulacin.