Feeds:
Posts
Comentários

Posts Tagged ‘Sarbane Oxley’

O Que e BSM – Business Service Management

BSM – é um modelo de gestão dos serviços prestados pelo TI e  que integra ações de  monitoramento,  identificação de incidentes e eventos que impactam na continuidade dos serviços de TI, priorização das ações de resposta, e medição de níveis de serviços  de TI a partir de uma perspectiva do ambiente computacional em relação à estrutura do negócio, ou seja,

    • “BSM é um conjunto de funcionalidades destinadas ao gerenciamento eficiente de processos e métodos relacionados ao ambiente de TI através de uma abordagem centrada no atendimento das necessidades e prioridades do negócio / Cliente / Inquilino”.
    • “BSM reúne em uma só ferramenta uma grande quantidade de processos distintos, informações do ambiente e dados de outras ferramentas, possibilitando com isto um conjunto de melhorias quantificáveis em termos de disponibilidade, Performance, capacidade e segurança através da visão da tecnologia em relação ao processo de negócio / cliente / inquilino  que se deseja priorizar as ações de suporte”.
    • BSM permite a Área de TI / Provedor Serviços direcionar e gerenciar seu ambiente (Hardware, Software, Serviços e Processos) ao invés de atuar através do modelo tradicional em grupos individuais ou torres por tecnologia (Ex: Operações, Redes, Segurança, Suporte, Atendimento a Incidentes) atuar através de um grupo único, coeso e integrado através de funcionalidades oferecidas pela ferramenta de BSM, permitindo a priorização dos esforços e oferecendo um melhor nível de serviço entregue para o negócio / cliente / inquilino ou para a própria organização como um todo”.

AGHATHA distribui as  Soluções integradas e convergentes da empresa Norte Americana ACCELOPS, (ACCELOPS PAM e ACCELOPS SIEM)  destinadas ao monitoramento integrado e em tempo real de Disponibilidade, Performance,  Segurança e Governança dos Ativos e Serviços no DATA CENTER, SOC  e NOC – (All-in-One Solution), atendendo aos requisitos estabelecidos pelo conceito do BSM – Business Service Monitoring,

  • Assista Video de Overwiew das Inovações das Soluções Accelops.

Disponibilidade, Performance  e Segurança para  Data Center e SOC /NOC – (All-In-One Solution) / BSM Business Service Management & Monitoring.

  • Assista Video Aplicando os Conceitos de BSM através do Accelops.

Veja como é possivel aplicar os conceitos de BSM – Business Service Management com o Apoio do AccelOps All-In-One Monitoring Solution – Data Center + SOC + NOC e as principais Inovações e o que esta solução pode oferecer ao seu Negócio:

  • Artigo contendo informações Técnicas Solução Accelops.

https://aghatha.wordpress.com/2011/08/11/solucao-inovadora-bsm-business-system-management-monitoring-all-in-one-solution/

Ficou interessado em conhecer melhor a Solução Accelops?

    • Solicite uma Demonstração da Solução Accelops:

Realizamos Demonstrações detalhadas da solução AccelOps através de apresentação em Salas Virtuais,  entre em contato conosco e agende a sua demonstração. email: consulting@aghatha.com .

 

    • Solicite uma Cópia Para Testes do Accelops no seu Ambiente:

Disponibilizamos cópia de demonstração para realização de um “test-drive” gratuito da solução AccelOps, veja você mesmo como esta aplicação efetivamente eleva os níveis de serviços prestados pela TI aos seruviços prestados pela TI ao seu negócio. email:  consulting@aghatha.com .

    • Solicite uma Cotação de Preços do Accelops:

Nossa solução oferece excelentes taxas de retorno em relação Custo x Benefício e ainda possui maior escalabilidade e baixo custo de propriedade – TCO. email:  consulting@aghatha.com .

(ACCELOPS = Baixo Custo Licenciamento e TCO, Mais Escalavel, Mais Completa e Mais Moderna e Promove monitroramento Pro-ativo da Disponibilidade, Multitenancy, Performance, Segurança e Compliance do seu ambiente em Tempo Real):

Aproveite condições Especiais de lançamento no Mercado Brasileiro.

Reduza seus custos operacionais e ainda melhore sensivelmente os Níveis de Serviço praticados para o Negócio, Saiba mais informações clicando no Botão Verde !! (E veja mais informações sobre as soluções em nosso Site), ou ainda:

  • Confira Mais informações sobre a solução em:

*  Divulgue este Post:

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.

Read Full Post »

O que e Governanca de TI – A Sua Origem, Historia, Conceitos e Fundamentos Basicos – Parte 1

O QUE É GOVERNANÇA  DE TI ?

A Sua Origem, História,  Conceitos e Fundamentos Básicos – Parte 1.

O que é Governança de TI ? – A Sua Orígem,  História, Conceitos e
Fundamentos Básicos – Parte 1.

1 – Introdução, Histórico e Conceitos.

1.1 – Introdução / Histórico.

 A Governança em TI ainda é um assunto bastante controverso e pouco entendido de forma geral pelos Gestores ou “Governantes” e na maioria das vezes o assunto é abordado de forma muito ampla ou superficial e não é raro observarmos abordagens equivocadas daquilo que se julgaria ser de fato Governança e ainda o que vem a ser de fato Governança de TI.

 Com o objetivo de auxiliar os colegas e gestores das empresas que necessitam dispender algum esforço em futuro próximo em direção a Governança em suas organizações,  resolvemos escrever este artigo, compartilhando algumas experiências e conhecimentos adquiridos ao longo dos últimos oito anos de atuação neste segmento de consultoria.

 É necessário prevenir ao nosso leitor que o tema Governança de TI é bastante amplo e dependendo das condições preexistentes na organização e da abordagem utilizada para a adoção dos critérios da Governança, a missão poderá ser mais ou menos complexa e ainda irá requer mais ou menos investimento e esforço para ser de fato atingida.

 Primeiramente, é necessário entendermos a origem da “Governança” e quais são os seus reais motivos e objetivos. Explicar a as razões da Governança de TI através da sua relação com a Governança Corporativa,  embora seja a “forma acadêmica” correta, enquanto “abordagem em si”,  não é de todo suficiente para exprimir todos os objetivos a serem tratados e atingidos,  e mais ainda,  não esclarece qual deve ser o papel do “Governante”  antes, durante e depois de  obter a condição de “Governança”, principalmente quando o assunto é relacionado ao uso e gestão da tecnologia da informação.

 

  • O Conceito “Puro” de Governança.

 

O conceito “puro” de governança não nasceu em 2002, com a aprovação da Lei Sarbanes-Oxley pelo Governo Norte Americano, ou seja, não foi o congresso deste país que inventou o conceito de Governança (Há colegas que acreditam que isto seja uma verdade, e que a “culpa” destas obrigatoriedades tenha  sido originado pelos políticos norte americano, o que obviamente não é verdade). O conceito de Governança é muito antigo e tem a sua origem nas primeiras organizações politicas e democráticas  nas  cidades-estados da Grécia Antiga (500 AC a 300 AC).

 

O Termo  “Governança” tem origem na palavra “Governo” e representa em sua essência o “Ato de Governar”, mesmo na Grécia antiga, era exigido do “Governante” certa “conduta” durante o exercício do “poder público” e relacionado aos “Atos” praticados pelo “Governante” durante o seu “Governo”,  sendo requerida pelos “eleitores”  uma conduta baseada em “valores” tais como: “Coerência”, “Transparência”, “Responsabilidade”, “Respeito”, “Ética” em relação ao “Grupo ou coletividade” o qual o governante deveria “representar” através dos seus “atos”.

Enfim, praticar “tudo aquilo” que pudesse ser “julgado pelo bom senso de todos” como sendo um “bom governo”.

 

  • O Conceito “moderno” de Governança.

 

Nos tempos atuais, o conceito “público” de governança permanece praticamente inalterado, mudando apenas as formas adotadas pelos governantes para a identificação das “necessidades” dos seus “eleitores” ou “representados” em razão do aumento significativo da quantidade de “eleitores”, e das formas adotadas para comunicar aos mesmos os seus “valores” e o “resultado” obtido pelo seu “governo”, sendo isto denominado “transparência” das ações realizadas, e visam basicamente obter “aprovação” dos “eleitores” dos atos praticados pelo  “governante” em seu “governo”.

Na Grécia antiga, bastavam os Governantes se deslocarem até a praça central e com alguma competência em oratória, quaisquer questões existentes entre  “governo” e “eleitores” poderiam ser de pronto resolvidas.

Nos dias atuais isto se tornou uma prática impossível de ser realizada “pessoalmente”, o que justifica aos “governantes” apoiarem-se nos meios de comunicação para promover a “transparência” dos atos e fatos.

 

  • O Conceito “organizacional” da Governança.

 Deste ponto em diante, iniciamos o tratamento do que seja Governança no contexto anunciado como sendo o objetivo deste artigo.

    • A Governança em Empresas onde o Dono é Único

 Uma organização, durante o período de tempo onde o  “proprietário” é o gestor único do seu negócio, em tese,  não há razão para aplicação dos princípios de  Governança, pois o “Único Dono” do negócio é o seu “único governante” e “ele próprio” por suas “ações”, “omissões”, “atos de empreendedorismo”  se  “auto constituiu” no exercício desta função.

  

    • A Governança em Empresas onde há poucos Sócios / Investidores

 

A Partir do momento que o “único dono” recebe “sócios” ou “investidores”, surge automaticamente à necessidade de aplicar os princípios de “governança”, pois surge ai as funções de “governo”, uma vez que dentre os sócios  e investidores existentes, haverá sempre a condição de que “um” mais que os “outros”, seja denominado o “governante” da organização, ou ainda, o seu “gestor”.

Note que mesmo nesta relação, o “gestor” é “aceito” pelos demais “sócios”, materializando a  relação de “governança”, pois há um “governante” e também há  a figura dos seus “eleitores”.

 

Neste caso, os conceitos e atitudes requeridos historicamente aos “políticos” passam a ser  aplicáveis ao “gestor” da organização, agora não mais  se relacionando com “eleitores”, mas sim em relação aos  demais “sócios e/ou investidores” que o instituiram nesta função.

Como a dimensão do público aqui exposta ainda é reduzida (Quando há poucos Investidores),  o esforço praticado pelo “governante” é um pouco maior,  do que seria necessário ser praticado por um “governante” da Grécia antiga, ou seja, através da execução de algumas reuniões, atas, e comunicados, todas  as questões de “governança” e “transparência” dos atos praticados em  sua “gestão” podem ser dadas como “satisfeitos”.

Neste caso, as questões de “transparência” dos atos de seu “governo”  ainda podem ser “comunicadas” e “avaliadas” com a “presença” de todos os “interessados”.

Pelo menos em “tese”,  as questões de “governo” podem ser resolvidas assim,  em organizações onde há incidência de poucos “sócios” e um “gestor” principal.

 

    • A Governança em Empresas onde há Muitos Sócios / Investidores

A partir do momento que uma organização, inicialmente com apenas “um dono” ou com “poucos sócios” resolve  “abrir” o seu “capital”, ou seja, transforma as “cotas capitais” em “ações”, e estas por sua vez, passam a serem disponibilizadas para “negociação” junto ao mercado de capitais, estas empresas passam a ser “acometidas” em termos de “governança” pelas mesmas “dificuldades” enfrentadas  pelos “políticos modernos” em razão da grande quantidade de  “eleitores”, só que agora estes “interessados” passam a ser “todos os acionistas” da organização (Aqueles que detêm ações), no entanto, um “gestor” de uma grande corporação não tem a possibilidade de utilizar-se de um canal de TV aberto ou dos meios de comunicação em massa  para comunicar e resolver ali as suas questões de “governo” e dar conta da “transparência” de suas ações,  frente ao publico em geral, uma vez que as “organizações” possuem caráter “privado”, e estas questões só dizem a respeito apenas a uma “parcela” do publico em geral composta apenas pelos seus “investidores”.

 

Então o nosso leitor poderá se perguntar: Se os assuntos de “governo”  de uma organização são tratados de forma “privada” ou “reservada”. Como então estas organizações atraem novos investidores?

 

Em resposta a esta dúvida, há ainda que explanar sobre as questões legais, relacionadas às grandes empresas (Lei das Sociedades Anônimas), regras e atribuições impostas pelo Mercado de Capital (Novo Mercado/BOVESPA, SOX, BASEL), e cuja ênfase, estão relacionadas a estabelecer critérios e proteções para o investidor, visando  promover a sua “confiança” em relação às organizações, e este,  é o “fator determinante” que irá “atrair ou repelir” novos investidores para uma organização, ou seja, o foco passa a ser uma “questão de confiança”  e não o critério de “aceitação/aprovação” como é a dimensão enfatizada pela  “governança publica”,  tanto a antiga como na moderna.

 

Em razão desta “transparência” com o seu “publico investidor”,  que uma “organização de capital aberto” estabelece a sua relação de “confiança”  entre os seus “gestores” e seu “publico investidor”. Isto em essência é o que se denomina “Governança Corporativa”.

 

Este conceito, embora possa parecer recente, também é antigo e tem a sua origem na “Revolução Industrial”, quando as primeiras “oficinas” se transformar em  “pequenas fábricas” e estas,  após  receberem a  adesão de investidores e sócios veio a se transformar nas primeiras grandes organizações modernas, ai surgiu o conceito e a necessidade do “governante organizacional” e em sua consequência as ações de “governança”.

  

  • A Relação da Governança de TI com a Governança Corporativa.

 

Em meados do Século passado surge a presença da informática, e com o uso desta ferramenta, as grandes corporações elevaram a sua “capacidade” de processar grandes volumes de operações, e este aumento,  acelerou o crescimento destas empresas e aumentando mais ainda a quantidade de investidores, promovido por décadas de operações e de crescimento constante.

 

No entanto, como todo o remédio tem o seu efeito colateral, o advento da “informatização” e do aumento “em ordem geométrica” das operações, surge um “Risco” que não havia antes, ou seja,  a “Possibilidade” de que uma “ação isolada” de alguém, em um determinado momento, alterar o conteúdo de um “número” para “mais ou para menos”, e modificar com isto o “resultado final” de uma organização em detrimento da ocorrência de  “fatos reais”  que o justifiquem.

 

Este tipo de ação “fraudulenta”, uma vez de conhecida  pelo “publico” investidor, pode comprometer drasticamente a “confiabilidade”  que os investidores possuem pela empresa em questão, desvalorizando o “valor” de suas ações no mercado de capitais, e com isto,  prejudicando seriamente a todos os seus investidores.

 

Pois fatos desta natureza de fato ocorreram, envolvendo algumas empresas americanas entre os anos de 2001 e 2002, foram descobertos e após serem comunicados ao público daquele país, acabou por prejudicar as “economias pessoais” de uma grande quantidade de investidores americanos. Visando a proteção do mercado de capitais e de seus investidores, surgiu em Junho de 2002 a Lei Sarbanes-Oxley,  estabelecendo o “conceito” atual de “Governança Corporativa” e em consequência da participação e importância da “informática” nas operações das organizações, surge também a “Governança de TI”, visando exclusivamente estabelecer mecanismos de proteção, segurança, confiabilidade nas empresas e com isto evitar a ocorrência de fraudes, viabilizar meios para a sua identificação e com isto,  proteger o mercado investidor americano, e demais investidores que atuam naquele pais.

É um fato pouco conhecido como os legisladores americanos chegaram a este “formato” de exigências a serem satisfeitas pelas empresas. Após os escândalos financeiros de 2001/02, os legisladores perceberam que havia algumas empresas, mesmo em detrimento dos eventos  ocorridos no mercado de capitais, continuavam apresentando um alto índice de “confiança” pelos  seus “investidores”, e posteriormente,  visitando cada uma destas empresas,  notaram que elas possuíam em comum a adoção de modelos de gestão baseados em regras de “governo”, controle de condutas administrativas, contábeis e dos processos de qualidade relacionados ao uso da tecnologia e operações embasadas em  “documentos e processos formais que incluíam o uso de melhores práticas sugeridas por diversos padrões de qualidade entre eles: “ISO – International Organization for Standardization e BS- British Standards Institution ” e praticavam ainda uma relação  de “transparência” e  forma “regular” com os seus investidores.

 

Com base nestas constatações e na inclusão da “responsabilização criminal pela ocorrência de fraudes” a que os gestores passariam responder, foram criadas às bases dos requisitos de Governança que foram instituídos através da Lei Sarbanes-Oxley. O conteúdo da lei em si não proporciona todo o seu conteúdo, pois ela o faz com o auxilio de instruções complementares emitidas por instituições regulatórias (Self-Regulatory Organization- SRO) as quais são instituídas e apoiadas pelo Governo Americano,  tais como: PCAOB – Public  Company Accounting Oversight Board e  ISACA- Information Systems Audit and Control Association,  e que juntas deram origem a base aos requisitos daquilo que denominamos “Melhores Práticas” aplicáveis em Governança e Governança de TI respectivamente.

 

1.2 – O Início da Governança no Brasil

 

A Governança Corporativa e a Governança de TI  passam a integrar como “necessidade real” para os Gestores de TI brasileiros, somente dois anos após a aprovação da Lei Sarbanes Oxley pelo Congresso Norte Americano,  visto que nos dois primeiros anos de aplicação desta lei (2002-2003), o  foco inicial era o processos de Compliance das empresas americanas sediadas no território americano, fazendo com que a “onda de Compliance”  chegasse para valer ao Brasil apenas em meados de 2004 e que perdurou fortemente até o final de 2006 (Limite para Conclusão de Compliance SOX).

Neste período, o foco das certificações passaram a ser subsidiarias e filiais das empresas norte americanas sediadas fora do território americano e incluindo algumas poucas empresas brasileiras, que nesta mesma época,  mantinham suas ações na Bolsa de Valores de Nova York (NYSE).

 

Desta época aos dias de hoje, diversas empresas que inicialmente não figuravam nesta pequena e seleta lista, buscou atender aos requisitos e certificações necessárias e obtiveram  o “direito”  de incluir as suas ações na bolsa de valores norte americana.

 

Para quem “não é do meio”, isto pode parecer algo “sem sentido”, mas certamente o é:

 

Para exemplificar a mudança promovida por este “Compliance”, seria mais ou menos em “termos de comparação” a  um fornecedor que vende o seu produto apenas para um “mercado” nas proximidades da sede de sua fábrica e de uma hora para outra, passa e estender as suas vendas para uma grande rede de “supermercados” presentes em todo o país.

Este “aumento”  na presença no mercado e consequentemente do aumento do volume de vendas apresentado pelo “produto”  é comparável  ao  possível impacto causado quando uma “ação” passa a ser comercializada na bolsa de valores  Norte Americana,  e as consequências disto para a empresa são extremamente positivas, pois há um aumento sensível no volume de vendas das suas  “ações” e também do “aporte de recursos” quando este direito é alcançado.

 

Nesta mesma época (entre 2001/2006),  diversas bolsas de valores pelo mundo afora acabaram criando regras de proteção aos seus  mercados de acionistas, seguindo os mesmos moldes adotados pela NYSE , e no Brasil não foi diferente, e ainda em 2001, iniciamos a adoção de critérios  baseados em “Governança Corporativa”, através da adoção de regras estabelecidas pela CVM- Comissão de Valores Mobiliários e BOVESPA, onde a adesão das empresas,  continua sendo voluntária aos critérios de “Governança Corporativa”, podendo ainda receber classificações de Nível 1 e Nível 2 (Mercado Novo / Bovespa) de acordo com o seu nível de adesão.

 

Nos critérios de Governança Corporativa estabelecida pelo Nível 2 – Mercado Novo/BOVESPA, a Governança de TI, é tratada de forma “indireta” e através das “verificações” de auditoria aplicadas aos controles internos operacionais e financeiros  nas empresas e realizados com base e referencia as  “melhores práticas de mercado”, quando observadas pelas Auditorias, onde a  ênfase está direcionada a verificação dos riscos e efetividade dos controles internos (Quando menciona o atendimento de “conformidade”  e nos remete as  “melhores práticas de Mercado”, indiretamente nos remete  as “melhores práticas” aplicáveis a Governança de TI, e que são  estabelecidas pela SOX e regradas de acordo com os critérios de auditorias indicados pelo  ISACA e PCAOB.

Embora o nível de exigência aplicado no Brasil não seja o mesmo (é Mais flexível), os critérios de uma “forma geral” utilizados durante a “identificação” e “mitigação” dos riscos seguem a mesma lógica e práticas adotadas pela Governança de TI  norte americanos.

 

1.3 – Os Novos Paradigmas da Governança no Brasil

 

Pense um pouco comigo, e veja se o conteúdo do paragrafo a seguir representa ou não uma “realidade muito possível” a médio e longo prazo em nosso país:

 

No ritmo que as empresas brasileiras estão crescendo, mais dia ou em menos dia, ela penderá para a abertura do seu capital e visando disponibilizar as suas ações para ser negociada na Bolsa de Valores, isto é algo inevitável e representa a única forma de uma empresa de “médio” ou  “médio-grande” porte se capitalizar e tornar-se uma empresa de “grande-porte” em  toda a sua plenitude.

 

E,  mesmo que a empresa onde atuamos seja uma empresa “familiar”, mesmo para elas,  este dia vai chegar, caso isto não ocorra de fato, estas empresas estão “fadadas” a permanecerem nos patamares atuais ou crescerão em ritmo mais lento, passando a correr o risco de que em algum dia, uma empresa pertencente ao “ grupo principal” venha a lhes adquirir ou venha a ocupar a sua parcela e lugar no mercado. “Infelizmente o mundo é assim mesmo, se não avançarmos rapidamente o “leão” vem e nos consome”.

Entenderá com mais propriedade o conteúdo desta frase, aquele que em alguma vez em sua vida teve a oportunidade de realizar um “salto com paraquedas”. Não é uma decisão fácil, mas será de fato “um paraquedista”, somente aquele que, efetivamente “realizar o salto”. “Para aqueles que “não saltaram” o voo foi apenas um passeio panorâmico, com uma mochila diferente atada as costas”.

 

Ou Ainda, se a empresa onde atuamos já possui ações negociadas na bolsa de valores em nosso país e obteve com isto um nível de crescimento que a tornou maior do que era inicialmente, é inevitável que em algum dia estas ações passem a ser negociadas em alguma das principais bolsas de valores espalhadas pelo mundo. Esta é a única forma de uma “grande-empresa nacional” vir a tornar-se uma multinacional global e hastear a nossa bandeira em mastros espalhados mundo afora.

 

Nada disto é, ou poderá ser possível, sem que as questões de Governança Corporativa e as relacionadas à Governança de TI estejam resolvidas e que os controles e métodos envolvidos estejam em pleno uso e funcionamento.”

 

Se a base  aplicada nesta linha de raciocínio te faz algum sentido e de alguma forma,  você leitor,  concorda com estes argumentos, você está mesmo “fadado” a vir a conhecer a aprofundar-se em “assuntos” relacionados a Governança.

 

Vamos pensar um pouco mais adiante: Se você esta no início de sua carreira (seja ela relacionada  às ciências de tecnologia ou a administração de empresas em geral), e  pretende vir a ocupar as posições de CIO ou CEO em grandes corporações daqui a  20 ou 30 anos, este é irremediavelmente o seu caminho a ser seguido,  comece a trilha-lo ainda hoje,  ou quem ocupará  esta vaga lá no futuro,  possivelmente será algum “profissional treinee” em  fase de treinamento neste assunto nos dias atuais.

Mesmo tendo atuado na organização de processos e controles organizacionais e, na organização de processos relacionados a TI durante mais de 25 anos,  confesso que  no início o entendimento e aplicação destes conceitos nos foi um pouco “confuso”, pois as abordagens utilizadas pelos diversos institutos e organizações envolvidas ou inseridas no contexto da  Governança nos parecia ser desconexas e muitas vezes sem sentido, quando analisadas de forma conjunta e integradas entre si, e infelizmente posso lhes garantir que em verdade é assim mesmo. Esta primeira “impressão” causada pelos “conceitos e aplicação” de tudo aquilo que seja relacionado à “governança” aos  “leigos” promove, e acreditamos que continuará a promover durante muito tempo ainda,  muita confusão, tentativas frustradas e uma sucessão infindável de erros de aplicação e integração dos diversos conceitos e práticas envolvidas.

 

A bem da verdade, cada instituição promove a sua “área de foco” ou “especialidade”, e cada qual,  dentro do limite estabelecido pelo universo contido em seu “quadrado”, promovem da melhor forma possível aquela “parcela” do conjunto de “conhecimentos e práticas” daquilo que denominamos ser governança de TI.  E, o grande “segredo” de tudo isto está relacionado à adoção de modelos que possam integrar e fazer interagir as diversas áreas do conhecimento envolvidas, para que tenhamos como produto final, aquilo que se denomina “Governança Funcional de  TI”.

 

1.4 – Componentes Principais da Governança de TI.

 

Vamos inserir aqui uma figura, colocando os principais modelos e recomendações, que juntos, proporcionam um “razoável” grau de cobertura  e  maturidade  em  Governança,  para que o nosso leitor possa perceber a dimensão geral do tema em questão:

 

Embora a figura represente um “organograma”, nos aludindo certa relação de “hierarquia” e “relação de dependência” entre os diversos “modelos” e “melhores práticas”, esta alusão não é de todo correta, embora exista de fato está “relação”, ela é absolutamente relativa quando passamos do campo teórico para o campo prático das relações entre os diversos processos e disciplinas que o compõe.

 

1.5– Erros comuns causados pela Unitarização dos Componentes da Governança de TI

 

O erro mais comum aplicado no entendimento e aplicação das disciplinas contidas em cada um dos componentes listados nesta figura e muitas outras variações publicadas mundo afora, é  acreditar que colocá-las em ordem unitária em um plano de ação  (To-do-list) e priorizar uma sequencia para a sua aplicação e então adotá-las  e ainda, que ao final desta  “jornada”,  o “assunto” governança estará resolvido,  Quem pensa assim,  sugerimos repensar imediatamente os seus conceitos, pois embora esta seja uma “abordagem possível”, é também aquela que representa o principal motivo pelo qual a adoção da  “Governança” seja tão dispendiosa, traumática e tão complexa para as empresas.

 

Vou lhes citar um exemplo, que pode nos representar isto que lhes afirmo, em relação ao volume de investimentos e das inúmeras “rodadas” de “tentativas e erros” que são necessárias muitas vezes para adotar uma melhor prática exigida pela Governança. Vamos citar aqui apenas um,  mas que geralmente é o “mais comum” é o mais “representativo” , e é o que mais facilmente pode ser percebido e entendido.

 

Exemplo:

 

Imaginemos que a nossa empresa “fictícia”,  necessita adotar uma “Metodologia”  para manter as suas iniciativas de mudanças em “projetos” sob controle, e com isto, atender aos requisitos estabelecidos pela Governança TI em relação a mudanças e projetos.  (Veja PO10 e AI6 – COBIT 4.1).

 

Por cinco minutos, vamos “fazer de conta” que a figura contida no gráfico acima citado “não existe ou ainda não seja conhecido por completo”, e sendo assim, “seria razoavelmente correto” imaginar que ao contratar alguém ou você mesmo compor uma metodologia para gerir os seus projetos de “desenvolvimento de sistemas” seria o “suficiente” para considerar o assunto “Gerenciamento de Projetos e mudanças” por concluído e atendido.

Em primeira análise, esta “missão” seria uma atividade razoavelmente “simples”, bastaria alocar alguns de nossos melhores analistas de sistemas, e determinarmos a eles que definam um modelo de trabalho “metodologia” se possível obtendo um “consenso” com os demais analistas de sistemas e programadores da companhia, e era isto, Em pouco tempo, teremos um “método” em uso para promover as mudanças e os projetos de desenvolvimento de sistemas na companhia.

 

No entanto, se trouxermos o “conteúdo contido em nossa figura” de volta a vida, e repassar cada quadro com um pouco mais de “critério”, facilmente poderemos perceber que  um “projeto”  que se propõe a  “desenvolver ou modificar  um sistema”,  possa ter algum tipo de “relação” e poderia muito bem “causar impactos” em quase “todos”  os quadros que compõem o referido organograma contido em nossa figura.

 

Vamos entender alguns relacionamentos possíveis, enumerando “uma pergunta” para cada “quadro”, considerando nela algumas “possíveis relações” entre a “disciplina” descrita em cada quadro com um “projeto/atividade” que se propõe a desenvolver/modificar um novo sistema:

 

  • O controle de acesso a ser inserido no escopo de desenvolvimento do sistema/aplicação foi avaliado pela equipe de riscos e segurança, no momento de analisar os requisitos da nova aplicação?
  • O desenvolvimento e testes, segregação entre as funções / perfis envolvidos na operação do sistema, alçadas e controles compensatórios, conflitos de interesse entre os usuários foram considerados como requisitos no escopo da nova aplicação?
  • Os requisitos do sistema consideram somente as questões de negócio (solicitante) ou também são consideradas as questões de ordem técnicas de TI, tais como: Modelos de  arquitetura, padrões de infraestrutura e serviços de TI, padrões de analise e codificação segura de sistemas,  integrações com os demais sistemas?
  • A Infraestrutura, serviços de apoio e suporte para a nova aplicação foram avaliadas durante o levantamento dos requisitos técnicos para o novo sistema?,  há recursos de TI capazes de absorver a nova aplicação sem causar impacto nas demais existentes?
  • O método de engenharia de software contempla ações de governança em relação ao registro de requisitos, analise, construções, validações e testes,  responsabilidades pela implantação e suporte aos usuários do negócio? – Normalmente as metodologias somente atendem a este requisito.
  • O projeto possui controles que possibilitam o seu gerenciamento durante todo o seu  ciclo de vida de desenvolvimento do software? – Normalmente é construída uma MDS para tratar as questões do ciclo de vida do software  e uma  MGP  atendendo as questões relacionadas ao ciclo de vida do Gerenciamento de projetos. Nestes casos, quando o projeto “não dá certo”,  não há formas de identificar claramente onde ocorreu a falha (Eis aqui a eterna discussão entre o PMO, GP , Analista de Sistemas, Programadores e Testadores, onde cada um fez exatamente a sua “cota parte”, mas o sistema não saiu conforme o combinado.).
  • E Por último e não menos importante,  estão as questões de segurança e não vamos nos enganar acreditando que a segurança deve estar restrita apenas as questões de acesso, pois há ainda as questões de segurança física, redes, backup /restore, continuidade, contingencias, e tudo mais relacionado ao gerenciamento da segurança da informação.

 

E  para Concluir,  duas perguntas finais:

 

  • Seria sensato incluir no ciclo de vida de desenvolvimento de sistemas,  “gatilhos” que pudessem atender e responder a estas questões  “durante” o ciclo de vida do projeto?

 

ou

 

  • Faria mais sentido não incluir estes “gatilhos”  no contexto da metodologia e deixar para que todas as áreas impactadas  controlem estas “integrações”  de forma paralela a Metodologia Desenvolvimento do sistema?

 

Quando ocorre uma resposta não adequada para estas perguntas,  verificamos posteriormente a existência de alguns possíveis “vícios”,  mesmo depois de investirmos tempo e dinheiro no desenvolvimento de  metodologias continuamos não atingindo o resultado proposto pela Governança TI e consequentemente causando impactos desastrosos na Governança Corporativa,  no que tange as questões relacionadas a “manter projetos sob controle”, e dai verificam-se situações como as abaixo relacionadas:

 

  • Sistemas sem controle de acessos, segregação de função, ou com controles falhos e incompletos.
  • Sistema que criam novas situações de risco para a TI e ao negócio, fraudes, erros, inconsistência de dados, apurações incorretas de valores, etc.
  • Sistemas, embora tecnicamente bem desenvolvidos, que não possuem os recursos de infraestrutura e serviços necessários para lhe oferecer o devido suporte, provocando paradas no negócio, perda performance, atrasos operacionais, incidentes recorrentes, etc.
  • Sistemas que acarretam impacto no ambiente e performance em recursos destinados a suportar outros  sistemas pré-existentes (Funcionava bem no inicio, agora demora ou perdeu a performance de uma hora para outra sem nenhuma explicação ou motivo aparente),
  • Projetos que demandam mais tempo para serem concluídos do que o inicialmente planejado, o software ficou pronto e a infraestrutura ainda não, faltam periféricos, instalações de rede até o ponto de utilização, etc.
  • Projetos que demandas mais recursos do que os inicialmente previstos,
  • Sistemas que apresentam falhas de engenharia de software ou de atendimento de escopo,  faltando ou sobrando requisitos em seu produto final,
  • Sistemas confeccionados para os usuários, mas estes,  inexplicavelmente não o utilizam ou apoiam o uso do sistema,
  • Sistemas sem documentação, sem rastreabilidade em seu processo de produção, quem mesmo foi o usuário que solicitou este sistema?
  • Sistemas que após serem concluídos, demandam novas solicitações de desenvolvimento para então integra-los aos sistemas pré-existentes,
  • E tantos outros vícios que poderiam ser aqui relacionados, cuja causa é a falta de  integração entre  a aplicação das melhores práticas com as demais melhores práticas de TI e que na grande maioria das vezes não tem nenhuma relação com aspectos de competência dos técnicos que construíram as soluções, mas sim os que definiram a amplitude dos seus métodos de trabalho (Aqui vale registrar a máxima de Albert Einstein, onde a “pergunta “certa” contém “metade” da resposta”, e a qual eu acrescentaria ainda um pequeno complemento: “Quando a “pergunta” ou a  “resposta” é errada, teremos como resultado o “dobro ou o triplo” do esforço que seria “realmente necessário” para obter a resposta “realmente certa”.)

Ai o nosso leitor poderá se perguntar, ou ainda continuar tendo dúvidas, relacionadas ao real motivo pelo qual devemos adotar “melhores práticas” em TI para o gerenciamento de projetos e mudanças e os motivos pelos quais estes métodos devem ser integrados a todos os
demais processos de TI.

A resposta é bastante “simples”,  quando inserimos a Tecnologia nas questões de governança, estamos endereçando com isto o “risco” atrelado as suas “operações” e incluindo nelas as atividades de  “desenvolvimento e manutenção” dos sistemas e consequentemente as informações que eles manipulam e armazenam (estas informações irão compor o resultado da empresa ao final do exercício contábil, e serão endereçadas e publicadas no seu Balanço).

Os fatos ocorridos em 2001/2002 ocorreram devido a “fraudes” relacionadas à “manipulação indevida” das informações das empresas.

O “ato” de “desenvolver ou modificar” sistemas esta relacionado diretamente as “informações”, seja através de “projetos ou atividades mudanças” aplicada em sistemas, e ainda, manter isto “sob controle” é um dos  “pontos chaves” da governança corporativa e Governança de TI,  pois interage diretamente na “relação” de Integridade, confiabilidade e disponibilidade das “informações”, e isto,  é à base da “confiabilidade” a que os “governantes”  devem “transparecer” para as partes  “interessadas” em seu “governo”, e, portanto, o resultado obtido pela sua gestão.

Fim 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.

——

  • FRAMEWORK DE PROCESSOS E CONTROLES PARA O COMPLIANCE DE TI

Convidamos a Navegar pelo em 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. 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).

http://www.aghatha.com/processos.htm  , clique nos fluxos para acessar o Suite de Navegação no Framework AGHATHA para o Compliance de Processos e Controles de TI.

Ou ainda, Leia mais sobre este mesmo assunto,  em nosso POST.

https://aghatha.wordpress.com/2012/05/24/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-padroe/

—- Fim Conteúdo Artigo —-

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  

———

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 http://www.aghatha.com/index.htm / 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

Compartilhe este post:

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 »

Blog Oficial – Aghatha Maxi Consulting

aghatha_maxi_top_300_300

AGHATHA MAXI CONSULTING é especializada em Governança de TI e Serviços Gerenciados de Segurança da Informação. Fornecemos framework integrado de processos e Serviços que possibilitam a conformidade aos seguintes padrões: GRC,SOX,PCI,COSO,COBIT,ISO-27.002,ISO-20.000, ITIL,Gerenciamento de Mudanças e Gestão de Portfólio de Projetos de TI através de PMO – Escritório de Projetos. Conheça melhor a nossa empresa  ( Http://www.aghatha.com.br / http://www.aghatha.com).

Somos Distribuidores no Brasil das Soluções Integradas e Convergentes da ACCELOPS / USA , para monitoramento de Disponibilidade, Performance e Segurança – AccelOps SIEM e AccelOps PAM –  Monitoramento integrado e Convergente de Data Center e SOC/NOC. (Veja mais detalhes em nosso site em http://www.aghatha.com.br/solucoes.htm e http://www.aghatha.com.br/datacenter.htm

——–

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

 Todas as demais marcas, modelos, desenhos, nomes, incluindo o conteúdo os textos integrais dos artigos contidos neste BLOG, são de propriedade dos seus respectivos fabricantes, autores ou publicadores.

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

O  leitor não é 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ícios comerciais de forma direta ou indireta para sí ou em favor de 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.

——–

Na confecção dos artigos contidos neste Blog, serão regularmente citados e/ou utilizados como referenciais técnicos os seguintes nomes, marcas e publicações:

 — fim declarações de Copyright —

As informações e comentários existentes neste BLOG  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 sobre qualquer artigo, conceitos ou conteúdos, 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

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

Skype : aghatha.maxi.consulting

Skype : eurico.haan.de.oliveira

 

Read Full Post »

%d blogueiros gostam disto: