Olá Adriano, Sempre que tentei usar fórmulas matemáticas e "receita bolos" acabei me dando mal. A experiência me mostrou que podemos usar sim este tipo de abordagem, mas sempre pensando que "cada caso é um caso" e que devemos olhar todos os aspectos pertinentes (não somente um número). Particularmente que eu confiaria 30% em uma avaliação de riscos baseada somente em números. Nunca mais usei cálculos. Prefiro chamar uma reunião multidisciplinar (adoro essas reuniões, várias cabeças juntas conseguem enxergar muito mais do que uma só), levar algumas premissas, alguns riscos que eu previamente identifiquei e assim começa a discussão. Dependendo da criticidade da mudança, detalhamos um plano B; ou seja; "e se a mudança não der certo, o que fazer?". Por algumas poucas vezes, tive que acionar esse plano. Se ninguém tivesse pensado antes, talvez tivéssemos perdido o equilíbro no momento da "tragédia" e tomado as decisões erradas. Um exemplo disso foi num projeto de migração de versão de várias bases de dados Oracle. Foi um desastre que poderia ter tido grande impacto financeiro para a companhia se não tivéssemos previsto anteriormente essa situação. Lembro que quando abri minha boca pra dizer "e se der errado?" quase foi crucificada, pois as "estatíticas" não tendiam a isso... Sugestão: use o bom senso, se comunique com outros profissionais envolvidos na mudança, tente pensar em todas as possibilidade e como cada uma delas afetaria o seu negócio. Aí você vai encontrar onde deve atacar.
Att, Gisely Em 26 de maio de 2010 15:37, Rui Natal <[email protected]> escreveu: > > > Meu amigo, > > > > Seria uma questão de você, em seu cenário específico, ir aplicando pesos a > cada uma das questões e suas respectivas respostas. > > De forma semelhante (em termos de linha de raciocínio) ao que se faz quando > se pondera Urgência e Impacto para se chegar à Prioridade. > > Mas isso é bem na base do cada caso é um caso. > > Entendo que não exista ou não deva existir uma regra única tipo “one size > fits all”. > > Não tem essa de coelho saindo da cartola. > > à IC’s envolvidos (em termos de Hw e seus componentes) ? aplicativos ? > serviços ? áreas impactadas ? abrangência ? . . . ? . . . ? > > > > Plagiando o tal do Roberto Carlos è “*... são tantas emoções ...*” Mas, > sem nenhuma conotação de deboche, OK ? > > E o importante é que você vivencie estas emoções, e vá fazendo ajustes, > inclusões / exclusões, estudando e sentindo suas repercussões, e fazendo > ajustes ... > > > > Um abraço. > > > > Rui Natal > > > > > ------------------------------ > > *De:* Adriano Litvak [mailto:[email protected]] > *Enviada em:* quarta-feira, 26 de maio de 2010 15:25 > > *Para:* [email protected] > *Cc:* Rui Natal > *Assunto:* Re: RES: [itsm_br] Análise de risco em gerenciamento de > mudanças > > > > Olá Rui, > > > > Então, me ajudou, os pontos foram muito interessantes, porém eu gostaria de > saber como cálculo matematicamente esses pontos, pra chegar se essa mudança > possui risco baixo médio ou alto... > > > > Abraços e muito obrigado > > > ____________________________________ > Adriano Litvak, Cobit4.1, ITILv3 > IT and Security Consultant > [email protected] > > > > > ------------------------------ > > *From:* Rui Natal <[email protected]> > *To:* [email protected] > *Sent:* Wed, May 26, 2010 8:14:20 AM > *Subject:* RES: [itsm_br] Análise de risco em gerenciamento de mudanças > > > > Adriano, bom dia. > > > > Não sei se estou lhe ajudando com a resposta, enfim... > > Trabalho diretamente com uma suíte de produtos de Sw, e ela já prevê que se > formule (a depender de customização / parametrização) umas tantas perguntas > e se atribua pesos às respostas a estas perguntas, e assim, chega-se ao > risco estimado para aquela mudança. > > > > Por exemplo: > > è Ela precisa ser realizada no horário do expediente ? > > è Em caso de problema temos como voltar à situação anterior (back-out) ? > > è A mudança já foi testada e homologada ? > > è Os procedimentos de restauração ou volta (ou back-out) já foram testados > ? > > è A mudança afeta recursos críticos / estratégicos do cenário operacional > / de produção ? > > è Esta mudança poderá comprometer outros IC’s (componenets, aplicativos, > serviços) ? > > è Qual o tempo estimado de interrupção ou degradação no caso de uma falha > na mudança ? > > > > °°° > > °°° > > °°° > > E por aí vai. > > Espero ter ajudado. > > Um abraço a todos. > > Rui Natal > > > ------------------------------ > > *De:* itsm...@yahoogroups .com [mailto:itsm_ b...@yahoogroups. com] *Em nome > de *Adriano Litvak > *Enviada em:* segunda-feira, 24 de maio de 2010 09:53 > *Para:* itsm...@yahoogroups .com; Governanca_COBIT_ i...@yahoogrupos . > com.br > *Assunto:* [itsm_br] Análise de risco em gerenciamento de mudanças > > > > > > Olá Pessoal, > > > > Como vcs fazem análise de risco em processo de uma mudança. É por > percepção, cálculo de fatores? se alguém puder disponibilizar exemplo, > agradeço > > > > > > Abraços > > > ____________ _________ _________ ______ > Adriano Litvak, Cobit4.1, ITILv3 > IT and Security Consultant > adriano...@yahoo. com > > > > >
