Business Continuity Plan: Aspectos Críticos Para as Organizações

São frequentes as queixas, por parte de executivos de numerosas organizações, relacionadas com o elevado custo dos projectos de TI. Na sequência disso, mais vulgarmente do que seria desejável, o investimento em Business Continuity Plan (BCP) é preterido, como forma de amenizar os avultados valores associados a iniciativas dessa natureza.

As empresas que conseguiram impulsionar a sua vertente de e-business, empenhando-se diariamente na conquista de vantagens competitivas face à concorrência e na satisfação das expectativas dos clientes, têm encarado o BCP como fonte de atraso na concretização dos projectos (se é que ponderam sequer a hipótese de integração do BCP no ciclo de vida dos seus projectos TI).

Geralmente, este conceito é abordado apenas parcialmente, no sentido de manter redundância de dados e disponibilidade numa base diária. Raramente é aplicado em toda a sua abrangência e profundidade, sendo que o nível de planeamento desejável é implementado, muito frequentemente, após a concepção e implementação dos sistemas.

A publicidade desfavorável e a perda de confiança dos clientes podem acarretar, a médio/longo prazo, consequências bastante mais graves do que o tempo extra e os recursos aplicados no planeamento do BCP desde o início do projecto de TI. O BCP deverá ser aplicado ao ciclo de vida dos projectos TI, ao invés de ser encarado, numa perspectiva de negócio, como mais um novo produto em desenvolvimento. A razão que suporta esta afirmação é contundente: a falta de BCP ao longo de todo o ciclo de vida dos projectos constitui, para muitas empresas, uma fonte importantíssima de fragilidade e de vulnerabilidade.

A adição de BCP ao ciclo de vida dos projectos configura parte do processo para a colocação do BCP à escala da organização, o que inclui a criação de uma política de continuidade de negócio, gestão de crise, planos de contingência e de evacuação de pessoal e planos de gestão.

O Disaster Recovery Plan (DRP) destina-se a fazer face a catástrofes de grande impacto, mas com fraca probabilidade de ocorrência (inundações, por exemplo). Envolve meios de vulto, como instalações alternativas (edifícios, equipamentos, etc.) e planos de deslocação de pessoas.

Os Meios de Continuidade de Operação devem permitir à empresa fazer face a incidentes comuns, como falhas de energia eléctrica, avaria de um servidor ou quebra de comunicação.

Os Processos de Contingência são constituídos pelos manuais de procedimentos que regulam a actividade da empresa em caso de falha dos meios técnicos ou outro problema que afecte a actividade da empresa (por exemplo, falha de fornecedor).

Os Procedimentos de Activação definem quando, como e quem deve accionar cada uma das três componentes do BCP referidas atrás. Normalmente são feitas as seguintes distinções:

• Lista dos responsáveis pela avaliação e declaração do problema;
• As normas de classificação do incidente (para posterior activação da componente adequada do BCP - por exemplo, a inundação de um edifício constitui uma catástrofe e activa-se o DRP);
• A cadeia de alerta (lista, ordenada por prioridade, das pessoas a contactar em caso de necessidade).
• Abordagem para um DRP/BCP adequado às necessidades da organização

A gestão de um DRP (ou de um BCP) é um processo recorrente que garante o alinhamento entre os meios de recuperação e o negócio. O objectivo da gestão do negócio para a primeira fase do ciclo de vida de um projecto de TI consiste na identificação de requisitos de alto nível relacionados com a continuidade do negócio para o novo sistema. As actividades que deverão estar completas no final desta etapa incluem:

1. Business Impact Analysis (BIA). Será o novo sistema crítico para a missão da organização? Que áreas de negócio serão afectadas e por quanto tempo? Da análise de impacto no negócio (BIA) resulta a definição de conceitos/noções importantes, nomeadamente:

• Cost of Downtime Analysis. Qual o impacto das perdas financeiras, reputacionais e de produtividade se o sistema estiver indisponível por um certo período de tempo?
• RTO (Recovery Time Objective). O lapso de tempo dentro do qual o sistema deverá estar de novo em produção, após a ocorrência do desastre.
• RPO (Recovery Position Objective). Posição recuperada, em termos de dados, correspondente ao último backup efectuado (independentemente de este ter sido realizado 24 horas ou 2 minutos antes do desastre).

2. Uma revisão do impacto do novo sistema nos processos e sistemas de negócio correntes, a qual garantirá que os requisitos de continuidade de negócio poderão ser suportados através de todo o fluxo de processamento. Poderão, neste ponto, ser necessárias alterações em processos e sistemas de negócio de suporte ou interdependentes que requeiram design, desenvolvimento, implementação e financiamento adicionais, não antecipados apenas sob a perspectiva do novo sistema.

Fonte: Pós-graduação em Sistemas de Informação; UAL.

Em suma, o ciclo de gestão de um DRP (ilustrado na figura), inicia-se com o Business Impact Analysis (BIA), a que se segue a definição e implementação da solução de DRP. Destaca-se a importância da manutenção e actualização da solução de DRP. É aqui que reside essencialmente o carácter cíclico da gestão de um DRP.

Este último não é algo estático que, após implementado, possa conservar-se imutável, sob pena de ser ultrapassado pelas constantes alterações características das TI e dos próprios ambientes de negócio, tornando-se ineficaz. Assim, deverá ser regularmente analisado, actualizado e adaptado a novas condicionantes (para que esteja permanentemente em condições de ser aplicado com sucesso, caso seja necessário) que possam, eventualmente, ter surgido. Desta forma, o ciclo repete-se para a promoção dos reajustamentos necessários.

Produzido em 2005