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.