Feeds:
Posts
Comentários

Archive for the ‘IT Process Compliance’ Category

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 »

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

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

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

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

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

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

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

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

1.1 – Grupos de Despesas

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

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

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

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

Ex:

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

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

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

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

 

 2 –   COBIT – PO Planejamento e Organização

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

2.1 – Alinhando TI ao Negócio:

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

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

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

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

Ex:

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

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

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

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

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

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

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

Alertas:

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

2.2 – Arquitetura da Informação.

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

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

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

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

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

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

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

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

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

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

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

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

Alertas:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Alertas:

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

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

2.4 – Avaliar e Gerenciar Riscos

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

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

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

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

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

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

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

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

—- Fim Conteúdo Artigo —-

———

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

———

Outros Artigos Relacionados com este Assunto:

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

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

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

—–

  • Agradecimentos e Convites:

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

    Abraço e Felicidades a Todos,

    Eurico Haan de Oliveira

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

  • consulting@aghatha.com

———

Compartilhe este post:

  • Declarações de Direitos de Copyright

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

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

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

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

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

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

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

–———

Fim Declarações de Direitos de Copyright —

–———

Fim Artigo

Read Full Post »

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

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

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

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

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

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

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

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

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

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

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

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

2 – A Estrutura Física dos Documentos

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

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

documento_padrao_aghatha_framework

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

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

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

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

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

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

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

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

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

Descrição das Diretrizes de Uma Politica:

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

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

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

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

Descrição das Regras de uma Norma:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 – Controles da Documentação.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

—-

———-

·  Download do conteúdo deste Artigo :

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

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

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

  • Visite nossa Webstore :

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

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

  • AGHATHA Framework – Compliance Norma ISO-27002

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

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

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

———-

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

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

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

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

Framework Compliance Norma ISO-27002

———-

—- Fim Conteúdo Artigo —-

Agradecimentos e Convites:

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

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

Abraço e Felicidades a Todos,

Eurico Haan de Oliveira

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

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

———

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


———

———

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

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

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

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

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

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

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

– Fim Declarações de Direitos de Copyright —

— Fim Artigo

Read Full Post »

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

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

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

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

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

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

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

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

– Politicas:

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

– Normas:

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

– Procedimentos:

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

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

DICAS:

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

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

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

Outros Artigos Relacionados:

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

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

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

—- Fim Conteúdo Artigo —-

Agradecimentos e Convites:

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

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

Abraço e Felicidades a Todos,

Eurico Haan de Oliveira

Consultoria@aghatha.com.br

———
———

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


———

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

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

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

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

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

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

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

– Fim Declarações de Direitos de Copyright —

— Fim Artigo

Read Full Post »

Blog Oficial – Aghatha Maxi Consulting

aghatha_maxi_top_300_300

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

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

——–

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

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

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

O  leitor não é autorizado a utiliza-los, de forma integral ou parcial para usos e fins comercias e/ou em atividades que visem à obtenção de lucro ou benefícios comerciais de forma direta ou indireta para sí ou em favor de terceiros.

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

——–

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

 — fim declarações de Copyright —

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

Caso você tenha alguma dúvida ou necessidade de informações adicionais sobre qualquer artigo, conceitos ou conteúdos, entre em contato conosco através do e-mail abaixo.

Abraço e Felicidades a Todos,

Eurico Haan de Oliveira

www.aghatha.com.br

Consultoria@aghatha.com.br

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

Skype : aghatha.maxi.consulting

Skype : eurico.haan.de.oliveira

 

Read Full Post »

« Newer Posts