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

HOW TO DRAW BUSINESS PROCESS FLOWCHART

Part 1 – Introduction, Concepts and Models.

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

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

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

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

1 – Introduction to the processes study

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

1.1 – Process Basic Components 

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

1.2 – Quality Control between Process Components

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

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

Translating this in a more clear:

1.3 –  Inter-Process Quality Control

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

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

Translating this in a more clear:

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

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

Practical Example:

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

Translating this in a more clear:

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

2 – Standard  Symbology

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

They are:

3 – The  Model Structure of the Process Flowchart.

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

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

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

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

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

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

———-

Share This Post:

Related Articles:

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

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

Part 2 – Survey, Analysis and Design Business  Process.

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

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

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

· Download do conteúdo deste Artigo :

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

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

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

Thanks and Invitations:

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

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

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

Embrace and Cheers to All,

Eurico Haan de Oliveira

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

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

• We invite you to join our discussion group on Linkedin: https://aghatha.wordpress.com/aghatha_grupo_de_usuarios_ti/

———

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

———

Copyrights and Preservation of Rights Declaration:

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

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

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

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

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

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

– End of Copyright Bills of Rights –

– End Article

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

• http://www.aghatha.com/processos.htm ,

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

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

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

———-

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

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

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

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

• Siga-nos pelo Twitter, e receba comunicados de novos artigos e/ou revisões deste texto.
• Convidamos a participar de nossos Grupos de Discussão no Linkedin: https://aghatha.wordpress.com/aghatha_grupo_de_usuarios_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.

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 »