Quer muito mais?

Então não perca tempo. Continue nos acompanhando em Sistema Moderno, na seção de Blog.

Grande abraço.

Modelagem de processos: O que não devo fazer?

A modelagem de processos é muito relevante para estabelecer e melhorar a operação e controle das organizações, e mais do que isso, para viabilizar o atingimento dos objetivos estratégicos dessas organizações. Isso parece ser um consenso, considerando a abundância de consultorias e cursos sobre o tema, e o discurso dos líderes de praticamente todas as empresas modernas. Evidência adicional é a proliferação de ferramentas e notações para a modelagem de processos (veja o artigo anterior).

Mas a pergunta que fica é: será que eu estou preparado para responder a essa expectativa da empresa? E ainda outra: será que meu trabalho de modelagem de processos produz resultados efetivos, ou seja, possibilita de alguma forma a agregação de valor ao negócio?

Uma pergunta que antecede a essas seria: quem sou “eu”, que gerencio a iniciativa de gestão de processos? Pode ser a área de Tecnologia da Informação, mas também a área de Garantia da Qualidade. Em algumas organizações a iniciativa de gestão de processos é pilotada pela área de Recursos Humanos. Há ainda outras possibilidades, dependendo da estrutura organizacional e dos objetivos da organização com a gestão de processos.

O grande problema, muitas vezes é que, seja qual for a área, a iniciativa de gestão de processos se torna algo superficial e meramente formal. A organização e seus colaboradores não conseguem perceber o que a iniciativa gera em termos de resultados, e pior ainda, muitas vezes a consideram uma função cartorial e burocrática que mais atrapalha do que ajuda. Esse é um sintoma que precisa ser tratado imediatamente. Mas, por que isso acontece?

Pode ser que a equipe de modelagem de processos não esteja qualificada para construir modelos adequados. Não podemos confundir a habilidade de manipular uma ferramenta de modelagem de processos, como o BizAgi, com a habilidade para construir modelos claros e completos. As ferramentas de modelagem de processos são muito simples de se aprender, e em poucas horas alguém pode tornar-se especialista em tal ferramenta. Isso não torna essa pessoa apta a modelar processos.

Os modelos precisam ser devidamente estruturados em diferentes níveis, sendo que cada nível comporta um determinado grau de abstração da realidade. Por isso, esses níveis são chamados também de níveis de abstração. É impossível modelar um processo inteiro em um único nível, ou em um único diagrama. Mas, por impossível que seja, é exatamente isso que a maioria dos “modeladores” tenta fazer. Já tenho visto alguns modelos de processo que mais se parecem com aqueles esquemas de circuito eletrônico que os técnicos de rádio e TV utilizavam para consertar os aparelhos (ainda se faz isso?). Ou seja, o principal objetivo do modelo de processo, que é o de ser um elemento de comunicação, se perde.

O outro lado do problema é quando os “modeladores” constroem um modelo bem superficial, só com as principais atividades da organização. E dão um nome bonito, algo como “Modelo da cadeia de valor organizacional com vistas a melhoria contínua”, ou algo parecido. Para piorar a situação, é comum que essas chamadas “cadeia de valor” sejam mera reprodução do organograma da empresa. Isso quer dizer que o modelo, além de superficial, tem uma visão funcional e não por processos.

Essa questão da modelagem de processos com base em uma visão funcional é grave e altamente prejudicial. Há uma diferença muito grande entre as duas visões. Na visão funcional o escopo é meramente determinada área, seja um setor, um departamento ou uma divisão. Na visão por processos, o escopo é toda uma cadeia de atividades que geram um determinado resultado. E essa cadeia perpassa diversos setores, departamentos e divisões para atingir resultado esperado.

Ao modelar processos com uma visão funcional (isso é até um paradoxo) nos limitamos ao interior dessas caixas do organograma, e consequentemente aos micro problemas e micro oportunidades de melhoria. Ao modelar processos com uma real visão por processos, viajamos por todo o organograma, em uma sinuosa linha que nos levará ao resultado esperado para aquele processo. Assim, podemos observar problemas muito maiores, e também maiores oportunidades de melhoria, especialmente os problemas de interface e comunicação entre as áreas durante todo aquele processo que estamos modelando.

Um fenômeno também comum são os modelos de processo para sistema. Acho esse fenômeno muito interessante exatamente porque sou da área de Tecnologia da Informação, mais especificamente da Engenharia de Software. O que ocorre é que o pessoal de Sistemas decide fazer um modelo do processo de negócio antes de elicitar os requisitos do sistema. Aliás, essa é uma decisão muito sábia. O problema é que o modelo é feito pelo mesmo analista de sistemas que vai elicitar os requisitos. Por isso, o modelo acaba não sendo o do processo de negócio, mas sim do sistema que vai ser feito. Como o objetivo era modelar o processo de negócio exatamente para estabelecer o escopo do sistema e seus requisitos, não se obtém o resultado desejado porque já se modela o processo do sistema, do qual ainda não se definiu claramente o escopo e os requisitos. Parece o efeito Tostines invertido.

Esses são apenas alguns fatores que precisam ser considerados em uma iniciativa de gestão de processos. É fácil perceber que grande parte está na modelam de processos. E isso é fácil de compreender: para que haja toda a gestão é preciso explicitar os processos, o que é realizado através da modelam dos processos. Um bom trabalho de modelam de processos é um pré-requisito para um efetivo sistema de gestão de processos. Então, a chave do sucesso, é aprender adequadamente a modelar os processos. Isso não é tão difícil, mas certamente exige algum e empenho.

Procurei proporcionar uma visão introdutória e razoavelmente ampla sobre a modelam de processos nessa série de três artigos. Vimos a importância da modelagem de processos, a principais notações utilizadas, e os principais erros que não queremos cometer. Espero ter contribuído para motivá-lo a aprender mais e a seguir nessa interessante trilha que é o tema da modelagem de processos.

Modelagem de processos: Notações

A modelagem de processos é uma ferramenta fundamental para as principais estratégias modernas de gestão. Organizações pequenas, médias e grandes lançam mão desse mecanismo com resultados cada vez melhores. Esse artigo faz parte de uma série, e caso não tenha lido o anterior, por favor, faça isso agora: veja o artigo anterior.

Como vimos, a modelagem de processos utiliza uma linguagem que descreve o comportamento organizacional. Essa linguagem é também chamada de notação e, na realidade, existem diversas linguagens, ou notações, disponíveis para a modelagem de processos. Então, qual seria a melhor escolha?

Conhece alguma notação para modelagem de processos? Podemos citar algumas das principais, tais como diagrama de Petri, IDEF0, Aris, SPEM, e BPMN. Essas notações foram criadas em épocas diferentes, motivadas por conjunturas técnicas, políticas e econômicas diferentes e, portanto, com objetivos diferentes.

Porém, a notação BPMN merece especial destaque. Ela foi criada originalmente para a modelagem de processos de negócios, o que é descrito no próprio nome: Business Process Model and Notation. Apesar disso, e de ser relativamente nova se comparada às outras notações, ela tem se mostrado eficiente para modelar até mesmo processos mais específicos, como os processos de software. Neste caso, há pesquisas indicando que BPMN possivelmente se tornou mais eficiente para a modelagem de processos de software do que a própria notação SPEM, criada especificamente para este fim.

Uma das grandes forças da notação BPMN é sua expressividade e simplicidade. Não é preciso ser um especialista de determinada área para entender modelos feitos em BPMN. Imagine, por exemplo, um processo de compra. Veja como ele ficaria descrito em BPMN na figura abaixo:

É possível  notar como os atores ficam nitidamente descritos, e é muito fácil perceber quais são as responsabilidades de cada um deles. Também os insumos e produtos informacionais são representados de maneira simples e eficiente. Fica muito fácil compreender o processo, tanto para profissionais de modelagem e de TI, quanto para os demais colaboradores da organização.

Mas, além disso, a notação BPMN tem muito mais a oferecer. Talvez sua maior força esteja no fato de ser uma notação aberta. Isto significa que ela não é proprietária de uma determinada organização e, consequentemente, não é necessário pedir autorização ou pagar royalties para alguém se quiser construir uma ferramenta que utilize a notação. Mas qual é a vantagem disso?

Simples. Em primeiro lugar, graças a isso, dispomos de dezenas de ferramentas para modelam de processos com BPMN, inclusive muitas gratuitas e de alta qualidade, com é o caso da BizAgi (www.bizagi.com). Em segundo lugar, uma vez que todas as ferramentas obedecem ao mesmo padrão aberto, é possível exportar/importar modelos de uma para a outra. Isso significa que você pode começar um modelo em uma, exportar para outra, e continuar trabalhando nessa outra. Ou que você pode modelar em uma ferramenta e um colaborador à distância poderá receber seus modelos e trabalhar na ferramenta que ele quiser. Mais importante ainda, significa menor dependência dos fornecedores de ferramentas.

Mas os benefícios da notação BPMN não param por aí. Graças ao mesmo padrão aberto, outras ferramentas foram construídas, além das de modelagem. Isso inclui produtos para automação de workflow, simulação, análise estatística, entre outros. Em geral, esses produtos mantém total portabilidade entre si.

A maioria das organizações já está trabalhando suas iniciativas de modelagem de processos utilizando notação BPMN. E aquelas que ainda não estão, buscam capacitação e consultoria nesta área. O governo brasileiro, inclusive, estabeleceu a notação BPMN como obrigatória para todas as suas iniciativas em modelagem de processos, tanto as conduzidas com os profissionais da própria instituição quanto as conduzidas por consultorias. Exatamente por se tratar de um padrão aberto.

Eu, particularmente, já fiz grandes trabalhos em IDEF0 e em Aris, mas há alguns anos passei a utilizar a notação BPMN  em função dos argumentos abordados nesse artigo. Naturalmente, ainda há trabalhos sendo realizados em outras notações. Mas não custa nada se atualizar e conhecer essa notação que cresce tanto a cada ano.

Naturalmente, não temos espaço aqui para abordar cada uma das notações, e todos os detalhes envolvidos. De qualquer modo, consideramos os principais conceitos sobre notações, e mais especificamente sobre BPMN. Que tal por mãos à obra?  Baixe uma das ferramentas gratuitas de modelagem de processos com BPMN e pratique um pouco. Se ainda não precisou essa notação, logo, logo, precisará.

Em breve trataremos de outro assunto necessário e interessante sobre modelagem de processos. Não perca esta série de artigos sobre o assunto.

Modelagem de Processos: Por quê?

Platão, Freud, Moran, e Sócrates concordam: o autoconhecimento é a estrada para a conquista e a realização. Quem não se lembra da célebre filosofia de Sócrates – “Conhece-te a ti mesmo”? Isto tem sentido, pois sem sabermos o que somos não podemos identificar pontos fortes e fracos, e não podemos agir para melhorar.

Este mesmo princípio se aplica às organizações. Pequenas ou grandes, elas acabam se tornando complexas, com dezenas, centenas e até milhares de processos de trabalho. Ou seja, com as mais diversas formas de realizar as tarefas em seus departamentos, divisões e unidades. É uma enorme quantidade de conhecimento pulverizado por toda a organização.

O grande desafio está exatamente nesta diversidade e nesta pulverização. É difícil olhar para todo este conhecimento de maneira holística, sistêmica, e a partir disso identificar os potenciais a serem explorados e as vulnerabilidades e fraquezas a serem mitigadas. E o desafio aumenta, porque grande parte deste conhecimento está na cabeça dos colaboradores, e estas pessoas são mais ou menos acessíveis, e mais ou menos estáveis na organização. Quando um colaborador sai, leva consigo parte do conhecimento e inteligência organizacionais.

Podemos dizer que os processos constituem o comportamento da organização. As melhorias só acontecem quando este comportamento é corrigido ou ampliado. Então, precisamos encontrar uma forma de descrever, desenhar, representar este comportamento. Assim, é possível observá-lo, identificar os problemas e os potenciais, e sugerir as melhorias nos pontos certos. Tudo milimetricamente calculado.

É para isso que existem os modelos de processo. Assim como se constroem modelos de casas, aviões, estradas, entre outros, também é possível fazer um modelo dos processos organizacionais. Estes modelos pretendem capturar o comportamento organizacional de maneira tal que fique fácil fazer observações e promover melhorias.

A partir desta argumentação é possível compreender que a modelagem de processos está intimamente relacionada com o autoconhecimento organizacional (se é que podemos chamar de “auto”), e consequentemente com a melhoria e com a inovação. É importante destacar que, entre outras, uma dimensão de melhoria se dá na área tecnológica, tanto pela construção e implantação de tecnologias físicas da informação, quanto pela aquisição, construção, ou adequação de sistemas de informação.

Mas como é feita esta modelagem de processos? Como este conceito se materializa na prática? Estas perguntas, que você talvez esteja fazendo, são importantes, mas precisam ser respondidas com o cuidado que merecem. Posso adiantar que existem dialetos, ou notações, específicas para modelar processos, tais como IDEF0, ARIS, UML, BPMN e outras. Consideraremos esse tema em nosso próximo artigo.

Você faz a diferença positiva?

Fazer a diferença positiva é ser o elemento que somado ao estado atual das coisas resulta em um estado diferente e melhor. Já se perguntou se você é este elemento que agrega valor e gera vantagem competitiva em sua organização?

Talvez o primeiro passo para isso seja realmente acreditar nesta possibilidade. Infelizmente alguns profissionais caem na armadilha do conformismo, e começam a pensar que não há mais espaço para inovação em suas organizações. 

Uma vez o comissário do Departamento de Patentes dos Estados Unidos disse que “tudo o que poderia ser inventado já havia sido inventado”. Segundo Gordon Dryden e Jeannete Vos, este comissário, Charles H. Duell, teria dito isso em 1899. Tem ideia da enormidade de coisas que foram inventadas depois disso?

Outra armadilha é ficar preso ao próprio mundo, e não conseguir perceber o que se passa em sua volta. É provável que você seja um profissional de TI, mas o que o impede de conhecer outros mundos, outras áreas, de se apropriar de outros conhecimentos?

É bom lembrar que o inventor do filme Kodachrome era um músico (Leopold Godowsky), o inventor da lâmina de barbear descartável era um vendedor de tampas de garrafa (King Camp Gillette), e o inventor do pneu era um cirurgião veterinário (John Boyd Dunlop). Combinar conhecimentos de TI com os das demais áreas da organização contribuirá para a construção de algo novo, que represente diferença positiva.

Não é necessário descobrir uma coisa totalmente nova, uma tecnologia inexistente, ou um processo absolutamente inovador, para fazer a diferença. Vale lembrar que com mais ou menos 20 notas musicas é possível criar milhões de músicas, e que quase tudo o que há escrito no planeta foi criado com apenas 26 letras. Gordon Dryden disse também que uma ideia nova é na verdade uma combinação diferente de elementos antigos.

Que tal olhar a sua volta e identificar problemas que precisam de solução? Mas cuidado, porque as vezes os problemas estão lá por tanto tempo que já nos acostumamos com eles. Eles nem parecem mais problemas. Quebre padrões e paradigmas e descubra a raiz, a causa dos sintomas. Este será o verdadeiro problema a resolver.

Estabeleça hipóteses e possíveis soluções.  Que mudanças poderiam resolver o problema? É preciso aplicar tecnologia? Nem sempre é preciso. Lembre, a tecnologia é um poderoso remédio, mas não tente usá-la para curar todos os males. Pense diferente, abra a mente. Os problemas são cada vez mais complexos, e as soluções tendem a combinar diversos remédios diferentes que atuam de maneira sinérgica.

Comece pensando, idealizando, sonhando. ‘Se você pode sonhar com algo, então pode fazê-lo’ (Walt Disney). Para se chegar a um estado diferente é preciso desafiar o estado atual. Para que uma ideia nova se estabeleça, é preciso desafiar as ideias já estabelecidas. Talvez imaginemos que não podemos mudar o estado das coisas na empresa porque ela é resistente a mudanças. Mas é possível que não consigamos isso porque nós somos resistentes a mudanças, e a mudança deve começar dentro de nós mesmos, para depois contagiar o outro.

Qualquer um pode fazer a diferença positiva em uma organização. Que tal se essa pessoa for você? Então, just do it.

Software - Engenharia, Moda ou Arte?

Se você constrói software, então é engenheiro. Mas o engenheiro de software é um sujeito paradoxal, uma espécie de peixe voador, ou pássaro mergulhão. Nada contra estas espécies, mas o nome deles já é um contrassenso. Me lembra um pouco o engenheiro de software. A palavra "engenharia" nos remete a prédios, máquinas, aviões, navios e coisas assim, diria, um tanto 'hard'. Mas o nosso engenheiro constrói 'soft'.

É claro que, como engenheiro de software que sou, aprecio os benefícios possíveis a partir do exemplo das outras engenharias, como a medição de prazos e resultados, a capacidade de simulação e previsão, a gestão dos recursos, entre outros. Essas similaridades são interessantes e podem nos ajudar a avançar. Me preocupam mais, no entanto, as diferenças. Que diferenças? Ah, já vou dizendo.

Uma importante diferença tem a ver com as ferramentas que utilizamos. Neste aspecto a engenharia de software está mais para a Moda do que para a Engenharia. Engenheiros tendem a exigir elevadíssimo nível de confiabilidade de suas ferramentas e materiais, especialmente quando se trata de construções críticas. Já pensou como seria a construção de uma usina nuclear com uma ferramenta que o primo do engenheiro descobriu em uma viagem que fez à Tailândia, e que ele achou super legal? Ou a construção de um foguete com uma chapa metálica recém inventada, que é o maior sucesso na indústria de carros? Pode parecer absurda a ideia, mas muitas vezes é exatamente o que faz o engenheiro de software.

Ao passo que as outras engenharias utilizam ferramentas e materiais amplamente testados e aprovados em rigorosos e demorados testes, que as vezes duram anos, o engenheiro de software usa o Python porque é bom a beça. O Java porque todo mundo tá usando. O Asp.Net porque é sofisticado e dá status. O PHP porque é facilzinho. Ou seja, como eu disse, está mais para a Moda do que para a Engenharia. Não digo que estas tecnologias são ruins ou boas, digo que a decisão por uma delas é geralmente feita da maneira mais ametódica possível. Há ainda aqueles que tratam a tecnologia como religião (nasci nela e vou morrer nela) e outros como time de futebol (tô torcendo pra minha ser campeã).  E aí, pra esse último, vale tudo: camiseta, boné, xícara, tudo com o nome da tecnologia pela qual ele torce. Eu ficaria muito preocupado de contratar um engenheiro com esse comportamento, pois como saber se ele está escolhendo a tecnologia mais adequada ao meu projeto, ou se está escolhendo a sua "tecnologia do coração"?

Outra importante diferença está relacionada ao produto que o engenheiro de software entrega. Colocar um avião em produção ou uma ponte pra operar, sem os devidos testes, pode levar o engenheiro para a cadeia. Entre os testes estão as mais diversas técnicas, inclusive simulações, que não se deixam abalar pela sempre presente pressa do cliente. Já na área de software, é muito comum ver em produção um sistema que sequer passou por uma equipe de testes; foi testado pelo desenvolvedor mesmo (se é que foi). Alguns usuários já até se acostumam com os erros e inventam maneiras de conviver com eles. E o desenvolvedor geralmente fica irritando quando alguém reclama. As duas respostas mais comuns são: 1) Estranho... e 2) Na minha máquina tá funcionando.

O caro colega engenheiro de software, a esta altura, deve estar irritado. Calma, também sou engenheiro de software, e sei que não gostamos de ouvir críticas. Quando alguém fala mal de nossos métodos e sistemas chegamos perto de perder o controle. Nossos sistemas são como filhos para nós, e não queremos ouvir ninguém falando mal deles. Neste caso estamos mais para o mundo das Artes do que da Engenharia. Somos artistas genais, os outros é que não conseguem entender nossa obra.

Que tal nos aproximarmos das engenharias tradicionais, mais velhas e mais sábias? A academia tem grandes estudos, muito experimentos, que podem ser uma pista do caminho a tomar. Há métodos de testagem disponíveis, que devem melhorar significativamente a qualidade do produto que entregamos. E por fim, vamos ouvir mais e falar menos. Afinal, temos dois ouvidos, apenas uma boca, e o cliente sempre tem razão.

Modelagem de processos - Começando com BPMN

A modelagem de processos é uma etapa fundamental da gestão de processos, e talvez a mais famosa. Nela nós observamos a realidade e tentamos representá-la, ou seja, criar um modelo a partir dela. Note que o modelo da realidade possui uma complexidade muito menor do que a própria realidade, e essa simplificação nos permite uma observação mais clara e mais objetiva.

De maneira similar, um escultor ou um pintor podem construir um modelo ou representação da realidade. Esses modelos são mais simples do que a realidade. Por exemplo, a pintura de uma mulher apenas a representa, é por mais bela que seja a obra não pode carregar a complexidade da textura da pele, dos cabelos, dos pensamentos ou da emoção da mulher que representa. Mas é suficiente para permitir observar a mulher em um determinado ponto do tempo (assim como a fotografia).

O modelo do processo apenas o representa, e apesar disso, já é o suficiente para proporcionar uma série de benefícios. Permite compreender melhor o processo, as pessoas que o executam, os dados produzidos e consumidos, os clientes atendidos, as decisões tomadas, entre diversas outras informações. A partir disso, é possível monitorar estes processos, pensar em melhorá-los parcial ou integralmente, extrapolar a operação do processo para outros ambientes ou para outras dimensões, verificar se há pessoas e competências adequadas  para a execução deles, entre muitas outras coisas. Veja este pequeno exemplo:

Seria um exemplo de processo de desenvolvimento de software. É muito bom para ter uma boa ideia de como as coisas acontecem, mesmo não chegando a apresentar os detalhes. E já nos permite observar uma oportunidade de melhoria: que tal fazer testes e validações no software desenvolvido, antes de implantar? Fazer isso seria uma melhoria promovida no processo de software a partir de seu modelo. Mas é possível fazer muito mais ainda a partir de um modelo.

Talvez você esteja com algumas perguntas, como: Como começo a modelar? Que caminho seguir? Como chegar a um nível maior de detalhes? Onde estão as decisões? Como representar dados e documentos? Como representar as pessoas que executam as atividades?

Bem, é muita coisa pra tratar em um post apenas. Mas prometo que vamos ver tudo isso por aqui, ok? E trabalharemos sempre com a notação BPMN. Não perca os próximos posts. Nos vemos por aqui.