HOW TO DRAW BUSINESS PROCESS FLOWCHART Part 1 of 3 – Introduction, Concepts

HOW TO DRAW BUSINESS PROCESS FLOWCHART

Part 1 – Introduction, Concepts and Models.

How to draw flowchart business processes – Part 1 of 3-  Introduction, Concepts and Models.

Often we are faced with the difficulty that those responsible for processes in organizations have to show them  graphically.  In order to assist colleagues in this activity in this article we describe a simple method,  but at the same time is very useful and practical.

Let’s use in the manufacture of this article, streams and graphs drawn using Microsoft Visio,  however the player may use any other tool available in the market, including  free tools.

Our goal here is not to evaluate this or that tool, or determine whether a tool is better than another,  or the possibility of using other models and formats for documenting processes. Our goal is to describe a method that the  reader can easily learn and apply in the documentation of its processes.

1 – Introduction to the processes study

Before discussing the technique to be used in the  design itself of the processes is necessary that our reader has an understanding  of the basic principles of processes, so that we will cover the major topics and  in this sense even knowledge.

1.1 – Process Basic Components 

By definition, a  “process” should have a set of basic components to be
considered a process, they are: Component “input”, based on  this component is carried out the activities of “processing” and as a result will produce an any  “output ”.

1.2 – Quality Control between Process Components

Like any  activity intended to produce something, the process requires the  completion of  control activities to ensure their quality and that should be applied to each of  its components (Input-Process-Output).

By doing so we avoid  communication errors or gaps between the elements of the process within the  universe understood by the process itself.

Translating this in a more clear:

1.3 –  Inter-Process Quality Control

However, a process is not an element of absolute and  restricted himself, possibly at some point will depend on other processes to be  “fed” and possibly, after performing its own processing, it will “feed” another  process through its “product” and so on.

Given this, it is good practice to consider actions of quality  control also between processes, and thereby ensure the quality and integration  between them, ie, it is important to ensure that the “product” generated by a  “supplier process ” is validated by himself before being communicated to your  “Customer Process”.

Translating this in a more clear:

In theory, when we act this  way, “Process Performer” would not need to validate their “inputs” to proceed  when the receipt of his “entry”, since this should have occurred previously in  the “Provider Process”, little carry out even before the release of  “output”.

However, if we check the quality only  once, we are subject to  occurrence of a fault in the output of  “Process supplier” and not always the “Quality declared” in the output of a  process, will fulfill the quality requirements needed to meet the “entry” to the  next process.

Practical Example:

Try to run life cycle of a project to develop systems, where  each step of the cycle can be likened to a process. When  we do not do these checks in and out at each stage of the production process of  the system, the degree of variation of the resulting product will be a factor of  error rates occurring at each stage, (the result will be measured by multiplying  the rates error in each step, the error rates of the following steps, and so
on), this is the mathematical explanation of possible distances between the  “original requirement of the business” and the “work product” project, note that  first of all a methodology is a process and can be used in formulating the  concept of quality control in formatting steps or stages of an MDS – Software Development Methodology).

Translating this in a more clear:

Once you understand these  components and the basic criteria of quality review and integration between the  components of a process and processes between suppliers and client processes, we  return to our initial goal, which is graphically demonstrate the business  processes through flowcharts.

2 – Standard  Symbology

There are several possible patterns of  symbols to draw flowcharts of processes, including standards and specifications  for technical design and software, data models and many others.  We adopt here a very simple model composed of a small number  of symbols, but suffice to establish a business process using a  flowchart.

They are:

3 – The  Model Structure of the Process Flowchart.

There are several  possible ways to structure a process flow diagram, to map the most appropriate  process is called (CROSS-FUNCTIONAL), which could be translated roughly as  “flowchart crossover between functions.”

In this format, the flowchart enables the inclusion of information in addition
to the sequence of activities provided by the sequencing of symbols, and it is
possible to segment the design process in “sectors / cells” like a mother, being
inserted in the lines or the Actors functions responsible for implementation of
activities and steps in the existing columns in a given process.

See how the design would be a process following the structure  Cross-Functional  in Landscape view:

The same process,  following the vision in Cross-Functional portrait view:

And yet, the  same process using the free form usually used.

Note that the additional  information present in the two previous options are in fact the difference in understanding the process.

———-

Share This Post:

Related Articles:

Part 2 – Survey, Analysis and Design  Workflow (Step-by-Step to Draw a Flow).

In the next article (Part 2), we will address the techniques to be used during the
interviews for information gathering processes to be drawn and some examples of
how we organize and prepare the content of the information obtained in the
survey to facilitate the preparation of the corresponding flowchart.

Part 2 – Survey, Analysis and Design Business  Process.

  • What’s in the 2a.Part  (Continuation of this article): (This article is in translation).

Part 3 – Survey, Analysis of  Capacity and Load Processes (Learn how to calculate effort, time and  costs)

  • See What’s in the third. (Continued from second. Part) in: (This article is in translation).

· Download do conteúdo deste Artigo :

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

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

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

Thanks and Invitations:

The information and comments in this article are the  result of observations and experiences gained by the author during the execution  of projects over 30 years of experience in the market.

We use this space for the dissemination and  exchange of knowledge with our readers, customers and friends.

If you  have any questions or need additional information to your understanding or
application, contact us via e-mail address below.

Embrace and Cheers to All,

Eurico Haan de Oliveira

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

consulting@aghatha.com
Follow us on Twitter, and get notified of new articles and / or revision of this
text. Aghatha_maxi Follow on Twitter

———

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

[youtube http://www.youtube.com/watch?v=T_gsHigMFvU]
———

Copyrights and Preservation of Rights Declaration:

All other brands, models, drawings, names, including the content of this article, are the property of their respective manufacturers, authors or publishers.

The  reader is allowed to make non-commercial internal use and the content of this
article, provided they kept the copyright notices and kept the references to its
origins and identification of the respective authors and owners.

Rights to commercial use of this  article are preserved and maintained in unique name of the author and the reader  is not allowed to use them, in whole or in part for commercial uses and purposes  and / or activities aimed at obtaining their own profit or commercial advantage  or third parties.

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.

For the preparation of this article have been cited and / or  used the following names, trademarks and publications:

  • COBIT ® 4.1, which is  wholly owned by ISACA – Information Systems Audit and Control Association ( www.isaca.org ) and IT Governance Institute ™ ( www.itgi.org  ) and All copyrights reserved.
  • This Article Content – is the exclusive property of  Author and AGHATHA ( Website: http://www.aghatha.com/index.htm  /Webstore:  Http: / / www.aghatha.com ), and all copyright is preserved, including its use and  commercial exploitation .
  • COSO ®, which is wholly  owned by Committee of Sponsoring Organizations of the Treadway Commission (COSO)
    ™ ( www.coso.org/  ) and All copyrights reserved.
  • ISO-IEC ® Standard – are  exclusive property of the International Organization for Standardization (ISO ®)
    and International Electrotechnical Commission (IEC ®) ( www.iso.org  ) and All copyrights reserved.
  • ITIL V-3 ® – IT Infrastructure Library ® ( www.itil-officialsite.com  ) that is owned and exclusive protection of the British Crown ( www.ogc.gov.uk  ) – Office of Government Commerce (OGC) – UK, and All copyrights  reserved.
  • PCAOB ® is the exclusive  property of the Public Company Accounting Oversight Board – ( http://pcaobus.org/
    ) and All copyrights reserved.
  • PMI ® / PMBOK ® exclusive  property of the Project Management Institute ( www.pmi.org/  ) and All copyrights reserved
  • Google Translator ® – The content of this article was translated by Google Translate®   – (http://translate.google.com) – which is  wholly owned by Google ® and All rights of this tools is reserved.

– End of Copyright Bills of Rights –

– End Article

Como Definir uma Politica de Seguranca Informacao – introducao conceitos estruturas e sugestoes

COMO DEFINIR UMA POLITICA DE SEGURANÇA DA INFORMAÇÃO

Introdução, Conceitos, Estruturas e Sugestões Práticas à Seguir.

 

COMO DEFINIR UMA POLITICA DE SEGURANÇA DA INFORMAÇÃO- Introdução, Conceitos, Estrutura e Sugestões a Seguir.

1 – Abertura e Objetivos

Neste artigo vamos tratar de um assunto muito discutido e denominado Politica de Segurança da Informação, abordando algumas dúvidas comuns e sugerindo algumas ações que possam ser adotadas para construir e implementar uma Politica de Segurança da Informação, citando alguns exemplos e práticas que possam ser aplicadas no dia a dia das empresas e com isto promover melhorias na Segurança da Informação.

Nosso objetivo é tratar o assunto de forma geral e não definitiva este assunto que é complexo e logicamente não poderemos trata-lo por completo nestas poucas páginas de texto,  fizemos nosso texto orientado aos colegas que não possuem domínio total do assunto mas que por algum motivo preocupam com o assunto e tem dificuldades em encontrar material de apoio relacionado a este assunto, principalmente em português, e ainda pensamos que também poderá proporcionar material de apoio aos colegas mais experientes, ou para aqueles que tratam da segurança da informação orientado ao Compliance a algum padrão ou legislação em particular.

2 – Introdução e Conceitos Básicos a Segurança Informação

Primeiramente precisaremos abordar alguns conceitos e ideias relacionadas ao assunto, elementos, características e atributos relacionados a uma Política de Segurança da Informação, são eles:

2.1 – Informação tem Valor e Precisa ser protegida.

Informação são todos os dados, fórmulas, contratos, documentos privados, o resultado econômico obtido, saldos bancários, projetos e fotos de produtos em desenvolvimento, propostas comerciais enviadas, propostas de fornecimentos recebidas, planos estratégicos, planos de marketing, a relação de clientes e fornecedores, os dados pessoais dos colaboradores, enfim todo o tipo de “informação” que “represente ou possua um determinado valor” ou ainda,  que possa vir a causar “prejuízo ou impacto negativo” caso venha a ser comunicado a elementos estranhos à organização.

Por mais elementar que possa parecer, é difícil fazer as pessoas entenderem o fato de que a informação “possui um valor” e em função disto deve ser “protegida por todos”, ou ainda, os motivos pelos quais  o “vazamento” de uma informação pode vir a trazer prejuízos para a empresa onde se atua,  ou mais ainda que a informação seja parte do “patrimônio de uma  empresa”, embora isto sejam conceitos, para alguns ainda são “paradigmas” a serem quebrados.

Vamos ilustrar duas situações hipotéticas como exemplos para que possamos transmitir e reforçar os conceitos de que a informação “possui mesmo um valor” e devido a este fato, “necessita ser mesmo protegida”.

  • A informação possui Valor:

Vamos imaginar, durante um minuto, que você leitor é um colaborador, dentre vinte outros colegas de trabalho, e a sua função e dos seus demais é realizar a faxina das salas no final do expediente em uma Grande Empresa, (Destas, que ocupam diversos andares em um mesmo prédio).

Um dia ao passar por uma das mesas, percebe que há um papel caído no chão, você simplesmente o pega e em seguida o coloca no cesto de lixo, continuando a sua atividade normalmente junto com seus colegas de trabalho.

No dia seguinte, a secretária do Gestor Financeiro percebe que o papel onde havia imprimido o Balanço contendo os resultados do ano anterior (Aquele Balanço que ainda não havia sido divulgado externamente), o qual ela havia imprimido a fim de ganhar tempo na organização da reunião matinal do dia seguinte, percebe que o papel impresso sumiu da sua mesa. Rapidamente ela imprime uma nova cópia do documento, e a reunião ocorre na hora marcada e nada de mais acontece.

Passados alguns dias, e uma semana antes da data do balanço ser divulgado pela empresa,  o gestor financeiro da empresa recebe os cumprimentos pelo excelente resultado obtido pela sua empresa ano anterior, recebido casualmente durante um jantar num restaurante, e, ainda o “cumprimento” foi proferido por uma pessoa estranha à empresa. Mesmo sem entender o que está acontecendo, recebe o cumprimento com um sorriso amarelo no rosto e sem seguida continua o jantar meio sem jeito, pensando em um milhão de possíveis hipóteses na tentativa de “explicar” o evento ocorrido.

ONDE esta o valor da informação?

  • Para você ou algum de seus colegas, foi mais um “lixo” colocado no “lixo”, e ainda, pode ter proferido algum “impropério” em homenagem ao desleixado que deixou “aquilo” caído no chão.
  • Para a secretária, pode representar o consumo de uma folha adicional de papel mais a atividade de reimprimir o documento, além do “stress” de ter que imprimi-la novamente às pressas no dia seguinte, para não atrasar a reunião.
  • Para o Gestor Financeiro, resta torcer para que o cumprimento recebido tenha sido uma “Obra do acaso, afinal de contas como o “fulano” poderia saber, e ainda mais uma semana antes da divulgação do Balanço…”.
  • No entanto, esta informação para um investidor do mercado de ações pode representar a diferença entre “ganhar um pouco” ou “ganhar um pouco mais”, pois indica que a compra antecipada de um lote maior de ações desta empresa poderá render um pouco mais, ainda mais depois de ter a certeza que o resultado “antes presumido” foi “de fato muito bom”. A isto se denomina “informação privilegiada”;

Este exemplo é bem interessante, pois pode ser aplicável a muitos outros tipos de informações “perdidas ou extraviadas”. Imagine um pouco mais adiante, substituindo o “Balanço”, por outras informações, tais como: O “plano estratégico”, “projetos ou plantas de produtos”, “Plano Marketing”, o cadastro de clientes, e assim por diante.

Quando a possibilidade de alguém encontrar um papel importante no lixo, tenha a seguinte certeza em mente: “havendo uma grande quantia envolvida, haverá sempre alguém interessado em “dar uma olhadinha” na sua lixeira”, estão lembrados de que alguns anos atrás, alguém perdeu um bilhete premiado, e depois de dizer que havia colocado no lixo, houve uma horda de pessoas em direção ao lixão da cidade, a fim de encontrar o “tal bilhete”.

  • A Informação precisa ser protegida.

Vamos investir mais um minuto imaginando outra situação: Onde você é o único responsável por salvaguardar uma fórmula de uma bebida ou refrigerante famoso, e que a empresa onde você trabalha, é o que é, devido à existência deste produto, o qual é fabricado através do uso desta formula.

É sensato concluir que empresa proprietária da formula, construiu esta “combinação de porções e ingredientes” depois de muitos anos de pesquisa, milhares de testes e uma soma incalculável de investimentos e recursos até que em algum dia conseguiu obter a “combinação ideal”.

É inegável, que a informação sob sua responsabilidade é algo que  representa e possui um “grande valor” e ainda, e que é “prioritário” que ela deve ser  protegida através da melhor forma possível.

Após entendermos as razões de valor de uma informação e entender que há motivos plausíveis para que ela seja protegida, surge à necessidade de aplicar ações neste sentido. Estas ações,  vistas de um nível mais alto em uma organização é o que se denominava há cem anos como “Instruções Técnicas de Segurança” e nos dias atuais de “Politica de Segurança da Informação”.

2.2 – Os atributos da Segurança Informação

Abaixo citaremos as principais características da segurança da informação, com base nestes atributos todo o resto é planejado e executado:

  • Confidencialidade:

A Confidencialidade nos impulsiona primeiramente identificar e classificar o nível de sigilo das informações para depois tomar medidas protetivas para que não seja comunicada ou acessada por todos aqueles que não a necessitam para o restrito exercício de suas funções e estão devidamente autorizados para isto.

  • Integridade:

As informações devem ser mantidas intactas e protegidas para que não se percam ou se deteriorem e precisa ser protegida contra agentes que possam destruí-la ou torná-la indisponível no momento em que se fizer necessária. A informação deve ter a sua integridade assegurada.

  • Confiabilidade:

As informações somente poderão ser alteradas ou modificadas por pessoa treinada ou capacitada para tal, evitando que uma informação seja invalidada por alguma atividade não regular ou realizada sem o devido controle. A informação deve ser confiável.

  • Disponibilidade:

De nada adiante atender os itens anteriores se a informação não estiver disponível para ser utilizada, no momento em que for necessária para alguma ação ou atividade. A informação deve estar disponível no momento certo.

2.3 – A Informática e a Segurança da Informação.

No inicio do século passado, seria necessário adquirir um “cofre com proteção contra incêndio” e organizar uma “Sala de Arquivo bem trancada” podíamos resolver uma boa “parcela” do problema.

Adicionando a isto, uma instrução identificando quais informações deveriam ser depositadas no “cofre” e quais deveriam ser depositadas no “arquivo”, o assunto estaria “sob controle”.

Atualmente, com uso cada vez maior e mais amplo da Informática, e agravado ainda pelo advento da expansão de uso da internet dos últimos 10 anos, o “problema” que já era complexo, se tornou em “algo” que pode envolver uma dezena de profissionais para ser tratado e executado para se conseguir um “nível aceitável de controle”.

E, devido à estra complexidade e a dimensão que as informações tomaram nas organizações surge à necessidade de uma Politica de Segurança da Informação nos termos requeridos dos dias atuais, não que isto não existisse no passado, mas certamente não era um assunto “tão complexo” como pode vir a ser nos dias atuais.

2.4 – Analise de Risco e as Ações de Segurança da Informação.

Há alguns motivos importantes, para identificar os riscos antes iniciar atividades destinadas melhorar os níveis de segurança da informação, embora já tenhamos observado empresas partirem diretamente para as ações de segurança da informação sem que tenham efetuado uma avaliação preliminar de riscos existentes ou ainda,  sequer possuem um processo formal  orientado ao  gerenciamento de riscos. No entanto a recomendação é primeiramente sejam identificados os riscos de TI e na sequencia, sejam  iniciadas as atividades de Gerenciamento da Segurança da Informação.

Vejamos algumas vantagens de avaliar os riscos anteriormente:

1-      Há modelos de referencia que nos indicam os riscos relacionados à segurança a informação, elaborados com base no impacto econômico que uma situação de risco  pode acarretar ao negócio. Estas referencias foram criadas a partir de lições apreendidas baseadas em fatos reais ou, ainda,  baseadas na probabilidade de que algumas situações possam vir a ocorrer e causar impacto ao negócio. O Importante é reforçar que o uso destas recomendações pode auxiliar na identificação da maioria das situações de risco relacionadas à segurança da Informação e podem ainda indicar as eventuais medidas de mitigação a serem tomadas.

Estas informações podem ser obtidas em organizações como ISACA, PCAOB, COSO e resumidamente em algumas normas ISO-IEC da série 27000.

2-      Os modelos de referencia nos apresentam uma visão completa da Segurança da Informação,  lembrando que uma equipe de TI composta por 20 Pessoas possui os mesmos problemas a resolver do que uma equipe de TI composta por 300 ou mais Pessoas, o ambiente pode até ser menos complexo, mas os riscos e as questões relacionadas à segurança da informação e as responsabilidades assumidas pelo TI, não são exatamente as mesmas, apenas  por “detalhes”.

Outra razão importante, é que nem sempre possuímos o orçamento necessário para mitigar “todos os riscos”, e podemos fazer uso da tabela se risco e as suas  classificações para focar na mitigação nos riscos mais críticos, deixando os de menor criticidade (Aqueles que representam menor gravidade/impacto para o negócio),  para serem tratados em um segundo momento ou simplesmente aceita-los.

De outro lado, quando partimos diretamente para o Gerenciamento da Segurança da Informação, sem a investigação prévia dos Riscos de TI, poderemos verificar algumas situações quepoderiam ser evitadas, tais como:

1- Podemos atuar em uma situação que envolva segurança da informação, onde o impacto ao negócio pode ser baixo, e eventualmente deixar de atuar em uma situação onde o impacto seja alto;

2-      Podemos ser levados a gastar mais do que o prejuízo causado pela ocorrência do fato em si.

3-      Podemos avaliar mal a amplitude de um evento de segurança,  deixando de fora ou sem tratamento elementos importantes da sua composição.

4-      Podemos atuar nas consequências e não nas causas dos problemas.

3 – Referencias técnicas para elaboração de Politica de Segurança Informação

Se você não possui uma Politica de Segurança da Informação, ou já possui uma e pretende verificar se ela está de acordo com as recomendações do mercado, sugerimos utilizar as normas ISO-IEC-27001 e ISO-IEC 27.002 como ponto de partida para a sua análise, pois ambas proporcionam a descrição das recomendações dos requisitos e das práticas que precisaremos adotar para primeiramente elaborar e depois cumprir o que foi definido na Politica de Segurança da Informação.

Há ainda, assuntos técnicos ou relacionados à infraestrutura e serviços técnicos de TI, que precisam ser adotados e estão disponíveis nos modelos do ITIL, PMO, e das  recomendações contidas nas Normas ISO-IEC-20.000:1 e 2, pois estes processos que são mais bem tratados através destas fontes complementares / normas.

3.1 – Composição Básica Sugerida para a Politica de Segurança da Informação.

Em tese, a Politica deve conter as diretrizes a serem cumpridas por todos na organização, se entendermos que devemos ter pelo menos uma diretriz para cada um dos grupos de assuntos (Capítulos) previstos pela norma ISO-27.002, nossa Politica de Segurança da Informação não deverá possuir mais de 2 ou 3 páginas.

É importante alertar que dependendo do segmento de mercado ao qual a empresa atua,  ela poderá ser “obrigada” a cumprir além dos requisitos contidos na norma, alguns outros elementos adicionais de segurança, muito mais em razão das diferenças contidas em sua “Matriz de Riscos” do que pela adoção ou não de uma determinada especificação contida na norma.

Ao final de algum tempo, você deverá atingir além da Politica, alguns grupos de Normas e Procedimentos, que possibilitem a cobertura de todas ou quase todas as recomendações contidas na referidas normas.

Modelo acima representa o Mapa Geral contendo a Politica, Normas e todos os Procedimentos necessários para a implementação de um Sistema de Gerenciamento de Segurança da Informação, do qual a Politica de Segurança da Informação é o elemento central e responsável por estabelecer todos os demais níveis de controle e das devidas evidencias destinadas a sua comprovação.

4 – Fatores Críticos de Sucesso

Há alguns fatores críticos para o Sucesso durante a implementação de um Sistema de Gerenciamento da Segurança da Informação, vamos citar aqui os principais:

4.1 – Resistencia Natural das Pessoas Envolvidas no Processo.

Como é de se esperar em todo o processo que envolve mudanças há resistência natural das pessoas, e no caso da segurança da informação especificamente há um detalhe a “desinformação sobre o tema”. As pessoas não “entendem facilmente”, pelo menos no início, o real motivo e a necessidade de tantos controles, processos e evidencias, e não é raro, observarmos algumas reações, dentre as mais diversas possíveis, no momento de colocar em pratica alguma ação orientada a promover a segurança.

E para ilustrarmos isto, vejamos alguns exemplos:

  • “A empresa resolveu burocratizar as coisas”,
  • “A empresa perdeu a confiança e por isto retirou os meus privilégios de acesso”,
  • “Eu sempre fiz assim e sempre deu certo, porque mudar agora”,
  • “Eu acho que a empresa vai me demitir”,
  • “Eu sei como fazer, mas não consigo colocar o que eu faço num papel”,
  • “Não consigo trabalhar direito sem usar o meu chat”.
  • “Não consigo mais acessar o meu e-mail pessoal aqui na empresa”.
  • “Se o diretor pode, eu também quero”.
  • Entre outras.

A boa notícia é que estas reações deixam de existir com o passar do tempo, quando as mesmas pessoas são treinadas e recicladas e as reações mudam bastante na medida em que vão entendendo o que de fato é “Segurança da Informação” e como este assunto é importante não só para a empresa, mas para si próprias.

4.2 – Apoio da Alta Direção / Gestores.

O Apoio dos gestores é fundamental para que a Politica de Segurança da Informação sejam efetiva, sem a presença deste apoio, iniciar qualquer ação neste sentido é algo no mínimo “temerário”.

Exemplo de ações onde o apoio da Alta direção será  necessário:

  • Há pontos que para serem tratados adequadamente, é necessário incluir clausulas adicionais em contratos de trabalho, termos de confidencialidades, Adesão a Regras de Navegação e Uso de Internet, Código de Ética e Conduta, e tantos outros itens com amplitude geral na empresa;
  • Segurança da informação abrange todos os funcionários da empresa, sem distinção de cargo ou função. Segurança é responsabilidade de todos, conseguir materializar isto sem o apoio da Alta Direção é uma missão quase impossível.

 4.3 – Treinamentos e Reciclagens constantes

Prover treinamentos regulares em Segurança da Informação aos colaboradores além de fundamental é o que de fato garantirá o sucesso da aplicação das diretrizes contidas na Politica de Segurança da Informação.

4.4 – Auditorias e Verificações Regulares

Recomenda-se a realização de auditorias ou verificações de Compliance nos processos estabelecidos, a própria norma estabelece em um de seus capítulos este controle de forma regular e constante.

Se os processos não forem periodicamente revisados, corre-se o risco de cair em desuso ou perder a oportunidade de simplifica-lo ou melhora-lo com o passar do tempo.

Mesmo que você não tenha o objetivo de certificar os processos de segurança, aos mesmos moldes dos processos de qualidade, é importante que um grupo de avaliadores, mesmo que internos verifiquem periodicamente a regularidade dos processos e controles.

5 – Por Onde Começar e o que fazer?

Sugerimos inicialmente a realização de um estudo considerando o volume de  custo e esforço necessário para a realização do projeto de compliance, sendo também muito importante obter o apoio da organizaçao e principalmente dos gestores nesta fase inicial do projeto. A Norna ISO-27003:2010 possui um roadmap sugerido para a implementação do sistema da segurança e pode ser de grande auxílio na organização e execução as ações necessárias.

É importante ter em mente que obtendo o “Compliance em Segurança da Informação” você estará construindo as bases para o compliance em diversas outras categorias de compliances existentes, tais como Governança TI e Corporativa, PCI, ANTT – Agencia Nacional Transportes Terrestres, Acreditação Segurança ao Fornecimento Serviços, Sarbanes-Oxley, Basel entre outros.

Caso tenha dúvidas em relação ao estudo dos custos, montamos a algum tempo um template destinado a comparar o volume de custos e esforço construindo todos os processos a partir do zero e com o apoio de um consultor especialista e uma outra hipótese considerando a utilização de modelos pré-definidos. Este template está disponível para download sem nenhum custo em nossa webstore na seção Brochures, no endereço http://www.aghatha.com

5.1 –  Adotar modelos pré-definidos para a organização de Processos e Controles Segurança da Informação – ISO-27002:

Conheça nosso AGHATHA Framework para o Compliance da Norma ISO-27002:2005,  mais detalhes sobre este produto podem ser conhecidas no post abaixo:

http://aghatha.wordpress.com/2012/12/04/aghatha-framework-licenca-uso-perpetua-modelos-aplicacao-norma-iso-iec-270022005-seguranca-informacao-r02-01a/

Você pode licenciar o uso deste framework em nossa webstore, veja no endereço abaixo o link de acesso as informações sobre o AGHATHA Framework – Compliance Norma ISO-27002 – Segurança da Informação.

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

 

5.2 – Contruir você mesmo com o apoio de sua equipe os Processos e Controles Segurança Informação – ISO-27002:

Em artigo anterior a este tratamos algumas sugestões de como adotar as melhores práticas contidas na Norma ISO_IEC-27.001 e 27.002, o artigo aborda o que fazer, e ainda sugere em linhas gerais como adotar as recomendações previstas por estas normas.

Este artigo pode ser visualizado em:

http://aghatha.wordpress.com/2011/05/22/compliance-de-processos-norma-isoiec-27-002-gerenciamento-de-seguranca-informacao/

Há ainda outros artigos relacionados especificamente em como Organizar a documentação de processos e boas práticas em TI, incluindo o template sugerido por nos para ser utilizado na descrição dos processos.

Este artigo pode ser visualizado em:

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

Caso o leitor se habilite a levantar e desenhar os processos e controles escrevemos três artigos que tratam deste assunto, considerando o que deve ser feito a partir dos  conceitos, métodos, símbolos, e exemplos de como descrever os processos e como desenhar os respectivos fluxogramas.

Estes artigos estão disponíveis em:

1 Parte: Introdução, Conceitos e Modelos

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

2 Parte – Levantamento, Analise e Desenho do Fluxograma

http://aghatha.wordpress.com/2011/07/10/como-desenhar-fluxogramas-de-processos-de-negocio-2-parte-levantamento-analise-e-desenho-do-fluxograma/

3 Parte – Analise de Capacidade e Carga dos Processos

http://aghatha.wordpress.com/2011/07/16/como-desenhar-fluxogramas-de-processos-de-negocio-3-parte-analise-capacidade-carga-processos/

  • Este artigo está disponível para download no formato de Documento (PDF) na pagina destinada a Noticias e Download   no site da AGHATHA, no seguinte endereço:  Http://www.aghatha.com/index.htm

Você pode ainda, Adotar Bibliotecas Contendo Modelos, Processos e Controles Prontos e Preparados para serem utilizados rapidamente.

Conheça nossa Biblioteca de Modelos – Licenciamos o Uso de Frameworks contendo todos as Politicas, Normas, Procedimentos e Controles para o Compliance de TI, isto é uma forma rápida, econômica e eficiente de implementar estes padrões, sem ter de desenha-los a partir do Zero, ou ainda, utiliza-los na complementação / revisão dos processos já existentes.

Caso tenha interesse em conhecer esta solução, veja mais detalhes abaixo:

  • 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).

Em nossa webstore, onde os 175 modelos (Politicas, Normas, Procedimentos e Controles podem ser licenciados on-line) em : http://aghatha.com/index.php/framework/framework-de-processos-e-controles-para-o-compliance-de-ti-norma-iso-27001-iso-27002-seguranca-da-informacao-release-02-01-a.html

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

http://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/

—–

· Download do conteúdo deste Artigo :

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

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

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

Compartilhe este post:

———

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

—- Fim Conteúdo Artigo —-

 

COMO-DESENHAR-FLUXOGRAMAS-DE-PROCESSOS-DE-NEGOCIO-3-PARTE-Analise-Capacidade-Carga-Processos

COMO DESENHAR FLUXOGRAMAS DE PROCESSOS DE NEGÓCIO

Parte 3 – Analises de Capacidade e Custos em Processos.

 

COMO DESENHAR FLUXOGRAMAS DE PROCESSOS DE NEGÓCIO – Parte 3  – Analises de Capacidade e Custos em Processos.

1 – Analise de Capacidade e Custos em Processos.

Em continuação as duas primeiras partes  do artigo  “Como desenhar fluxogramas de processos de Negócio”, trataremos neste artigo algumas técnicas  de analises envolvendo custos e desempenho de processos, que podem ser utilizadas para identificar possíveis necessidades de melhorias ou  otimizações.

2.     – Termos e Nomenclaturas Utilizados:

  • Analista: Pessoa Responsável pelo levantamento, a analise e confecção do fluxograma de processo.
  • Usuário: Pessoa responsável pela transmissão do conhecimento do processo a ser analisado e representado graficamente.
  • Horas Disponíveis: Quantidade de horas em que o responsável por uma determinada atividade permanece à disposição para realizar as ações previstas em um processo durante o período compreendido pela jornada de trabalho.
  • Horas Trabalhadas: Quantidade de horas que o responsável por uma determinada atividade ou processo realizada efetivamente durante uma jornada de trabalho.
  • Horas Ociosas: No contexto deste artigo é quantidade de horas em que o responsável por uma atividade ou processo não executa atividade alguma.
  • Horas Produtivas: No contexto deste artigo, é a quantidade de horas efetivamente produtivas executadas pelo responsável de uma atividade ou processo.
  • Horas Retrabalhadas: No contexto deste artigo é a quantidade de horas realizadas em duplicidade devido à ocorrência de um erro ou falha no processo
  • Jornada de Trabalho: é o mesmo que um dia de trabalho, é composto em média por 8 horas diárias.

3 – Método 5w2h – (Incluindo as Perguntas e Informações Adicionais)

  • Custo Hora / Recurso?  = (Taxa Hora/Homem)   

Esta questão identifica a taxa hora, ou o custo por hora trabalhada e relativa ao recurso responsável pela execução da atividade. Há diversas formas e métodos de calcular este valor, uma vez que há responsáveis (Horistas) – tem seu salário calculado e pago de acordo com as horas efetivamente trabalhadas, há meses que recebem mais e outros menos, e os (Mensalistas) – tem o seu salário calculado e pago com base em uma carga horária padrão mensal, ou seja, independente da quantidade de dias úteis no mês, recebem sempre o mesmo valor padrão. Em nosso exemplo adotaremos uma fórmula simples, para que possamos identificar o valor da taxa hora padrão para o responsável utilizado em nosso exemplo (Assistente de Vendas) e que utilizaremos para custear as analises  que faremos a seguir.

Ex:

 (Informações necessárias):

Salário médio do Assistente de Vendas:  R$ 1.000,00

Encargos trabalhistas:  84% (Férias, 13º, FGTS, provisão para multa de Aviso Prévio, e outros)

Quantidade de Horas Disponíveis:  168 horas mensais  (mesmo que 8,0 horas diárias x 21 dias)

 (Fórmula de Calculo)

Taxa Hora = (1.000 x 1,84 ) / 168

Taxa Hora = R$ 10,95 / Hora

  • Quantas Vezes? =  (Qtde de eventos em uma Jornada Trabalho)

Esta é pergunta representa a quantidade média de eventos executados em durante uma jornada de trabalho. No exemplo de processo utilizado, mapeamos o processo de recebimento de pedidos de vendas de uma empresa.

Ex:

(Informações Necessárias)

Identificar a quantidade média de pedidos de vendas processados diariamente, vamos supor que sejam:

  • 200 pedidos em média.

(Informações Complementares)

No processo mapeado há duas hipóteses de erros ou que podem ocasionar retrabalho ao assistente de vendas.

São eles:

Os pedidos podem ser enviados com campos incompletos ou sem preenchimento válido

Os pedidos podem ser enviados sem a assinatura do cliente.

Vamos supor que a media diária de erros em cada um dos eventos sejam 5%, totalizando 10% dos pedidos recebidos possuem erros e precisam ser devolvidos ao remetente para realização dos ajustes necessários.

Os pedidos incompletos ou sem preenchimento válido

  • 5% =  (200 x 0,05) = 10 pedidos

Os pedidos sem a assinatura do cliente.

  • 5% =  (200 x 0,05) = 10 pedidos
  • ·         Quando Tempo? = (Duração média de uma atividade / em Minutos)

Esta é pergunta representa a quantidade média de tempo gasto em minutos para a execução de uma atividade incluída no processo. Note que em nosso exemplo, algumas atividades não possuem tempo informado, e isto é assim mesmo. Explico: As atividades lógicas (Perguntas / decisões e indicação de  saltos entre a sequencia de atividades)  não consomem esforço durante a  execução do processo, existem apenas para complementar a descrição e detalhamento facilitando o entendimento da sequencia lógica do processo.

Ex:

1-       Receber o pedido por e-mail :  2 min

2-      Conferir o preenchimento de todos os campos:  3 min

3-      Todos os campos forem preenchidos?  :   0 min

4-      Caso negativo, prosseguir do item 11. :  0 min

5 – Caso positivo: Verificar se o documento foi assinado pelo cliente:   1 min

Notas adicionais:

  • No item 4, houve apenas um endereçamento para a linha 11, e não houve esforço agregado no processo, pois ela é uma ação para o leitor executar durante a leitura do processo.
  • Já no item 5, houve uma ação pertencente ao processo (Verificar se o pedido foi assinado pelo cliente e neste caso consumiu 1 min de esforço do Assistente de Vendas).

Agora com  o preenchimento destas informações em nossa matriz modificada do Método (5W2H), vamos por fim calcular o H (How Much / Quanto custa) cada atividade de nosso processo de exemplo e ainda calcularmos mais alguns indicadores para servirem de base para as nossas análises:

4 – Preenchimento dos Campos Adicionais no  “Check List” Modificado para levantamento dos Dados.

Ex Planilha para Levantamento de Informações do Processo, com os dados adicionais já preenchidos:

 <Clique na figura para ampliar a imagem/  full Screen>

5 –  Analises dos Cálculos efetuados com as Informações Adicionais

5.1 – Analise Quantitativa de Tempos do Processo

 a)      Tempo dispendido para o processamento de um pedido de Vendas :

  •  30 min  / Pedido de Venda 

b)      Tempo Total de esforço por jornada de trabalho para o processamento dos pedidos de vendas:

  •  3.920 min / por  jornada de trabalho
    • 3.920 min / 60 =  65 horas / Jornada de Trabalho
    • 65 horas de trabalho equivalem a uma necessidade de pelo menos 8  Colaboradores na função de Assistente de Vendas,  para executar esta rotina / jornada de trabalho sem que fiquem pedidos por serem processados de um dia para o outro.
    • Qtde Colaboradores = (65 / 8 horas diárias) = Mínimo de 8 Colaboradores, sendo 9 a quantidade ideal.

c)       A atividade que mais dispensam esforço para serem executadas:

  •  Atividade Produtiva:
    • Informar o pedido de vendas no sistema de vendas:
  •  10 min / por pedido = Representando 33.34 % do esforço necessário para o processamento completo do pedido de vendas
  • 1800 min / por jornada de trabalho = representando 45 % do esforço total diário dispendido para processar os pedidos de vendas.
  •  Atividades para o Processamento de erros:
    • Preencher a notificação de não conformidade Pedido Venda
  •  6  Min / por pedido incompletos ou não assinados pelo cliente
  • 120 min / por jornada de trabalho = Representando 3% do esforço total diário dispendido para  processar os pedidos de vendas e,
  •  60% do esforço total das atividades executadas para o tratamento dos pedidos de vendas não conformes (Recebido com erros).

5.2 – Analise Quantitativa de Custos do Processo

 a)      O Custo para o processamento de um pedido de Vendas :

  •  O custo médio paraprocessar um  Pedido de vendas é de R$ 10,95 / pedido

b)      O Custo Diário dispendido no processamento dos pedidos de vendas:

  •  O custo total dispendido por jornada de trabalho para o processamento dos pedidos de vendas é de R$ 1.431,11 / jornada de trabalho

c)       A atividade que mais representam custos para serem executadas:

  •  Atividade Produtiva:
    • Informar o pedido de vendas no sistema de vendas:
  •  R$ 3,65  / por pedido = Representando   do custo total  33.44% dispendido para o processamento completo do pedido de vendas (R$ 10,95/pedido)
  • R$ 657,14 / por jornada de trabalho = representando 45,92 % do custo total diário (R$ 1,431,11/jornada) dispendido para processar o volume de pedidos de vendas.
  •  Atividades para o Processamento de erros:
    • Preencher a notificação de não conformidade Pedido Venda
  •  6  Min / por pedido incompletos ou não assinados pelo cliente
  • 120 min / por jornada de trabalho = Representando 3% do esforço total diário (30 min/pedido) dispendido para  processar cada um dos pedidos de vendas e,
  •  Representa 60% do esforço total das atividades executadas para o tratamento dos pedidos de vendas não conformes (Recebidos diariamente com erros – 200 min / jornada).

 5.3 – Gráficos para analises Auxiliares do Processo

 Analise dos Custos do Processo

Observações:

Atividades ordenadas pela ordem da atividade mais cara da esquerda para a direita, e os percentuais de participação acumulada do valor indica que se atuarmos nas 4 primeiras atividades (esquerda para a direita), e buscando uma forma de otimiza-las, estaremos atuando em 76,67% do valor total do processo.

Atividade Custo Unitário Atividade
Informar os dados do Pedido no Sistema de Vendas R$ 3,65
Notificar não conformidade ao Vendedor responsável pelo pedido R$ 2,19
Devolver pedido não conforme ao vendedor R$ 1,46
Verificar se o documento está com todos os dados preenchidos R$ 1,10

Analise do Esforço / Tempos  do Processo

 

Observações:

Atividades ordenadas pela ordem da atividade mais demoradas para serem executadas  da esquerda para a direita, e os percentuais de participação acumulada do esforço  indica que se atuarmos nas 4 primeiras atividades (esquerda para a direita), e buscando uma forma de otimiza-las, estaremos atuando em 75,oo% do esforço aplicado para execução do processo.

Atividade Esforço Min /Unitário Atividade
Informar os dados do Pedido no Sistema de Vendas 1.800
Verificar se o documento está com todos os dados preenchidos 600
Arquivar o pedido de vendas 540
Receber o pedido de vendas 400

Analise do Carga / Taxa Ocupação Equipe alocada no Processo

 

Observações:

O gráfico demonstrando a taxa de ocupação do processo indica que há  5% de horas ainda ociosas para a execução do processo, equivalendo a  6,67 Horas ainda disponíveis para absorver mais pedidos a serem processados por Jornada de Trabalho.

Ex:

Horas Disponíveis = ( 8 horas diárias * 60 min *  9 colaboradores ) = 4.320 min / Jornada

Horas Trabalhadas – Soma tabela 5w2h = 3,920 minutos para processar 200 pedidos em média por jornada.

Horas Ociosas = (4.320 – 3.920) = 400 min ociosos / jornada

Tempo Processamento completo de um pedido = 30 min

Então:

Qtde Pedidos Adicionais possíveis =  (400 / 30 min)  = 13 Pedidos

Tipo de Horas Qtde Minutos / Jornada Qtde Horas / Jornada
Horas Disponíveis 4320,00 72,00
Horas Trabalhadas 3920,00 65,33
Horas Ociosas 400,00 6,67

Fim do Conteúdo deste Artigo.

———-

·  Download do conteúdo deste Artigo :

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

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

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

  • Visite nossa Webstore :

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

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

  • AGHATHA Framework – Compliance Norma ISO-27002

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

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

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

———-

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

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

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

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

Framework Compliance Norma ISO-27002

———-

·       Mais Artigos desta Série:

1 Parte – Introdução, Conceitos e Modelos

COMO DESENHAR FLUXOGRAMAS DE PROCESSOS DE NEGÓCIO – Parte 1 – Introdução, Conceitos e Modelos.

  • Veja Conteúdo em :

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

2 Parte  – Instruções Passo-a-Passo para Desenhar um Fluxo.

No próximo Artigo (Parte 2), trataremos as técnicas a serem utilizadas durante as Entrevistas para levantamento de informações dos processos a serem desenhados e alguns exemplos de como devemos organizar e preparar o conteúdo das informações obtidas no levantado para facilitar a confecção do respectivo fluxograma. Próximo Artigo : COMO DESENHAR FLUXOGRAMAS DE PROCESSOS DE NEGÓCIO – Parte 2 – Levantamento, Analise e Desenho do Processo de Negócio.

  • Veja Conteúdo em :

3 Parte  – Levantamento, Analise de Capacidade e Carga de Processos (Saiba como Calcular Esforço, Tempo e Custos)

  • Veja Conteúdo em:

———–

·       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:

http://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

———

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

[youtube http://www.youtube.com/watch?v=T_gsHigMFvU]
———

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

  • 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 Artigo:

ENTENDENDO COMO FUNCIONAM OS ATAQUES CIBERNETICOS EM MASSA TIPO DDOS E DRDOS

ENTENDENDO COMO FUNCIONAM OS ATAQUES CIBERNÉTICOS EM MASSA – Parte 1 – SEGURANÇA DIGITAL ATAQUES (DDOS E DRDOS)

Entendendo como funcionam os ataques cibernéticos em massa – Parte 1 – Segurança Digital contra Ataques (DDOS E DRDOS).

O objetivo deste artigo é proporcionar informações básicas e esclarecer este assunto ao maior número de pessoas possível,  mesmo explanando o assunto na forma mais simples e objetiva possível, para o público leitor. Como este assunto poderá ser complexo e exaustivo, confiamos ao leitor que procura por literaturas técnicas avançadas, a liberdade de aprofundar o conhecimento através de outras fontes com o nível técnicos desejados disponíveis na Internet.

1.    Quebrando alguns Paradigmas em Segurança Digital

Primeiramente vamos quebrar alguns paradigmas e alinhar alguns conceitos:

  • Não existe sistema 100% seguro à Até mesmo a NASA, governos dos EUA, Brasil e demais países já sofreram ataques e sempre estarão vulneráveis de uma forma ou outra, uma vez que os atacantes a estes sites estão sempre em busca de oportunidades e falhas visando novos ataques, para aqueles que atuam com ações na bolsa de valores é o mesmo que a briga entre o “urso” e o “touro” em algumas vezes vence o “touro” e em outras o ”urso”.

O que pode ser feito é “subir cada vez mais o muro de proteção”, ou seja, dificultar ao máximo através de sistemas detectivos, preventivos, testes de eficácia da segurança e melhoria contínua do nível de segurança. A tendência de sermos atacados depende do nível de exposição e vulnerabilidades ou ameaças no ambiente disponíveis aos atacantes.

Para que você tenha a compreensão das vulnerabilidades e ameaças mais comuns vamos citar alguns exemplos comuns do dia a dia.

Ex:

Os atacantes são oportunistas e atacam sites que estejam vulneráveis:

(Caso 1: Se um “sujeito” ao passar pela rua onde você mora, percebe que a porta da sua casa está aberta. Possivelmente ele vai entrar, e quando você menos esperar haverá alguém sentado no sofá da sua sala”.

Os atacantes possuem objetivos e criam novas ameaças:

(Caso 2: Se um “Sujeito” passar pela rua onde você mora, olha a sua casa e percebe que nela há objetos que possam interessar e toma a decisão de invadir a sua casa, mesmo que a porta da frente esteja trancada, possivelmente ele forçará a entrada através de alguma outra abertura. e depois de algumas tentativas ele vai conseguir entrar, e quando você menos esperar haverá alguém sentado no sofá da sua sala, mesmo que a porta estivesse bem trancada”.

Os atacantes também criam oportunidades através de Engenharia social:

(Caso 3: Se um “sujeito” ao passar pela rua onde você mora, percebe que há nela objetos que possam interessar, e ainda percebe que há alguém dentro da casa, ele pode tentar chamar a atenção desta pessoa e com alguma “desculpa” ele pode conduzir a mesma a abrir a tranca interna da porta).

  • Segurança nos Perímetros de Rede : A Segurança deve ser reforçada não apenas nos perímetros de rede, mas em todo lugar onde a informação estiver. Este é um dos requisitos de negócio e de segurança da informação se não for observado criteriosamente haverá falhas.

O Perímetro de rede é geralmente a primeira camada de proteção, e pode ser comparada a “Muros e Cercas” presentes em nossas casas, um perímetro de rede aberto é o mesmo que uma casa sem proteção alguma.

  • Segurança em Camadas : Se você reforçar a Segurança apenas numa determinada camada, Ex: Camada de aplicação, os Hackers poderão explorar as vulnerabilidades presentes no seu link de comunicação, fazendo com que a suas aplicações externas fiquem indisponíveis para os usuários.

Proteção em camadas seria o mesmo que você possuir um “cofre trancado”, dentro de um cômodo da sua casa, com a porta trancada, todas as aberturas da casa “fechadas” e o dispositivo que aciona a “cerca elétrica” do muro ativada. Para alguém conseguir chegar até o “cofre”, o “sujeito” deve quebrar todas estas “camadas de proteção”  até que consiga atingir o seu objetivo.

  • Segurança Digital da Informação : Este é um assunto complexo e só é efetiva se todos os usuários e não apenas da área de Segurança ou TI agirem de forma conjunta e coordenada. É importante que a organização possua uma “Política de Segurança” robusta, procedimentos técnicos identificados e endereçados aos seus respectivos responsáveis, equipamentos de apoio bem instalados, configurados e integrados entre si, tais como Firewall, IPS, Antispam, Antivírus, ferramentas de navegação segura cada qual protegendo a sua camadas e todos agindo de forma integrada e convergente em prol da segurança do ambiente, e mesmo assim,  tudo isto só irá funcionar se houver colaboração “ativa e efetiva” de todos os envolvidos, sem exceção.

Mesmo depois de tudo isto, você deverá realizar inspeções contínuas e diligentemente visando verificar a efetividade da “sua segurança” ou poderá simplesmente acreditar que já está “seguro” e entender que “não há mais nada para ser feito”.

Devemos lembrar que em termos de “Segurança Digital” temos de fato apenas aquilo que inspecionamos, medimos e gerenciamos, senão você corre o risco de “acreditar que está seguro” e na realidade “pode não estar” e a noticia ruim que temos a dar é que na maioria das vezes  “Se pensa estar protegido”, e isto em organizações de grande porte, com pessoal técnico especializado presente, treinado e muitas vezes até certificados. Segurança Digital eficiente é um conjunto combinado de pessoas, equipamentos configurados de forma integrada e principalmente de processos e métodos de controle.

Não é uma atitude recomendada, aguardar a ocorrência de um evento para então agir, esta atitude poderá ser tardia demais e corre-se o risco de não haver mais nada para ser inspecionado…quando menos se espera “Lá se foi o boi com a corda…” como se diz.

Não queremos criar “pânico” aos nossos leitores, mas os incidentes de segurança existem, são reais mesmo, não é coisa para os outros se preocuparem, e ainda,  este tipo de “atividade” é  realizada por “profissionais”  e a idéia de que  “hackers” é um só  “bando de jovens” em busca de aventura não é mais verdade a muito tempo, não sendo incomum identificarmos na outra ponta de uma “ameaça digital”  a existência de  técnicos formados, certificados, pós-graduados e até doutores cometendo este tipo de “ameaça”.

Se você leitor é responsável pela segurança digital em sua empresa, fique certo que não existe “Robin-Hood Cibernético”, pense comigo, se alguém se dispõe a ligar um computador, busca aleatoriamente um site, identifica o seu site em particular e passa a executar diversas tentativas apenas para “fazer uma visita dentro no seu site”, ficando possivelmente horas e dias apenas para conseguir quebrar senhas e abrir os seus arquivos de dados, inspecionar seus contratos, fórmulas, desenhos, clientes, fornecedores, valores que você paga a empresa “a” ou empresa “b”, quanto você faturou e para quem faturou, não o faz isto por “esporte” ou pela “adrenalina ou emoção” o produto desta atividade é um “artigo valioso” no mercado, e infelizmente há gente sem escrúpulos disposta a “pagar” muito dinheiro por isto e este é o peso de nossa responsabilidade, proteger a segurança da informação de propriedade dos outros.

Vejam estes dois exemplos:

Há cerca de 10 anos, quando iniciamos nossa carreira em Segurança Digital, após realizamos uma auditoria de “Logs de acessos” a servidores expostos a na WEB em uma empresa aqui no Sul do Brasil, identificamos diversos acessos vindo de um país do outro lado do mundo, sempre destinados a um diretório específico de um servidor de arquivos onde havia informações dos produtos que estavam em desenvolvimento. E os acessos sempre eram efetuados justamente nas pastas onde havia as “fotos” dos protótipos dos produtos que seriam lançados no ano seguinte. Se isto ocorria a mais de 10 anos atrás, onde poucas empresas possuíam acesso a WEB, imaginem nos dias de hoje onde “tudo” ou “quase tudo” está vinculado ou relacionado à internet.

Há alguns meses atrás, em um destes grupos de discussão que participamos, surgiu uma discussão promovida por um representante de empresa de software, onde um de seus colaboradores ao ser demitido, levou consigo  “todos os fontes” do sistema desenvolvido pela empresa durante vários anos, e acabou vendendo ou prestando serviços aos clientes desta mesma empresa oferecendo ainda os serviços com preço menores do que o praticado pela empresa onde atuava. Conversando com o responsável, o mesmo me informou que todos na empresa possuiam acesso ao “diretório de fontes” e só depois do fato ter sido identificado isto teria sido corrigido. Dai me pergunto: Quantas empresas possuem este tipo de “falha de segurança”, simplesmente no fato de “confiarem” em sua equipe. Pois acreditem, esta foi a justificativa alegada pelo responsável desta empresa, até que o referido “evento” aconteceu.

Isto posto,  agora vamos abordar os tópicos de Ameaças previstas para este artigo… e nos perdoem se o textoque vamos utilizar seja técnico demais, infelizmente há ainda muitos termos que não possuem tradução ou ainda não foram descobertos termos em português que lhe deem o mesmo significado (Na medida do possível vamos “traduzi-los”), então fizemos algumas figuras adicionais na tentativa de lhes passar a visão de como estes tipos de ataques ocorrem e como podem ser perigosos.

2.    O que é DoS, DDoS, DRDoS ?

  •  Denial-of-Service (DoS) àÉ uma tentativa maliciosa quando um host atacante poderá causar à vítima, site ou nó, negação de serviços aos usuários/clientes, resultando na inutilização destes serviços pelos usuários legítimos.
  • Distributed Denial-of-Service (DDoS) à É uma tentativa maliciosa quando múltiplos hosts atacam simultaneamente podendo causar à vítima, site ou nó, negação de serviços  aos usuários/clientes, resultando na inutilização destes serviços pelos usuários legítimos.
  • Distributed Reflected Denial-of-Service (DRDoS) àSemelhante ao DDoS, mas onde o atacante pode enviar pacotes forjados para outra rede e permitir que esta rede realize o ataque.

2.1.        Principais Estratégias de Ataques DDoS

  •  Consumo excessivo de recursos (Banda, CPU e Memória).
  • Exploração de vulnerabilidades em Sistema Operacional e Serviços. 

2.2.        A Rede Atacante

A rede atacante é formada através das principais etapas:

  • Descoberta de sites ou hosts vulneráveis
  • Exploração para ganhar acesso a estes hosts
  • Instalação de programas (conhecido como ferramentas de ataque) nos hosts comprometidos
  • Hosts que executam estas ferramentas de ataque são conhecidas como máquinas “Zumbis”
  • O conjunto de vários “Zumbis” formam um Exército, também chamado de Botnet.

*Trataremos em outro artigo específico os Botnets.

 2.3.        Como Funciona um Típico Ataque DDoS

O exército do atacante consiste de máquinas “Zumbis”  Mestre (Master) e Escravo (Slave). Estas máquinas comprometidas estão infectadas por código malicioso (Possivelmente recebido por email ou baixado ao navegarmos inocentemente pela web). O atacante envia ou programa um comando de ataque para os Zumbis Mestres e ativa o processo de ataque nestas máquinas que estavam em hibernação, esperando por comandos para “acordar” e iniciar o ataque. Os Zumbis Mestres enviam comandos de ataque para os Zumbis Escravos, ordenando que eles montem um ataque DDoS contra a vítima através do envio de grande volume de pacotes para a vítima, inundando (flooding) o sistema desta com carga e exaustão de recursos.

Na figura abaixo, temos um resumo desta representação:

Nestes casos, os endereços IP de origem são falsificados nos pacotes do tráfego atacante, escondendo ou dificultando a identidade dos Zumbis para que a vítima não consiga rastrear e filtrar a origem deste tráfego malicioso.

2.4.        Como Funciona um Típico Ataque DRDoS

Semelhante ao ataque DDoS, com as seguintes características:

  • “Zumbis escravos” enviam um fluxo de pacotes com o endereço IP da vítima (como endereço IP de origem), para outras máquinas não infectadas (conhecidas como refletores).
  • Os refletores conectam com a vítima e enviam um grande volume de tráfego,  porque eles acreditam que o host da vítima foi quem solicitou por isso.
  • O ataque é montado pelas máquinas não comprometidas sem estarem cientes da ação.

Neste caso, o atacante tem mais máquinas para compartilhar o ataque, por isso ele é mais distribuído e cria um volume maior de tráfego devido a sua natureza distribuída.

3.  Principais Vetores de Ataques DDoS

1)Baseados em Inundação (Flooding) de pacotes (UDP, ICMP): Pela primeira vez, em 2010, os ataques em massa quebraram a barreira de 100Gbps. Estes patamares, excedem a banda de diversos provedores no Brasil. Em comparação, em 2002 a barreira era de 400Mbps. Geralmente os alvos são interfaces de roteadores / link principal, endereços de BGP, Firewall, IPS, balanceadores de carga, servidores web, demais elementos de rede.

2)Baseados em Aplicação ou Serviço (URL, GET, DNS, SQL): Os principais alvos são HTTP, DNS e SMTP. Não consomem quantidades gigantes de banda e geralmente os alvos são serviços de rede, Servidores (Web, DNS, SMTP), elementos de rede e banco-de-dados.

3)Baseados em Protocolos (RST, SYN, Frag): Geralmente os alvos são sistemas Web e elementos de rede.

4.  Exemplos de Ataque DDoS

5.  Ferramentas Utilizadas neste Tipo de Ataque

Atualmente existem centenas de ferramentas na Internet que enviam quantidades gigantescas de requisições web, flooding ICMP, UDP porta 80, randomizações de URLs e controle remoto pelos BOTNETs IRC, RSS, Twitter e Facebook para atacarem os servidores das vítimas.

Outras ainda mais sofisticadas para inundação de tráfego HTTP com multi-tarefas, atacando simultaneamente centenas de websites.

Com estas ferramentas é possível através de uma única estação indisponibilizar serviços web em menos de 5 minutos!

Existem diversos convites pela Internet com planejamento de ataques distribuídos (atualmente com menos de 100 máquinas Zumbis bem conectadas são capazes de indisponibilizar serviços de grandes empresas).

  • Por motivos óbvios, não citaremos nomes de ferramentas, embora estejam publicadas livremente na internet. Publicaremos artigo específico focando nas melhores práticas para detecção, prevenção e testes de eficácia da segurança.

6.    Tendências de Ataques

Atualmente, a maioria dos ataques DDoS são baseados em inundação para atingirem a capacidade de links ou sobrecarga dos equipamentos alvo.

Os ataques baseados em aplicação serão mais sofisticados e difíceis de serem diferenciados do tráfego legítimo (exemplo: Protocolo HTTP porta 80, explorados atualmente, pois é muito comum estar liberado nos Firewalls para que os clientes possam acessar as aplicações web pela internet).

Veremos com mais frequência ataques com motivações políticas ou protestos, similares as retaliações demonstradas nos casos do Wikileaks, e possivelmente presentes nestes “movimentos” estejam incluidos alguns “profissionais” que já citamos neste artigo, apenas monitorando as eventuais “portas abertas” ou “falhas” para fazer uso posteriormente.

A velocidade de mobilização através das redes sociais e a popularização de ferramentas cada vez mais sofisticadas representa um perigo real para a rede e a nossa dependência cada vez maior na Internet.

  • No próximo artigo, publicaremos as melhores práticas para detecção e prevenção de ataques DDoS.
  • Este artigo está disponível para download no formato de Documento (PDF) na pagina de Download  do Site da AGHATHA  na seção Free Whitrepaper em nossa webstore :  http://www.aghatha.com

—- 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 15 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,

Gledson Maurício Ferrazzo

(CTO- Aghatha Maxi Consulting)

www.aghatha.com.br

Consulting@aghatha.com

———

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:

  • 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.
  • 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.
  • 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.
  • Accelops, com sede no Vale do Silício, Califórnia, EUA. Fundada pela equipe que criou o MARS (adquirido pela CISCO em 2005).
  • Arbor Networks, com sede em Chelmsford, MA, EUA.
  • Cisco, com sede no Vale do Silício, Califórnia, EUA.

– Fim Declarações de Direitos de Copyright —

– Fim Artigo

COMO DESENHAR FLUXOGRAMAS DE PROCESSOS DE NEGOCIO – 2 Parte – Levantamento Analise e Desenho do Fluxograma

COMO DESENHAR FLUXOGRAMAS DE PROCESSOS DE NEGÓCIO

Parte 2 – Levantamento, Analise e Desenho Fluxograma (Passo-a-Passo).

COMO DESENHAR FLUXOGRAMAS DE PROCESSOS DE NEGÓCIO – Parte 2 – Levantamento, Analise e Desenho Fluxograma (Passo a Passo) – Rev.2.

Em continuação primeira parte do artigo  “Como desenhar fluxogramas de processos de Negócio”, trataremos neste artigo algumas técnicas que podem ser utilizadas para a realização de levantamento de informações de processos de negócio, analise das informações coletadas e finalmente o desenho do processo de negócio.

1.     – Termos e Nomenclaturas Utilizados:

  • Analista: Pessoa Responsável pelo levantamento, a analise e confecção do fluxograma de processo.
  • Usuário: Pessoa responsável pela transmissão do conhecimento do processo a ser analisado e representado graficamente.
  • Organização: No contexto deste artigo é o Domínio onde os processos de negócio se desenvolvem – Mesmo que Empresa, Filial ou subsidiária.
  • Unidade de Negócio: No contexto deste artigo, é o local onde um ou mais processos se desenvolvem – Mesmo que Gerencias (Financeiro, Comercial, Controladoria, etc.).
  • Área de Negócio: No contexto deste artigo é o local responsável pela execução de um ou mais processos – Mesmo que Departamentos (Contas a Pagar, Contas a Receber, Pedidos, Faturamento, Patrimônio, Contabilidade, etc..).

2.     – Preparação para a Realização do Levantamento de informações do Processo de Negócio

Recomendamos ao Analista a execução de algumas atividades preliminares que lhe poderão ser muito úteis durante a realização do levantamento e entendimento do processo a ser avaliado, são elas:

2.1 – Entendimento da Estrutura Organizacional

Realizar o entendimento da estrutura organizacional onde o processo está inserido proporcionará ao Analista a “localização” do processo a ser avaliado dentro do contexto da Organização,  além da identificação dos cargos/funções e a cadeia hierárquica existente na organização e que possa ter algum vinculo ou relacionamento com o processo a ser avaliado.

E, ainda no momento em que o processo for entendido e posteriormente desenhado, pode-se utilizar o Organograma para referenciar corretamente as denominações de cargos e funções existentes, identificar os responsáveis pelas autorizações e ainda identificar as relações processuais existentes entre as “Unidades de Negócio”, se estas estão ou não subordinadas ao mesmo gestor;

Ex:

 2.2 – Entendimento do Modelo de Integração do Negócio

É importante o Analista conhecer o modelo de integração entre os processos de negócio existente na organização, ou seja, possuir uma visão de alto nível dos principais eventos de integração existentes e onde eles ocorrem no contexto de sua estrutura organizacional.

Esta visão auxiliará o Analista no entendimento das integrações entre as Unidades de negócio, suas respectivas Áreas de Negócio e consequentemente entre os Processos que as mesmas executam.

Ex:

Se entendermos que uma Unidade de Negócio (Financeiro) representa um grupo de processo que são executados pelas suas Áreas de Negócio a ela subordinadas (Contas a Pagar, Contas a Receber, Caixa e Bancos, etc…) e que ainda, há pontos de integração e relacionamento entre estes processos (Entrada-Processamento-Saída), conseguimos ter uma visão de alto nível dos processos que são executados na Unidade de negócio (Financeiro) e como eles se relacionam entre si.

Expandindo esta mesma visão, verificando as integrações existentes entre o Financeiro e as demais unidades de negócio da Organização, poderemos entender como a organização funciona e como as suas áreas de negócio interagem e se integram entre si (Modelo Funcional do Negócio).

Ex: 

O pré-conhecimento deste nível macro de integrações e relacionamentos existentes  entre os processos, certamente irá dirimir muitas questões e dúvidas no momento do levantamento e entendimento das informações de cada processo individualmente, com base no modelo de integração e na visão de grupo entre os processos.

2.3 – Identificação do Responsável pelo Processo

É uma tarefa importante identificar quem será o responsável pela transmissão das informações relativas a cada processo individualmente, pois o mesmo deve conhecer em detalhes todas as atividades, controles e todos os demais itens que deverá compor a documentação do processo. Quanto maior for o nível de conhecimento do Responsável pelo Processo, maior será a riqueza de detalhes contida na documentação a ser gerada para o mesmo.

É natural que o Responsável pelo processo seja um componente de sua estrutura organizacional, em Tese não se deve utilizar recursos de áreas diferente para documentar processos de outra área. Necessariamente o responsável deve pertencer e estar inserido no grupo de pessoas que executam de fato as atividades. Agindo de forma diferente o Analista estará “inferindo” os eventos do processo e não levantando de fato os eventos que ali ocorrem e,  certamente não conseguirá identificar todas as integrações e relacionamentos existentes (Corre-se o risco de que algum processo possa  ficar sem uma de suas entradas ou uma de suas saídas poderá não ser comunicada adequadamente a todos os seus processos clientes) – Esta é a origem da maioria das falhas de Integração e de comunicação entre os processos de negócio.

3.     – Técnicas de Execução do Levantamento das informações do Processo de Negócio

Para o leitor/Analista  iniciante em atividades de levantamento de informações sobre processos,  recomendamos o uso de uma técnica muito simples mas que pode auxiliar na realização da entrevista, possibilitando o mapeamento adequado das informações sobre o processo de negócio, e ainda, poderá ser muito útil durante a etapa de analise do processo e posterior documentação e desenho do fluxograma do processo.

3.1  – Método 5w2h

Abaixo descrevemos o que cada campo significa, para o entendimento do conteúdo a ser incluído em cada Questão/item:

  • O que?

Esta questão determina as ações ou atividades que são executadas pelo usuário durante toda a extensão do processo, podem ser ações de Processamento, Decisões a serem tomadas, autorizações a serem solicitadas e executadas, enfim é através desta descrição tomamos conhecimento do que de fato é efetuado durante o processo.

Recomenda-se desdobrar as ações descritas pelo usuário em um verbo, ou seja, em uma ação executada. É comum ao descrever uma ação, considerar mais de um verbo ou mais de uma atividade contidas em uma única ação.

Ex:  O que ?: Receber um documento e conferir o seu conteúdo.

O mais recomendado é dividir esta “atividade composta”  em duas  “atividades simples”, pois isto facilitará a analise de lógica posterior no fluxograma ou ainda não devemos utilizar mais de um “verbo” em cada ação. No caso do exemplo foram descritos dois: “receber” e “conferir” indicando que são duas ações e não apenas uma.

  • Quem?

Esta questão determina ou identifica que deve ser o agente executor de uma ação ou atividade, da mesma forma que na questão anterior uma atividade não pode ser executada por duas pessoas ao mesmo tempo, o mesmo ocorre com o executor, caso isto “venha a ocorrer”, é possível que estejamos considerando “duas atividades” sendo executadas “simultaneamente por duas pessoas” e de acordo com as definições básicas de processo (Entrada-Processamento-Saída) isto não pode ocorrer. Se por algum motivo esta hipótese venha de fato a ocorrer, deverá ser desdobrada e documentada em duas ações, cada qual um com o seu executor.

  • Onde?

Esta questão determina ou identifica os locais onde a atividade ocorre, podendo indicar um Departamento ou
Localidade. Esta informação possibilita organizarmos o fluxograma do processo no “espaço”. O cruzamento desta informação com o conteúdo da coluna “Quem?”, será a base necessária para a construção do fluxograma, quando escolhido o formato “cross-functional”.

  • Quando?

Esta questão determina um  situação qualquer ou condições necessária para que a ação ocorra. Nos casos onde o “Quando” não puder ser identificado pode-se considerar simplesmente que a ação é “eventual”.

Alguns erros muito comuns quando se usa este método para o mapeamento e/ou levantamento de processos e considerar o “quando” como prazo, e na realidade este campo só tem esta função, quando se usa o mesmo método para estabelecer as atividades de um plano de ação.

Em nosso caso, utilizamos  o método para levantamento de processos e esta informação passa a ser utilizada para determinar a existência de alguma condições que possa vir a ser necessárias para disparar a execução de uma determinada ação. (Quando tal fato ocorrer….).

Ex.:

    • Confeccionar o Balanço Contábil de uma empresa é uma ação que somente pode ser executada após o fechamento contábil ter sido concluído (Evento de Saída de um processo que possibilita o evento de entrada para um outro processo).
    • Mesmo que esta atividade tenha uma data e hora marcada para ocorrer, há uma condição de processo que precisa ser atendida para que ação de confecção do balanço possa ser disparada (Condição de entrada), e, no caso em questão, será iniciada somente após a conclusão do fechamento contábil, tenha sido ele executado ou não dentro do prazo (Para efeito de mapeamento e desenho de processo esta informação não tem fundamento). Durante a avaliação do processo, depois de documentado é que poderá ser avaliado a pontualidade ou não do processo.
  • Por quê?

Esta questão identifica a razão ou motivo pelo qual a ação deve ser executada. Embora isto possa parecer “o obvio”, em alguns processos (Principalmente os Técnicos) é muito comum e em alguns casos muito importante identificar a razão ou motivo de execução de uma determinada ação,  pois identifica qual é o motivo técnico ou qual é o requisito de uma determinada norma ou regra que deva ser cumprido. Caso a norma ou regra vier a ser alterada, pode-se identificar rapidamente nos processos onde ela ocorre e revisar os processos.

Em processos de negócio o motivo ou razão de execução de uma ação pode estar relacionado a necessidade de autorizações, desmembramento de atividade para garantir regras de segregação de função, mitigar um determinado risco ou na maioria dos casos esta informação pode ficar sem conteúdo (Não Aplicável), pois a ação poderá ser apenas um componente dentre uma sequencia de passos destinados a atingir um objetivo único, ou seja, as ações podem ser o meio de atingir o objetivo ou a razão determinado pelo próprio processo.

Ex:

  • Ao atingir 300º Celsios o equipamento deverá ser desligado.

O motivo para esta atividade podem os mais variados possíveis, tais como: Por quê? : Acima de 300º o equipamento pode ser danificado, pode haver risco de explosão, e assim por diante.

  • Solicitar autorização do superior imediato do solicitante.

O motivo ou razão para a ocorrência desta atividade indica a necessidade de autorização prévia para que a atividade solicitada seja considerada válida somente e após  existência de uma autorização.

  • Como?

Esta questão identifica o método ou forma que a ação deverá ser executada, podendo indicar ou referenciar uma sequencia inteira de ações ou atividades (Descrição detalhada do Método) através de outro documento que demostre o método a ser utilizado com mais detalhes Ex: (Lista de Critérios de aprovação, Lista de Regras de Negócio, Instrução Técnica contendo instruções passo-a-passo, Manual, etc.).

  • Quanto?

Esta questão identifica o montante a ser gasto ou quanto custa à execução da ação. Em tese este valor é um resultado de alguma formula destinada a  apuração dos valores. Sugerimos levantar os elementos necessários para calcular o valor ou ainda indicar onde o valor pode ser obtido e mais importante ainda, onde ele poderá ser posteriormente atualizado. Infelizmente é comum encontrarmos fluxos contendo valores de atividades com mais de 5 anos de idade e totalmente defasados ou desatualizados.

3.2 – Informações Adicionais ao Método 5w2h

Agora vamos sugerir algumas outras informações que podem ser adicionadas e  levantadas e com isto complementar a visão oferecida pelo método 5w2h.

Vejam algumas possíveis:

Custo Hora/Recurso?

Esta questão identifica os recursos necessários para execução de uma determinada ação, Recursos podem ser por exemplo: (Telefone, Mão de Obra, Máquina ou equipamento, serviços de telecomunicações, correio, entre outros). Com a identificação destas variáveis o custo de uma ação poderá ser melhor entendido e calculado e/ou posteriormente atualizado.

Artefato?

Esta questão identifica quais documentos, evidencias, controles ou documentos são emitidos ou confeccionados através da ação (Se a ação produz algum entregável). Com esta informação adicional podemos identificar onde os artefatos são gerados no contexto do processo, oportunizando ainda outras informações adicionais, como: Tempo de retenção do documento, forma de armazenamento, o que deverá ser feito para o descarte , classificações de segurança das informações contidas no artefato, e assim por diante. a quantidade de informações sobre os artefatos podem variar muito, dependendo do objetivo desejado pela documentação do processo em questão.

Quantas Vezes?

Esta é uma informação interessante, quando se pretende avaliar a capacidade ou a carga exercida por um processo, vamos detalhar este assunto em um artigo específico.

Não é incomum um processo ocorrer um determinado numero de vezes durante uma jornada de trabalho e o tempo disponível para executa-lo não ser suficiente para a sua completa execução na mesma jornada. Com base nesta informação e na informação contida na questão seguinte (Quanto Tempo?), consegue-se identificar “gargalos” nos processos de negócio, ou ainda, identificar a quantidade necessária de pessoas para atender um determinado processo e mantendo um nível aceitável de serviço.

Ex:

São emitidos em média 300 pedidos de vendas a cada jornada de trabalho.

Quando Tempo?

Esta informação identifica a quantidade de tempo médio para a execução de uma ação ou atividade. Em combinação com a informação anterior (Quantas Vezes?) pode nos indicar quanto uma atividade consome em termos de capacidade de trabalho (tempo disponível) da equipe.

Ex:

Um Pedido de venda consome 5 minutos para ser concluído, multiplicando-se esta informação pela quantidade média de pedidos emitidos durante uma jornada de trabalho (Quantas Vezes?), podemos calcular que esta atividade consome (5 min x 300 pedidos = 1.500 minutos / 60 min = 25 horas de trabalho por jornada). Se uma jornada de trabalho possui 9 horas, em tese, são necessários pelo menos 3 colaboradores alocados na execução desta atividade, para que não fiquem pedidos pendentes de serem processados de um dia para o outro. E mais ou menos assim que calcula-se a quantidade de atendentes de caixa em um bancos, supermercados, lojas e etc…

3.3  – Preparação do “Check List” para levantamento dos Dados.

Recomendamos preparar uma planilha para documentar o levantamento dos processos, além de possibilitar o acréscimo posterior de fórmulas de calculo para o tratamento dos valores, disponibiliza funcionalidade de filtros de conteúdo de campos, geração de visões e gráficos que podem ser muito úteis nas analises posteriores. Se o Analista utilizar editores de texto os cálculos e visões auxiliares demandarão mais esforço para serem  executadas.

Ex Planilha para Levantamento de Informações do Processo:

4.     – Execução das Entrevistas de Levantamento de Informações dos Processos

Embora o método em questão seja bastante simples, é preciso tomar alguns cuidados,  pois em virtude da quantidade de informações que serão levantadas para cada atividade, corre-se o risco de que a lógica de continuidade do processo seja “perdida” ou “quebrada” , em função das interrupções causadas pelas lista de perguntas que deverão ser necessárias para o preenchimento de todas as colunas.

Para que isto não ocorra, sugerimos levantar as informações em ciclos completos, iniciando pelo conteúdo das colunas (O que?, Quem? e Como? Artefato?) executando o levantamento do processo do inicio até o fim e mantendo o foco inicial no mapeamento destas informações.

Após o término deste primeiro ciclo, retorne a primeira atividade e execute as perguntas complementares relativo as demais colunas, Oportunize a cada ciclo realizado no mesmo processo a execução de possíveis revisões de conteúdo do que já foi documentado. Não é raro ao repassarmos um processo junto com o usuário, que o mesmo venha a lembrar de “detalhes” que foram esquecidos ou ainda não declarados nos ciclos/rodadas anteriores.

As demais colunas, portanto, representam informações adicionais e destinadas ao detalhamento e compreensão do conteúdo contido nas quatro primeiras e, podem ser identificadas em ciclos posteriores ao levantamento inicial, sem que isto venha a causar prejuízos ao resultado obtido no levantamento do processo.

Caso o processo a ser levantado seja muito complexo e envolva um número exagerado de pessoas para a sua execução, é interessante avaliar a hipótese de realização do levantamento em uma única sessão com a presença de todos os envolvidos. Agindo assim, o Analista obterá como resultado uma visão de consenso sobre o processo e ainda,  será muito mais simples a aprovação do resultado final pelos envolvidos.

5.     – Desenho do Fluxograma do Processo de Negócio

Bem agora como já sabemos como são estruturados os processos, critérios de integração, e já possuímos um método para execução dos levantamentos das informações junto aos usuários responsáveis dos processos, vamos mostrar um processo mapeado segundo as informações principais do Método 5w2h e como este processo pode ser representado graficamente através de um fluxograma no formato Cross-Functional.

5.1 –  Exemplo de Resultado obtido no Levantamento do Processo.

Observação:

Embora não tenha sido mostrado na tabela acima o conteúdo da coluna (Onde?), estamos considerando, para efeito deste exemplo que todas as atividades ocorrem na “Área Comercial”.

5.2 – Passo-a-Passo para Confecção do Fluxograma.

5.2.1 – Preparativos Iniciais – “Folha de Desenho”

Após a validação da planilha de levantamento do processo de negócio ter sido concluída e validada junto ao
usuário, estaremos prontos para o início da etapa de desenho do fluxograma.
Para que não percamos tempo durante a execução desta atividade, recomenda-se que a “Folha de desenho” seja previamente preparada. Caso seja adotado o formato “cross-functional”, convém identificar todos os “atores”  e “locais” que serão endereçados pelo fluxograma e isto pode ser facilmente identificado através de  “filtros” na coluna (Quem?) e (Onde?) da planilha de levantamento de informações (5w2h).

Ex: Em nosso exemplo temos:

Atores:

  • Auxiliar Vendas
  • Vendedor Responsável

Locais:

  • Área Comercial

Portanto a nossa “folha de desenho” ficará composta da seguinte estrutura.

5.2.2 – Desenhando Fluxo – Convenções Gerais para o Desenho e Leitura do Fluxograma / Conectores / Setas

  • Sentido de escrita e leitura dos Símbolos aplicados no Fluxograma

Embora esta “convenção” não seja obrigatória, é extremamente interessante que o fluxo seja desenhado no mesmo sentido e direção aplicados pela escrita normal, ou seja, da Esquerda para a Direita, e de Cima para Baixo.
Esta convenção é realmente bastante útil e facilita bastante à leitura do fluxo, pois é a forma natural adotada por todos nós quando realizamos a leitura de qualquer  documento,  porém nem sempre a mecânica do desenho permitirá a sua aplicação durante toda a amplitude do desenho, vez por outra, seremos forçados a desenhar algum símbolo no “contra fluxo” definido por esta convenção,  mesmo assim recomendamos adota-la como um critério geral.

  • Sentido das linhas de Conexão e o uso de setas indicativas de direção

Há ainda uma Convenção relacionada ao uso de setas nas  “linhas de conexão” utilizadas entre os “símbolos”
a qual define que nas situações onde uma linha esteja conectando dois símbolos e o sentido de conexão estiver indicando o mesmo sentido de direção definido pela “convenção de escrita/leitura” – (da Esquerda para a Direita, e de Cima para Baixo) não é necessário a colocação de “seta” no final da linha de conexão  Ex. ( 1 ao 2), ( 1 ao 3) e (3 ao 4). Segundo esta “mesma convenção”, As setas, devem ser usadas apenas nos casos onde o sentido
apontado pela  conexão esteja apontando no “contra fluxo” estipulado pela convenção aplicada para a sua  leitura Ex. ( 2 ao 3 ) e ( 4 ao  2 ). Ex:

Para evitar qualquer tipo de confusão, causada pela eventual esquecimento deste detalhe, sugerimos aplicar o uso generalizado das “setas”, é mais simples e rápido de executar o desenho, como foi a “regra” adotada em nosso modelo final, mais adiante demonstrado.

5.2.3 – Desenhando Fluxo – Cabeçalhos e Informações de Identificação dos Fluxos

Não há uma convenção fixada para definição de um cabeçalho ou informações necessárias para a indicação de fluxogramas de processos de negócio, para isto recorremos às referencias aplicáveis as tabelas de identificação de plantas de engenharia, ou até mesmo controles aplicações documentos em geral.

Há campos que são importantes, tais como:

  • Titulo ou Descrição do Fluxograma, Versão e Revisão
  • Autor Desenho, Data de emissão
  • Revisor Desenho, Data Revisão, se houver.

O Quadro de identificação normalmente é posicionado na parte inferior, direita do fluxograma (Fim do Documento), da mesma forma que buscamos um índice ao final do livro, mas esta convenção não é rígida e a presença da tabela pode ocorrer onde for possível coloca-la na “folha de desenho”. Ex:

5.2.4 – Desenhando Fluxo – Identificando o Início e Fim de Processos

Utilizar os símbolos indicando onde o mesmo “inicia” e onde é “finalizado” é uma indicação lógica e
recomendamos sempre utilizar estes símbolos ao desenhar qualquer fluxograma, por mais simples que seja e por consideração ao leitor do fluxo.

É importante lembrar que os fluxos devem possuir um “inicio” e pelo menos um “fim”, exceto em casos muito
específicos tais como o fluxo de processos contínuos, onde ao final de um ciclo, retornamos a condição de “inicio” de forma contínua e ciclicamente.

Há casos onde um fluxo possui uma indicação de “inicio” e pode possuir mais de uma forma de ser “Finalizado”, e
isto é uma condição normal, visto que um processo pode ter diversas possibilidades de “saídas” ou até mesmo formas de ser “finalizado”, vejamos um exemplo:

Em um processo de Vendas, inicia com a chegada do vendedor na sede do cliente, e o fluxograma do processo de
venda pode encerrar nas seguintes situações, todas possíveis:

  • Com o cancelamento da visita pelo cliente
  • Com a ocorrência da reunião sem realizar uma venda efetiva
  • Com a emissão do pedido de venda
  • Entre outras situações….

A figura demonstrada no item 5.2.2 , ilustra graficamente o uso dos conectores de inicio e fim de um processo.

5.2.5 – Desenhando Fluxo – Tratamento de Atividades Sequenciais

Procure detalhar o máximo possível em cada símbolo de atividades a ação a ser executada, sendo indicado sempre iniciar o texto a ser empregado na  “atividade” por um verbo, indicando a ação de fazer alguma coisa.

Ex:

  • “Conferir” a assinatura do cliente no pedido
  • “Arquivar” o documento na pasta de pedidos

Dependendo do nível de detalhamento realizado durante o  levantamento de informações do processo, pode
haver diversas atividades, executadas em sequencia, sem que algo seja efetivamente  produzido entre elas, além
da execução da própria atividade em si. O importante em relação ao sequenciamento é identificar a ordem de execução das ações no contexto de um processo, ao contrário da regra em que a “ordem dos fatores não altera o resultado do produto”, em termos de processo, a ordem pode significar muito para o resultado final desejado, e devido a isto deve ser muito bem identificada e principalmente validada junto aos seus responsáveis.

Ex:

“De nada adianta solicitar os dados de identificação de pessoa, para lhe franquear o acesso ou não a um determinado ambiente proibido, depois que ela já estiver no interior do próprio ambiente. Neste caso: A ordem indicada seria, primeiro solicitar a identificação, avaliar a situação  e, somente depois disto, liberar o acesso ao referido ambiente”.

Quando uma atividade estiver relacionada ao preenchimento de um documento, por exemplo, ela poderá ser representada através de uma única atividade (“Preencher tal documento…”), sendo desnecessário identificar uma
atividade para cada campo contido no corpo deste documento. Este nível de detalhamento e outros tantos exemplos a ele relacionados, não é indicado, pois torna o fluxo além de muito extenso, extremamente cansativo no momento de ser interpretado.
Exceções existem, e nestes casos, faça o uso deste tipo de representação apenas quando houver motivos muito relevantes para o entendimento do processo em si. Isto é uma questão de “bom senso”, (“Nem “8” e nem “80””).

Ex:

As Atividades (1), (2), (3) e (4), são sequenciais e indicam a ordem exata das atividades a serem executadas no contexto do processo.

5.2.6 – Desenhando Fluxo – Tratamento de Documentos (Artefatos)

É função excencial dos processos a produção de algum “Resultado tangível” em algum momento de sua execução esta resultado encerra o ciclo de vida do processo, pois está relacionado ao se componente de “Saída”,
conforme tratamos na 1ª Parte deste artigo.

  • (Quando o Processo é “Formal” e o Resultado é “Informal”).

Quando estamos desenhando um processo de negócio e não identificamos oo mesmo não produz um “resultado tangível” no final do seu ciclo de vida, este processo tem um erro de concepção grave:

Quando um Processo é “Formal”, mas o “Resultado produzido” pelo mesmo é “algo intangível ou não formal”, todo o processo passa a ser classificado como um “processo informal”. E, portanto não produziu nenhum sentido ou efeito concreto a atividade realizada para a sua documentação. Ex:

Pensemos juntos: “Quando desenhamos um processo, sob a ótica da documentação de processos, ele até que poderá ser categorizado como um  “processo formal”, pois esta ali, descrito e documentado. No entanto, se, ao analisarmos o contexto do processo em si, e notamos a “ausência” de “evidências materiais e concretas”
durante todo o seu ciclo de vida, Podemos concluir, que mesmo tendo sido documentado formalmente ele ainda continua sendo um PROCESSO INFORMAL. (Ele não produziu nada, apenas documentou os  esforços tidos pelas atividades sem fornecer nenhuma evidência de que de fato foi executado).”

Em processos de negócio, onde estes estão inseridos no mecanismo de funcionamento de uma empresa, padronizando eventos, integrando equipes, produzindo obrigações e direitos em quase todos os eventos são raros
os casos onde as “permissões ou possibilidades” de que os ”produtos” produzidos pelos processos possam ser “informais”.

  • (Quando o Processo é “Formal” e o Resultado é “Formal”).

O mais comum é que os processos “produzam” durante o seu ciclo de vida “algum artefato ou evidencia”, tais como,  documentos, controles, registros de dados em sistemas e tantas outras possibilidades formais de comprovar que aquele ciclo de fato ocorreu. A isto se denomina “Prova Material” produzida pelos processos.

No momento de desenhar os “artefatos” em um fluxograma, o mesmo deve ser inserido sempre e logo após a ultima atividade que concluiu a sua produção ou que efetivamente tenha o  produzido.

Nos casos onde um documento é finalizado e em seguida enviado para outra pessoa ou área de negócio, é uma boa prática representa-lo no processo fornecedor e indica-lo novamente na entrada do processo cliente.
Faz-se isto para que o leitor, ao interpretar o processo cliente, não tenha que navegar até mesmo identificar de qual “artefato” está se tratando.

Há ainda algumas convenções que sugerem marcar no documento, um traço diagonal, no momento onde é gerado pela primeira vez, e ainda, há convenções que determinam um traço para cada via emitida. Embora a informação
possa ser útil de alguma forma, este método é raro de ser observados nos dias atuais e praticamente caiu em desuso.

Vamos ao Ex:

Na representação abaixo, podemos concluir que a Atividade (3) produziu o Artefato (4), e que as atividades (1) e (2) podem estar relacionadas as atividades de preparação para a sua produção.

5.2.7 – Desenhando Fluxo – Representando as Decisões Tomadas

As decisões representam a “alma” dos fluxogramas, pois são através delas que podemos representar à graficamente a dinâmica e as alternativas existentes nos processos, regras de negócio, enfim tudo aquilo que diferencia um fluxograma de uma “Receita de bolo, Lista de compras do Supermercado, lista de pendencias,
entre outros”.

O conceito de fluxograma somente existe, se houverem situações de decisão ou de alternativas distintas de ação frente a uma situação positiva ou negativa qualquer. Onde houver a possibilidade de duas alternativas em relação a uma situação qualquer, esta, poderá ser representada através de um fluxograma.

Embora o losango, símbolo convencionado para as decisões possua 4 vértices, utiliza-se apenas 3 nas representações dos fluxos, sendo sempre 1 entrada e 2 saídas possíveis, frente a uma Questão interrogativa qualquer, indicando pela resposta “SIM / POSITIVO” um caminho e “NÃO / NEGATIVO” o outro caminho a ser seguido pela lógica representada pelo grafia do fluxo.

É um erro muito comum, incluir no símbolo a ação que pretere a decisão lógica, quando o correto é colocar esta ação em uma atividade anterior a decisão, e deixar para incluir no símbolo apenas questões simples e diretas (Perguntas Fechadas são as mais recomendadas, pois não deixam dúvidas em relação ao caminho a ser seguido).

Ex:

Se pretendermos verificar a completude de um documento, antes de tê-lo como concluído, (Validação de preenchimento, por exemplo).

 

5.2.8 – Desenhando Fluxo – Tratamento de Arquivos

Deixamos este símbolo por ultimo, pois ele sem sempre consta em todos os fluxos. Representa o destino final de um “artefato”, e que poderá vir a ser um Arquivo, depósito, Almoxarifado, ou até mesmo a sua destruição ou
descarte.

As convenções mais antigas do uso deste símbolo recomendavam inserir no interior do triangulo, algumas letras indicando a “ordem” de arquivamento que deveria ser adotada como índice de ordem de arquivamento, esta
informação poderia ser ainda acompanhada pelo tempo em (M – Meses / D – Dias / A – Anos), que o documento deveria ser mantido, até ser descartado/destruído.

Ex.:

(A/3 A)- Alfabética – Destruir após 3 anos, (D /3M) – Ordem Cronológica, (N /30D) – Ordem Numérica) ou ainda, se estivesse sem conteúdo  (Sem a presença de Letras seria o equivalente a arquivar o artefato em Ordem de Chegada – ( – /3A) – Ordem de Chegada, destruir após 3 anos),

ou ainda,

Uma segunda indicação de qual a Informação deveria ser utilizada como índice para a ordem de arquivamento (Nr. Pedido/A3 – Destruir após 3 Anos, Razão Social, CNPJ).

Nos casos onde o documento não seria arquivado e sim destruído, convencionava-se colocar um X cobrindo todo o triangulo ou o símbolo do próprio documento, indicando a destruição do documento. Embora estas informações também fossem interessantes, atualmente fazem sentido em apenas alguns casos de processos (Ex: Processos de ordem jurídicas ou legais, Processos de produção envolvendo fórmulas químicas).

  • Situações onde o Arquivamento encerra o Processo

O mais comum, e encontrarmos símbolos de arquivo no fim de processos, onde após ser executadas todas as ações e atividades previstas e ainda depois de serem produzidas todas as evidencias (Artefatos), o destino final da documentação é indicada nos processos através do arquivamento dos documentos.

Para efeito de organização e métodos: Mais importante do que indicar o arquivamento de um artefato em um fluxograma  é,  tê-lo de fato disponível para uso. No local indicado no fluxo, e  ainda, em acordo com a ordem
de armazenamento previstas no mesmo fluxo.

  • Situações onde o Arquivamento Inicia o Processo

Embora seja menos comum, também podemos encontrar símbolos de arquivo no inicio dos processos. Isto normalmente ocorre nos casos envolvendo rotinas de “limpeza e descarte” das próprias informações contidas nos arquivos ou ainda informações que estavam armazenadas de forma temporária ou aguardando um evento ou data para serem recuperadas e processadas.

Vamos Exemplificar, para facilitar o entendimento:

5.3 – Representação Gráfica do Processo (Fluxograma)

Observação:

Demonstramos o processo de Vendas, anterior ao processo tratado em nosso exemplo (Processamento do Pedido de Vendas),  com o objetivo de demonstrar a orígem do documento “Pedido de Vendas”, como sendo a (Saída do Processo anterior) e a sua respectiva entrada em nosso processo de exemplo.

Fim do Conteúdo deste Artigo.

———-

———-

·  Download do conteúdo deste Artigo :

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

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

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

  • Visite nossa Webstore :

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

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

  • AGHATHA Framework – Compliance Norma ISO-27002

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

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

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

———-

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

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

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

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

Framework Compliance Norma ISO-27002

———-

·       Mais Artigos desta Série:

1 Parte – Introdução, Conceitos e Modelos

COMO DESENHAR FLUXOGRAMAS DE PROCESSOS DE NEGÓCIO – Parte 1 – Introdução, Conceitos e Modelos.

  • Veja Conteúdo em :

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

 

3 Parte – Analise Técnica de Processos de Negócio.

COMO DESENHAR FLUXOGRAMAS DE PROCESSOS DE NEGÓCIO – Parte 3 – Analise Técnica de Processos de Negócio.

Neste artigo trataremos algumas analises técnicas de processo de negócio, tais como Carga, Capacidade, Nível de Serviço entre outas análise possíveis através do fluxograma de processos de negócio.

  • Veja Conteúdo em :

http://aghatha.wordpress.com/2011/07/16/como-desenhar-fluxogramas-de-processos-de-negocio-3-parte-analise-capacidade-carga-processos/

Outros Artigos Relacionados em Conteúdo:

———–

·       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:

http://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.

Todos os artigos estão disponíveis para download no formato de Documento (PDF) na pagina Free Whitepaper em nossa WebStore em AGHATHA.com em : Http://www.aghatha.com , faça-nos uma visita e assine a nossa newsletter, para receber atualizações deste artigo e outros relacionados ao mesmo assunto.

Abraço e Felicidades a Todos,

Eurico Haan de Oliveira

www.aghatha.com/index.htm

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

———

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

[youtube http://www.youtube.com/watch?v=T_gsHigMFvU]
———

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

  • 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 (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

· Compartilhe este Artigo:

COMO DESENHAR FLUXOGRAMAS DE PROCESSOS DE NEGÓCIO – 1 Parte – Introducao Conceitos e Modelos

COMO DESENHAR FLUXOGRAMAS DE PROCESSOS DE NEGÓCIO

Parte 1 – Introdução, Conceitos e Modelos.

Como desenhar fluxograma de processos de negócio – parte 1 – Introdução, Conceitos e Modelos.

Muitas vezes nos deparamos com a dificuldade que os responsáveis pelos processos nas organizações têm ao demonstra-los graficamente.

Com o objetivo de auxiliar os colegas nesta atividade  vamos descrever neste artigo um método simples, mas que ao mesmo tempo é bastante útil e prático.

Vamos utilizar na confecção deste artigo, fluxos e gráficos desenhados com o uso do VISIO da Microsoft,  no entanto o leitor poderá fazer uso de qualquer outra ferramenta disponível no mercado, inclusive ferramentas livres.

O nosso objetivo aqui não é avaliar esta ou aquela ferramenta, ou determinar se uma ferramenta é melhor que a outra, ou ainda a possibilidade de utilização de outros modelos e formatos para a documentação de processos.

O nosso objetivo é descrever um método que o leitor possa aprender facilmente e aplicar na documentação de seus processos.

1 – Introdução ao estudo de processos

Antes de abordar a técnica a ser utilizada no desenho propriamente dito dos  processos é necessário que o nosso leitor tenha o entendimento dos princípios básicos dos processos, para isto vamos abordar os tópicos principais e neste sentido nivelar os conhecimentos.

1.1    – Componentes Básicos dos Processos

Por definição, um “Processo” deve possuir um conjunto de componentes básicos para ser considerado um processo, são eles:  Componente  de “entrada”, com base neste componente é realizado as atividades de  “processamento”, e como resultado  deverá produzir uma  “saída” qualquer.

1.2   – Controle de qualidade entre os Componentes do Processo

Como qualquer atividade destinada a produzir algo, o processo requer a realização de atividades de controle para assegurar a sua qualidade e que deverá ser aplicada em cada um dos seus componentes (Entrada-Processamento-Saída). Agindo desta forma estaremos evitando comunicação de eventuais erros ou falhas entre os elementos que compõem o processo, dentro do universo compreendido pelo próprio processo.

Traduzindo isto de uma forma mais clara:

 

 1.3   – Controle de qualidade entre Processos

No entanto, um processo não é um elemento absoluto e restrito a si próprio,  possivelmente em algum momento dependerá de outros processos para ser “alimentado” e possivelmente, após a execução de seu próprio processamento, passará a “alimentar” outro processo através do seu “produto” e assim sucessivamente.

Diante disto, é uma boa prática considerar ações de controle de qualidade também entre processos, e com isto garantir a qualidade e a integração entre os mesmos, ou seja, é importante assegurar que o “produto” gerado por um “processo fornecedor” seja validado por ele mesmo antes de ser comunicado ao seu “Processo Cliente”.

Traduzindo isto de uma forma mais clara:

 

Em tese, quando agimos desta forma, o “Processo Executor” não teria necessidade de validar os seus “insumos” no momento de proceder o recebimento de sua “entrada”, uma vez que isto deveria ter ocorrido previamente no “Processo fornecedor”, pouco antes do mesmo proceder a liberação de “saída”.

No entanto,

Se verificarmos a qualidade apenas uma única vez, estamos sujeitos à possiilidade de ocorrência de alguma falha na saída do “Processo fornecedor” e nem sempre a “Qualidade declarada” na saída de um processo, atenderá plenamente os requisitos de qualidade necessários para atender a  “entrada” no processo seguinte.

Exemplo Prático: Experimente executar o ciclo de vida de um projeto de desenvolvimento de sistemas, onde cada etapa do ciclo pode ser comparada a um processo. Quando não realizamos estas verificações de entrada e saída em cada uma das etapas do processo de produção do sistema, o grau de variação do produto resultante será um fatorial das taxas de erro ocorridas em cada etapa, (O Resultado será medido pela multiplicação das taxas de erro existentes em cada etapa,  pelas taxas de erro das etapas seguintes, e assim sucessivamente), esta é a explicação matemática de possíveis distanciamentos  entre o “requisito original do negócio” e o  “resultado do produto do projeto”, note que antes de mais nada uma Metodologia é um Processo e pode-se utilizar este conceito na formulação do controle de qualidade na formatação de etapas ou fases de uma MDS.

Traduzindo isto de uma forma mais clara:

 Uma vez entendido estes componentes e os critérios básicos de revisão de qualidade e  integração entre os componentes de um processo e entre processos fornecedores e processos clientes, retornaremos ao nosso objetivo inicial, que é demonstrar graficamente os processos de negócio através de fluxogramas.

2        Padrão de Simbologia

Existem diversos padrões de símbolos possíveis para desenhar fluxogramas de processos, e inclusive padrões destinados a especificações e desenho técnico de software, modelos de dados e tantos outros. Vamos adotar aqui um modelo bastante simples e composto por um número reduzido de símbolos, mas que são suficientes para demonstrar um processo de negócio através de um fluxograma.

São eles:

 

 

3        – O  Modelo de Estrutura do Fluxograma do Processo.

Existem diversos formas possíveis de estruturar um fluxograma de processo, a mais indicada para mapear processo é a denominada (CROSS-FUNCTIONAL), o que poderia ser traduzido mais ou menos como “fluxograma cruzado entre funções”.

Neste formato, o fluxograma possibilita a inclusão de informações adicionais, além da sequência de atividades proporcionada pelo encadeamento dos símbolos, e é possível segmentar o desenho do processo em “setores/celulas” como se fossem uma matriz, sendo inseridos nas linhas os Atores ou funções responsáveis pela execução das Atividades e nas Colunas as etapas existentes em um determinado processo.

Veja como ficaria o desenho de um processo seguindo a estrutura Cross-Functional na visão Horizontal:

 

 O mesmo Processo, seguindo a visão Cross-Functional na visão Vertical:

 

E ainda, o mesmo processo utilizando-se a forma Livre normalmente utilizada. Note que as informações adicionais presentes nas duas opções anteriores fazem de fato a diferença no entendimento do processo.

——-

See the article content in English here:

http://aghatha.wordpress.com/2011/07/29/how-to-draw-business-process-flowchart-part-1-of-3-%e2%80%93-introduction-concepts/

———-

·  Download do conteúdo deste Artigo :

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

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

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

  • Visite nossa Webstore :

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

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

  • AGHATHA Framework – Compliance Norma ISO-27002

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

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

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

———-

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

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

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

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

Framework Compliance Norma ISO-27002

———-

·       Mais Artigos desta Série:

1 Parte – Introdução, Conceitos e Modelos

COMO DESENHAR FLUXOGRAMAS DE PROCESSOS DE NEGÓCIO – Parte 1 – Introdução, Conceitos e Modelos.

  • Veja Conteúdo em :

2 Parte  – Instruções Passo-a-Passo para Desenhar um Fluxo.

No próximo Artigo (Parte 2), trataremos as técnicas a serem utilizadas durante as Entrevistas para levantamento de informações dos processos a serem desenhados e alguns exemplos de como devemos organizar e preparar o conteúdo das informações obtidas no levantado para facilitar a confecção do respectivo fluxograma. Próximo Artigo : COMO DESENHAR FLUXOGRAMAS DE PROCESSOS DE NEGÓCIO – Parte 2 – Levantamento, Analise e Desenho do Processo de Negócio.

  • Veja Conteúdo em :

3 Parte  – Levantamento, Analise de Capacidade e Carga de Processos (Saiba como Calcular Esforço, Tempo e Custos)

  • Veja Conteúdo em:

———–

·       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:

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

———

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

[youtube http://www.youtube.com/watch?v=T_gsHigMFvU]
———

·       Declarações de Direitos de Copyright

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

 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 (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

· Compartilhe este Artigo:

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

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:  http://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:

http://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

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

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

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

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

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

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

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

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

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

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

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

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

2 – A Estrutura Física dos Documentos

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

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

documento_padrao_aghatha_framework

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

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

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

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

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

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

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

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

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

Descrição das Diretrizes de Uma Politica:

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

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

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

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

Descrição das Regras de uma Norma:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 – Controles da Documentação.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

—-

———-

·  Download do conteúdo deste Artigo :

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

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

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

  • Visite nossa Webstore :

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

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

  • AGHATHA Framework – Compliance Norma ISO-27002

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

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

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

———-

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

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

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

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

Framework Compliance Norma ISO-27002

———-

—- Fim Conteúdo Artigo —-

Agradecimentos e Convites:

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

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

Abraço e Felicidades a Todos,

Eurico Haan de Oliveira

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

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

———

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

[youtube http://www.youtube.com/watch?v=T_gsHigMFvU]
———

———

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

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

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

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

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

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

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

– Fim Declarações de Direitos de Copyright —

— Fim Artigo

Compliance de Processos – Norma ISO/IEC-27.002 – Gerenciamento de Segurança Informação

SUGESTÃO DE ESTRATÉGIA – ADOÇÃO DAS RECOMENDAÇÕES DA NORMA ISO-IEC-27.002 – SEGURANÇA DA INFORMAÇÃO

Sugestão de estratégia – adoção das recomendações da norma ISO-IEC-27.002 – Segurança da Informação

Uma estratégia vencedora pra implementação de melhores práticas é adotar os frameworks através de níveis organizacionais, ou seja:

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

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

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

Adotar a implantação dos modelos através destes três níveis possibilita a formalização dos processos recomendados pelas melhores práticas, e distribui o escopo de cada recomendação nos diversos níveis da organização.

SUGESTÃO DE APLICAÇÃO DAS RECOMENDAÇÕES DA NORMA NOS ATRAVÉS DOS NÍVEIS DE DOCUMENTOS. 

– Politicas:

Confeccionar uma ou mais políticas, adotando formalmente as recomendações  estabelecidas pela Norma.

– Normas:

Cada Capítulo da Norma ISO-IEC-27.002, possui definido um objetivo e controles a serem implementados. Normalmente isto pode ser adotado criando uma norma para cada item, ou seja,  devem-se definir as regras de aplicação do conteúdo de cada capítulo.
Um fato interessante é que a ISO-27002 tem recomendações genéricas (O Que fazer?), mas não detalha o (Como Fazer?).  Para que o escopo do projeto de adoção fique adaptável à realidade de cada organização, é necessário estabelecer através de regras, o que será feito e quais os critérios deverão ser adotados para cada capítulo da norma.

– Procedimentos:

Cada capítulo estabelece os controles que devem ser adotados, estes, uma vez delimitados pelas Regras de como a empresa adotará ou não alguma recomendação, acabam por estabelecer quantos controles deverão ser criados e consequentemente quantos processos devem ser organizados.

Cada controle é lastreado por um processo, o qual tem como escopo definir as atividades e responsáveis pela execução do controle, e qual artefato será produzido durante a realização de cada ação ou atividade. Finalizado o processo devemos ter em mãos uma evidencia de que a atividade foi realizada.

DICAS:

Os processos devem ser construídos e relacionados seguindo uma ordem de baixo para cima, ou seja:

– Controle de Riscos – Sec 4.
– Controles de Politicas e Organização da Segurança – Sec 5,  6 e 15.
– Controle de Ativos – Sec 7.
– Controle de RH – Sec 8.
– Controle de Segurança Fisica – Sec 9.
– Controle de Operações e Comunicações – Sec 10.
– Controle de Acessos Lógicos – Sec 11.
– Controle de Aquisição e Desenvolvimento de Sistemas – Sec 12.
– Controle dos Incidentes de segurança – Sec, 13

– Controle de Continuidade do Negócio. Sec 14,
Recomendamos implementar esta seção em uma etapa seguinte a implementação das seções anteriores, pois para que um plano de continuidade de negócio possa ser estruturado e testado de forma eficiente, devem estar implementados os controles de ativos, acessos, operações e comunicações e devidamente gerenciados em relação a gestão de mudanças, convém adotar também os requisitos estabelecidos pela Norma ISO-IEC-20.000 – Gerenciamento de Serviços de TI.

Outros Artigos Relacionados:

  • Veja Artigo sobre como Formatar, Organizar Documentação de Processos em TI para implementar boas práticas em:

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

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

Consultoria@aghatha.com.br

———
———

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

[youtube http://www.youtube.com/watch?v=T_gsHigMFvU]
———

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

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

É 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