Feeds:
Posts
Comentários

Posts Tagged ‘diretrizes ti’

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

Anúncios

Read Full Post »