Dicas para uma prática bem-sucedida de simulação

Anais da Conferência de Simulação de Inverno de 2009

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

Simio LLC
504 Beaver St
Sewickley, PA 15143, EUA

RESUMO

Um projeto de simulação é muito mais do que construir um modelo. E as habilidades necessárias vão muito além do conhecimento de uma ferramenta de simulação específica. Este documento discute algumas etapas importantes para permitir o sucesso do projeto e alguns cuidados e dicas para ajudar a evitar armadilhas comuns.

1. INTRODUÇÃO

Este documento discute alguns aspectos da modelagem que muitas vezes passam despercebidos pelos simuladores novos e aspirantes. Em particular, são fornecidas dicas e conselhos para ajudá-lo a evitar algumas armadilhas comuns e garantir que seu primeiro projeto seja bem-sucedido. Os quatro primeiros tópicos que tratam da definição dos objetivos do projeto, da compreensão do sistema, da criação de uma especificação funcional e do gerenciamento do projeto geralmente recebem atenção inadequada dos modeladores iniciantes. As últimas seções, que tratam da criação, verificação, validação e apresentação do modelo, oferecem alguns insights sobre algumas abordagens comprovadas.

2. DEFINA OS OBJETIVOS DO ESTUDO

Quando você pensa pela primeira vez em realizar um estudo de simulação, uma das primeiras coisas a considerar são os objetivos do projeto. Por que alguém quer simular esse sistema e o que espera obter com isso? Para ser mais específico, você deve determinar quem são as partes interessadas e como elas definem o sucesso.

2.1 Quem são suas partes interessadas?

Uma parte interessada é alguém que tem interesse no resultado do projeto, alguém que se importa. Parece que a pergunta "Quem são suas partes interessadas?" tem uma resposta óbvia: seu gerente ou seu cliente. Mas se você explorar por que alguém gostaria de ver os resultados desse estudo, provavelmente descobrirá outras partes interessadas. Você está tentando melhorar a produtividade da fábrica? Nesse caso, o gerente responsável pelas operações diárias do sistema vai querer ter certeza de que os resultados são precisos. Os executivos responsáveis pelo resultado final desejarão ver os resultados financeiros. Os representantes dos trabalhadores podem se interessar pelas alterações no conteúdo do trabalho. Se houver probabilidade de mudanças na equipe, o pessoal de recursos humanos pode se interessar pelo estudo. Várias outras funções de operações (manutenção) e de equipe (engenharia de processos) também podem se interessar. Até mesmo o departamento de marketing pode se interessar em usar a animação para promoção.

Cada projeto terá diferentes participantes e, obviamente, alguns deles terão mais interesse do que outros. E algumas partes interessadas podem ser mais importantes do que outras. Embora seja óbvio que as partes interessadas mais importantes devam ser satisfeitas, não ignore as outras. Muitas vezes, a cooperação e a satisfação das partes interessadas menos importantes podem ser decisivas para o sucesso ou fracasso de seu projeto.

2.2 Como as partes interessadas definem o sucesso?

O grupo de Marketing Pragmático cunhou a frase "Sua opinião, embora interessante, é irrelevante". Basicamente, isso significa que a opinião do cliente (ou, nesse caso, de suas partes interessadas) sobre o sucesso do projeto conta muito mais do que a sua. Mesmo que você considere pessoalmente que o projeto foi um grande sucesso, se as partes interessadas mais importantes o considerarem um fracasso, seu projeto será um fracasso.

É importante sondar seus participantes para descobrir quais são realmente suas necessidades e expectativas. Eles querem reduzir o número de funcionários ou as despesas? Aumentar os lucros? Melhorar a previsibilidade ou a confiabilidade do sistema? Aumentar a produção? Melhorar o atendimento ao cliente? Em todos os casos, você precisa descobrir não apenas o que eles valorizam, mas também como eles medem isso.

É aconselhável também estar ciente das "agendas ocultas". O motivo real para a realização da análise de simulação é o fato de alguém ter exigido a criação de um modelo? Às vezes, um cliente ou uma fonte de financiamento exige a criação de um modelo de simulação como condição de um contrato. Nesse caso, o objetivo principal da parte interessada pode ser ter um modelo que dê suporte ao que ela pretende fazer de qualquer maneira. Para citar um robô popular... "Perigo, Will Robinson!" Começar com a resposta que você deve "provar" é uma situação que deve ser evitada a todo custo.

Sabendo como seus participantes mais importantes definem (e, com sorte, até medem) o sucesso, agora você está pronto para escrever seus objetivos de alto nível. Esse será o ponto de partida para outras discussões sobre o projeto, de modo que todos tenham uma visão compartilhada. Essas informações também são um bom começo para a especificação funcional detalhada que será feita posteriormente.

3. ENTENDA O SISTEMA

Se você tiver sorte, o sistema que está modelando é seu e você o conhece bem. Normalmente, mesmo que o sistema seja de propriedade da sua empresa, você não o conhece bem o suficiente para modelá-lo com precisão. Todo sistema tem sutilezas que geralmente são importantes. Embora não seja razoável esperar que um simulador conheça todos os sistemas, um bom simulador deve saber as perguntas importantes a serem feitas e ser capaz de entender as respostas.

Uma boa maneira de começar é revisar o processo para que você entenda os principais aspectos. Quais são as entidades? Como elas estão sendo transformadas? Quais são as restrições? Se possível, aproveite a oportunidade de percorrer literalmente a instalação real ou semelhante para descobrir aspectos que podem passar despercebidos em uma discussão ou revisão de diagrama.

Faça perguntas. Faça mais perguntas. Faça as mesmas perguntas a pessoas diferentes e não se surpreenda se receber respostas diferentes. Seu objetivo nesta etapa não é resolver o problema, mas entender o problema e o sistema o suficiente para poder descrever e estimar o trabalho. Parte desse estágio é identificar o que você não sabe para que possa reservar tempo e riscos no projeto para esse esclarecimento.

4. CRIAR UMA ESPECIFICAÇÃO FUNCIONAL

Há um velho ditado que diz: "Se você não sabe para onde está indo, como saberá quando chegar lá?" Isso é especialmente verdadeiro em projetos de simulação. Uma especificação funcional esclarece o escopo e o nível de detalhes do modelo. E o mais importante é que ela define claramente os resultados. Ela define os objetivos, bem como os resultados, e determina como todos saberão quando você tiver terminado.

Uma especificação funcional deve esclarecer o projeto e levar todos a um entendimento comum dos resultados. Os tópicos devem incluir:

• Objetivos- Resuma, a partir de seus objetivos iniciais de alto nível, o que você pretende resolver e o que não pretende resolver.
• Nível de detalhe -Um modelo é sempre apenas uma aproximação da realidade e sempre pode ser melhorado. É importante definir os limites desse modelo. Por exemplo, o nível de detalhes de um determinado modelo pode ser adequado para comparar a produtividade relativa de projetos alternativos, mas pode não ter detalhes suficientes para fornecer uma previsão confiável da produtividade absoluta do sistema.
• Requisitos de dados- Identifique quais dados serão necessários para apoiar o nível de detalhe acordado. De onde virão esses dados? Quem será responsável por fornecê-los? Quando serão fornecidos?
• Pressupostos e lógica de controle -Resuma o seu entendimento da lógica em vários pontos do sistema. Liste todas as suposições que serão feitas para que você e todas as partes interessadas tenham um entendimento comum de quantos detalhes serão modelados para cada parte do sistema. Por exemplo, os detalhes de despacho, prioridade de fila e alocação de recursos devem ser acordados antes do início da modelagem.
• Análise e relatórios- Determine quem estará envolvido na fase de análise do projeto. Defina a forma e o conteúdo dos resultados a serem entregues. Uma maquete de um relatório final é uma parte importante de uma especificação funcional. Ao analisar a maquete, as partes interessadas quase certamente identificarão coisas que estão faltando e coisas que são desnecessárias. É muito melhor identificar esses itens nesse momento do que na apresentação final do projeto.
• Animações- Geralmente, é necessário um certo nível de animação para o desenvolvimento e a validação do modelo. Qual é a importância da animação para as partes interessadas? Em muitos casos, as partes interessadas podem inicialmente indicar que a animação tem pouca importância para elas. Minha experiência geral é que, uma vez que as partes interessadas tenham visto a animação 2D ou 3D feita no desenvolvimento, elas apreciam seu valor para a comunicação e, posteriormente, exigem-na como parte do produto final.
• Prazo e agilidade- A simulação é geralmente um processo de descoberta. À medida que você modela e aprende sobre o sistema, encontrará novas alternativas a serem exploradas e, possivelmente, áreas do modelo que exigem mais detalhes. Explorar adequadamente essas áreas pode tornar o projeto muito mais valioso. Mas os melhores resultados possíveis não terão valor se forem entregues após a decisão ter sido tomada. Quando os resultados são esperados? Qual é a data de validade absoluta após a qual os resultados não terão valor? Talvez você ache que o seu projeto não precisa de uma especificação funcional ou que ela é muito formal para um projeto pequeno ou um projeto interno. Ela não precisa ser necessariamente formal. Mas todo projeto precisa de uma especificação funcional e deve levar de 5% a 10% do tempo total do projeto para ser finalizado. Mesmo um projeto que se espera concluir em um único dia deve dedicar de 30 a 60 minutos para definir o escopo e os detalhes. Esse tempo gasto pensando no futuro será mais do que compensado posteriormente no projeto.

O desenvolvimento de um protótipo durante a fase de especificação funcional pode ser esclarecedor para todas as partes. Você pode descobrir que é mais fácil ou mais difícil do que imaginava. Mesmo no menor projeto, geralmente vale a pena mostrar um modelo rápido e fazer a pergunta: É isso que você quer dizer? Você pode descobrir que tem um entendimento totalmente diferente do das partes interessadas. Muitas vezes, é possível criar um protótipo de modelo que atenda a uma grande porcentagem do que as partes interessadas dizem precisar. Porém, assim que veem o protótipo, eles se lembram das situações complexas e de todas as outras necessidades que não foram identificadas anteriormente.

A parte final da fase de especificação funcional é a aprovação. Deve ficar claro para todos que essa especificação funcional define o projeto e que o projeto será considerado concluído e bem-sucedido quando todos os aspectos da especificação funcional forem entregues. O ideal é que a especificação final seja formalmente aprovada por pelo menos as principais partes interessadas para evitar controvérsias posteriores.

5. GERENCIAR O PROJETO

Embora o melhor momento para iniciar um estudo de simulação seja bem no início do ciclo de vida do projeto associado, infelizmente essa não é a situação mais comum. É muito mais comum que a simulação seja considerada pela primeira vez quando os problemas são encontrados no final do ciclo, talvez um pouco antes de as decisões finais serem tomadas. Nesse momento, tudo se torna urgente, e você pode até mesmo estar "atrasado" antes de ter começado.

Em uma situação como essa, a tentação é entrar no modo reativo, deixando que a urgência o puxe primeiro em uma direção e depois em outra. E sempre há pressão para pular etapas importantes, como decidir exatamente o que você deseja realizar (a fase de especificação funcional). Isso tende a resultar em um fluxo de trabalho abaixo do ideal e até mesmo em um projeto incompleto.

Gerencie o projeto, não deixe que ele gerencie você. Um projeto que é concluído logo após a tomada de decisão tem pouco valor. Faz parte do seu trabalho gerenciar o projeto de simulação para que você forneça informações valiosas em tempo hábil. Observe as palavras "insight valioso". Todas as simulações são uma aproximação. Embora uma aproximação próxima tenha mais valor, uma aproximação mais grosseira ainda pode fornecer informações valiosas. Se não houver tempo suficiente para realizar bem todo o projeto, selecione um subconjunto ou uma aproximação mais grosseira que você possa realizar bem no tempo alocado. Isso deve ser refletido nas suposições da especificação funcional.

A simulação é geralmente um processo de descoberta. Você ganhará conhecimento ao passar do esforço para descrever com precisão o sistema para os primeiros resultados da simulação. Muitas vezes, essas novas informações podem levar o estudo a novas direções. Um certo grau de agilidade é apropriado para responder a essas necessidades; entretanto, agilidade demais pode impedir a conclusão do projeto. Nessas ocasiões, é preciso tomar a difícil medida de dizer "não" aos interessados e adiar essas solicitações para uma fase posterior do projeto. Embora ninguém goste de ouvir a palavra "não", a maioria das partes interessadas prefere um "não" honesto a um "sim" enganoso, que basicamente diz: "Sim, farei o que você pediu, mas, como resultado, o projeto pode não retornar nenhum resultado útil dentro do seu prazo". Faça um orçamento do seu tempo para que as tarefas importantes sejam concluídas e só então permita que o projeto explore algumas direções não previstas.

6. COLETAR DADOS DE ENTRADA

O tópico de dados de entrada geralmente pega os simuladores de surpresa. E isso pode facilmente ser motivo de fracasso do projeto. Nos dias anteriores à prevalência dos computadores e da automação, era comum que houvesse poucos ou nenhum dado disponível. Agora, é muito mais provável que você seja sobrecarregado por dados. Organizar e dar sentido a esses dados geralmente é o desafio.

O primeiro desafio é conhecer seus dados. Aqui está um exemplo simples, mas bastante comum: Talvez você colete alguns dados de tempo de inatividade da máquina e, ao analisá-los, descubra que o tempo mínimo de reparo é de 8 minutos, o modo é de 32 minutos e o máximo é de 9,5 horas. Sem um estudo adicional, talvez você não descubra que o tempo máximo de reparo também incluiu um período de 8 horas fora do turno, quando o reparo começou perto do final do turno. Seria fácil usar esses dados incorretamente no modelo e gerar resultados ruins. É importante conhecer seus dados e sua qualidade, "limpá-los" de quaisquer dados inválidos e realizar a análise de entrada apropriada.

Como a coleta de dados pode ser cara, os objetivos do seu estudo de simulação devem ser avaliados para determinar onde são necessários os dados mais precisos. Por exemplo, se estiver avaliando a utilização do operador, é importante ter dados suficientes relacionados às tarefas específicas pelas quais os operadores são responsáveis. Entretanto, os dados relacionados a outra área do sistema sem impacto sobre os operadores podem ser aproximados.

Você também pode usar seu modelo e algumas execuções piloto para ajudar a determinar onde precisa de dados melhores, determinando o grau de sensibilidade do modelo a diferentes valores de dados. Você deve verificar a sensibilidade tanto à magnitude (por exemplo, a média) quanto à variabilidade (por exemplo, o intervalo). Se os resultados do modelo sofrerem pouca alteração quando você usar outros dados de entrada razoáveis, então os números atuais podem ser bons o suficiente. Entretanto, se você notar uma mudança significativa nos resultados, com uma mudança relativamente pequena na magnitude ou na variabilidade, isso pode ser uma indicação de que você deve dedicar mais tempo e esforço para garantir que tenha os melhores dados possíveis para esse parâmetro.

Você já especificou em sua especificação funcional quem é responsável por fornecer os dados e quando. É prudente informar às pessoas, com bastante antecedência, quando você precisa dos dados e em que ponto o projeto sofrerá atrasos sem eles. Embora você possa culpar outra pessoa pelo atraso do projeto, é muito melhor trabalhar em conjunto para garantir que o projeto seja pontual e bem-sucedido.

7. CONSTRUIR E VERIFICAR O MODELO (ITERATIVO)

A construção de um modelo é o processo de criação de uma representação do sistema real adequada para apoiar o cumprimento dos objetivos declarados. Verificar o modelo é o processo de garantir que o modelo realmente faça o que você acha que ele está fazendo. Embora a criação e a verificação do modelo sejam duas tarefas diferentes, elas são abordadas em um único tópico para enfatizar a importância de realizá-las sempre de forma iterativa.

7.1 Criação do modelo

Às vezes, os novatos constroem uma grande parte do modelo, ou talvez até o modelo inteiro, antes de iniciar a verificação. Essa é uma causa significativa de fracasso do projeto. Quando você começa a verificar um modelo grande, há tanta coisa acontecendo que a compreensão das interações detalhadas se torna difícil ou impossível. Em vez disso, é muito mais eficaz adotar uma abordagem iterativa: criar uma parte do modelo, verificá-la e, em seguida, continuar adicionando outras partes da lógica ao modelo. Duas abordagens muito eficazes para a criação de modelos podem ser resumidas como "primeiro a amplitude" ou "primeiro a profundidade".

Na modelagem "amplitude primeiro", você pode criar o modelo inteiro ou uma seção importante dele com um nível mínimo de detalhes. Em seguida, você pode verificar se o modelo funciona antes de continuar. Isso tem a vantagem de gerar imediatamente um modelo potencialmente útil. Sua primeira passagem poderia ser, na verdade, o protótipo usado na especificação funcional. Outra vantagem é que você pode obter mais facilmente o feedback das partes interessadas a partir de um modelo completo (embora não totalmente detalhado) e obter feedback regular sobre onde é necessário mais detalhes. Às vezes, você pode até fazer alguma medida de validação (discutida mais adiante) como parte do ciclo iterativo.

Na modelagem "depth first", você seleciona uma pequena seção do sistema e a modela com todos os detalhes necessários. É possível verificar completamente essa seção do modelo e, em casos extremos, nunca mais precisar revisá-la. Uma vantagem dessa abordagem é a capacidade de modularizar o modelo, o que é particularmente importante se várias pessoas estiverem trabalhando no modelo ao mesmo tempo. Um novato pode optar por construir uma seção fácil do modelo primeiro para ganhar experiência. Um simulador mais experiente pode implementar as seções mais difíceis ou mais complicadas primeiro para eliminar alguns riscos do projeto logo no início. Um modelador com algum histórico "ágil" pode fazer primeiro as seções de maior prioridade ou mais importantes. Com essa última abordagem, em qualquer estágio, os aspectos mais importantes do modelo já foram concluídos. Isso ajuda a reduzir o risco de esgotar o tempo ou o orçamento sem conseguir produzir resultados significativos.

As abordagens "abrangência em primeiro lugar" e "profundidade em primeiro lugar" também podem ser combinadas, adicionando alternadamente alguns detalhes em todo o nível do modelo e, em seguida, adicionando alguns detalhes a (ou concluindo) uma subseção específica. Mas o aspecto mais importante é adicionar seções relativamente pequenas da lógica do modelo e, em seguida, verificar cada seção antes de adicionar mais lógica.

Em cada ciclo de verificação, você deseja responder definitivamente a duas perguntas. A seção do modelo que acabei de criar funciona como eu pretendia (por exemplo, há erros na lógica dessa nova seção)? Quando essa nova seção interage com seções do modelo criadas anteriormente, o modelo inteiro ainda funciona como pretendido (por exemplo, há erros nas interações entre as seções)? À medida que o modelo fica maior, talvez seja melhor diminuir o tamanho das novas seções para facilitar a resposta à segunda pergunta.

7.2 Como você verifica um modelo e como isola um problema quando o encontra?

As maneiras mais óbvias de encontrar e diagnosticar problemas no modelo são assistir à animação e examinar os resultados de saída. Resultados inesperados não são um problema - eles são o principal motivo para se fazer uma simulação. Resultados inexplicáveis são um problema. Quando o modelo gera um resultado inesperado, você precisa usar todas as ferramentas disponíveis para encontrar a explicação. Em alguns casos, isso pode levar à descoberta de um bug que precisa ser corrigido. Em outros casos, isso leva a um momento de "ah-ha" - um lampejo de esclarecimento sobre como um sistema complexo funciona.

A maioria dos produtos tem uma variedade de ferramentas para dar suporte à verificação do modelo. O rastreamento do modelo geralmente está disponível e pode fornecer grandes detalhes sobre o que está acontecendo exatamente, passo a passo, no seu modelo. Talvez você queira começar observando uma única entidade passar por todo o processo. Normalmente, há controles no software que permitem percorrer um modelo ou "interromper" a execução em um determinado local, hora ou condição. Muitas vezes, haverá uma janela de observação que permite explorar o estado detalhado do sistema a qualquer momento ou para qualquer objeto para ajudar a esclarecer melhor o que está acontecendo. E, certamente, aproveite os painéis de controle ou outras estatísticas e gráficos interativos oferecidos pelo software. O processo de verificação certamente será uma parte esclarecedora e bastante necessária do projeto.

7.3 Ajuda de um bom ouvinte

Mesmo com tudo o que foi dito acima, talvez você descubra que tem uma situação que simplesmente não parece correta, mas não consegue explicar o motivo. Chegou a hora de fazer uma revisão do modelo.

Encontre um bom ouvinte, de preferência um simulador ou um de seus participantes, e examine todas as seções relevantes do modelo e explique a ele o que está acontecendo. Se o ouvinte conseguir entender o que você está explicando, isso será um bônus.

Mas, em uma grande porcentagem das vezes, você encontrará seu próprio problema percorrendo metodicamente as interações. Ter isso em mente abre amplas possibilidades para um candidato a ouvinte. Um colega de trabalho não envolvido, um cônjuge ou até mesmo um animal de estimação são bons candidatos. Embora cães e gatos possam, às vezes, ser bons ouvintes, nada supera um peixinho dourado de estimação para um público cativo. O segredo é que explicar seu modelo em voz alta parece abrir uma parte diferente do seu cérebro e permite que você resolva seu próprio problema.

7.4 Como você sabe quando terminou?

Conforme mencionado anteriormente, um modelo é apenas uma aproximação de um sistema real. Normalmente, o modelador e as partes interessadas querem que o modelo seja o mais preciso e abrangente possível. Para evitar projetos intermináveis, atrasados e acima do orçamento, você precisa voltar ao seu documento de especificação funcional. Sua meta é criar um modelo com detalhes suficientes para atender aos objetivos declarados e nada mais!

A animação é uma área em que é fácil "se perder". A animação pode ser o trabalho mais divertido e instantaneamente gratificante do projeto. É fácil deixar que ela tome mais tempo do que deveria. A maioria dos pacotes tem algum nível de animação automática. Em geral, isso é suficiente para a verificação do modelo. Da mesma forma, muitos pacotes têm algum nível de animação 2D ou 3D que é muito fácil de gerar. Um pouco disso pode facilitar a validação, fornecendo uma medida adicional de realidade e reconhecimento pelas partes interessadas. Mas, novamente, é preciso voltar a essa seção da especificação funcional. Sua animação final deve ser boa o suficiente para atender aos objetivos do cliente identificados anteriormente, e nada mais!

8. VALIDAR OS RESULTADOS

A validação do modelo precisa ser feita para determinar se o modelo representa a realidade na medida necessária para atender aos objetivos. Às vezes, você pode concluir alguma medida de validação ao fazer as iterações de construção e verificação do modelo e deve aproveitar todas as oportunidades para fazer isso. Mas você ainda precisará fazer uma validação adicional no modelo concluído. A verificação e a validação perfeitas geralmente são impossíveis porque o único modelo perfeito é o sistema real. Mas há algumas maneiras de tentar demonstrar que o modelo é suficientemente válido para fins de projeto.

Uma técnica de validação comum é começar com um modelo do sistema existente (supondo que o sistema real exista). Compare os resultados do modelo "como está" com o desempenho do sistema real. Uma comparação estocástica pode considerar um período representativo (por exemplo, 30 dias ou 30 semanas) e comparar os resultados médios durante esse período. Outra abordagem é tornar o modelo tão determinístico quanto possível (por exemplo, usar tempos exatos de chegada de entidades, dados exatos de falhas etc.) e comparar os resultados desse período mais curto. Cada uma dessas abordagens é valiosa em sua própria maneira. Em ambos os casos, você deve se esforçar para identificar e explicar quaisquer diferenças significativas.

Outra técnica de validação é usar a experiência de seus participantes. Eles conhecem bem o sistema e devem ser capazes de assistir a uma animação e fornecer alguma medida de confiança. Você também deve dar a eles a oportunidade de ver o desempenho do modelo em uma ampla variedade de situações, como alto volume, baixo volume ou recuperação de uma falha. O ideal é que as partes interessadas possam até mesmo criar essas situações por conta própria, por exemplo, "Quero ver a máquina A falhar... agora".

Embora uma única parte interessada possa fornecer informações valiosas, um grupo de partes interessadas de diferentes origens pode fornecer um valor ainda maior. Talvez um engenheiro possa dizer: "Sim, você capturou o projeto exatamente como eu o descrevi", ao que um operador pode responder: "Talvez, mas nunca faríamos isso dessa forma. Veja como faríamos isso...". Nesse ponto, a simulação já está fornecendo um valor significativo como ferramenta de comunicação. Sua função no restante da reunião é facilitar a discussão e fazer anotações.

9. EXPERIMENTE, ANALISE E APRESENTE OS RESULTADOS

Durante a fase de experimentação, você gerará os cenários identificados na especificação funcional. Muito provavelmente, você também precisará de alguns cenários adicionais com base no que aprendeu durante o andamento do projeto. Os detalhes da análise estatística estão além do escopo deste documento, mas a análise estatística adequada é fundamental. Consulte a seção de leitura adicional para obter um tratamento completo da experimentação adequada e da análise estatística.

Como em todas as outras partes do projeto, certifique-se de reservar tempo suficiente no cronograma para experimentos e análises. Muitas vezes, se você ficar para trás nas fases de construção, verificação ou validação do modelo do projeto, poderá se deparar com uma escassez de tempo para a análise. Lembre-se de que o motivo para realizar o projeto de simulação é, normalmente, analisar vários cenários, portanto, planeje adequadamente e deixe bastante tempo programado para a fase de análise final.

Seu principal objetivo deve ser ajudar os participantes a tomar a melhor decisão possível, considerando o tempo e os recursos alocados. Embora você possa ter outras metas pessoais, como criar credibilidade ou obter lucro, é provável que essas metas sejam atingidas se você se concentrar em ajudar os participantes.

Considere o histórico e as necessidades específicas de cada parte interessada antes de criar seu relatório. Embora você provavelmente esteja orgulhoso do seu modelo e da maneira detalhada como resolveu problemas complexos, poucas partes interessadas compartilharão esse interesse. A maioria das partes interessadas está interessada em três coisas. Primeiro, quais alternativas foram consideradas. Segundo, quais são suas conclusões ou recomendações. Terceiro, que informações de apoio você pode fornecer para merecer a confiança deles em sua análise.

Embora você precise ter dados para apoiar suas conclusões, não sobrecarregue os interessados com muitos detalhes. Tente fornecer informações no contexto necessário. Por exemplo, em vez de simplesmente declarar "A utilização média de motoristas foi de 76%", você pode dizer "Como a utilização média de motoristas é alta (76%), não há tempo livre suficiente para recuperar o atraso durante os períodos de pico sem causar atrasos na linha".

Não exagere na precisão dos dados de saída. Reconheça e até mesmo enfatize para as partes interessadas que o modelo é uma aproximação e não gerará respostas exatas. Exiba seus dados com a precisão adequada com base na precisão de seus dados e nas suposições de modelagem (por exemplo, 76,2% e não 76,2315738%). E mostre a precisão de seus números sempre que possível. A maioria das partes interessadas pode se relacionar com um intervalo de confiança como 76,2% ± 1,3%.

10. RESUMO

Apesar do que você possa ter ouvido, fazer projetos de simulação bem feitos não é fácil. Há muitas maneiras pelas quais até mesmo um simulador experiente pode falhar. Neste documento, discutimos algumas armadilhas comuns e maneiras de evitá-las. Embora seguir essas sugestões não garanta um acerto em cheio, certamente aumentará sua chance de acertar o alvo.

LEITURA ADICIONAL

Banks, J., J. S. Carson, B. L. Nelson e D. M. Nicol. 2010. Discrete-event system simulation (Simulação de sistemas de eventos discretos). 5ª edição. Upper Saddle River, Nova Jersey: Prentice-Hall, Inc.

Law, A. M. 2007. Simulation modeling & analysis (Modelagem e análise de simulação). 4a ed. Nova York: McGraw-Hill, Inc.

Sadowski, D. A. e M. R. Grabau. 1999. Tips for Successful Practice of Simulation (Dicas para uma prática bem-sucedida de simulação). Em Proceedings of the 1999 Winter Simulation Conference, ed., P. A. Farrington, H. B. Nembhard, M. R. Grabau. P. A. Farrington, H. B. Nembhard, D. T. Sturrock e G. W. Evans, 60-66. Piscataway, Nova Jersey: Institute of Electrical and Electronics Engineers, Inc.

Sturrock, D. T., Success in Simulation, blog e discussão contínuos em .