Feeds:
Posts
Comentários

Archive for the ‘Aghatha Maxi Consulting’ Category

Mais de 85.000 Acessos  (45.000 acessos e 40.000 downloads) – (dez/2011 a jun/2012) –

(Over 85,000 Hits ( 45,000 hits and 40,000 downloads) – (2011/dec – 2012/jun))

Agradeço sinceramente a TODOS os nossos Leitores em todo o mundo….

(I sincerely thank all our readers around the world ….)

Mapa de Hits / Downloads – 85.000 hits

Pela ordem do número de visitas / downloads….

Sorted by  number of hits / downloads ….

 / MUITO OBRIGADO / THANK YOU  /  GRACIAS  /  ESKERRIK / GRÀCIES / ขอขอบคุณ  /  धन्यवाद

/   TAK  /  СПАСИБО  /  DANK U / DANKIE /  DANKE /    תודה    /   ありがとうございました /   謝謝

/ تشکر   / HVALA /   شكرا لك  /   감사

Danke U !!!

(Obrigado Pessoal….  thank you,  guys…)

Eurico Haan de Oliveira, CEO

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

HyperSmash

Anúncios

Read Full Post »

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

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

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

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

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

Convidamos você a conhece-los um pouco mais …

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

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

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

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

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

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

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

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

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

  •  Abordagem Utilizada:

 
 

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

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

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

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

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

  

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

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

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

 


 

c)  Workflow –  Automatização Mensagens e Eventos

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

 

3.1 – Licenciamento Eletrônico.

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

http://www.aghatha.com

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

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

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

3.2.1 – Diagnósticos On-Site

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

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

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

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

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

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

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

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

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

4– Onde estamos Localizados / Escritórios .

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

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

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

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

www.aghatha.com/processos.htm

———-

· Download do conteúdo deste Artigo :

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

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

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

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

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

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

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

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

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

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

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

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

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

Porto Alegre, RS, Brasil, fevereiro de 2012.

Read Full Post »

TOP 10 Motivos para Substituir o CS-MARS pelo ACCELOPS SIEM Next Generation.

Procurando uma solução para a substituir o Cisco Mars?

Você precisa conhecer uma solução que seja além do SIEM em termos de Inteligência de Segurança.

Desenvolvido pela equipe que construiu originalmente o produto MARS,  O AccelOps vem definir o novo padrão para SIEM.

O nosso produto de próxima geração proporciona mais Inteligência em Segurança através de:

  • Todos os eventos são totalmente enriquecidos com o contexto para automatizar as respostas as ameaças e reduzir os custos de análise forense
  • Proporciona uma caminho mais rápido para monitoramento amplo da empresa, eliminando pontos cegos
  • Solução totalmente virtualizada, opera além do equipamento de firewalls e em empresas que adotam nuvens híbridas
  • Repositório de Dados para análises em tempo real e para lidar com exploração dos  dados
  • Visibilidade em tempo real em segurança, disponibilidade, performance e gerenciamento de configurações em um único painel de controle.

TOP 10 Motivos para Substituir o CS-MARS pelo ACCELOPS SIEM Next Generation.

1. Tempo de investigação de incidentes de segurança do usuário final de uma extremidade a outra em 2 horas versus dias.
2. Mais de 50% de Redução de Custos para o gerenciamento da solução de SIEM.
3. Mais de 80% de redução em horas dedicadas na confecção de relatórios operacionais de segurança digital e de Compliance.
4. O mais rápido processo de Delivery de solução e de disponibilização de acesso aos benefícios existente no mercado de ferramentas para o monitoramento de TI.
5. Mais escalável devido a sua arquitetura ser baseada em Clusters de Appliance Virtuais.
6. Priorização dos incidentes com base nos impactos causados aos Serviços Suportados para o Negócio.
7. Identificação dinâmica do usuário e do rastreamento de sua localização.
8. Oferece o “Engine de Regras” mais avançado da Indústria, incluindo o seu mapa de vulnerabilidades de IPS.
9. Oferece preços e condições especiais para Substituição do CS-Mars.
10. Oferece gratuidade dos valores de Taxas de Manutenção do Primeiro Ano, avaliação do ambiente legado e assistência durante o processo de migração.

Veja mais detalhes no texto original em Inglês / Fonte: http://www.accelops.com/ciscomars/why-accelops.php

Enviamos apresentação contendo todos os detalhes dos motivos acima citados, entre em contato conosco pelo email :  consulting@aghatha.com

Deseja ver mais informações, telas, dashboards, estudos de caso do AccelOps SIEM next Gen, visite o nosos site em (http://www.aghatha.com/solucoes.htm )

    • Principais razões para escolher o AccelOps SIEM Next Generation.

1- Analise comparativa:

Veja os resultados das comparações entre o AccelOps com o CS MARS e outros produtos tradicionais do mercado e observe como o AccelOps auxilia o aumento de sua produtividade e capacidade através do Modulo AccelOps SIEM Next Generation.
Capacidades padrão de soluções de SIEM, tais como gerenciamento de Log, gerenciamento de ameaças e Compliance são geralmente equiparadas entre os fornecedores, portanto, foram excluídas desta comparação.

Veja mais detalhes no texto original em Inglês / Fonte: http://www.accelops.com/ciscomars/accelops-competitors.php

2- Distribuidor AccelOps no Brasil.

Caso você tenha interesse em conhecer melhor a Solução AccelOps All-In-One Monitoring Solution, nos podemos lhe disponibilizar:

• Acesso a uma Sala virtual para assistir uma Demonstração Completa da solução, apresentada por técnicos brasileiros e no idioma Português, onde você poderá verificar em tempo real todas as funcionalidades e inovações proporcionadas pela solução AccelOps.

Ou ainda,
• Uma cópia completa da solução, para uso em demonstração em seu próprio site, sem nenhum custo.

Entre em contato conosco agora mesmo, pelo email :  consulting@aghatha.com

3- Mais informações,

visite o nosso site ( http://www.aghatha.com/index.htm  ) ou no site da AccelOps Inc. nos USA (http://www.accelops.com ),  ou nos solicite mais informações sobre o AccelOps.

Outras fontes de referencia: (AccelOps Expands Cisco MARS Replacement Program) – Cisco MARS Customers Find AccelOps Improves Productivity by 50%, Eliminates Multiple Tools, and Better Supports Virtualization , by: Deb Motner 203-226-9290 x10 Email Contact

http://finance.yahoo.com/news/AccelOps-Expands-Cisco-MARS-iw-1574277234.html?x=0

Divulgue este post:

———

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

 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 mantendo a 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 do seu distribuidor no Brasil, e o leitor não está autorizado a utiliza-los, de forma integral ou parcial para usos e fins que visem à obtenção de lucro, benefício comercial próprio ou a terceiros.

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

– Fim Declarações de Direitos de Copyright —

– Fim Artigo

Read Full Post »

O Que e BSM – Business Service Management

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

*  Divulgue este Post:

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

Read Full Post »

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

O QUE É GOVERNANÇA  DE TI ?

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

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

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

1.1 – Introdução / Histórico.

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

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

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

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

 

  • O Conceito “Puro” de Governança.

 

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

 

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

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

 

  • O Conceito “moderno” de Governança.

 

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

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

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

 

  • O Conceito “organizacional” da Governança.

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

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

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

  

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

 

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

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

 

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

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

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

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

 

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

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

 

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

 

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

 

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

 

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

  

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

 

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

 

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

 

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

 

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

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

 

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

 

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

 

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

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

 

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

 

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

 

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

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

 

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

 

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

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

 

1.3 – Os Novos Paradigmas da Governança no Brasil

 

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

 

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

 

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

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

 

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

 

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

 

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

 

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

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

 

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

 

1.4 – Componentes Principais da Governança de TI.

 

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

 

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

 

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

 

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

 

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

 

Exemplo:

 

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

 

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

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

 

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

 

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

 

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

 

E  para Concluir,  duas perguntas finais:

 

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

 

ou

 

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

 

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

 

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

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

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

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

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

Fim Artigo.

—–

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

——

  • FRAMEWORK DE PROCESSOS E CONTROLES PARA O COMPLIANCE DE TI

Convidamos a Navegar pelo em Nosso Framework de Processos e Controles para o Compliance de TI aos Padrões e Recomendações para o compliance SOX, ISO-27.001/2, ISO-20.000:1/2, COBIT, ITIL V3, PMI. você

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

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

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

https://aghatha.wordpress.com/2012/05/24/como-implementar-processos-e-controles-para-o-compliance-de-ti-atraves-do-licenciamento-de-uso-de-um-framework-modularizado-e-contendo-documentos-processos-controles-e-workflow-para-cada-um-dos-padroe/

—- Fim Conteúdo Artigo —-

Agradecimentos e Convites:

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

Abraço e Felicidades a Todos,

Eurico Haan de Oliveira

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

———

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

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

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

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

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

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

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

– Fim Declarações de Direitos de Copyright —

– Fim Artigo

Compartilhe este post:

Read Full Post »

Solução Inovadora – BSM – Business Services Management & Monitoring – (All-in-One Solution)

Solução Inovadora – BSM – Business Services Management & Monitoring – All-in-One Solution – AccelOps

Monitoramento de Disponibilidade, Performance, Segurança e Governança para a infraestrutura do Data Center, SOC e NOC disponível em um Unico Appliance Virtual (Software).

1-  O que é BSM – Business Service Management?

Business Service Management (BSM) é uma metodologia que integra ações de  monitoramento,  identificação de incidentes e eventos que impactam na continuidade dos serviços de TI, priorização das ações de resposta, e medição de níveis de serviços  de Tecnologia da Informação a partir de uma perspectiva do ambiente de TI em relação à estrutura do negócio, ou seja,

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

2-   Solução BSM – AccelOps PAM + AccelOps SIEM – All-in-One Solution

 

AccelOps PAM  + AccelOps SIEM

( Visão 360 Graus de todo o seu Ambiente de TI )

A Solução AccelOps foi lançada no mercado Norte Americano em 2007, e mesmo com pouco tempo de presença no mercado, já recebeu diversos prêmios devido a sua inovação, capacidade de integração, relação custo x benefício e diferenciais tecnológicos oferecidos, e em função disto, vem apresentando excelente nível de crescimento, em termos de aceitação e de participação no mercado Norte Americano de BSM – Business Service  Management & Monitoring.

Premiações Recebidas – AccelOps

  •  Componentes  da  Solução

A Solução de BSM – Business Services  Management & Monitoring – (All-in-One Solution) da ACCELOPS, é composta por  dois módulos principais, sendo:

A utilização combinada destes dois  módulos estabelece uma Solução Integrada e destinada ao Monitoramento da  Disponibilidade, Performance, Segurança,  Governança e Compliance da Infraestrutura presentes no Data Center, SOC e NOC e  é  indicada para o segmento de empresas que operam ambientes de Data  Center que não estão dispostas a pagar o preço das soluções oferecidas pelas grandes corporações ou que ainda pretendam reduzir os  seus custos operacionais nas ações de monitoramento de sua infraestrutura  e ainda promover melhorias nos Níveis de Serviços de forma orientada a satisfazer as necessidades do negócio, através de uma solução moderna, atual e  com custos muito mais atrativos, viáveis e escaláveis.

  • Tecnologia  Aplicada

A solução ACCELOPS foi  desenvolvida com base em plataformas tecnológicas mais Atual em comparação com  as soluções tradicionais de mercado, oferece uma arquitetura inovadora e dinâmica baseada em Adobe Flex Web 2.0 GUI,  fornece uma visibilidade completa e interativa  do ambiente computacional, redes, VMWare, Storages, Segurança, Compliance, Aplicações e Serviços que oferecem suporte as atividades do negócio.

As funcionalidades são orientadas ao  atendimento das necessidades operacionais de monitoramento, conectividade,  escalabilidade, e contemplando interfaces totalmente integradas, interativas e projetadas para satisfazer as necessidades de identificação e visualização dos eventos ocorridos no seu ambiente no ponto de vista técnico  e  ao mesmo tempo  possibilitando a identificação da abrangência e impacto causados ao seu negócio. (Veja Aqui exemplos das Telas de Monitoramento)

Estas informações e o nível de  interatividade e integração promovidas durante o uso da solução representam um grande diferencial operacional,  durante a identificação das causas dos  incidentes, priorização  e  tratamento dos  eventos  que impactam na disponibilidade,  performance, Segurança e Governança dos elementos que compõem a  infraestrutura de TI de forma orientada a atender as necessidades do negócio..

A solução representa  um avanço tecnológico importante às operações de monitoramento e em apoio às  equipes de suporte a Infraestrutura de TI e ainda apresenta custos e formas de  licenciamento  altamente competitivos, escaláveis e com baixo custo de propriedade (TCO).

  • Controle de  Acesso Personalizável e baseado em Função.

AccelOps  fornece suporte ao modelo de controle de acessos da Equipe Técnica usuária  (RBAC – Role-Based Access Control)  que permite a solução ser efetivamente utilizada por um conjunto  diversificado de usuários e técnicos,  com  diferentes papéis funcionais e em  ambiente  de grandes provedores de serviços / empresas. E também possui várias funções do sistema já pré-definidas e que podem ser facilmente  modificadas para adaptar-se a qualquer cenário de controle sofisticado de acesso presentes no Data Center, SOC e NOC.

  • Arquitetura  da Solução.

As Soluções ACCELOPS reúnem o que de  melhor existe em termos de arquitetura orientada a conectividade e a capacidade  de tratamento de grandes volumes de logs de eventos de dispositivos da  infraestrutura de TI, múltiplos protocolos de comunicação e uma grande  variedade de devices suportados incluídos no “core” da solução, dispensando a  aquisição adicional de licenças, devices, filtros ou aplicações destinadas à  integração, leitura e processamento de logs de devices (Arquitetura de  conectividade é inovadora e com patente pendente XML de leitura e processamento da estrutura de eventos de  base para analises, sem impactar na performance do processamento de eventos da solução como um todo).

As Soluções ACCELOPS Oferecem ainda interface  interativa e que lhe habilitam ao monitoramento de ambientes variados, distribuídos  e complexos e com alto volume de processamento de eventos da infraestrutura do Data Center, SOC e NOC e tudo isto  disponibilizadoatravés de um Único appliance Virtual  quando disponibilizado de forma (Site-central) ou em cluster (Multi-Sites) quando pode ser apoiado por coletores remotos que podem ser instalados  em filiais ou ambientes computacionais remotos / filiais / empresas coligadas.

 

Topologia – Site Único (Unico Data Center) ou Multi sites (Cluster contendo diversos Data Centers)

3-  Inovações AccelOps

3.1 – Priorizações Orientadas aos Serviços do Negócio / Serviços Prestados

ACCELOPS fornece uma  plataforma para o mapeamento rápido dos elementos de infraestrutura que compõem  os serviços que suportam os negócios (é possível identificar quais itens da  infraestrutura de TI estão vinculados a quais áreas de negócio da empresa), para  em seguida, analisar os problemas e impactos na  disponibilidade, desempenho e  segurança que estão ocorrendo e impactando em cada um destes componentes do negócio.

Isto permite uma melhor visualização  e priorização das ações de atendimento e resposta aos incidentes (Visão 360° do ambiente), ou seja, uma visão  integrada entre os componentes do negocio e a infraestrutura destinadas a lhe  oferecer suporte e operacionalização. Este rápido diagnóstico dos problemas possibilita um tempo maior de atividade aos serviços que são realmente  importantes para o negócio.

As informações de disponibilidade e performance são ainda possíveis de serem medidas, detalhadas  e demonstradas de acordo com os níveis de serviços praticados pela TI durante o  tratamento dos incidentes e o seu respectivo impacto real ao negócio (A solução possui centenas de relatórios de demonstração de serviços prestados, prontos para serem utilizados e que podem ainda ser facilmente customizadas pelo próprio usuário).

A existência destas informações  possibilita ao gestor da infraestrutura, redes e serviços de TI planejar e  monitorar o desempenho de sua infraestrutura e serviços disponíveis,   promovendo a  identificação das melhorias necessárias e/ou orientar  cada vez mais os seus esforços para execução de ações que efetivamente agregam  valor ao negócio.

Esta mesma funcionalidade (Visão de acordo com a  estrutura de Negócio), se aplicada pelos provedores de serviços de  infraestrutura, através da classificação das informações e visões para cada  cliente dos serviços prestados ou compartilhados, definindo de forma clara e  visual os níveis de disponibilidade, performance e segurança dos serviços prestados  classificados para cada um dos seus assinantes/inquilinos. Estas visões  integradas podem ainda ser  incorporadas aos produtos dos  assinantes/inquilinos e promovendo assim as ações de Governança / Transparência e demonstração  dos  serviços prestados (Versão da Solução para Service Provider).

 

Clique na Figura e saiba como !!

 

4-  Analise Comparativa – Atendimento  a Eventos e Incidentes

4.1 – Com o Uso de  Soluções Tradicionais

  • Cada  uma das soluções utilizadas apresentando a sua Visão parcial e  verticalizada dos eventos e incidentes,
  • Tempo de identificação dos eventos e de reação aos incidentes é via de regra  comprometido em virtude da necessidade de execução de reuniões técnicas,  War Rooms devido à dificuldade em identificar a causa raiz dos eventos e  incidentes entre as diversas verticais de serviços / equipes de suporte.
  • Visão  do ambiente é segmentada e limitada  as verticais ou grupos de Serviços /  Suporte ou por tecnologia, Múltiplas  Equipes de suporte e com Interesses e dificuldades especificas, visão 360°  do ambiente e parcial ou comprometida.
  • Dificuldade  em relacionar o uso dos ativos e serviços com a estrutura do negócio  (Quais ativos estão vinculados a cada segmento do negócio).
  • Dificuldade  em avaliar a amplitude do evento e o seu impacto no negócio, priorização  de chamados múltiplos, alocação da equipe no evento que mais tem impacto  no negócio.
  • Dificuldade  na obtenção de informações e cálculos de indicadores de disponibilidade e  performance para ativos e serviços que prestam suporte as unidades do  negócio.

4.2 – Com o Uso das  Soluções AccelOps

  • Monitoramento  convergente e integrado através de único painel de controle, integrações  promovidas automaticamente pelas funcionalidades da Solução AccelOps, possibilitam  a identificação da causa raiz, ativos e equipes de suporte que estão  diretamente relacionadas nos incidentes/eventos.
  • Tempo  de reação aos incidentes é otimizado através da identificação automatizada  da causa raiz dos eventos e incidentes, redução do tempo médio de  atendimento incidente, viabilização de atendimento dos SLA,
  • Apoio  as verticais de serviços / suporte através da disponibilização de  informações proativas,  gráficos  comparativos, analises de tendências,
  • Configurações  CMDB e suporte as atividades de Change management durante o atendimento  dos incidentes.
  • Proporciona  uma Visão 360° do ambiente do Data Center + SOC + NOC.
  • Mapeamento  da Disponibilidade, Performance, Segurança dos ativos e serviços  classificados de acordo com impacto a estrutura de suporte ao negócio  (Quais ativos e serviços são vinculados a quais estruturas e serviços de  suporte ao negócio).
  • Painel  de Indicadores On-Line / Real time da disponibilidade, performance e  Segurança de ativos e serviços, possibilitando a apuração de SLA’s de
    forma dinâmica e automatizada, Analises  de tendências e comparativas de dados históricos e  dados on-line, informações para calculo de Capacity Plan com base em dados históricos reais.

Com AccelOps, as equipes responsáveis elas operações de rede, administração de sistemas e aplicações têm agora uma visão unificada da disponibilidade da infraestrutura e performance de um componente e a visão de sob a perspectiva no serviço prestado ao negócio/estrutura de suporte aos elementos do negócio.

  • possibilita resposta às perguntas como:
    • O que os gargalos da rede,  falhas de equipamento, problemas de sistema e problemas de aplicação estão afetando os serviços de TI e o Negócio?
    • Quando e por que estão ocorrendo às interrupções,  degradação de performance e indisponibilidades?
    • Quais são as tempos de resposta de aplicações críticas do negócio e quais são as causas mais prováveis das perdas de performance?
    • Como é que o movimento de VM, falhas de hardware, patches e atualizações afetam o desempenho e tempo de disponibilidade dos
      ativos?
    • Os meus investimentos em tecnologia estão rendendo os resultados  esperados ?
    • Quais recursos podem ser otimizados, ou por consolidação ou por adição de capacidade?

5-  Relação de Devices Suportados pelas Soluções AccelOps – (Nativo):

Clique no corpo da Figura abaixo, para visualiza-la em tamanho Ampliado:

Fonte: (Transcrição do conteúdo Publicado Web Page AccelOps Inc.
em: (http://www.AccelOps.net/product/integration.php ).

6-  Programa de Avaliação  Técnica Soluções AccelOps

  • POC – Provas de Conceito e Testes da Aplicação –  ON-SITE

Caso você tenha interesse nas Soluções de BSM,  a AccelOps disponibiliza e realização de um POC – para execução de testes de avaliação e provas de conceitos da  solução em seu ambiente,  sem a  incidência de nenhum custo.

  • Requisitos necessários do sistema para a  versão de avaliação AccelOps:

A versão de  avaliação AccelOps é instalada como um dispositivo ou como um Appliance Virtual VMware.

  • Requisitos: Dois  núcleos 64 bits, 4 GB de memória e 8 GB de espaço no disco rígido.
  • Limitações:  pode descobrir 25 dispositivos, EPS: 20, e licença de trabalho por 14  dias.

Para isto, solicite informações e  instruções de como participar do Programa de Avaliação das Soluções AccelOps,  através do e-mail: consulting@aghatha.com .

  • Informações Adicionais e Vídeos de Demonstração das Funcionalidades Solução AccelOps

Você poderá ainda obter mais  informações sobre estas soluções em nossa web Page em http://www.aghatha.com/datacenter.htm

e http://www.aghatha.com/solucoes.htm, incluindo a  disponibilidade de vídeos adicionais, contendo  demonstrações de uso e funcionalidades da  Solução, telas e cases de sucesso.

  • Demonstrações / Reuniões Apresentação Ao Vivo em Português  – Via Skype

A Equipe técnica da AGHATHA poderá realizar demonstrações de  uso e navegação na Solução, através de Secções Compartilhadas de Vídeo através  de SKYPE, através do Endereço.  Aghatha.maxi.consulting.

Disponibilizamos o conteúdo deste artigo, contendo ainda tabelas comparativas, exemplos de Telas de Utilização do Sistema, Condições e Regras de Licenciamento através de um documento (PDF), caso desejar receber este documento através de email, envie e-mail de solicitação, informando seu nome completo, email e Razão Social de sua Empresa.

Agende a sua demonstração / reunião / Solicite documento completo através do e-mail  consulting@aghatha.com

Compartilhe este post:

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

Direitos de uso ou exploração  comercial do conteúdo deste artigo são preservados e mantidos em nome exclusivo  do autor, 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 para terceiros, o infrator estará  sujeito às penalidades previstas pela Legislação Brasileira de proteção a  propriedade intelectual e de direitos autorais.

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:

ACCELOPS ® , ACCELOPS PAM ®, ACCELOPS SIEM®, figuras utilizadas  neste artigo, sites, nomes e marcas registradas são de propriedade exclusiva AccelOps  Inc. – USA. (www.AccelOps.net ), sendo  Todos os direitos autorais reservados.

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 do Artigo / Traduções – é de propriedade exclusiva do  Autor e de AGHATHA (http://www.aghatha.com/index.htm  ) sendo  todos os direitos autorais preservados, incluindo a sua utilização e exploração  comercial em todo o território brasileiro e países de língua portuguesa.

DSS PCI ® é de propriedade exclusiva do PCI Security Standards  Council (https://www.pcisecuritystandards.org ), sendo  todos os direitos autorais preservados.

HIPAA ® – Health Insurance  Portability and Accountability Act (HIPAA) of 1996 (P.L.104-191) [HIPAA], foi  promulgada pelo Congresso dos EUA em 1996. Foi originalmente patrocinado pelo  senador Edward Kennedy (Democratas – Massachusetts) e Nancy senador Kassebaum  (Republicano – Kansas).

SOX – Sarbanes Oxley Act – foi  promulgada pelo Congresso dos EUA em 30 de julho de 2002, Foi originalmente patrocinado  pelo senador Paul Sarbanes (Democrata de Maryland) e pelo deputado Michael  Oxley (Republicano de Ohio).

Read Full Post »

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:

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

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

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

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

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

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

https://aghatha.wordpress.com/2012/05/24/como-implementar-processos-e-controles-para-o-compliance-de-ti-atraves-do-licenciamento-de-uso-de-um-framework-modularizado-e-contendo-documentos-processos-controles-e-workflow-para-cada-um-dos-padroe/

—–

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

 

Read Full Post »

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 :

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

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

—–

·       Agradecimentos e Convites:

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

Abraço e Felicidades a Todos,

Eurico Haan de Oliveira

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

———

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


———

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

Read Full Post »

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 :

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

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

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

—–

·       Agradecimentos e Convites:

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

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.


———

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

Read Full Post »

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:

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

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

———

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


———

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

Read Full Post »

Older Posts »

%d blogueiros gostam disto: