B.3 R´ eduction ` a la forme normale
B.3.2 Algorithme de Tarjan
Ao aprofundar no conhecimento sob as barreiras de implementação da GTI, percebe-se que algumas delas impactam diretamente no alinhamento Negócio-TI. Buscando entender estas relações, este tópico da pesquisa revisa os conceitos do alinhamento Negócio-TI.
O alinhamento Negócio-TI é uma das principais preocupações organizacionais (LUFTMAN e BEN-ZVI, 2011). Há muitos anos, vem sendo uma das principais preocupações de CIOs e CEOs (SALLES, 2013). Esta preocupação com o alinhamento estratégico é reiterada no COBIT, o alinhamento estratégico de Negócio-TI é representado como uma das áreas de foco da GTI e 23 dos 37 processos tratando da questão (COBIT, 2012).
Para manter um nível alto de alinhamento, é necessário um cuidado constante com os processos de Negócio, com os processos de TI e com a relação entre seus indicadores de resultados. Desta forma, é possível identificar pontos fracos e fortes para realizar as correções necessárias. A grande dificuldade é operacionalmente, na confusão do dia a dia, identificar, medir, melhorar e manter o nível de alinhamento entre Negócios e TI (SILVA e CHAIX, 2008).
Na pesquisa de De Haes e Van Grenbergen (2008), a relação da GTI com o alinhamento estratégico é demonstrada. O estudo realizado em empresas belgas do ramo financeiro revelou que empresas com um nível de maturidade alto em alinhamento entre TI e Negócio apresentam semelhante nível de maturidade em GTI e que o oposto também é verdadeiro, baixos níveis de maturidade em alinhamento de TI e Negócio estão relacionados a baixos níveis de maturidade da GTI.
Figura 14: Maturidade do Alinhamento de TI e Negócio
A Figura 14 apresenta um gráfico com dez empresas, dispostas em relação aos seus níveis de maturidade em alinhamento Negócio-TI. A escala varia de 0 a 5, sendo 0 a pior situação e 5 a melhor. Quatro destas empresas estão fora da média, duas estão com um nível mais alto (acima de 3) e duas com nível mais baixo (2.1 e 2.2). Segundo os pesquisadores, esperava-se que empresas do ramo financeiro tivessem melhores resultados, pois é este tipo de Negócio que depende muito da TI.
Figura 15: Maturidade em GTI.
Fonte: De Haes e Van Grembergen (2008).
A Figura 15 apresenta um conjunto das quatro empresas que ficaram fora da média no gráfico da Figura 14, representadas pelas letras A, B, I e J. O gráfico demonstra a relação entre essas empresas e a maturidade de suas práticas de GTI. Analisando os dois gráficos, observa-se que as empresas como o nível alto de alinhamento também tem um nível alto práticas de GTI e vice-versa.
Segundo a interpretação De Haes e Van Grembergem (2008), a implementação da GTI está totalmente relacionada ao alinhamento TI e Negócio. Partindo deste princípio, os pesquisadores apontam uma linha de base para
implementação eficaz da GTI, apontando os elementos de GTI mais eficazes entre estruturas, processos e mecanismos relacionais para obter melhores resultados referentes ao alinhamento entre TI e Negócio.
Um modelo muito citado para avaliar o nível de maturidade de uma organização em relação ao alinhamento entre Negócio e TI é o de Luftman (2004). Ele consiste de cinco níveis de maturidade:
1. Inicial / Processo Ad Hoc
2. Comprometida com o Processo
3. Centrada em Processos Fundamentados
4. Melhoria / Processo Gerenciado
5. Processo Otimizado
Outro modelo bastante citado na literatura é o proposto por Henderson e Venkatraman (1993). Este modelo é composto de quatro domínios: externo, interno, de funções de Negócio e de funções de TI. O domínio externo basicamente diz respeito às relações da empresa com o mercado e o domínio interno às estruturas e processos da organização, tanto para as funções Negócio quanto para as de TI. Os autores defendem o alinhamento em ambos os domínios, chamam de adequação estratégica, o alinhamento entre domínio interno e externo e de alinhamento funcional entre o domínio de funções de Negócio e funções de TI; também defendem um terceiro alinhamento, chamado multidirecional, entre os quatro domínios quando são formadas relações entre subconjuntos destes domínios. A Figura 16 apresenta o modelo de Henderson e Venkatraman (1993).
Figura 16: Modelo de Alinhamento TI e Negócio
Fonte: Henderson e Venkatraman (1993)
Para Silvius e Waal (2010), que citam o modelo Henderson e Venkatraman em sua pesquisa, cada um destes domínios contém seis variáveis de maturidade, que servem de indicadores na avaliação da maturidade da organização. O Quadro 8 descreve as questões relacionadas a cada uma das variáveis propostas.
Quadro 8: Variáveis de Maturidade
Variáveis de Maturidade Descrição
Comunicação Quão bem o pessoal técnico e de Negócios entendem uns aos outros?
Eles se conectam com facilidade e frequência?
Disseminam a aprendizagem organizacional internamente?
A empresa se comunica efetivamente com consultores, fornecedores e parceiros?
Medição de Valor Quão bem a empresa mede o seu próprio desempenho e o valor de seus projetos? Após os projetos serem concluídos, eles
avaliam o que deu certo e o que deu errado?
Eles melhoram os processos internos para que o próximo projeto seja melhor?
Governança Os projetos são desenvolvidos a partir do fluxo de uma compreensão da estratégia de Negócio?
Os projetos apoiam essa estratégia?
A organização tem a transparência e prestação de contas para os resultados de projetos de TI?
Parceria Em que medida departamentos de Negócio e de TI forjam verdadeiras parcerias baseadas na confiança mútua e compartilhamento de riscos e recompensas?
Escopo
e
Em que medida a tecnologia evoluiu para tornar-se mais do que apenas suporte ao Negócio?
Arquitetura Como a tecnologia tem ajudado a empresa a crescer, competir e lucrar?
Habilidades Os funcionários têm as habilidades necessárias para serem eficazes?
Quão bem o pessoal técnico entendem os direcionadores de Negócio e falam a linguagem do Negócio?
Quão bem o pessoal de Negócios entendem os conceitos de tecnologia relevantes?
Fonte: Silvius e Wall (2010)
A Figura 17 apresenta o gráfico que demonstra o grau de maturidade de uma organização em relação as variáveis de maturidade de Silviuis e Wall. A linha azul representa a situação atual da empresa e a linha vermelha a situação que ela deseja estar no futuro.
Figura 17: Gráfico de Maturidade de TI e Negócio de uma Organização
Fonte: Silvius e Wall (2010)
O Quadro 9 traz os valores extraídos do gráfico acima para cada variável de maturidade em um escala que varia de 0 a 5, onde 0 é o mais baixo nível de maturidade e 5 o mais alto nível.
Quadro 9: Nível de Maturidade (onde está e aonde quer chegar)
Fonte: Silvius e Wall (2010)
Um aspecto interessante do alinhamento de TI e Negócio é a diferença cultural que pode existir entre o pessoal de Negócio e de TI. Essas diferenças culturais podem impactar no alinhamento funcional. Entender essas diferenças é fundamental para melhoria do alinhamento. Na pesquisa de Silvius e Waal (2010), as diferenças culturais encontradas em organizações educacionais distanciam acadêmicos do pessoal de TI, como mostra o Quadro 10.
Quadro 10: Diferenças Culturais
Cultura da TI Cultura Acadêmica
Profissão emergente Profissão madura
Mudança de agente Valores tradicionais e ceticismo Foco institucional Foco disciplinar
Foco na produção Foco da inovação Busca por consenso e alinhamento Busca pela verdade Ser anônimo na organização Busca por reputação Prestação transparente de atividades e
serviços
Complexidade de processos e práticas
Velocidade é objetivo valioso Velocidade pode ser contrária à qualidade
Ciclo de vida curto para produtos, serviços, resultados e tecnologias.
Produtos de trabalhos projetados para durar por anos, décadas e mesmo séculos.
Usa idiossincrasia e linguagem técnica para se comunicar
Usa uma diferente idiossincrática e técnica linguagem para comunicar suas expectativas.
Fonte: Silvius e Waal (2010)
2.2 Modelagem e Simulação
“Simulação é a imitação da operação de um processo do mundo real ou sistema ao longo do tempo. Simulação envolve a geração de uma história artificial do sistema e a observação da história artificial para fazer inferências sobre o funcionamento e características do sistema real que está sendo representado. A Simulação é uma indispensável metodologia de resolução de problemas para a solução de muitos problemas do mundo real. Simulação é usada para descrever e analisar o comportamento de um sistema, perguntar usando questões do tipo “e se” sobre o real sistema, e ajudar na concepção de sistemas reais. Ambos os sistemas, existente e conceitual, podem ser modelados com a Simulação” (Banks e Jerry, 1998, p.3).
2.2.1 Considerações iniciais
A Simulação no sentido geral é buscar a imitação de um sistema. Pode ser estática quando imita um sistema em um ponto no tempo, por exemplo, a obra de um falsário, que simula a obra de um grande artista; ou dinâmica quando está
relacionada com o deslocamento do tempo, por exemplo, a previsão do tempo é a simulação da passagem das nuvens em relação ao tempo futuro. O termo Simulação está mais relacionado com a forma dinâmica (ROBINSON, 2004).
Para desenvolver a Simulação, primeiramente, deve-se pensar que tipos de sistemas quer simular, eles podem ser de quatro tipos: (i) natural, (ii) projeto físico, (iii) projeto abstrato e (iv) atividade humana, também pode ser híbrida, envolvendo mais de um tipo de sistema. Em seguida, deve-se pensar no propósito da Simulação, que podem ser quatro propósitos básicos: (i) entendimento da realidade, (ii) mudança da realidade, (iii) controle da realidade e (iv) gerenciamento da realidade (ROBINSON, 2004).
Robinson (2004) também ressalta dois aspectos da Simulação: simplicidade e experimentação. O primeiro enfatiza a necessidade de criar modelos simplificados, que recebam entradas dos seus manipuladores e retorne o resultado esperado. A tendência de construir modelos de alta fidelidade é questionável, pode ser considerada perda de tempo e de recurso. O segundo aspecto é a experimentação, que diz respeito ao uso da Simulação, servindo como ferramenta de apoio à decisão, onde os experimentos são testados para realização de mudanças no sistema real.
A Simulação se justifica pela variabilidade, complexidade e interconectividade dos sistemas, o que dificulta a sua análise de desempenho. A variabilidade está relacionada às entradas não previsíveis nos sistemas. A complexidade pode ser combinatória ou dinâmica: a dinâmica está relacionada à mudança de padrões de comportamento do sistema no tempo e a combinatória relaciona-se com a quantidade de possíveis combinações que podem ocorrer em um sistema. A interconectividade relaciona-se com a mudança de estado de uma parte do sistema em decorrência da mudança de outra parte do sistema (ROBINSON, 2004).
A Simulação é um método amplamente utilizado e cada vez mais popular para estudar sistemas complexos (SOKOLOWSKI e BANKS, 2009).
A Simulação é uma ferramenta amplamente utilizada por vários setores, e não é por acaso, ela é capaz de prover uma série de benefícios a seus usuários. Esses benefícios são relatados pela literatura. Algumas possíveis vantagens da Simulação podem ser responsáveis pelo uso ostensivo da Simulação, por exemplo: a Simulação é muitas vezes o único tipo de investigação possível; a Simulação permite estimar o desempenho de um sistema existente sob um conjunto de condições de operação previstas; projetos de sistemas com propostas alternativas, ou políticas operacionais alternativas podem ser comparados através de simulações e verificar qual melhor atende uma exigência específica; em uma simulação, podemos manter um controle muito melhor sobre as condições experimentais do que seria geralmente possível quando experimentando com o próprio sistema; a Simulação permite estudar um sistema com uma estrutura de muito tempo, por exemplo, um sistema econômico, comprimindo o tempo ou estudando o funcionamento detalhado de um sistema em tempo expandido (ZEIGLER et al 2000).
Segundo Sokolowski e Banks (2009) as vantagens da Simulação são:
habilita a escolha correta, através de testes de todos os aspectos de uma mudança proposta, sem compromisso de recursos adicionais;
comprime e expande o tempo, habilitando o usuário a acelerar e desacelerar o comportamento ou fenômeno, facilitando a pesquisa aprofundada;
permite o entendimento do porquê, através da reconstrução de cenários e exame de cenário e inferências;
explora possibilidades, através de um contexto de políticas, procedimentos e métodos, sem interromper o sistemas real;
diagnostica problemas, viabilizando o entendimento das interações das variáveis que compõem os sistemas complexos;
identifica restrições pela revisão de atrasos no processo, informação ou materiais para determinar se as restrições são a causa ou efeito;
desenvolve o entendimento pela observação de como o sistema opera, ao invés de tentar prevê como ele deveria funcionar;
visualiza o planejamento, usando animação para observar o sistema ou a organização efetivamente operando;
constrói um consenso para uma opinião objetiva;
prepara para mudanças, respondendo questões do tipo “what-if”' (se fizer isso o que acontece) no projeto ou modificação de um sistema;
melhora o treinamento, podendo ser realizado com menor custo e menos interrupções do que o treinamento no ambiente de trabalho;
melhora dos investimentos, pois um estudo por Simulação custa muito menos que a mudança ou ajuste de um sistema; e
melhora a especificação de requisitos de um sistema para que realmente os objetivos sejam atingidos.
Comparando a Simulação com a experimentação de sistemas reais, existem quatro fatores onde a Simulação tem vantagens: (i) custo, (ii) tempo, (iii) controle e (iv) a inexistência de um sistema real (ROBINSON, 2004).
(i) Custo: um mesmo modelo pode ser modificado várias vezes, sendo assim, qualquer alteração no sistema real pode ser simulada antes, evitando gasto de recursos desnecessário.
(ii) Tempo: uma simulação possibilita que o tempo seja controlado, acelerado ou retardado.
(iii) Controle: as variáveis do sistema permanecem visíveis durante toda a simulação, podem ser alteradas em tempo de execução e os indicadores são gerados em tempo real.
(iv) Inexistência de um sistema real: quando o sistema ainda não existe, há a possibilidade de gerar um modelo de Simulação a partir de um sistema real e verificar o comportamento do mesmo.
2.2.2 Modelos de Simulação
Para utilizar os benefícios relatados da Simulação, algum esforço deve ser aplicado, inicialmente, para desenvolver um modelo da realidade. Este modelo será programado e executará em um motor de Simulação. Para desenvolver um modelo de Simulação para um sistema, deve-se ter em mente que todo sistema tem um conjunto de elementos que interagem entre si para chegar a um objetivo pré- definido. Os modelos de Simulação são a imitação destes sistemas, sendo assim devem compartilhar das mesmas características, com algumas suposições e simplificações (LAW e KELTON, 2000). Para os autores um modelo de Simulação pode ser classificado como:
(i) físico ou matemático - um exemplo de um modelo físico são as piscinas usadas para simular a ação das ondas em uma plataforma de petróleo. Já os modelos matemáticos são representações dos sistemas em termos lógicos, suas relações e reações;
(ii) estático ou dinâmico - os sistemas, durante sua execução, passam por vários estados, por exemplo, em um atendimento médico, o sistema em um primeiro estado pode estar com um paciente na triagem, com outro no consultório do médico e com outro recebendo medicação, em um segundo estado, não tem nenhum paciente na triagem, um está no consultório e dois estão recebendo medicação. Em modelo estático busca-se analisar um estado especifico do sistema, já em dinâmicos analisa-se os vários estados em um determinado período de tempo;
(iii) determinístico ou estocástico - quando um modelo de Simulação utilizam componentes que geram valores aleatórios em algum momento, são chamados estocásticos, por exemplo, em um modelo de Simulação militar que inclui eventos de bombas lançadas sobre tropa inimiga, os cálculos de quantos e quais soldados devem morrer ou se ferir são aleatórios, não é possível determinar o resultado exato do impacto da bomba, ao contrário de um modelo que calcula as
reações químicas, através de equações diferenciais, pois os resultados destas equações são previstos;
(iv) contínua ou discreta. - no modelo discreto tem eventos acontecendo esporadicamente, por exemplo, em Simulação de missões da Força Aérea, tem-se um evento quando a missão é passada para a aeronave e outro quando a aeronave retorna com a missão, o que acontece durante o percurso não é objetivo da simulação, já em um modelo de dinâmica de voo, tudo que acontece nesse espaço de tempo interessa para Simulação, ou seja, simulação contínua.
O desenvolvimento da Simulação conta com linguagens específicas, exemplo é a Simlib (Simple Simulation Language), baseada na linguagem C, é estruturada para gerenciar filas de eventos, que podem ser manipulados de diferentes formas. Esta linguagem também prover funções de gerenciamento do tempo, agendamento de eventos, criação de aleatoriedade (LAW e KELTON, 2000).
Zeigler et al (2000) apresentam um framework para desenvolvimento de modelos de Simulação baseado em um conjunto de entidades que se relacionam. As entidades e seus respectivos significados estão relacionados Quadro 11.
Quadro 11: Framework de modelagem e Simulação
Sistema de Origem Ambiente real ou virtual de interesse da simulação
Banco de Dados de Comportamento Coleção de dados coletados
Estrutura de Experimentação Condições específicas sob o qual o sistema é observado ou experimentado.
Modelo Instruções que geram dados
gerar o comportamento do modelo.
Fonte: Zeigler et al (2000)
2.2.3 Modelos Conceituais de Simulação
A Simulação, segundo Robinson (2004), pode ser física ou baseada em computador. Exemplo de simulação física é a piscina que simula o comportamento das ondas, utilizada na Petrobras, para analisar o desempenho das plataformas de petróleo. Já nas simulações baseadas em computador, inicialmente deve-se construir um modelo conceitual para em seguida ser programado e então executado por computador. O papel do modelo conceitual é tão importante quanto o da própria Simulação, em alguns casos o modelo conceitual pode obter 50% dos resultados esperados da Simulação.
Para construir um modelo conceitual alguns aspectos devem ser considerados como: credibilidade, validade, viabilidade e utilidade:
a credibilidade está relacionada à percepção do cliente da Simulação sobre modelo conceitual, quando levado ao computador, atenderá a finalidade para a qual foi construído;
a validade compartilha dos mesmos conceitos da credibilidade, a diferença é o ponto de vista, que, na validade, é de quem está criando o modelo, o modelador;
a viabilidade diz se o modelo pode ser implementado em um computador, se os dados podem ser coletados e se o espaço de tempo a ser considerado pode ser processado; e
a utilidade questiona a possibilidade do modelo ir para o computador, se realmente ajudará no processo de tomada de decisão, ou seja, se ele será útil.
Observados estes quatro aspectos, a especificação da Simulação pode ser realizada e deve contar com as seguintes informações: uma descrição do problema que será tratado; os objetivos do estudo, que utilizará a Simulação; os benefícios esperados; o modelo conceitual (entradas, saídas, conteúdo, os pressupostos e simplificações); a experimentação (cenários a serem considerados); os requisitos de dados (dados necessários, quando necessário, a responsabilidade pela coleta); a escala de tempo; e o custo estimado (ROBINSON, 2004).
Para o modelo conceitual incluído na especificação, primeiramente, tem-se os objetivos: o propósito do modelo; as entradas, todos os elementos do modelo que melhoram o entendimento do mundo real, também conhecidos como fatores de experimentação; as saídas, resultados da simulação quando for executada; e o conteúdo dos componentes do modelo com suas conexões, podendo ser mais ou menos detalhado, dependendo dos objetivos.
Em seguida, o nível de detalhamento do modelo deve ser questionado, pois a precisão do modelo não é diretamente proporcional ao seu nível de detalhamento. Mais detalhes não quer dizer mais precisão, 80% de precisão é atingida com 20% de complexidade e 100% de precisão do mundo real é impossível de se atingir. Empregar esforço para detalhar o modelo pode ser perda de tempo. A Figura 18 mostra o gráfico da relação entre a precisão e o nível de detalhamento.
Figura 18: Modelo de Simulação Complexidade e Acurácia
Fonte: Robinson (2004)
O desenvolvimento de um modelo conceitual de simulação pode ser padronizado, Robinson (2004) propõe um “framework” com quatro fases: (i) desenvolver uma compreensão da situação-problema, (ii) determinar os objetivos de modelagem, (iii) projetar o modelo conceitual: entradas e saídas, (iv) projetar o modelo conceitual: o conteúdo do modelo. A Figura 19 apresenta os detalhes do “framework” de Robinson (2004).
Figura 19: Framework para Modelagem Conceitual
Fonte: Robinson (2004)
No modelo do “framework”, observa-se que as fases de desenvolvimento estão relacionadas e são iterativas. A construção do modelo inicia com a compreensão do problema que se deseja resolver com uso da Simulação, por exemplo, um restaurante de fast-food está com problemas com um dos ramos em sua rede, seus clientes queixam-se sobre o período de tempo que permanecem na fila dos balcões de atendimento, resultado não da escassez de alimentos, mas da falta de pessoal de serviço. Ao definir o problema, não se deve encara-lo como estático, pois ele evolui durante a construção do modelo e após a execução da Simulação, ou seja, novas perspectivas são trazidas para o domínio do problema constantemente (ROBINSON, 2004).