Guia de Análise de Impacto nos Negócios

Nem todo mundo sabe onde e quando começar a implementar planos de continuidade de negócios. Costumo dizer o seguinte: quando as possíveis perdas forem maiores que os custos de combater a ameaça, é hora de tomar medidas, os custos serão adequados. E vice-versa. Se o custo da contração for mais ou menos claro, estimar as perdas é uma tarefa não trivial. Convido você aos bastidores de um projeto para avaliar o impacto de emergências em um negócio (Business Impact Analysis - BIA) e desenvolver uma estratégia para garantir a continuidade da TI com o exemplo de um grande varejista. Então vamos lá.

Iniciar

Participamos do projeto do X5 Retail Group - o maior varejista da Rússia. A empresa gerencia as redes de Pyaterochka, Carrossel e Crossroads.

Ela já tinha sua própria política de gerenciamento de riscos de interrupção, que incluía:

1. seguro de risco;
2. formação de gestão de crises;
3. minimização de riscos à vida e à saúde das pessoas;
4. controle de riscos de gerenciamento de negócios;
5. Preparação de planos de recuperação de emergência para sistemas de TI.

De acordo com essa política, a infraestrutura de TI centralizada exigia o desenvolvimento de planos de continuidade de serviços de TI e recuperação de desastres. A solução ideal seria construir um data center de backup, configurar a replicação síncrona, configurar a automação de transferência de emergência e assistir a "H" em uma hora na tela como os sistemas de TI se movem para o data center de backup e as luzes verdes acendem, sinalizando que não há perigo para os negócios.

Mas, dada a economia do processo, a empresa sugeriu que reservar apenas os sistemas de TI mais críticos seria uma medida de emergência adequada, sem a qual as lojas não seriam capazes de operar e perdas financeiras significativas começariam na empresa. Uma questão importante surge - quais sistemas e por quanto tempo devem ser restaurados?
O departamento de TI do cliente determinou a classificação dos sistemas de TI e o tempo de recuperação aceitável para cada sistema. No entanto, posteriormente, foi decidido realizar uma avaliação completa do impacto de emergências nos negócios da empresa (BIA), de acordo com a ISO 22301 e as melhores práticas.

Volume e limites

O teatro começa com um cabide, e a BIA começa com a definição do escopo do trabalho. Para isso, é necessário examinar os processos de negócios da empresa, seus serviços, demonstrativos financeiros, relacionamentos com parceiros, clientes e contratados. Em seguida, identifique e coordene os principais processos e serviços de negócios que se enquadram dentro dos limites do projeto. A duração e o custo da BIA dependem do volume. Além disso, nossa experiência sugere que você não deve esticar o projeto por mais de 9 meses.

No nosso caso, o cliente já determinou os limites escolhendo os processos de negócios mais significativos para as atividades de negociação.

A entrevista

Depois de fixados os limites e a estrutura da BIA, é determinada uma lista de partes interessadas da empresa e de outros departamentos com os quais você deseja realizar uma entrevista. É muito importante coletar informações de diferentes departamentos, a fim de obter uma imagem objetiva dos processos da empresa, entender como eles funcionam, obter uma avaliação do "o que acontecerá se ...". Nesta fase, obtemos informações sobre como exatamente os processos de negócios dependem da TI e construímos uma matriz dessas dependências. Além disso, representantes comerciais e partes interessadas no processo comercial avaliam as consequências, possíveis danos, possíveis cenários. Para isso, desenvolvemos um questionário especial e entrevistamos cerca de 50 entrevistados (apresentamos 50 apresentações sobre o próprio projeto, conduzimos, recebemos e processamos todos os questionários preenchidos).

Processos de negócios

Paralelamente à entrevista, descrevemos os processos de negócios, levando em consideração o tempo necessário para concluir as operações individuais e a profundidade da elaboração, suficientes para análises posteriores. É necessário particionar um processo em componentes menores e operações específicas para entender como um sistema de TI afeta um processo específico em diferentes momentos do dia e em diferentes épocas do ano. Nesse estágio, é importante entender que não descrevemos processos de negócios de acordo com o GOST ou outra metodologia. Não otimizamos processos de negócios e geralmente não fazemos recomendações para melhorar os processos de negócios, pelo menos dentro da BIA. Descrevemos os processos de negócios com tanto detalhe que nos permite justificar a metodologia para calcular perdas e avaliar perdas de acordo com vários critérios. Para uma descrição gráfica, as notações EPC, ARIS e MS Visio foram usadas como ferramentas.

Limiares

Para determinar o tempo objetivo de recuperação do alvo, é necessário em terra concordar com os critérios pelos quais avaliaremos o dano e com seus valores limite. Se esses limites forem excedidos, consideraremos o dano crítico e o intervalo de tempo em que o valor limite é atingido se tornará o tempo de recuperação desejado. Duas opções foram sugeridas:

• determinar a RTO por um critério - perdas financeiras;
• determine a RTO por três critérios - perda financeira, perda de reputação, perda de controlabilidade dos processos de negócios.

A primeira opção com um critério parece ser preferível, pois qualquer perda pode ser condicionalmente convertida em dinheiro - o principal é concordar com uma fórmula de recálculo. Mas, como mostra a prática, ninguém contabiliza especificamente perdas de reputação em perdas financeiras, e a aprovação dessa fórmula pode levar um tempo indefinido. Foi decidido considerar o tempo de recuperação para ambas as opções e, na fase de apresentação dos resultados, o próprio cliente determinará qual reflete a realidade de maneira mais objetiva.



Olhando para o futuro, direi que, ao usar a primeira opção com um critério, a RTO no processo de "precificação", por exemplo, pode chegar a 10 dias. Ao calcular a segunda opção, o RTO não excedeu 24 horas. De qualquer forma, a decisão da administração - quais perdas considerar e quais não - permanecem com o cliente.

Os riscos

Juntamente com o cliente, determinamos a lista de riscos operacionais. Ou seja, aqueles que afetam a TI e os que, por sua vez, afetam os processos de negócios que ... bem, você entende. Esta etapa é importante porque uma emergência não é considerada um cavalo esférico no vácuo, eles dizem o que acontecerá à Pátria e a nós se perdermos a TI. Os riscos foram divididos em global e local. Para cada um deles, foram determinados um cenário de desenvolvimento e impacto nos processos da empresa, levando em consideração os resultados da entrevista. Obviamente, o mesmo sistema de TI em caso de falha pode afetar vários processos de negócios, mas estávamos muito preocupados com apenas dois processos no projeto. Em seguida, avaliamos as reivindicações de acordo com os seguintes parâmetros:

• propagação de ameaças;
• a capacidade de alertar;
• duração da exposição;
• probabilidade de ocorrência;
• dano estimado.

Como resultado, eles desenharam um mapa de calor onde cada aplicativo recebia uma avaliação de quão quente a empresa poderia ser queimada durante o tempo de inatividade. Por exemplo, durante 4 horas de inatividade de módulos SAP individuais, a empresa ainda não recebe problemas sérios, mas mesmo as primeiras horas de tempo de inatividade do software da caixa registradora no mapa de calor são marcadas em vermelho ardente.

É necessário esclarecer que a avaliação de riscos e a classificação adicional são formadas com a ajuda de um grupo de especialistas e são necessárias para determinar as situações mais críticas para o cliente.

Risco e cenário contingentes. Incêndio no datacenter: a sala do servidor ficou completamente queimada, o módulo SAP envolvido no processo "Reabastecimento" não está disponível. Isso significa que todos os dias, até que o módulo SAP queimado seja restaurado, a gama de produtos é reduzida. Em primeiro lugar, trata-se de produtos perecíveis, em segundo lugar, produtos com alta demanda (por exemplo, cereais e pão) e, em terceiro lugar, produtos químicos domésticos. Obviamente, essa situação levará a uma diminuição na receita nas lojas. Mas isso não é totalmente óbvio: o comprador que veio buscar cerveja e cigarro, na ausência de um dos produtos, provavelmente não pode comprar nada. Da mesma forma para o processo de precificação. Se um comprador condicional que descobrir descontos na quarta-feira às 12:00 da tarde chegar à loja à tarde e o processo de "Preços" não funcionar (ou seja, preços sem descontos), ele:

A) não compra nada (= perda financeira);
B) acusará a loja de fraude (= perda de reputação)
B) reclama ao regulador (= penalidade por publicidade desleal).

Técnica de Estimativa de Perdas

Como você provavelmente já entendeu, para calcular as perdas financeiras, é necessário desenvolver uma metodologia e fórmulas para calculá-las, levando em consideração descontos, promoções, hora do dia, alta temporada (por exemplo, agitação no final de dezembro). A técnica deve conter uma parte descritiva (de onde vem e por que é multiplicada por fatores de ponderação), bem como tabelas e gráficos para maior clareza da percepção.

A técnica também descreve:

• Como o tempo de recuperação é determinado para um processo de negócios
• Como o tempo de recuperação de um processo de negócios se traduz em RTO / RPO para sistemas de TI
• classes de criticidade e classes de recuperação - por que isso é necessário.

Nós estamos indo além.

Cálculo de RTO

Após todas as entrevistas terem sido realizadas, os processos de negócios são descritos, os riscos são avaliados, uma metodologia é definida e aprovada e as perdas são calculadas. Como os negócios de Pyaterochka, Carrossel e Crossroads diferem pelo menos em escala - para cada rede, desenvolvemos nossas próprias tabelas, nossos próprios cronogramas e cálculos de perdas.

Para o processo de negócios como um todo, o tempo de recuperação é determinado (consulte a metodologia), quando as perdas excedem o valor limite (consulte limites). Esse tempo de recuperação é atribuído aos sistemas de TI envolvidos no processo de negócios (consulte a matriz de entrevistas e dependências). Parece que os parâmetros de continuidade estão definidos - o projeto está concluído (consulte limites e estrutura). Mas não basta dizer "o processo deve ser restaurado em 12 horas". É importante determinar como isso funciona agora. Quantas horas um sistema de TI pode ser reanimado hoje? E se o tempo de recuperação atual for maior ou significativamente maior que o objetivo? Para quem ainda mantém a razão e a concentração, seja bem-vindo ao GAP!

Análise de GAP e plano de ação

Como resultado das etapas anteriores, determinamos o estado dos processos e dos sistemas TO TO, ou seja, como deveria ser o ideal. No estágio atual, determinamos o estado de "COMO ESTÁ". Ao mesmo tempo, tocamos os processos de negócios em menor grau e focamos no componente de TI. Para o cliente, avaliamos suas soluções atuais em termos de recuperação de uma emergência. Além disso, neste caso, não era necessário realizar uma recuperação real com um temporizador. Foi o suficiente para aprofundar os detalhes e testar a área de trabalho o suficiente para entender que o RTO de destino é inatingível.

Depois disso, desenvolvemos várias recomendações, de natureza geral (para garantir a continuidade da TI) e diretamente relacionadas aos sistemas de TI e sua arquitetura. Estes são esboços de soluções técnicas e uma estimativa aproximada do custo de sua implementação. De fato, agora existe uma base para uma decisão. De um lado da escala - perdas e do outro - o custo das medidas.
Se alguns sistemas de TI não passam na análise GAP, ou melhor, seu tempo de recuperação é maior que o objetivo, criamos um programa de projetos para atingir o estado-alvo ou, se desejar, um roteiro com justificativa da sequência de projetos e uma avaliação intermediária para melhorar a sustentabilidade da organização.

Além disso, para o cliente, desenvolvemos materiais e modelos metodológicos para a formação de planos de continuidade e planos de recuperação de desastres.

Estratégia

Espere, espere, estou quase terminando.

Com base nos resultados da BIA, desenvolvemos uma estratégia de continuidade de TI. A estratégia de continuidade descreveu dois pontos principais.

1. Quais riscos de TI que afetam as atividades da empresa são levados em consideração e quais não são (ou seja, o que temos medo e que decidiremos no âmbito da continuidade, e do que não temos medo, e por isso temos gerenciamento de incidentes).
2. Que soluções organizacionais, arquitetônicas, de infra-estrutura e outras iremos defender contra ameaças.

Por estratégia, matamos dois coelhos com uma cajadada. Em primeiro lugar, todos na empresa entendem como e do que nos protegeremos. Em segundo lugar, para não especialistas em TI (por exemplo, financiadores), o processo de orçamento das soluções de recuperação de desastres de TI parece mais transparente. E, por mais patético que isso pareça, a estratégia ajuda a tomar as decisões gerenciais certas (sempre há a opção de não gastar dinheiro com DR, e agora sabemos exatamente como isso afetará a empresa em caso de acidente).

O que vem a seguir? Implementação adicional da estratégia de continuidade e análise de impacto nos negócios para outros processos de negócios e sistemas de TI. Desenvolvimento de planos de continuidade, testes periódicos desses planos, mas essa é uma história completamente diferente.

Igor Tyukachev, consultor, Jet Infosystems Design Center