Olá Gustavo, Antes de tudo, esqueci de mencionar que trabalho em uma indústria farmacêutica, na área de TI. Então tente pensar nesse cenário... Dividimos os riscos basicamente em duas grandes categorias. Riscos que chamamos de "compliace", que compreendem todos os riscos relativos à qualidade do produto (tudo que pode prejudicar a saúde do paciente) e o resto dos riscos ficam todos juntos no que diz respeito ao peso / criticidade. Quando temos um risco referente à compliance, não dá pra decidir se vamos implementar ou não; a resposta é sempre sim. Mostramos aos gestores (que como você disse, são os verdadeiros donos) e implementamos. O se problema é verba, sinalizamos à alta gerência e conseguimos a verba. Um risco de "compliance" jamais é aceitável, pois pode levar, no pior caso, a autuações da ANVISA, fechamanto da fábrica, racall, etc, o que seria gravíssimo em termos de reputação e financeiramente para a companhia.
Os riscos que não são classificamos como "compliance" possuem diversas categorias, como por exemplo, organização de TI, finanças, gestão de projetos, etc. Então atacamos esses riscos de acordo com a criticidade das aplicações, dentro do processo de negócio da companhia. Não é só porque não é um risco de compliance que não deve ser tratato. Ex: não dá pra ficar sem emitir nota fiscal e não vender, e não lucar. Por isso que para todos os softwares que usamos, realizamos uma espécie de classificação, para determinar em que faixa de risco cada um se enquadra e identificarmos as atividades de mitigação. Nós não esperamos os riscos aparecerem. Há 4 anos trabalhamos em um projeto de mitigação de riscos. Anualmente os sistemas são avaliados e reavaliados, conforme o nível de maturidade / qualidade que a organização determina ser o aceitácel, respeitando sempre os requerimentos dos órgãos regulatórios nacionais e internacionais (ANVISA, EMEA, FDA - estamos começando agora). Claro que há risco que conhecemos e que não foram mitigados. Nestes casos a alta gerência concordou e assumiu o risco. Talvez pelo ramo em que trabalho (farmacêutica), não seja muito viável aplicar esse tipo de abordagem que você citou... Números não ajudariam muito... Poucos riscos são aceitáveis quando se está lidando com a saúde de alguém e é isso que eu vejo diariamente. As vezes preferimos cobrir um pouco mais do que expor à organização a custa de tão pouco. E temos o apoio da companhia para isso. Por isso discordo quando diz que entende que o nível de maturidade seja 1. Depende muito do negócio de casa empresa se adequar ou não a determinado processo de gestão de mudanças, riscos, problemas, etc... Espero ter contribuído com minhas experiência =D Até breve! Gisely Em 28 de maio de 2010 21:30, Gustavo Lens Minarelli, CGEIT, CISM < [email protected]> escreveu: > > > > > Gysele, > > > > Achei muito interessante a forma com que você descreveu o processo de > análise e avaliação dos riscos que vocês seguem. Achei prático. > > Mas gostaria de fazer uma pergunta. > > > > Sem números, ao menos qualitativos, como vocês decidem se um risco é > aceitável e vale apena investir na sua mitigação? Como vocês apresentam > estes riscos para os gestores que são os verdadeiros donos deste risco? Se > vocês tem diversos riscos, tratam todos? Como vocês priorizam as mudanças? > Como relacionam com os objetivos do negócio e sensibilizam a direção da > empresa? > > Parece-me que vocês estão em um estágio insipiente do processo, uma > avaliação de maturidade qualificaria o processo como inicial, ou nível 1. > > Será que não vale a pena tentar avançar para uma análise qualitativa, mesmo > que simplificada? As vantagens são as que citei acima. > > Pelo que relata, o processo de vocês começa na identificação dos riscos, > estes riscos são avaliados informalmente e um plano B é gerado para todos os > riscos. > > É isso mesmo? > > > > Grande abraço > > Gustavo Lens Minarelli > > > > > > *From:* [email protected] [mailto:[email protected]] *On > Behalf Of *Gisely > *Sent:* quinta-feira, 27 de maio de 2010 14:54 > > *To:* [email protected] > *Subject:* Re: RES: [itsm_br] Análise de risco em gerenciamento de > mudanças > > > > > > 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 > > > > > > >
