O dia em que o processo falhou

Para tudo na vida definimos algum tipo de processo. Processo pela definição literal do Aurélio, “é um conjunto de papeis relativos a um negócio” e que pode ser aplicado a qualquer tipo de seguimento de trabalho, software, administrativo, jurídico, etc.

Para Sommerville o processo de software consiste em atividades e informações associadas que são exigidas no desenvolvimento de um sistema de software (Sommerville, 2003). Logo uma das partes mais importantes para a correta definição e manipulação de um processo é a informação.

Tal informação é trafegada por diversas camadas e definidas pelas atividades que cada pessoa exerce no sistema. E o mais importante que em um processo de qualidade são as formas com as quais uma informação pode se transformar.

Depois de entender um pouco mais sobre processos, chegamos ao momento automatizar uma parte das atividades, tornando-as mais ágeis e menos suscetíveis a falhas. Uma automatização sempre se dá através de máquinas ou programas. Quando a automatização se processa através de software, deve-se pensar em primeira instancia nos papeis que os atores exercem em um processo, assim a definição do workflow da informação fluirá mais fácil. Vale ressaltar que o foco do processo sempre está direcionado a qualidade do andar do negócio, não se constrói falhas, furos ou mesmo lacunas no processo.

Na construção da automatização de um processo, pode-se escolher (comprar) frameworks já prontos onde pode-se utilizar ipsi litem, customizar esse framework ou mesmo criar um novo baseado no correto entendimento do negócio. Os passos básicos que não se pode faltar nesse framework são: Comunicação, Modelagem, a Construção e a implantação. Quando se constrói alguma coisa cujo negócio não faz parte do nosso dia a dia, devemos adotar a pratica da boa comunicação, uma boa comunicação pode eliminar falhas de entendimento o que pode causar conflitos, pode também gerar compromissos e se gerenciado por uma coordenação, estimula e intermédia a percepção dos interlocutores do processo e facilita a Cooperação nas tarefas executadas no processo. Esse modelo 3C (Figura 1) é detalhado em (Borghoff and Schlichter, 2000).

Se um processo for seguido sempre a risca, isto é, nunca há desvios, exceções ou falhas, nesses casos deve-se sempre mensurar, com periodicidade, a execução das atividades do processo de negócio. Quando se codifica um procedimento não há possibilidades de burlar, manipular, alterar o fluxo das atividades bem como as informações que são imputadas pelos atores do negocio. Essas medidas são eficazes, pois sempre a desvios do fluxo normal de uma atividade. Exceções acontecem, são esperadas, não são freqüentes, mas existem.

Construído, testado e implantado o processo automatizado vive seus dias em produção e passa a cada dia por provas que nem sempre foram levantadas em tempo de projeto.
Vejamos agora se esse processo automatizado for para um negocio de segurança predial. Há um fluxo de cadastro de pessoas, entradas de dados diversos, gerencia de informações, controle de hardware, liberações que dependem de cadastros x dados informados que podem estar relacionados com horários, estatísticas, periodicidade de entradas e diversas outras regras envolvidas nesse processo que aparentemente é muito simples: entrar com nome e CPF sair com a liberação de uma catraca.

Analisando em primeira instância, uma boa segurança patrimonial se torna morosa, pela quantidade de variáveis que devem se validadas para uma simples ação. Essa morosidade é compensada quando seus gerentes conseguem rastrear todas as informações de entrada e saída de pessoas em estabelecimento com processos automatizados. Em segunda instancia já identificamos uma falta de agilidade no processo quando, por exemplo, uma pessoa não cadastrada precisa entrar no estabelecimento para uma reunião emergencial e sua atuação é crucial para o negocio da empresa, mas como o processo é altamente seguro, exige um cadastro de pelo menos 24h de antecedência, a fim de liberar seu acesso.

Para esse tipo de problema a solução é bem simples:
1 – Criar o fluxo de exceção no sistema e fazer o redeploy;
2 – O Gerente do processo mandar entrar fora dos cadastros e fluxo de atividades descritos no sistema.

Mas é claro que a primeira solução é a mais recomendada. Pois com ela é possível a rastreabilidade das exceções que ocorrem no processo, porem essa solução se torna ainda mais morosa que o simples fato de liberar a entrada de uma pessoa às dependências da empresa. Agora imagina que essa segunda ação é tomada contra uma empresa de segurança patrimonial? O que pode gerar? Desconforto aos envolvidos, irritação por parte dos atendentes, a não correção do processo por aqueles que definem tais regras de acesso, tempo despendido para liberar o acesso até a tomada da ação.

Conclusão

Não se executa mais nenhuma tarefa sem que as informações sejam cadastradas, cruzadas, medidas e analisadas manualmente. Processos automatizados que não contemplam fluxo de exceções são geralmente mais lentos que os manuais, pois todo desvio num processo manual pode ser simplesmente contornado na hora, podendo não haver uma rastreabilidade desse desfio. Um processo que tem a cada passo um fluxo de exceção pode ser que não seja in totum seguro.

Para que um processo automatizado seja equilibrado, deve-se pensar em todas as alternativas cabíveis: quais atores irão utilizar o sistema, alguns fluxos de exceção que não altere a segurança, desempenho ou a modularidade do processo.

Referências:

Borghoff, U.M., Schlichter, J.H. 2000. Computer-Supported Cooperative Work: Introduction to Distributed Applications. Springer, USA

Sommerville, Ian. “Engenharia de Software”, Addison Wesley, São Paulo, 2003.