Gestão de Processos

Ξ Deixe um comentário

Os sete erros da modelagem – #3: Tudo junto e misturado

publicado por André Campos

Figura - Os sete erros da modelagem - #3: Tudo junto e misturadoJá pensou uma casa de um só cômodo, contendo ali o sofá, a TV, a pia, o fogão, o sanitário, a cama, guarda roupas, e tudo o mais que uma casa pode ter? Claro, não sou designer, mas penso que seria difícil entender e manter um ambiente desse tipo. A mesma coisa pode acontecer com os modelos de processos, e esse é um erro frequentemente cometido por modeladores menos experientes.

Por que isso acontece? Talvez pelo desejo de controle, de ver tudo ao mesmo tempo, o modelador faz um esforço enorme para colocar em um único diagrama o máximo possível de elementos notacionais. Em outras palavras ele tenta modelar tudo em um mesmo diagrama. O resultado? O diagrama mais se parece com um esquema de eletrônica do que um modelo de processo. Ninguém consegue entender. Depois de algum tempo de modelado, nem o modelador consegue!

Mas não é verdade que um dos principais objetivos de um modelo de processo é proporcionar a comunicação entre os vários atores que lidam com esse processo? Claro que sim. Então um modelo difícil de entender não passa de um trabalho enorme para construir algo que não será utilizado para nada. Não parece muito inteligente, não acha?

Então, como fazer? O que fazem os arquitetos ao construir uma casa? Eles projetam o espaço de acordo com o uso. Dentro desses espaços ficarão os móveis e facilidades exclusivamente relacionados a esse uso (é difícil imaginar um vaso sanitário na sala). Ainda, esses espaços não ficam entulhados, ou não deveriam. Vamos aprender com eles? Analise o modelo abaixo.

Model_Errado

Esse modelo contém 12 atividades, além de outros elementos notacionais. No mundo real, ainda outros elementos seriam adicionados, como objetos de dados, mensagens, atores internos e externos, etc. Nesse caso, a bagunça seria ainda maior. Mas ainda poderia piorar. O modelo poderia receber outras camadas de informação, como por exemplo, o conjunto de requisitos funcionais ligados às atividades, ou o conjunto de riscos ligados a essas atividades. Ou seja, a tendência desse diagrama seria ficar cada vez mais difícil de entender ao passo que fosse mais utilizado.

Então, vamos dividir os cômodos por assunto? Podemos perceber alguns assuntos diferentes naquele modelo inicial. Tem a compra propriamente dita, o recebimento do material, e o tratamento do material já dentro da organização. Podemos então modelar esses assuntos principais, que poderia ficar assim:

Novo_01

Isso já nos permite uma visão ampla e clara de tudo o que o nosso modelo pretende descrever. Essa visão abrangente é muito útil no apoio à compreensão, e é o tipo de diagrama que utilizamos em conversas com o alto escalão, com pessoas que não tem muito tempo para conhecer os detalhes de um modelo. Agora, a partir dessa visão do todo, podemos conhecer melhor as partes. Abaixo podemos entender como seria o processo COMPRAR.

Novo_02

Note que diversos pedidos são recebidos, provavelmente de diversas áreas da organização. Esses pedidos são agrupados por similaridade, por exemplo, e as cotações são feitas com os fornecedores. Com base nos critérios da organização um fornecedor é selecionado, e recebe autorização para emitir a nota fiscal e fornecer o produto. Mas o que acontece quando o material chega na organização? Isso se refere ao processo RECEBER, apresentado a seguir.

Novo_03

No processo acima, tudo começa com a chegada do material e com sua respectiva nota fiscal. O material é recebido e conferido. Se estiver tudo de acordo com o pedido, o material é estocado e o pagamento ao fornecedor é autorizado. Do contrário, o material é devolvido na hora.

Uma vez que o material está em estoque, ele pode ser solicitado por qualquer setor da organização. Isso se refere ao processo DISTRIBUIR, que é apresentado abaixo. Nesse caso, o material é separado e entregue ao solicitante.

Novo_04

Viu como ficou bem mais fácil de entender? Tudo bem, um diagrama foi transformado em quatro diagramas. Mas isso não é prejuízo algum. A sua casa também deve ser modularizada em cômodos. No caso do modelo, foi graças a essa modularização que tudo ficou muito mais simples, assim como em sua casa. Novas camadas podem ser adicionadas aos modelos e ele ainda continuará fácil de entender.

Uma vantagem importante é que os cada diagrama trata de um assunto e, portanto, será o foco da atenção apenas quando esse assunto em particular estiver sendo tratado. Quer dizer, não precisa ficar olhando e tentando entender aquele modelo com todos os assuntos quando for falar apenas de recebimento de materiais. Em engenharia de software esse benefício é conhecido como coesão, quando uma classe (em nosso caso um diagrama) trata de apenas um assunto. Isso facilita a manutenção e o reuso dos modelos. Então queremos alta coesão na modelagem de processos.

Outra vantagem importante é que quando separamos os modelos, eles se tornam mais independentes um do outro. Isso acontece porque cada modelo tem seu próprio início e seu próprio fim, recebendo as entradas necessárias e gerando os resultados para o qual foram criados. Em engenharia de software esse benefício é conhecido como baixo acoplamento, ou seja, baixa dependência entre as classes (em nosso caso, entre os diagramas). Isso quer dizer que podemos alterar cada diagrama individualmente sem gerar problemas para os demais, desde que as entradas e saídas de cada diagrama sejam respeitadas. Então queremos baixo acoplamento na modelagem de processos.

Agora que arrumamos a bagunça e colocamos cada coisa em seu lugar, lembre: alta coesão, baixo acoplamento e nada de fazer tudo junto e misturado.

[Crédito da Imagem: Modelagem de Processo – ShutterStock]

Autor

Doutor em Engenharia de Sistemas e Computação pela COPPE/UFRJ, Mestre em Informática pelo NCE/UFRJ, é também especialista em Gestão Estratégica de TI (UFRJ), Gestão Industrial (UFRJ) e em Segurança da Informação (UNESA). Com mais de 25 anos de atuação em Tecnologia da Informação, em suas diversas áreas, possui certificações Microsoft, ITIL, Auditor Líder BS 7799, e Security Officer (MCSO). É autor dos livros "Modelagem de Processos com BPMN" e "Sistema de Segurança da Informação - Controlando os Riscos". Nos últimos 10 anos concentra-se na relação da TI com o Negócio, em áreas como Governança e Gestão em TI, Engenharia de Software, e Segurança da Informação. Ainda, publicou o livro "Segurança da Informação - Controlando os Riscos".

André Campos

Comentários

You must be logged in to post a comment.

Busca

Patrocínio

Publicidade



Siga-nos!

Newsletter: Inscreva-se

Para se inscrever em nossa newsletter preencha o formulário.

Artigos Recentes