Feeds:
Posts
Comentários

Posts Tagged ‘Framework ITIL V3’

Como-implementar-processos-e-controles-para-o-compliance-de-ti-atraves-do-licenciamento-de-uso-de-um-framework-modularizado-e-contendo-documentos-processos-controles-e-workflow-para-cada-um-dos-padroes-desejados

Como Obter Compliance de Processos de TI,  com o licenciamento de uso de um framework  contendo documentos,  processos, controles para cada um dos padrões desejados,

(COBIT, ITIL V3, COSO, PMO,  ISO-27002, ISO-20.000, ISO-27.005, GOVERNANÇA E SARBANES-OXLEY))

1- Introdução / As motivações…

Via de regra nos deparamos com debates calorosos com relação ao alto custo, tempo e esforço necessário para adotar alguma prática ou padrão nos processos e controles de área de Tecnologia da Informação, e não é para menos,  se observarmos rapidamente a nossa volta  a quantidade e diversidade Padrões, Normas, Bibliotecas ou ainda de recomendações e melhores práticas que poderiam ser aplicadas e as vantagens que cada uma poderia trazer para a qualidade e efetividade dos serviços prestados pela TI ao negócio,  pode ser o sonho de qualquer gestor,  no entanto ao estudar melhor cada  padrão, o volume requerido de tempo, esforço e investimentos necessários para colocar isto ou aquilo em prática,  faz com que os debates sejam de fato calorosos e não raro,  são vencedores aqueles que postulam direcionar os escassos recursos existentes em ações que efetivamente produzem resultados práticos e palpáveis para o negócio (Máquinas, infraestrutura e  Aplicações) ou ainda,  programas de treinamento e certificações com visão futura de um dia, com os próprios recursos internos evoluir nesta ou naquela direção em termos de obter o necessário Compliance nos processos e controles na TI. Foi em busca de uma solução que viabilizasse este tipo iniciativa que nos motivou a criar este conjunto de FRAMEWORKS contendo processos e controles para o COMPLIANCE DE TI, denominados AGHATHA Framework.

Convidamos você a conhece-los um pouco mais …

2 – Visão Geral da Solução.

Tratamento dos padrões e recomendações através de Níveis sucessivos de  Detalhamento (Camadas) a partir de um modelo geral, seus padrões e Grupo de Processos, Processos e seus controles possibilita ao usuário uma visão inicial de alto nível de cada modelo e  padrão de Compliance, e através de navegação dinâmica (drill-dow), entre os diversos componentes tornam mais fácil e agil a localização e o acesso aos diversos documentos que compoem cada padrão e por fim,  o detalhamento das informações adicionais contidas cada Norma, Processo e Controle compleentam a base de conhecimento necessária para aplicação rápida e eficiente dos requisitos.

Vejamos um Exemplo desta abordagem, e os recursos de visualização disponível em cada padrão que compões a solução : AGHATHA – FRAMEWORK DE PROCESSOS E CONTROLES PARA O COMPLIANCE DE TI.

Nivel 0 – Visão Geral dos Padrões e Componentes de Compliance.

Nivel mais alto de visão dos padrões e melhores práticas, promove a visualização das integrações em nível macro entre os diversos padrões.

Nivel 1 – Visão Geral do Padrão Específico de Compliance.

Nivel intermediário, que possibilita uma visão geral de cada padrão ou melhor prática, promove a visualização das integrações entre os diversos grupos de processos que compoem cada padrão ou melhor prática individualmente.

Nivel 2 – Visão Geral do Grupo de Recomendações do Padrão de Compliance

Nivel mais detalhado de um Grupo de Processos, indicando as Politicas, Normas e Procedimentos relacionados ao controle e promomento a visão de integração e relacionamentos entre cada processo e seus controles.

  •  Abordagem Utilizada:

 
 

a)      Política – Representa o nível estratégico das normatizações de segurança e descreve às “DIRETRIZES” sobre as quais se baseiam a Segurança da Informação,  descrevem  ‘o que deve ser feito’.

b)      Normas – Representa o nível tático das normatizações e referem-se às Normas que regem a Organização da Segurança da Informação. São baseadas nas Políticas e descrevem as “REGRAS” a serem adotadas para o cumprimento das diretrizes contidas na Política da segurança e previamente estabelecidas.

c)      Procedimentos – Representa o nível Operacional das normatizações e referem-se aos procedimentos que regem as atividades relacionadas à Organização da Segurança da Informação. São baseadas nas Normas e definem “COMO” as regras serão implementadas e operacionalizadas.

d)     Evidências, artefatos e controles – Representa o resultado material dos processos. São baseados em artefatos ou controles produzidos pelo nível operacional para atender aos requisitos da Segurança da Informação.

Nivel 3 – Visão do Processo necessário para Aplicação da Recomendação  indicada pelo Padrão de Compliance

  

Nivel mais baixo e detalhado, indica os componentes existentes em cada processo, suas atividades, interações, regras e métricas de execução de cada atividade, responsaveis e como de fato o padrão deve ser adotado.

a) Visão dos Componentes de Normatização – Regras Formais

b) Visão dos Componentes de Procedimentos  – Processos, Controles e Registros Formais

 


 

c)  Workflow –  Automatização Mensagens e Eventos

3 – Como é Possível obter acesso ao Uso desta Solução?

 

3.1 – Licenciamento Eletrônico.

Disponibilizamos os Frameworks através de nossa Loja Virtual (www.aghatha.com), onde o arquivo contendo os modelos em cada padrão é disponibilizado eletronicamente, sendo acompanhados com istruções passo-a-passo de como aplicá-los em seus projetos nas empresas licenciadas.

http://www.aghatha.com

3.1 – Licenciamento – Embarcado em Projetos de Consultoria de Compliance em TI.

O AGHATHA – FRAMEWORK DE PROCESSOS E CONTROLES PARA O COMPLIANCE DE TI, é um produto baseado em notação própria para composição de WORKFLOW de atividades, sendo acompanhado de documentação formal para obtenção de Compliance a um determinado padrão ou norma em particular.

A AGHATHA utiliza-se deste modelos em seus projetos de consultoria, como aceleradores de projetos. Os modelos são licenciados para uso perpétuo pelos clientes de forma embarcada no contrato de prestação de serviços de consultoria.

3.2.1 – Diagnósticos On-Site

Os profissionais da AGHATHA realizarão um Diagnóstico atual dos níveis de maturidade corrente dos processos e controles em uso no ambiente do cliente, indicando o relatório de itens a serem implementados para a obtenção do Compliance desejado.

Os valores investidos no diagnóstico são abatidos do custo das licenças de uso, caso o cliente confirme o licenciamento dos módulos do AGHATHA –  FRAMEWORK  DE PROCESSOS E CONTROLES DE TI.

3.2.2 – Consultoria on-Site para Documentação e Padronização de Processos Pré-Existentes

Os profissionais da AGHATHA  poderão mapear, revisar, documentar e padronizar os processos existentes seguindo os mesmos padrões utilizados no AGHATHA –  FRAMEWORK  DE PROCESSOS E CONTROLES DE TI, mediante proposta de serviços de consultoria técnica e de processos de TI.

3.2.3 – Consultoria Técnica (On-Site) – Padrões de Compliance

Os profissionais da AGHATHA  poderão efetuar consultorias Pontuais ou Por períodos agendados sob demanda on-site, para realização de treinamentos, coaching, mentoring para aplicação de padrões e solução de problemas relacionados ao processo de Compliance em cada padrão existente no AGHATHA –  FRAMEWORK  DE PROCESSOS E CONTROLES PARA O COMPLIANCE DE TI, mediante proposta de serviços de consultoria técnica e de processos de TI.

3.2.4 – Consultoria Técnica (Remota) – Padrões de Compliance

Os profissionais da AGHATHA  poderão efetuar consultorias Pontuais ou Por períodos agendados sob demanda remotamente, para realização de treinamentos, coaching, mentoring para aplicação de padrões e solução de problemas relacionados ao processo de Compliance em cada padrão existente no AGHATHA –  FRAMEWORK  DE PROCESSOS E CONTROLES PARA O COMPLIANCE DE TI, mediante proposta de serviços de consultoria técnica e de processos de TI.

As seções remotas de consultoria, reuniões de trabalho e treinamentos são realizadas através do uso de soluções de videoconferência.

4– Onde estamos Localizados / Escritórios .

Tire suas dúvidas por E-mail através de nosso contato técnico:  consulting@aghatha.com .

5- Deseja Conhecer melhor o – AGHATHA – FRAMEWORK DE ?

Visite nosso website, lá você poderá acessar uma versão de testes e totalmente funcional e contendo algumas informações e funcionalidades presentes em nosso Framework.

http://www.aghatha.com/index.php/framework.html

www.aghatha.com/processos.htm

———-

· Download do conteúdo deste Artigo :

O Conteúdo deste artigo está disponível para download no formato Arquivo (PDF) na pagina Free Whitepaper publicada em nosso site

www.AGHATHA.com , acessando a pagina : http://aghatha.com/index.php/whitepapers.html , você poderá realizar o download do mesmo gratuitamente.

Faça-nos uma visita, caso opte por assinar a Nossa Newsletter, você passará a receber avisos de atualizações e ampliações do conteúdo deste artigo e/ou comunicados sobre a publicação de outros artigos relacionados com este mesmo assunto.
———-

6– Termos e Condições Gerais – Licenciamento de Uso.

6.1 – DECLARAÇÃO DE  DIREITOS AUTORIAIS E DE PROPRIEDADE INTELECTUAL (Copyrights / All Rights Reserved ).

Da Declaração dos Direitos Autorais e de Propriedade.

– O Conteúdo Integral desta “OBRA” é protegido por Lei e possui todos os Direitos Autorais Reservados e são de propriedade intelectual de forma “EXCLUSIVA” em nome de AGHATHA MAXI CONSULTING (TITULAR DOS DIREITOS) em nome do Autor ou dos seus sucessores legítimos. (www.aghatha.com/index.htm – Av. 21 de Setembro, 554 – 95046-460 – Caxias do Sul – RS – Brazil).

Da Qualificação Legal da Obra e do Direito de Propriedade:

Para todos os efeitos legais desta declaração, considera-se “OBRA” todos os componentes,  bases de dados, coletâneas e compilações, correlações entre os conteúdos dos diversos Padrões e Melhores Práticas e ainda, do conteúdo de outras obras e experiências técnicas pessoais, cuja as referencias foram utilizadas, adaptadas, explanadas, compostas, utilizadas na composição de exemplos e casos de uso quanto a sua melhor forma de aplicação, definição de formatos, sequencia e disposição de atividades em processos, fluxos,  conteúdos de informações necessárias, citadas e não limitadas ao disposto no item (CONTEÚDO), desta declaração são classificados de “PLENO e AMPLO DIREITO”  como “CRIAÇÃO INTELECTUAL” e “OBRA” do autor e propriedade legal da “TITULAR DESTES DIREITOS” ,  sendo todos estes elementos considerados “partes integrantes, Incluídos, referenciadas e Utilizadas”  na composição dos produtos, módulos e serviços  identificados comercialmente como:  “AGHATHA – FRAMEWORK PROCESSOS E CONTROLES PARA O COMPLIANCE DE TI – TECNOLOGIA DA INFORMAÇÃO” e doravante referenciado simplesmente como “OBRA”.

Das Obrigações de NÃO FAZER  – USUÁRIO LICENCIADO.

– É “VETADO” ao “USUÁRIO FINAL” desta “OBRA”,  mesmo na condição de “USUÁRIO LICENCIADO PERPÉTUO”, COMUNICAR, CEDER, EMPRESTAR, VENDER, ALUGAR, LICENCIAR, SUB-LICENCIAR, ENVIAR, PUBLICAR ou executar ou facilitar “QUALQUER AÇÃO”  seja esta por “AÇÃO DIRETA OU INDIRETA, OU AINDA POR OMISSÃO DE GUARDA” e que venha resultar na “TRANSFERENCIA” de conteúdo “TOTAL” ou “PARCIAL” desta “OBRA” para terceiros, quer sejam eles, de natureza física ou jurídica.

Do Uso Ilegal e Não Autorizado – USUÁRIOS NÃO LICENCIADOS.

– É expressamente “PROIBIDO” a qualquer pessoa física ou jurídica o uso não autorizado “TOTAL OU PARCIAL” desta “OBRA” sem a pré-existência da respectiva e legitima “LICENÇA DE USO”, sendo também “PROIBIDAS” quaisquer ações relacionadas à sua comercialização, distribuição não autorizada de copias,  uso de quaisquer métodos de engenharia reversa para a obtenção de códigos fontes, informações e parâmetros utilizados em sua composição, acesso ou uso não autorizado do “CONTEÚDO” protegido desta “OBRA”.

Porto Alegre, RS, Brasil, fevereiro de 2012.

Read Full Post »

COMO REDUZIR CUSTOS EM TI ATRAVÉS DA APLICAÇÃO RACIONAL DOS OBJETIVOS ESTABELECIDOS PELA GOVERNANÇA TI – Parte 1

Como reduzir custos em TI através da aplicação racional dos objetivos estabelecidos pela Governança TI – Parte 1

Muitas vezes nos deparamos com a dificuldade dos Gestores de TI em identificar vantagens econômicas na adoção de boas práticas e padrões da TI tais como, (ISO/IEC-27.002, ISO/IEC-20.000, ITIL V3, COBIT, COSO, ISO/IEC-12.207 e tantas outras. Em razão disto, daremos inicio a uma série de artigos abordando cada padrão individualmente e lhes enumerando algumas sugestões e alertas nesse sentido.

O conteúdo abordado neste artigo não é e nem pode ser considerado como algo definitivo, uma vez que existem disciplinas especificas e destinadas à completa gestão do planejamento e controle orçamentário em geral.

Nosso objetivo e identificar algumas diretrizes e práticas contidas no COBIT que podem promover ou gerar alguma economia de receitas ou em alguns casos até mesmo promover a geração de resultados econômicos como consequência da sua adoção no conjunto de boas práticas em TI. Neste artigo trataremos situações contidas e referenciadas no primeiro Objetivo previsto no COBIT, denominado PO – Planejamento e Organização.

1 – Matriz de Custos em Tecnologia da Informação.

Primeiramente é necessário tratar alguns conceitos gerais que nos serão bastante úteis no entendimento dos custos e benefícios que por ventura possam vir a ser explorados pelo Gestor de TI.

Devido a grande quantidade de variáveis contidas no universo da TI, vamos evoluir nossas abordagens através da regra (80/20), estabelecida pelo economista Italiano Vilfredo Pareto, onde: “80% dos problemas estão concentrados em 20% das possíveis causas”, com o objetivo de focar as analises e sugestões naquilo que realmente possa ser relevante.

1.1 – Grupos de Despesas

Por “convenção”, de uma maneira geral, vamos classificar os custos envolvidos de acordo com os seguintes grupos principais de possíveis despesas em TI.

  •  Aquisição de Infraestrutura,
  • Aquisição de Sistemas / Aplicações,
  • Aquisição de Mão de Obra (Pessoas),
  • Aquisição de Serviços,

Utilizaremos estes grupos na medida em evoluirmos a avaliação das práticas e recomendações e indicando algumas sugestões de reduzir estes custos através da aplicação das práticas envolvidas em cada análise:

É importante lembrar que algumas despesas, economias ou resultados a serem obtidos podem ocorrer uma única vez ou ainda, podem ocorrer de forma recorrente (Por evento, Mensal, Semestral, Anual):

Ex:

  •  Ao ser adquirido um novo Servidor ou um novo Software, além dos valores relacionados à sua aquisição e instalação/implementação, passaremos a ter outros custos recorrentes relacionados à sua manutenção, upgrade de sistemas operacionais, energia elétrica, suporte da equipe ao equipamento, etc..  (= TCO – Custo de Propriedade).
  • Ao ser eliminado um Sistema / Aplicativo: Há redução dos custos recorrentes de Manutenção, renovações de licenças de uso, alocação de serviços de suporte, custos de desenvolvimento que não serão mais necessárias realizar.

1.2 – Fatores Geradores de Despesas em TI  – “Gatilhos”.

Há ainda grupos de necessidades a que poderíamos classificar como “Gatilhos”, pois atuam como fontes de demandas ou de necessidades, que nos levam a realizar novos investimentos em TI.

Para exemplificar, vamos listar alguns “gatilhos”: Atender novas necessidades do Negócio, mitigar Riscos, Upgrades,  Nível de serviço, Disponibilidade, Performance, Capacidade, Segurança, Requisitos legais entre outros desafios a que os gestores de TI estão sujeitos a tratar no seu dia a dia.

 

 2 –   COBIT – PO Planejamento e Organização

Este objetivo é muito importante, pois as ações de planejamento e organização direcionam as ações conduzidas nos objetivos dos capítulos AI – Aquisição e Implantação e DS – Entrega dos Serviços.

2.1 – Alinhando TI ao Negócio:

Adotar critérios de alinhamento ao negócio pode auxiliar a reduzir custos em TI e em alguns casos até promover a geração de receitas  ao negócio:

  •  Direcionar ações e investimentos que “agregam valor” ao negócio.

TI proporciona “valor agregado” ao negócio quando lhe oferece diferenciais competitivos através da aplicação da Tecnologia, ou seja: Fazer mais em menos tempo, mais com menos esforço, mais com menos custo, mais nível de serviço ao produto do negócio, mais funcionalidade ao produto do negócio, e tantos outras.

Embora seja razoavelmente fácil entender estes valores, não é uma tarefa muito simples colocá-las em prática, pelo menos inicialmente, em identificar situações que promovam dois, três ou até mais “valores agregados” de forma simultânea, mas lhes garanto que esta dificuldade diminui com exercício de planejamento e execução de projetos e quando se adota o nesta atividade, o  critério citado acima como sendo uma regra geral.

Ex:

Já vivenciamos situação onde um Gestor de TI de uma determinada empresa, iniciava o ano com uma bolsa de valores a serem investidos, apuradas com base neste critério e um plano de ação previamente acordado com os gestores das áreas de negócio identificando as iniciativas e prioridades de execução. Este valor era então destinado às equipes destacadas para a execução de cada iniciativa.

Cada iniciativa deveria promover como resultado econômico do projeto um determinado índice de retorno (Payback) a ser calculado com base no valor investido. Ao final do  projeto o retorno efetivo para o negócio era apurado e o capital investido era retido (Devolvido ao Negócio), e somente as sobras (Eficiência econômica do Projeto), retornavam para o montante destinado a prover os investimentos dos demais projetos daquela mesma  equipe.

Depois de alguns anos, o CIO passou a iniciar o ano com apenas 3/5 do montante necessário para promover todas as iniciativas em TI, e resultado obtido pelos próprios projetos deveriam gerar o montante necessário para a execução dos restantes 2/5.

Assim sendo, nesta empresa não havia nenhuma iniciativa que de fato não agregava valor efetivo ao negócio e as equipes aprenderam com o passar dos anos a propor iniciativas que efetivamente proporcionassem retornos e consequentemente valor ao negócio,  e que ainda, pudessem prover sobras suficientes para realização de outros projetos.

Um fato interessante sobre este caso é que mesmo em tempos de crises,  esta empresa não reduzia os valores destinados aos investimentos em TI, e o orçamento de TI era sempre o primeiro a ser aprovado pela empresa, e por motivos óbvios.

Este é o poder de uma Diretriz aplicada e orientada a trazer vantagens e competitividade ao negócio, pois se reduziam tempos, custos, esforços, agilizavam-se entradas e saídas de materiais, reduzia-se o tempo de produção, eliminavam-se tarefas desnecessárias e assim por diante.

Traçar diretrizes que tragam resultados é uma ação de inteligência e surte os efeitos desejados hoje e no decorrer do tempo, sobretudo pela liderança do Gestor em relação motivação de suas equipes em mantê-la ativa e gerando os resultados desejados durante muitos anos.

Alertas:

  •  Nos casos onde não há a adoção de critérios técnicos  para a proposição de soluções e projetos em TI, é possível que algumas iniciativas venham a  apresentar resultados não concretos para a organização e ainda fortalecer a imagem de que a  TI seja apenas uma fonte de custos para o negócio.
  • Mesmo que o alinhamento das demandas seja totalmente orientado a oferecer valor agregado ao negócio, se estes resultados não forem mensurados e previstos “antes” e confirmados “depois” da conclusão dos projetos, poderá surgir duas situações possíveis:  Ou a iniciativa não cumpriu o que se propunha a realizar e nunca saberemos os reais motivos, Ou a iniciativa foi concluída com pleno êxito, e nunca saberemos se ele o resultado foi em razão da competência da equipe ou simplesmente uma (“Obra do acaso”). Ou seja, qualquer iniciativa que se proponha a gerar valor ao negócio, deve prever o “quanto” e o “como” o negócio será beneficiado. Somente assim, os resultados obtidos poderão ser validados e poderemos evoluir nos critérios de avaliação de novas iniciativas.

2.2 – Arquitetura da Informação.

Embora o COBIT trate fortemente este assunto mais orientado a Arquitetura da Informação, Conteúdo dados, Desenho modelo dados, Dicionário de Dados, iremos abordar aqui a “Arquitetura” de forma mais ampla, pois a arquitetura da informação requer outras camadas, para lhe prover suporte e/ou sustentação e que também necessitam possuir algum modelo ou padrão de arquitetura relacionado. Como a nossa ênfase aqui é analisar as possibilidades de redução de custos, seguiremos nesta linha, pois ela irá nos proporcionar mais opções a explorar.

Estes modelos de Arquitetura se fazem necessários para manter e suportar a Arquitetura da Informação e que também devem ser alinhados a atender aos objetivos e necessidades do negócio, tais como: Arquitetura de Comunicação de Dados, Servidores, Estações Trabalho, Sistemas Operacionais, Serviços (e-mail, Active directory, VMs, Sistemas e Aplicações de suporte ao negócio, e etc.

Se entendermos que todos estes modelos, sejam camadas sucessivas e posicionadas acima ou abaixo da camada das  informações com o objetivo de juntas proporcionarem suporte e sustentação aos dados, podemos dar inicio a nossa analise de custos.

Adotando um  modelo de arquitetura que represente um ambiente de TI,  que possa interagir de forma integrada e convergente entre si e  que facilite ainda  as integrações técnicas entre as camadas e equipes envolvidas, é certo que custos destinados a upgrades, suporte, integrações, pessoal, serviços de manutenção e outros serão mantidos sob controle a médio e longo prazo. Isto somente será possível se os modelos definidos, uma vez adotados, sejam de fato considerados como um  “padrão a ser seguido ou perseguido por todos” ,  no momento de propor / avaliarem as possíveis alternativas de soluções para o atendimento das demandas da TI.

Vejamos um exemplo de uma diretriz que possibilite este tipo de economia ou redução dos custos:

  •  As Soluções propostas para a TI devem estar alinhadas aos padrões e modelos de arquitetura vigentes.

Por mais singelo que isto possa parecer, esta diretriz certamente proporciona redução de custos e ainda auxilia a prevenir muita dor de cabeça aos gestores de TI ao longo do tempo, vejamos como:

Caso não exista um padrão técnico que sirva de filtro as proposições de solução as  demandas de TI, é mais provável que as soluções atendam ao proposito único das necessidades que as deram origem, e este aparente grau de liberdade passará a promover lenta e progressivamente o que denominamos “O efeito da Torre de Babel” em TI, ou seja, teremos em um futuro muito próximo uma variabilidade tal de soluções e variantes de arquiteturas,  que se fará  necessário para mantê-las a contratação de uma infinidade de novos cargos e/ou funções adicionais em TI  (Um DBA para cada banco de dados a ser suportado: Oracle, SQL Server, MySQL, …), Um especialista de Suporte aos Sistemas Operacionais (Windows, Linux), Equipes de Manutenção para cada plataforma a ser mantida e integrada (Abap, .Asp. .Net, Java, …) e ainda em função das demandas e integrações do negócio, e muito possível uma vez ou outra promover  interfaces entre as soluções através de investimentos com aquisição de bens e/ou serviços.

Normalmente quando nos damos conta deste “efeito”, pode ser tarde demais para promover algum tipo de convergência ou padronização das arquiteturas existentes por ser tecnicamente inviável ou custar muito caro.

É possível que este seja o motivo mais comum para os seguintes efeitos:

  •  Estruturas de TI com elevado “head-count”  de pessoas e cargos,
  • Nível de granularidade / especialidades técnicas muito distribuídas,
  • Interferência atuação desintegradas entre as equipes de TI,
  • Surgimento de Ilhas Tecnológicas,
  • Aumento do tempo e esforço requerido para definição e aplicação de soluções aos problemas/ atendimento de demandas,
  • Indisponibilidade de recursos técnicos especializados e em numero suficiente para atender a todas as tecnologias e plataformas existentes (elevado valor com terceirizações e serviços complementares).
  • Elevação de custos e complexidade em atendimento mesmo para demandas simples ou não muito complexas.

Todos estes efeitos a que as equipes de TI estão expostas e consequentemente os custos necessários para a sua manutenção  são invariavelmente consequências impostas pelas limitações técnicas de integração entre as plataformas e tecnologias a que estas mesmas equipes devem oferecer suporte.

Alertas:

  •  Como a tecnologia é bastante dinâmica, não podemos levar este critério ao “pé da letra”, pois estaríamos bloqueando a entrada de novas tecnologias e/ou  inovações que poderiam ser utilizadas a favor do negócio. Devido a esta hipótese, quando uma iniciativa propõe algo que não esteja alinhado aos padrões vigentes, antes de lhe bloquear o prosseguimento, há de se ponderar se a “novidade” irá ou não agregar valor ao negócio (hoje, amanha ou por um bom tempo até que algo melhor lhe venha a substituir).  Se depois de ponderada, a resposta for positiva, pode-se agregar mais um padrão ao modelo de arquitetura ou ainda dar inicio a migração de um padrão existente para um novo padrão mais eficiente ou que promova maiores resultados para o  negócio. É assim que os modelos de arquitetura evoluem no tempo e proporcionam valor ao negócio. (Em função disto, devem ser controladas as diferenças entre uma versão e a outra dos padrões de arquitetura, e ainda, mantidos os registros históricos das avaliações e justificativas utilizadas na época em que mudanças foram adotadas).
  • Não devemos esquecer que uma vez modificado as bases da arquitetura vigente, se ganha com isto uma nova missão: “migrar o legado existente para o novo padrão proposto” (Alterar padrões de Arquitetura é um forte “gatilho” para geração de despesas em TI, e não migrar acarreta o fortalecimento do efeito “torre de babel”), portanto, este assunto deve ser tratado com muita cautela.
  • Não se deixe levar por modismos ou termos de ocasião,  ou isto custa caro hoje ou pode custar  muito mais caro amanhã, diante disto considere os custos e esforços de migração do legado quando houver necessidade de mudanças em plataformas de tecnologia, ou prepare-se para justificar o aumento do “head-count” de TI e revisar os valores previstos para investimentos em treinamentos, certificações, processos e controles adicionais e tudo mais que poderá advir,  e que certamente se farão necessários.

 2.3 – Processos, Organização e Relacionamentos de TI.

Neste item o COBIT nos propõe, talvez o seu objetivo mais importante, pois nenhuma outra recomendação ou objetivo será de pleno factível se não houver processos formais que promovam a sua organização, execução, controle e monitoramento dos resultados obtidos.

Os processos formais tem esta função e de fato transformam as iniciativas em ações recorrentes no dia a dia das organizações.  Veja um outro artigo nosso, indicando instruções para formatar e organizar processos para implementar boas práticas em TI , incluindo um modelo de template para ser utilizado como plataforma de organização dos processos em TI:  https://aghatha.wordpress.com/2011/06/18/como_formatar_e_organizar_a_documentacao_de_processos_ti/ )

Um processo necessita atender a alguns requisitos para ser efetivo de fato, são eles:

As atividades de TI devem ser suportadas através de processos formais que determinem claramente:

    • O que deve ser feito,
    • Porque deve ser feito,
    • Quem deve fazer,
    • Como deve ser documentado,
    • Como será monitorado ou mensurado,
    • Quais são os critérios de qualidade serão aplicados para a sua avaliação e promoção de melhorias.
    • Alguns motivadores para justificar a formalização e padronização através de processos:
      • Principio da geração de conduta, onde a regra escrita promove uma conduta ou resultado desejado a um determinado público,
      • Principio de Melhoria continua dos processos, através da repetitividade de execução e avaliação contínua dos resultados e identificação de melhorias,
      • Principio da previsibilidade das ações e dos resultados esperados,
      • Principio da materialização dos fatos, através de registros e evidencias produzida pelas ações realizadas.

Qualquer iniciativa em algum momento irá requerer a necessidade de execução repetitiva de alguma ação ou atividade com objetivo de produzir um determinado resultado: executar um conjunto de atividades, promover um controle, produzir uma evidência ou ainda, comunicar um fato ocorrido a uma determinada pessoa ou grupo de pessoas.

Realizar isto, sem que haja um guia formal indicando o que deve ser feito,  quem são os responsáveis, quando e como deverão ser executados,  para uma ou duas atividades, se combinarmos bem o que deve ser feito com os atores envolvidos,  até poderá se tornar possível, mas quando se tem necessidade de adotar um conjunto de práticas e com a necessidade de execução de 20 ou 30 processos, cada um contendo diversas atividades e atores distintos,  isto se torna  impraticável, correto?.

Para facilitar o entendimento: Os processos têm como componentes fundamentais: entradas, processamentos e saídas e, se alinharmos estes componentes de acordo com a lógica de construção de algum resultado esperado ou desejado, verá que isto possibilita ao gestor atingir efetivamente quaisquer resultados que seja por ele  proposto.

Quanto mais integrada e eficiente for uma equipe através dos processos, maiores serão as chances e possibilidades de reduzir e/ou economizar recursos, pois as equipes poderão ser dimensionadas sem que haja sobrecarga ou sobreposição de atividades, eliminar retrabalhos e conflitos desnecessários, reduzir a incidência de erros operacionais, eliminar a omissão de práticas requeridas pelo negócio ou pela legislação, e assim por diante.

Melhorias operacionais com base nas analises de processos existentes, proporcionam o dimensionamento dos custos envolvidos,  simplesmente comparando quanto custava um processo antes da aplicação da uma melhoria e qual será o valor  após a aplicação da mesma. Multiplicando o valor da diferença apurada pela quantidade de eventos executados em um mês,  e o produto deste cálculo,  multiplicado pelos 12 meses do ano, passamos a perceber quanto uma melhoria em algum processo pode impactar economicamente no orçamento da TI;

O tempo de implantação ou de adoção de melhores práticas pode ser reduzido em muitos meses de trabalho, quando se opta pela utilização de frameworks ou pacotes contendo modelos de processos já testados e validados.

É mais fácil, econômico e muito mais eficiente adaptar e integrar modelos existentes do que “costurar processos sob medida a partir do zero”, simplesmente com base na percepção de que empresa onde atuamos “é diferente” das demais.

Alertas:

  •  Nossa experiência nos diz que o índice de variação entre os processos de uma empresa e outra, somente em casos absolutamente raros ultrapassa a 30% (seja qual for o segmento, tamanho ou complexidade), no entanto,  a diferença de valores a serem dispendidos comparando uma situação com a outra, poderá variar entre 10 a 20 vezes mais e levar 10 vezes mais tempo e esforço, ficando ainda gap´s de integração por serem otimizados ou implementados posteriormente.
  • Nos casos onde as Organizações optam por “costurar” seus processos internamente. Nestes casos, há de ser verificado se os processos resultantes atendem de fato aos requisitos e objetivos propostos pelo padrão ou prática que se deseja adotar. É comum observar adaptações  “míopes”, onde o padrão é  “atendido” e mesmo com a evidência do  “processo formal”, depois de uma análise mais apurada,  de todos os detalhes existentes em comparação com a melhor prática, verificamos que a “idéia” não foi completamente atendida, ou está sendo “praticada”  na forma “híbrida” ou “não recomendada”, ou seja, a melhor prática define o que deve ser feito, adotá-la parcialmente com a retirada de itens importantes e incluindo itens das práticas atuais não proporciona “em tese” o completo status de Compliance a uma prática/recomendação.
    • Ex1: (Já observamos diversas vezes a ocorrência deste exemplo em empresas de todos os tamanhos e complexidades) –  “PMO”- (Escritórios de Projetos), onde o colaborador responsável apenas tinha a função de recolher e consolidar as informações dos projetos existentes e os apresentava regularmente a um comitê de representantes de Organização. Com base nestas atividades os projetos eram “declarados sob controle”,  quando na verdade, as práticas e atribuições recomendadas para um Escritório de projetos promover o controle dos projetos deveria incluir Atividades de Fomento as práticas de Gerenciamento de Projetos, o que poderíamos listar aqui a algumas atividades compreendidas nesta função: Definir padrões, métodos e controles de gerenciamento de projetos, promover a integração das equipes envolvidas, Formar e treinar continuamente pessoas em técnicas de GP e nos padrões internos definidos pelo PMO, cogerir projetos, apoiar os GP na identificação e superação de dificuldades apresentadas pelos projetos (Mentoring/Coaching) em questões de planejamento, execução e controle, apoiar tecnicamente as ações corretivas  e o uso de ferramentas de apoio, e construir na forma mais efetiva possível os resultados a serem obtidos pelos projetos, e ao final de cada período apresentá-los aos gestores da organização em companhia dos GP envolvidos, reportando os acertos,  erros cometidos e das ações corretivas que já estariam sendo aplicadas para corrigir  ou melhorar os resultados a serem obtidos no próximo período/avaliação.
    • Ex2: (Já presenciamos casos onde outra empresa, onde o PMO executava todas estas atividades e realizava a cogerência e apoio ao grupo de GP existentes, e ainda apresentando excelentes resultados, mesmo realizado tudo isto em ainda co-gerenciando mais de 30 projetos em TI sendo executados simultaneamente. Tudo isto possível apenas pelo uso de uma metodologia que promovia a integração dos projetos ao negócio e aos demais processos de TI).
  • Devemos lembrar que os processos de TI devem promover as integrações, distribuir as responsabilidades e distribuir as cargas de trabalho observando os demais processos existentes. Caso o processo não atenda a estes requisitos, poderá promover a existência de “falsos gargalos”, onde uma série de atividades é interrompida, pela falta de comunicação de um grupo ao outro, que a etapa foi concluída, promovendo atrasos e perda de tempo na execução de uma ação. Em primeira análise a segunda equipe foi ineficiente, pois causou o atraso, mas na realidade há uma falha de integração entre os dois processos.
  • Caso você vivencie este tipo de situação, antes de tomar qualquer iniciativa, observe se os processos envolvidos são de fato integrados e se as entradas requeridas em processo são claramente identificadas nas saídas dos processos que lhes são fornecedores, se as responsabilidades estão claras, e etc… Ao traduzirmos esta ineficiência em custos ou prejuízos causados desnecessariamente ao negócio, é bem possível que você tenha uma surpresa.

Uma situação mais grave ainda é quando não há processo algum, onde todos estes problemas deixam de ser exceções e passam a ser regras, onde é comum escutarmos frases do tipo “eu fiz a minha parte…” e não há nenhuma evidencia ou registro daquilo que todos reportam terem realizado. É bem possível que à origem real da frase “administração do caos” tenha surgido a partir deste tipo de situação.

2.4 – Avaliar e Gerenciar Riscos

Gerenciar riscos é uma atividade que requer o uso de uma boa carga de bom senso. Não é raro observarmos situações onde se realizam investimentos visando mitigar um risco com montante igual ou até mesmo maior que o próprio dano econômico causado na hipótese da sua ocorrência.

A situação mais comum na tomada de decisão para mitigação de um risco é avaliar apenas o custo da ação direta ou principal destinada a mitigar um risco, comparado ao valor do possível dano causado  sem levar em consideração os custos secundários “gatilhos” que são disparados em consequência das ações adotadas.

Como estes custos normalmente não são observados ou considerados parcialmente, infelizmente não é raro observar casos onde figurativamente falando “Paga-se mais pelo seguro do automóvel do que o seu valor de venda no mercado” porque faltaram ser computados no custo de mitigação um ou mais efeitos secundários na tomada de decisão para a mitigação dos riscos.

Um critério a ser adotado é a determinação do nível de risco que a companhia estaria disposta aceitar  e traduzir este nível de apetite ao risco a um valor ou percentual em relação a algum índice do negócio (Ex: tratar Riscos individuais cujo impacto seja maior que X%  do valor do patrimônio e o impacto aceitável dos riscos restantes e tratados, somados juntos, não podem ultrapassar a X% do Valor do patrimônio). A partir daí calcular os valores dos impactos de todas as situações de risco identificadas e avaliar se o mesmo está acima ou abaixo desta linha de base.

Esta prática, além de liberar a equipe para focar na mitigação dos riscos que realmente possam provocar danos graves ao negócio, reduz significativamente o montante de recursos a serem investidos na mitigação de riscos menores ou que causam baixo impacto no negócio, o que de fato teria algum sentido mitigar, se houvesse alguma possibilidade de que todos os riscos não mitigados pudessem vir a ocorrer simultaneamente, o que matematicamente poderíamos classificar como uma situação “possivelmente improvável” e mesmo que isto viesse a ocorrer estaria dentro do limite estabelecido de aceite dos riscos.

Uma situação que nos deparamos muito são os riscos que promovem algum tipo de dano a “imagem”, “marca”, “confiança”, ou qualquer outro tipo de variável que “teoricamente” seria intangível ou “difícil de estimar”. Infelizmente a matemática não nos oferece esta opção (Imagine o valor do Seguro do Museu do Louvre), e se “algo” não puder ser traduzido em números, este “algo” ou não existe ou não possui valor algum (é Zero), e, portanto o impacto causado por um risco, mesmo que o valor seja em tese “Intangível” ele deverá necessariamente ser “tangibilizado ou dimensionado” através da apuração de um valor, mesmo que este valor não seja exato, deverá ser calculado ou estimado de alguma forma.

Uma vez “definido” o valor do Impacto do risco, a analise de risco poderá seguir o seu caminho natural ate a mitigação do risco.

Continuaremos os demais objetivos através de um próximo artigo – Aqui tratamos itens relacionados ao PO – Planejamento e Organização do COBIT, agradecemos a sua visita e a leitura deste artigo.

—- Fim Conteúdo Artigo —-

———

Este artigo está disponível para download no formato de Documento (PDF) no seguinte endereço:  Http://www.aghatha.com   opção free whitepapers.

———

Outros Artigos Relacionados com este Assunto:

  • Como Formatar, Organizar, Estruturar documentação de Processos (Politicas, Normas e Procedimentos)

Em artigo anterior, descrevemos como formatar, organizar e estruturar a documentação de processos, contendo ainda o modelo de template destinado a descrição passo-a-passo dos processos disponível para download, vamos utilizar este modelo no próximo artigo para descrever um processo e em seguida utilizar o mesmo para desenhar o respectivo fluxograma:

https://aghatha.wordpress.com/2011/06/18/como_formatar_e_organizar_a_documentacao_de_processos_ti/

—–

  • Agradecimentos e Convites:

    Seu feedback é muito importante para nós,  caso você tenha alguma dúvida ou necessidade de informações adicionais para o seu entendimento ou aplicação, entre em contato conosco através do e-mail abaixo.

    Abraço e Felicidades a Todos,

    Eurico Haan de Oliveira

    http://www.aghatha.com/index.htm

  • consulting@aghatha.com

———

Compartilhe este post:

  • Declarações de Direitos de Copyright

    Declaração e Preservação de Direitos Autorais e de Propriedade:

    Todas as marcas, modelos, desenhos, nomes, incluindo o conteúdo integral deste artigo, são de propriedade de seus respectivos fabricantes, autores ou publicadores.

    O leitor está autorizado a fazer o uso interno e não comercial do conteúdo deste artigo, desde que mantidas as observações de direitos autorais e mantidas as referencias a suas origens e identificação dos respectivos autores e proprietários.

    Direitos de uso comerciais deste artigo são preservados e mantidos em nome exclusivo do autor e o leitor não está autorizado a utiliza-los, de forma integral ou parcial para usos e fins comercias e/ou em atividades que visem à obtenção de lucro ou benefício comercial próprio ou a terceiros.

    Licença Creative Commons This work is licensed under a Creative Commons Atribuição-Uso não-comercial-Vedada a criação de obras derivadas 3.0 Unported License.

    Para a confecção deste artigo foram citadas e/ou utilizados os seguintes nomes, marcas e publicações:

    • COBIT ® 4.1, que é de propriedade exclusiva ISACA – Information Systems Audit and Control Association (www.isaca.org ) e IT Governance Institute™ (www.itgi.org), sendo Todos os direitos autorais reservados.
    • Conteúdo Artigo – é de propriedade exclusiva do Autor e de AGHATHA (Website: http://www.aghatha.com/index.htm / Webstore: Http://www.aghatha.com ), sendo todos os direitos  autorais preservados, incluindo a sua utilização e exploração comercial.
    • COSO®, que é de propriedade exclusiva Committee of Sponsoring Organizations of the Treadway Commission (COSO)™ (www.coso.org/), sendo Todos os direitos autorais reservados.
    • ISO-IEC® Standard – São de propriedade exclusiva do  International Organization for Standardization (ISO®)   e International Electrotechnical Commission (IEC®) (www.iso.org), sendo Todos os direitos autorais reservados.
    • ITIL V-3 ® – IT Infrastructure Library®  (www.itil-officialsite.com) que é de propriedade e proteção exclusiva da Coroa Britanica (www.ogc.gov.uk) – Office of Government Commerce (OGC) – UK, sendo Todos os direitos autorais reservados.
    • PCAOB ® é  propriedade exclusiva do  Public Company Accounting Oversight Board  – (http://pcaobus.org/), sendo Todos os direitos autorais reservados.
    • PMI ®  / PMBOK ®   propriedade exclusiva do Project Management Institute ( www.pmi.org/),  sendo Todos os direitos autorais reservados

–———

Fim Declarações de Direitos de Copyright —

–———

Fim Artigo

Read Full Post »

COMO FORMATAR E ORGANIZAR A DOCUMENTAÇÃO DE PROCESSOS DE BOAS PRÁTICAS– ISO-27.002 / ISO-20.000 / COBIT / ITIL-V3

COMO FORMATAR E ORGANIZAR A DOCUMENTAÇÃO DE PROCESSOS  DE BOAS PRÁTICAS– ISO-27.002 / ISO-20.000 / COBIT / ITIL-V3.

Após a decisão em adotar algum padrão ou recomendações tais como (ISO/IEC-27.002, ISO/IEC-20.000, ITIL, COBIT, COSO e tantos outros existentes, surge a pergunta: COMO COLOCAR EM PRÁTICA AS AÇÕES NECESSÁRIAS?,

Depois de alguns anos chegamos a um modelo que é bastante efetivo em termos de conteúdo e praticidade para formalização de processos e controles.

Embora existam normas especificas de qualidade que contemplam recomendações e práticas neste sentido, há necessidade de fazermos algumas adaptações para implantar boas práticas relacionadas à Tecnologia da Informação, as quais passaremos a abordar. O nosso leitor poderá adotar ou não estas sugestões, mas vamos procurar explanar o que elas representam e porque são recomendadas.

1 – A Estrutura Hierárquica da Documentação.

Primeiramente é necessário definir a estrutura a ser seguida na organização dos documentos, lembrando que é necessário contemplar nesta estrutura todos os escalões hierárquicos existentes na organização e lhes referenciando a cada um os tipos de documentos sob sua responsabilidade organizacional ou institucional. Vejamos um exemplo na figura abaixo:

Politicas:  Estabelecer o nível estratégico a ser cumprido na adoção das melhores práticas. É atribuída pelo nível diretivo das organizações e estabelece as diretrizes gerais a serem observadas por todos.

Normas: Estabelecer o nível tático e estabelece as regras a que as áreas operacionais deverão observar para o cumprimento das diretrizes ditadas pelas políticas. É atribuída aos gerentes e gestores das áreas envolvidas em cada prática ou modelo que será adotado.

Procedimentos: Estabelecer o nível operacional e estabelece o “como será feito!”, descrevendo passo a passo as atividades, responsáveis, evidências a serem produzidas, e ainda em um segundo momento, poderão ser adotadas métricas que possibilitem a medida de eficiência e de nível de serviço obtido pelo processo.

Controles e Métricas: Estabelece o “Entregável ou Evidencia física da execução do Processo”, ou seja, o processo de fato foi executado, quando ao final de seu ciclo, o usuário tenha produzido o controle ou a evidencia nele instituído.

Pode-se ainda vincular métricas ou indicadores de controle para medir a efetividade do procedimento, e dependendo do resultado ser favorável ou não, identificar a necessidade de melhorias ou ajustes no processo até que o índice desejado seja atingido.(Assim se estabelece o ciclo de melhoria contínua dos processos).

2 – A Estrutura Física dos Documentos

Uma vez estabelecido à estrutura hierárquica da documentação, e o seu endereçamento nas escalas de comando da companhia, passamos a estabelecer o conteúdo físico de cada tipo de documento, cada um estabelecendo o conteúdo a ele determinado na estrutura hierárquica da documentação (Item 1).

Na figura abaixo, exemplificamos um modelo de documento muito fácil de ser entendido e ao mesmo tempo bastante completo em termos de conteúdo e formato de apresentação.

documento_padrao_aghatha_framework

2.1 – Composições de Estrutura Comum (Politicas, Normas e Procedimentos).

Tipo de Documento:  é recomendado que o documento possua uma indicação claramente visível que identifique ao leitor o tipo de documento (ex. Politica, Norma, Procedimento, Controle, Instrução Técnica, entre outros).

Cabeçalho / Identificação: Deve haver um quadro incluindo as informações relacionadas a identificação do documento, tais como Título/Descrição do Documento, Identificação, Versão, Data emissão, data de Inicio Vigência, Data de fim da vigência, e data prevista para a sua próxima revisão, responsáveis, classificação de sigilo, áreas responsáveis.

Objetivo do Documento: Descrever de forma clara o objetivo do documento, ou o proposito desejado do documento.

Abrangência/Aplicação: Descrever ao leitor qual é a abrangência de uso do documento, se é um documento de uso corporativo, aplicável a apenas uma Unidade, departamento ou a um grupo de pessoas. A informação deve ser clara ao leitor quando ele puder ser identificado no grupo de pessoas que deve ou não cumprir o que está estabelecido no documento.

Terminologia: Identificar os termos técnicos não usuais e o seu significado através de uma descrição clara e preferencialmente não técnica, e que possa ser entendido por pessoas leigas em relação ao termo técnico, siglas ou palavras em outros idiomas.

 2.1.1 – Composições Especificas  (Descrição de Politicas).

Descrição das Diretrizes: Identificar o conteúdo detalhado das Diretrizes forma mais detalhada e clara possível.

Sugerimos adotar o formato de uma tabela, contendo em cada coluna as informações requeridas em cada Diretriz, sendo no mínimo: Numero sequencial, descrição ou enunciado das Diretrizes a serem seguidas e um campo para Observações e informações complementares. Ex:

Descrição das Diretrizes de Uma Politica:

Seq Diretrizes Observações
1 As entradas e Saídas de Colaboradores nas dependências da organização deverão ser controladas através de identificação funcional padrão. São considerados colaboradores, todos os níveis hierárquicos da Organização, incluindo Diretores, Gerentes, Supervisores, colaboradores e estagiários.

 2.1.2 – Composições Especificas  (Descrição de Normas).

Descrição das Normas: Identificar o conteúdo detalhado das normas a serem seguidas para a aplicação das Diretrizes, estabelecendo regras na forma mais detalhada e clara possível..

Sugerimos adotar o formato de uma tabela, contendo em cada coluna as informações requeridas em cada Regra, sendo no mínimo: Numero sequencial, descrição ou enunciado das Regras a serem seguidas e Observações. Ex:

Descrição das Regras de uma Norma:

Seq Regras Observações
1 Todos os colaboradores da organização serão identificados através de identidades funcionais, seguindo o modelo padrão da companhia. São considerados colaboradores, todos os níveis hierárquicos da Organização, incluindo Diretores, Gerentes, Supervisores, colaboradores e estagiários.
2 As identidades funcionais devem ser providenciadas pela Área de RH e entregues no primeiro dia de trabalho. Os colaboradores que ainda não possuem a identidade funcional deverão receber a sua identificação até 30 dias da data de inicio de vigência desta norma.
3 Os colaboradores deverão apresentar as suas identidades funcionais na portaria nas ocasiões de movimentação de entrada e saídas das dependências da organização. O procedimento de entrada e saída identificadas entrará em vigora 30 dias após a data de inicio de vigência desta norma
4 Nos casos de perdas e extravio o colaborador deve reportar formalmente o fato a Área de RH, para que seja providenciada a emissão de nova identidade funcional.

 2.1.3 – Composições Especificas  (Descrição de Procedimentos).

Descrição do Processo:  Identificar o conteúdo detalhado do Procedimento na forma mais detalhada e clara possível..

Sugerimos adotar o formato de uma tabela, contendo em cada coluna as informações requeridas em cada atividade, sendo no mínimo: Numero sequencial, descrição da Atividade e Observações, podendo-se ainda incluir campos adicionais e facultativos, tais como, a Identificação do Responsável (Quem?) as situação ou condição de execução da atividade (Quando?). Quanto mais informações, mais completo será o conteúdo do processo e mais demorado e complexo será a sua confecção, isto posto, sugerimos iniciar com modelos mais simplificados e complementando campos adicionais na medida em que se fizerem necessários. Ex:

Descrição das Atividades de um Procedimento (Procedimento de Entrada e Saída na Portaria de Pedestres):

Seq Descrição Atividade Observações Quem? Quando?
1 Verificar a identificação do colaborador na ocasião de entrada do colaborador. Modelo Identificação MOD-001 – Identidade Funcional Vigilante No momento de entrada e saída dos colaboradores na empresa
2 A identidade funcional do colaborador é valida? N.A. Vigilante N.A.
3 Caso Positivo:Liberar o acesso ao colaborador N.A. Vigilante N.A.
4 Caso Negativo:Encaminhar o colaborador ao RH, para que seja providenciada emissão de nova identidade funcional / Identidade provisória. N.A. Vigilante N.A.

 2.1.3 – Composições Comuns  (Campos de Controle dos Documentos).

No Item 2.1 e seus subitens tratamos as partes específicas de cada documento, informando as variações de conteúdo dependendo de cada tipo de documento (Politica, Norma ou Procedimento). Após esta parte, o documento pode ser padronizado nas questões de controle e referencias.

Sugerimos incluir após a parte especifica os seguintes campos de controle.

Documentos Referenciados /Anexos: Identificar ao leitor a relação de documentos relacionados, por Exemplo, identificar em uma política quais normas está a ela subordinada, identificar em uma norma quais procedimentos a ela estão subordinados, e etc..

Este tipo de informação dá ao leitor informações de referencia entre os documentos, uma vez que a Politica gerou uma determinada norma, e esta gera uma determinada relação de procedimentos, desdobrando uma Diretriz em Regras e esta em um ou mais procedimentos.

Pode-se ainda desenhar graficamente os processos através de fluxos das atividades demonstrando as atividades passo-a-passo e facilitando em muito o entendimento do processo. (Politicas e Normas não possuem Fluxogramas), mas podem conter desenhos esquemáticos que facilitem o entendimento dos objetivos das mesmas.

Classificação da Informação: Nos casos onde as organizações possuem politicas de segurança da informação é importante identificar nos documentos a sua classificação de segurança (Documento de Uso Interno, Documento Confidencial, Documento Restrito a um determinado Grupo de Pessoas).

Controle de Aprovação / Revisão: Tabela contendo a identificação dos responsáveis pela aprovação e revisão do documento, local para assinatura e data dos responsáveis, e identificação de contato.

Anexos: Convém incluir toda e qualquer informação adicional, modelos e templates necessários para a execução ou entendimento como anexo ao final do documento. Recomendamos enumerar os anexos e referencia-los no corpo do documento para facilitar a navegação e leitura.

3 – Controles da Documentação.

3.1 – Lista de Documentos e Controle de Revisão.

Na medida em que os documentos sejam confeccionados é recomendado que sejam apontados em um controle destinado a relacionar os documentos vigentes, em revisão, revogados, e  a identificação do documento, Numero de sua versão, Identificação de seus responsáveis, data de inicio de vigência, data de fim da vigência e data prevista para a sua próxima revisão, resumo de revisões realizadas identificando o que mudou entre uma versão e outra.

Regularmente recomendamos a verificação deste controle, com a finalidade de promover as revisões periódicas de conteúdo e de aplicação de melhorias nos processos, sendo que pelo menos 30 dias antes da data de vencimento da data prevista para a revisão, o responsável pela documentação deve enviar uma notificação de revisão ao responsável para que o documento seja revisado até a data do seu aniversário.

As boas práticas determinam que a documentação deva ser revisada pelo menos uma vez a cada ano, e não é incomum encontrar documentos com mais de 10 anos de vigência e com 30 ou 40 revisões, ou seja, um processo é uma entidade com vida própria e está em constante evolução. Não existe processo perfeito e ele sempre poderá ser melhorado, simplificado, apoiado por aplicações automatizadas, e assim por diante.

3.2 – Visões de Hierarquia entre os documentos (Mapa de Processos).

Com o acumulo de práticas a serem adotadas e a quantidade de documentos que se fazem necessários confeccionar para atender as boas práticas, há alguns anos atrás montamos uma visão hierárquica dos documentos, isto facilita em muito o controle e visão holística dos processos (A mesma visão da Pirâmide demonstrada no item 1, com um organograma dos documentos demonstrando as suas dependências e relações mutuas).

A seguir ilustraremos um modelo, para quem estiver interessado em seguir.

Modelo Mapa de Processos Compliance - Aghatha Maxi Consulting - www.aghatha.com.br

4 – Mapa Geral de Processos – Compliance Norma ISO-IEC-27002 – Gerenciamento de Segurança da Informação

Mapa Geral Processos Compliance Norma ISO-27002 - Aghatha Maxi Consulting - http://www.aghatha.com.br

Modelo acima representa o Mapa Geral de Politicas, Normas e Procedimentos requeridos para a Implantação de Politica de Segurança da Informação, conforme as recomendações da Norma ISO-27.002.

Framework Compliance Norma ISO-27002, Veja mais informações em:

5 – Mapa Geral de Processos – Compliance COBIT  – Governança TI e Sarbanes Oxley Compliance

 Mapa Geral Processos para o Compliance Governança TI e Sarbanes Oxley  - Aghatha Maxi Consulting - http://www.aghatha.com.br

Modelo acima representa o Mapa Geral de Politicas, Normas e Procedimentos requeridos para a Implantação da Governança de TI e Sarbanes Oxley Compliance, conforme as recomendações do COBIT,  PCAOB e Norma de Segurança e Modelos de Gerenciamento de Serviços ITIL-V3.

Veja em nosso outro artigo, como desenhar fluxograma de processos de negócio, em:

https://aghatha.wordpress.com/2011/07/03/como-desenhar-fluxogramas-de-processos-de-negocio-1-parte-introducao-conceitos-e-modelos/

—-

———-

·  Download do conteúdo deste Artigo :

O Conteúdo deste artigo está disponível para download no formato Arquivo  (PDF) na pagina Free Whitepaper publicada em nosso site

www.AGHATHA.com , acessando a pagina :  http://aghatha.com/index.php/whitepapers.html , você poderá realizar o download do mesmo gratuitamente.

Faça-nos uma visita, caso opte por assinar a Nossa Newsletter, você passará a receber avisos de atualizações e ampliações do conteúdo deste artigo e/ou comunicados sobre a publicação de outros artigos relacionados com este mesmo assunto.
———-

  • Visite nossa Webstore :

Economize centenas de horas com a realização de levantamentos, definição, documentação e organização de processos e controles em Tecnologia da Informação.

Agora é possivel obter suites contendo modelos pré-definidos, integrados e  prontos para utilização / implementação e contruídos em conformidade com as regras e requisitos estabelecidos nos diversos padrões de compliance em TI.

  • AGHATHA Framework – Compliance Norma ISO-27002

http://aghatha.com/index.php/framework-de-processos-e-controles-para-o-compliance-de-ti-norma-iso-27001-iso-27002-seguranca-da-informacao-release-02-01-a.html

  • AGHATHA Services – Serviços Suporte Técnico e Consultoria Técnica Sob Demanda.

http://aghatha.com/index.php/servico-consultoria-suporte-tecnico-compliance-ti-nao-presencial.html

———-

  • Framework de processos e controles para o Compliance de TI.

Convidamos a conhecer  nosso Framework de Processos e Controles para o Compliance de TI aos Padrões e Recomendações para o Compliance SOX, ISO-27.001/2, ISO-20.000:1/2, COBIT, ITIL V3, PMI.

Nele, você poderá ver alguns exemplos de como é possível descrever processos complexos com a adoção de 4 camadas sucessivas de detalhamento, sendo o nível # 1 a visão mais alta e o nível # 4 o nível mais detalhado do processo (Drill-Down de detalhamento de processos em camadas).

Ou ainda, Leia mais sobre este mesmo assunto, em nossos POSTs.

Framework Compliance Norma ISO-27002

———-

—- Fim Conteúdo Artigo —-

Agradecimentos e Convites:

As informações e comentários existentes neste artigo são o fruto de observações e experiências adquiridas pelo autor durante a  execução de projetos ao longo de 30 anos de atuação no mercado. Utilizamos este espaço para a divulgação e intercâmbio destes conhecimentos junto aos nossos leitores, clientes e amigos.

Caso você tenha alguma dúvida ou necessidade de informações adicionais para o seu entendimento ou aplicação, entre em contato conosco através do e-mail abaixo.

Abraço e Felicidades a Todos,

Eurico Haan de Oliveira

http://www.aghatha.com/index.htm

Siga-nos pelo Twiter, e receba comunicados de novos artigos e/ou revisões deste texto.   Follow aghatha_maxi on Twitter

———

Apresentação AGHATHA Framework – Norma ISO-27001:2/2005.


———

———

Declaração e Preservação de Direitos:

 Todas as demais marcas, modelos, desenhos, nomes, incluindo o conteúdo integral deste artigo, são de propriedade de seus respectivos fabricantes, autores ou publicadores.

O leitor está autorizado a fazer o uso interno e não comercial do conteúdo deste artigo, desde que mantidas as observações de direitos autorais e mantidas as referencias a suas origens e identificação dos respectivos autores e proprietários.

Direitos de uso comerciais deste artigo são preservados e mantidos em nome exclusivo do autor e o leitor não está autorizado a utiliza-los, de forma integral ou parcial para usos e fins comercias e/ou em atividades que visem à obtenção de lucro ou benefício comercial próprio ou a terceiros.

Licença Creative Commons
This work is licensed under a Creative Commons Atribuição-Uso não-comercial-Vedada a criação de obras derivadas 3.0 Unported License.

Para a confecção deste artigo foram citadas e/ou utilizados os seguintes nomes, marcas e publicações:

  •  COBIT ® 4.1, que é de propriedade exclusiva ISACA – Information Systems Audit and Control Association (www.isaca.org ) e IT Governance Institute™ (www.itgi.org), sendo Todos os direitos autorais reservados.
  • Conteúdo Artigo – é de propriedade exclusiva do Autor e de AGHATHA (http://www.aghatha.com/index.htm  / Http://www.aghatha.com ), sendo os direitos preservados todos os direitos autorais e exploração comercial.
  • COSO®, que é de propriedade exclusiva Committee of Sponsoring Organizations of the Treadway Commission (COSO)™ (www.coso.org/), sendo Todos os direitos autorais reservados.
  • ISO-IEC® Standard – São de propriedade exclusiva do  International Organization for Standardization (ISO®)   e International Electrotechnical Commission (IEC®) (www.iso.org), sendo Todos os direitos autorais reservados.
  • ITIL V-3 ® – IT Infrastructure Library®  (www.itil-officialsite.com) que é de propriedade e proteção exclusiva da Coroa Britanica (www.ogc.gov.uk) – Office of Government Commerce (OGC) – UK, sendo Todos os direitos autorais reservados.
  • PCAOB ® é  propriedade exclusiva do  Public Company Accounting Oversight Board  – (http://pcaobus.org/), sendo Todos os direitos autorais reservados.
  • PMI ®  / PMBOK ®   propriedade exclusiva do Project Management Institute ( www.pmi.org/),  sendo Todos os direitos autorais reservados

– Fim Declarações de Direitos de Copyright —

— Fim Artigo

Read Full Post »

É correto contornar Incidentes através de processos de Gerenciamento de Mudanças?

Por mais estranho que pareça, esta duvida ainda é bastante comum, como já me fizeram por diversas vezes esta mesma pergunta, vamos aqui tentar auxiliar aos interessados  a chegarem ao um denominador comum, em uma abordagem o mais prática possível e ressalvando as dificuldades e restrições pelo uso da forma escrita.
Para isto, é necessário registrar alguns pontos iniciais, que podem auxiliar no entendimento da questão.
1.  O que é Incidente:
Primeiramente precisamos entender o que é um Incidente: Em tese, um incidente é todo tipo de imprevisto (Já vivenciado ou não) e que durante a sua ocorrência pode vir a comprometer  ou causar impacto nas operações normais de uma organização.
Ex:
  • Parada de um servidor durante o seu período normal de operação;
  • Parada do sistema de emissão e notas fiscais durante o período de pico da expedição de mercadorias;
  • Lentidão no trafego de dados em um determinado momento do dia, onde se executa alguma rotina crítica de negócio, causando a demora na conclusão desta rotina.
1.1.  Objetivo do Processo de Gerenciamento de Incidentes:
O processo de Gerenciamento de Incidentes possui um objetivo muito claro e muito específico, que é: “Tomar as providencias necessárias, no menor tempo possível, para que a as operações da organização retornem ao seu estado normal de operação através do contorno/solução dos incidentes”.
Exemplo:
Durante o processo de tratamento do incidente há alguns passos formais a serem seguidos, e quando são praticados, os passos mais comuns são:
  1. Identificação do Evento,
  2. Confirmação do Evento;
  3. Abertura do registro do incidente

a. Identificação da Causa,

b.      Tratamento da Causa,

c.       Aplicação da correção,

d.      Validação do contorno do incidente  e,

4.       Encerramento do registro do incidente,

Até aqui, nenhuma novidade, e normalmente são assim mesmo que as coisas acontecem em um IRT – Incident Response Team / Service-Desk,
1.2.   O que se Pretende Resolver:
a)      Há casos onde o ciclo de vida do incidente deve ser executado em questão de alguns poucos minutos, dependendo da gravidade e do impacto causado pelo mesmo aos negócios da organização.
Obs.: (Pense em um site de vendas pela Internet permanecer algumas horas fora do ar…isto em si, já poderia representar um grande prejuízo, e ainda poderia ser transformado em uma calamidade, se o momento da parada,  fosse às vésperas do dia de Natal);
Exemplos de Algumas Possíveis Causas:
  • Erro lógico na Aplicação
  • Vulnerabilidade  ou quebra de segurança
  • Erro físico ou Lógico no Servidor de Aplicação;
  • Erro físico ou lógico no Servidor de Banco de Dados
  • Erro físico ou lógico no Serviço de Rede interna
  • Erro físico ou lógico no Serviço de Rede Externa
  • Erro em algum componente de Hardware / Software que suporte a aplicação ou serviço
Dependendo da complexidade do ambiente (Quanto mais crítico o serviço mais complexo será o ambiente que lhe presta suporte, e quanto mais complexo o ambiente, mais difícil será identificar qual é a causa que provocou o incidente), e ainda poderíamos ter diversas pequenas causas que se somadas, poderiam promover a ocorrência do mesmo tipo de incidente ou Consequência:
b)      Em Razão disto, o item mais crítico o tratamento de um incidente é identificar a sua existência (Algum evento já está ocorrendo), algumas equipes são informadas da existência de um incidente pelo usuário, e ai..,  já se foram até os 30 minutos de prazo previstos para o seu contorno. E neste caso,  somente a partir de  então dará inicio a busca da causa e promover as ações para o seu tratamento/contorno.
2.  O que é Mudança:
Em tese, uma mudança é um processo formal, planejado e documentado para aplicação de melhorias ou alterações estruturais ao ambiente (Infraestrutura, serviços, aplicações, segurança, processos, etc…). Toda mudança deve prever, avaliar  e tratar todos os impactos que por ventura ela possa vir a causar ao ambiente onde será promovida.
Ex:
  • Migração de dados de um servidor para outro;
  • Promoção de um pacote de melhorias em uma aplicação;
  • Instalação e configuração de uma nova rede / sub-rede
  • Instalação, migração ou Upgrade de versão de um serviço;
2.1. Como as mudanças podem ser classificadas
As mudanças podem ainda ser classificadas de acordo com o seu tamanho,  complexidade ou quantidade de serviços /ativos envolvidos/impactados em sua aplicação.
a)      Recomenda-se que mudanças Muito Complexas, sejam executadas através de Projetos de Gerenciamento de Mudanças;
          Ex:
  • Migração / Upgrade de Serviço Crítico
  • Migração de Versão de Banco de Dados
  • Migração de IP´s
  • Instalação e Configuração de Storage
O Gerente de Projeto tem a função de gerenciar e integrar  todas as atividades e pessoas envolvidas na execução da mudança a fim de que o objetivo do projeto seja atendido. O Projeto inclui no processo de mudança à atividade de gerenciamento e integração das equipes, que por sua natureza demora mais tempo que uma mudança simples (Dias, Semanas e até meses para ser concluída todas as atividades necessárias para a realização da mudança).
b)      Mudanças mais simples ou menos complexas, podem ser executadas através de processos padronizados de Gerenciamento de Mudanças (Framework/Roadmap/Procedimento).
       Ex:
  • Aplicação de um pacote de atualização em um serviço.
  • Instalação Física de um servidor
  • Configuração de uma Nova VM
  • Inclusão de base de dados na rotina de backup
O Gerente de Mudança tem a função de gerenciar as analises de impacto, prover as ações de contorno e integrar  as atividades envolvidas na execução da mudança a fim de que todos façam a sua parte e mudança ocorra com êxito, uma dica nestes casos é que uma mudança não pode demorar mais que uma semana,  se o seu ciclo de vida for maior que isto, sugerimos realiza-la através de um projeto.
c)       O que estes  dois processos de mudanças tem em comum.
  • Identificação prévia do Escopo/Objetivo da Mudança
  • Analise de impacto no ambiente
  • Estimativa de esforço e Prazo /Previsão de Entrega
  • Analise de impacto no ambiente
  • Preparação prévia do ambiente para aplicação da mudança.
  • Alocação de Recursos humanos e Técnicos.
  • Ambos possuem um responsável indicado pelo planejamento, controle e execução.
d)      Em que estes  dois processos de mudanças são diferentes.
A diferença básica é na forma ou na  abordagem aplicada no planejamento, execução  e controle, ou seja, quanto mais complexo,  mais  longo for o tempo necessário para aplicação de uma mudança, maior deverá ser o nível de robustez do processo responsável pelo seu planejamento,  execução e controle de execução.
a)      O Gerenciamento de Mudança é indicado para mudanças com ciclo de vida mais curto e possivelmente  menos complexos, suas etapas são executadas através de reuniões de planejamento e controle e as atividades são endereçadas através de roadmap para as mesmas pessoas da equipe de mudanças. O Próprio processo se encarrega de empurrar ou direcionar a aplicação da mudança, o gerente de mudanças conduz o e monitora as atividades conforme as regras previstas no processo.
b)      O Projeto de Gerenciamento de Mudança é indicado para mudanças que tem ciclo de vida mais longo, onde os eventos da mudança passam a ser as etapas do projeto, as pessoas alocadas podem ou não fazer parte da equipe de mudança, o nível de risco é proporcional a complexidade do projeto, e as atividades necessárias para a sua execução extrapolam as ações previstas no processo de Gerenciamento de mudança tradicional. O planejamento, execução e o controle é mais complexo e necessita de um agente que promova a sua  integração e controle, características mais aderentes a função de Gerente de Projeto, o qual tem responsabilidade de puxar o processo de mudança e garantir a sua aplicação.
3. Retornando A Dúvida Inicial:
Com estas explanações preliminares já é possível perceber a diferença entre os dois processos e mais precisamente entender os motivos pelos quais um Incidente não deve, em tese, ser  contornado/solucionado através de uma mudança.
Mas quando um incidente é contornado/solucionado através do próprio processo de incidente (O que seria o mais recomendado), as duvidas tornam a aparecer, vejamos quais são as mais frequentes:
3.1. Dúvidas Operacionais:
O Gerente de incidentes, em principio efetuou o seu trabalho , e com um pouco de sorte e competência técnica de sua equipe, o mesmo tenha sido contornado dentro dos limites de tempo estabelecidos pelo (SLA) – Nível de Serviço estipulado para o tipo de incidente em questão.
O Gerente de Mudanças acredita que houve um erro, pois qualquer tipo de mudança deveria em tese ser efetuada  somente através do processo de Gerenciamento de Mudanças, afinal de contas, foi alterada alguma coisa no ambiente, tal é o fato de que houve uma aplicação de correção, e claramente a mesma foi executada “fora do processo” de gerenciamento de mudanças.
3.2. Dúvidas Conceituais que geram a controvérsia (e Graves…):
  • Um incidente grave ao ponto de interromper todas as operações de uma organização é um “problema” ,  e que para ser resolvido, devido à gravidade do fato, deverá ser realizada uma Mudança  conformidade com o processo de Gerenciamento de mudanças.
  • Qualquer tipo de mudança promovidas no ambiente devem necessariamente ser executado pelo processo de Gerenciamento de Mudanças.
  • Há uma relação de um para um entre os Incidentes e Mudanças, e todos estão sujeitos a métricas de SLA – Níveis de Serviço.
3.3.  Dúvidas Decorrentes das Dúvidas anteriores…
a)      Se o Incidente promoveu uma alteração no ambiente, porque ela não foi promovida pelo processo de Mudança?
– O Incidente tem tempo de resposta (Minutos, Horas) e a mudança aplicada no contorno do incidente não possui analise completa de causa raiz, foi realizada analise preliminar de possíveis causas, sucessivamente até que  incidente fosse contornado.
Mesmo o serviço tenha retornado a sua condição de funcionamento, podem ainda haver outras causas não tratadas pelo incidente e o mesmo pode vir a recorrer.
O processo de mudança tem planejamento formal e prazo de entrega (Dias, Semanas, Meses), não cabe usar Gerenciamento de Mudanças para contorno de incidentes, devido ao fator tempo de resposta.
b)      Como a mudança promovida pelo incidente foi documentada?
Há duas formas possíveis de documentar incidentes:
Incidentes não críticos são documentados na medida em que o incidente é tratado, devendo ser controladas e documentadas as mudanças através do processo de Gerenciamento de Configuração, ou quando o tratamento não envolver mudanças na configuração, através de descrição detalhadas das atividades executadas para o contorno do incidente.
Incidentes Críticos Podem ser documentados da mesma forma adotada na documentação de  incidentes não críticos, porém, pode-se realizar isto assim que o incidente seja contornado/solucionado (Isto mesmo, pode-se documentar depois, justamente para agilizar o atendimento do incidente, (Veja Cobit item AI6).
c)       Se os Incidentes promovem todas as mudanças necessárias no ambiente, para que serve então o processo de Gerenciamento de mudanças?
Como já vimos, as duas formas de aplicação de mudança (Através de Processo de Mudança ou através de Projeto de Mudança) não são aplicáveis para a solução de incidentes, devido a incidente possui tempo de resposta e os demais possuem prazo de entrega.
(Obs Importante: NÃO EXISTE SLA, SLO, SLM ou qualquer outro tipo de métrica orientada a medir nível de serviço que possa ser aplicável para o processo de GERENCIAMENTO DE MUDANÇAS, e as métricas aplicáveis nestes casos, podem ser as  mesmas utilizadas para os  projetos, Veja PMI/PMBOK).
Incidentes promovem ações de contorno ou corretivas urgentes,  mudanças promovem instalações de novos serviços e melhorias no ambiente, portanto ambos os processos são necessários e muito  importantes.
d)      Deveria então existir um processo de mudança dentro do Incidente?
No sentido formal do processo de mudança Não  e também não é a ação mais indicada, a documentação das possíveis  “mudanças” aplicadas no contorno / solução de incidentes resume-se a documentação da causa identificada do incidente e na documentação da ação que efetivamente foi aplicada para o seu contorno ou solução (Ajuste, Correção, Parâmetros, etc..).
Aos que possuem ferramenta de Gerenciamento de configuração, a informação da ação podem ser registradas em uma ferramenta de (CMDB) é suficiente para documentar a mudança de quase todo tipo de incidente (Não se trata desastres e acidentes através de Incidentes).
Quando não se tem disponível uma ferramenta de (CMDB), basta identificar a causa e descrever as ações o mais detalhadamente possível, também pode ser válido para documentar as mudanças realizadas pelo incidente.
e)      Quando e Como o gerente de mudança vai tomar conhecimento do que foi alterado pelo Incidente?
Esta pergunta é interessante, pois os dois processos podem se  comunicar através do Processo de Gerenciamento de  PROBLEMAS.
Note que um problema só pode ser aberto com base em incidentes, pode ser originado de um único incidente ou mais de um incidente, desde que haja alguma correlação entre eles (Mesmo Ativo, mesmo Serviço, mesmo consequência),  e somente após os incidentes estarem  encerrados, ou seja, os eventos já foram  contornados/solucionados e o tempo de resposta do incidente já tenha sido atendido.
É responsabilidade do processo de Gerenciamento de problemas, analisar o conjunto de incidentes ocorridos em um determinado período, e realizar uma detalhada investigação de causa raiz (Quase como se fosse uma AUTOPSIA) dos  incidentes mais relevantes ou recorrentes no mesmo periodo.
É através do problema, que TODAS as causas de um determinado incidente sejam identificadas e tratadas, de forma que o incidente não mais ocorra ou reduza a sua incidência.
Métricas aplicáveis ao Processo de Gerenciamento de Problemas são relacionadas à redução do volume de incidentes, Se um problema foi aberto, as causas foram identificadas, e as ações corretivas decorrentes do mesmo foram aplicadas com sucesso pelas Mudanças:
Dois Fatos podem ocorrer:
 O Incidente deixará de existir
            O Gerenciamento de Problemas cumpriu a sua função, indicou as melhorias corretas para eliminação das causas dos Incidentes, e estas por sua vez foram promovidas com exito pelo processo de Gerenciamento de Mudanças.
 O incidente volta a ocorrer,
            Há apenas tres hipóteses possíveis para a recorrencia deste incidente:
  • Surgiu uma nova causa para ocasioná-lo,
  • A analise de causa raiz realziada pelo processo de Gerenciamento de problema não foi suficientemente bem realizada para identificas todas as causas(Ficaram causas sem serem tratadas).
  • Houve erros não identificados durante a aplicação da Mudança
 As ações corretivas identificadas pelo processo de Gerenciamento de Problemas devem originar as Requisições de Mudanças destinadas as melhorias necessárias no ambiente.
f)       Quem é o responsável pelo controle do conteúdo das mudanças aplicadas pelo processo de Gerenciamento de Incidentes,  Gerente de Mudanças e Gerente de Projetos de Mudanças?
O responsável pelo repositório de documentação das mudanças promovidas pelos Incidentes, Processo de Gerenciamento de Mudanças e Projetos de Gerenciamento de Mudanças  é o processo de Gerenciamento de Configuração, ou seja,  o controle do conteúdo é responsabilidade do Gerente de Configuração.
Se houver aplicação de CMDB, o controle deve ser feito pela própria ferramenta, quando não se possui  este tipo de ferramenta, uma planilha detalhada para cada ativo passível de configuração, pode ajudar no controle.
Cada processo deve informar as suas mudanças no controle do Gerenciamento de Configuração.
4.     Então, como  estes processos são Integrados?
4.1.             Incidentes:
Processo independente, não depende diretamente dos processos de Problemas e Mudanças, apenas identifica e  valida os eventos verdadeiros e confirmando a existência de um incidente. Identifica causas possíveis do incidente, e promove as correções necessárias para que o evento seja contornado/solucionado.
Possui tempo de resposta de acordo com a severidade e impacto do incidente, e pode variar de alguns minutos a algumas horas.
4.2.             Problemas.
Devem ser abertos problemas para incidentes  graves ou muito recorrentes, para que se possam realizar investigação de causa raiz de todas as causas possíveis que possam gerar um determinado tipo de incidente.
O período de investigação pode durar em média de 5 a 10 dias, e gera como resultado o detalhamento da investigação de causas e endereçamento de recomendações de melhorias necessárias.
(Normalmente tratam-se  incidentes graves individualmente, ou sejam  1 incidente Grave = 1 problema, e para os incidentes de menor severidade,  pode-se criar um problema para um grupo de incidentes correlacionados, através da identificação de  fatores de  agrupamento (mesmo serviço, mesmo servidor, mesmo impacto).
Para incidentes não graves e isolados, não é necessário incluir o incidente no processo de Gerenciamento de Problemas.
Das analises de Causa Raiz e recomendações de ações corretivas são geradas as solicitações de mudanças
4.3.             Mudanças,
As mudanças podem ser originadas de todas as dimensões relacionadas com o ambiente (Aplicações, Infraestrutura, Serviços e Segurança, etc…), quando uma mudança tem a função de resolver situações relacionadas a incidentes, deve haver um problema e as suas recomendações de melhorias previamente documentadas..
Se a mudança for relacionada a incidente e não houver um problema, que previamente a justifique, a execução desta mudança não possivelmente não promoverá a redução do volume do incidente ao qual se deseja eliminar/reduzir a sua incidência.
4.4. Configuração.
O Processo de Gerenciamento de Configuração devem manter o armazenamento dos seus registros a disposição dos processos anteriores, sendo utilizados como informações iniciais para a realização de suas atividades. Ao final de cada processo, os seus respectivos responsáveis deverão atualizar os registros para seu próprio uso no futuro, ou pelos demais processos.
—-

Este artigo está disponível para download no formato de Documento (PDF) na pagina de Download  do Site da AGHATHA  em :  http://www.aghatha.com.br/

—- Fim Conteúdo Artigo —-

Agradecimentos e Convites:

As informações e comentários existentes neste artigo são o fruto de observações e experiências adquiridas pelo autor durante a  execução de projetos ao longo de 30 anos de atuação no mercado. Utilizamos este espaço para a divulgação e intercâmbio destes conhecimentos junto aos nossos leitores, clientes e amigos.

Caso você tenha alguma dúvida ou necessidade de informações adicionais para o seu entendimento ou aplicação, entre em contato conosco através do e-mail abaixo.

Abraço e Felicidades a Todos,

Eurico Haan de Oliveira

www.aghatha.com.br

Consultoria@aghatha.com.br

———

Declaração e Preservação de Direitos:

 Todas as demais marcas, modelos, desenhos, nomes, incluindo o conteúdo integral deste artigo, são de propriedade de seus respectivos fabricantes, autores ou publicadores.

O leitor está autorizado a fazer o uso interno e não comercial do conteúdo deste artigo, desde que mantidas as observações de direitos autorais e mantidas as referencias a suas origens e identificação dos respectivos autores e proprietários.

Direitos de uso comerciais deste artigo são preservados e mantidos em nome exclusivo do autor e o leitor não está autorizado a utiliza-los, de forma integral ou parcial para usos e fins comercias e/ou em atividades que visem à obtenção de lucro ou benefício comercial próprio ou a terceiros.

Licença Creative Commons
This work is licensed under a Creative Commons Atribuição-Uso não-comercial-Vedada a criação de obras derivadas 3.0 Unported License.

Para a confecção deste artigo foram citadas e/ou utilizados os seguintes nomes, marcas e publicações:

  •  COBIT ® 4.1, que é de propriedade exclusiva ISACA – Information Systems Audit and Control Association (www.isaca.org ) e IT Governance Institute™ (www.itgi.org), sendo Todos os direitos autorais reservados.
  • Conteúdo Artigo – é de propriedade exclusiva do Autor e de AGHATHA (http://www.aghatha.com.br / Http://www.aghatha.com ), sendo os direitos preservados todos os direitos autorais e exploração comercial.
  • COSO®, que é de propriedade exclusiva Committee of Sponsoring Organizations of the Treadway Commission (COSO)™ (www.coso.org/), sendo Todos os direitos autorais reservados.
  • ISO-IEC® Standard – São de propriedade exclusiva do  International Organization for Standardization (ISO®)   e International Electrotechnical Commission (IEC®) (www.iso.org), sendo Todos os direitos autorais reservados.
  • ITIL V-3 ® – IT Infrastructure Library®  (www.itil-officialsite.com) que é de propriedade e proteção exclusiva da Coroa Britanica (www.ogc.gov.uk) – Office of Government Commerce (OGC) – UK, sendo Todos os direitos autorais reservados.
  • PCAOB ® é  propriedade exclusiva do  Public Company Accounting Oversight Board  – (http://pcaobus.org/), sendo Todos os direitos autorais reservados.
  • PMI ®  / PMBOK ®   propriedade exclusiva do Project Management Institute ( www.pmi.org/),  sendo Todos os direitos autorais reservados

– Fim Declarações de Direitos de Copyright —

— Fim Artigo

Read Full Post »