Evoluindo Processos com o Modelo de Decisão - Brigadeiros da Nice (Parte 3)

Nesta última parte desta série, vamos mostrar como a modelagem de decisões pode simplificar significativamente os modelos de processo, tornar mais clara a lógica de negócio que os governa, e facilitar a evolução dos processos da organização. Esta série de posts é baseada no processo de negócio da Brigadeiros da Nice (uma excelente apresentação dos conceitos de modelagem de decisão criada e apresentada por Fabrício Laguna, da Gigante Consultoria, de SP).

No post anterior discutimos o impacto que umas poucas mudanças na lógica do negócio pode ter sobre o tamanho e a complexidade dos modelos de processos puros. Agora, vamos ver como as mesmas mudanças são tratadas de forma muito mais simples quando aplicamos os conceitos da modelagem de decisões, utilizando a metodologia TDM (The Decision Model), criada por Barbara von Halle e Larry Goldberg, da KPI.

Primeiramente, retiramos do modelo de processo original todas as atividades que tem a ver  com a lógica do negócio, e as substituímos por "tarefas de decisão" (isto foi mostrado no primeiro post desta série). O modelo de processos resultante é mostrado abaixo:

Clique na imagem para ampliar

Para atender às alterações na lógica de negócio que a Nice determinou para a avaliação da viabilidade de entrega dos pedidos e determinação da taxa de entrega, fazemos pequenas modificações neste processo, que fica assim:

Clique na imagem para ampliar

Basicamente, as modificações realizadas são:

• incluir uma decisão que determina se o cliente é VIP, pois clientes VIP não pagam taxa de entrega
• incluir uma decisão para calcular a taxa de entrega, e verificar sua aceitação pelo cliente
• o restante do processo permanece inalterado

Como isto é possível? Simplesmente porque as únicas modificações necessárias no processo são as novas atividades necessárias para verificar a aceitação, pelo cliente, da taxa de entrega. Todo o restante são alterações na lógica do negócio e, portando, são incorporadas aos modelos de decisão correspondentes. Vejamos como ficou a decisão Determinar aceitação do pedido:

Aqui, fica claro que a única mudança é a inclusão de uma nova condição para determinar a viabilidade da entrega de acordo com as regras estabelecidas pela Nice. As tabelas de Famílias de Regra necessárias para isto são estas:

Para o cálculo da taxa de entrega criamos um novo modelo de decisão e as tabelas de Família de Regra correspondentes:

Clique na imagem para ampliar

E, finalmente, alteramos o modelo de decisão que calcula o valor do pedido para adicionar a taxa de entrega devida:

E é isto! Devido ao desacoplamento entre a lógica do negócio e as tarefas do processo, e ao alto nível de reaproveitamento e isolamento dos modelos de decisão, as modificações estabelecidas pela Nice foram implementadas rapidamente, sem impacto significativo no modelo de processo, e mantendo a clareza e a facilidade de manutenção e evolução que são característicos da aplicação da modelagem de decisão aos processos. Notem que os modelos de decisão e tabelas de Família de Regra não mostrados aqui foram mostrados no primeiro post e permanecem inalterados.

Com isto terminamos esta série de posts baseados no caso Brigadeiros da Nice (que, agora, pode continuar crescendo seu negócio com agilidade). Dúvidas? Perguntas? Comente aqui ou entre em contato com a Centus. Será um prazer conversar com você.
______________________________________________________________________________
Para conhecer mais sobre o Modelo de Decisão, e como ele pode ajudar as organizações a tornarem seus processos mais ágeis, visite o site da Centus e acesse dezenas de artigos, apresentações e webinares sobre modelagem de decisão e arquitetura corporativa.

Evoluindo Processos com o Modelo de Decisão - Brigadeiros da Nice (Parte 2)

No nosso post anterior mostramos como o processo de negócio da Brigadeiros da Nice (uma excelente apresentação dos conceitos de modelagem de decisão criada e apresentada por Fabrício Laguna, da Gigante Consultoria, de SP) se torna muito mais simples e fácil de ser compreendido quando associamos a modelagem de decisão com a modelagem de processos. Agora, vamos discutir como a modelagem de decisão pode facilitar de forma significativa a melhoria e a evolução dos processos de negócio de qualquer organização, desde as mais simples, como uma doceria, até as mais sofisticadas, como grandes instituições financeiras.

Primeiramente, vamos imaginar que a Doceria da Nice continuou fazendo um tremendo sucesso, mas que o crescimento começou a trazer alguns problemas operacionais: com o aumento das encomendas, as dificuldades com o processo de entrega dos brigadeiros também cresceram na mesma proporção. Muitas pessoas que moram muito longe da casa de Nice começaram a fazer pedidos de brigadeiros, e ela não tem como entregar os brigadeiros em todos os lugares. Mesmo quando é possível entregar, o custo de entrega é alto e é necessário cobrar um adicional de entrega por pedido para compensar os custos do transporte.

Para resolver estes problemas a Nice definiu algumas regras de negócio relativas à forma e ao custo de entrega dos pedidos, como podemos ver abaixo:

• pedidos de pessoas que residem acima de 20 km da casa da Nice não serão atendidos, a não ser que a pessoa se disponha a buscar o pedido
• para os pedidos aceitos e que serão entregues pela Nice, as seguintes regras serão adotadas:
• para distância até 1 km a entrega será grátis, de bicicleta, se a quantidade for menor que 200 brigadeiros
• para distância até 20 km a entrega será feita por motoboy, com taxa de entrega de R$ 10,00, se a quantidade for de até 500 brigadeiros, ou se a entrega for à noite
• para distância até 20 km a entrega será feita por taxi, com taxa de entrega de R$ 20,00, se a quantidade for superior a 500 brigadeiros, ou se estiver chovendo
• se o cliente não concordar com as taxas de entrega, ou não puder buscar os brigadeiros, o pedido não será aceito.
• A D.Creusa continuará sendo atendida em qualquer situação (a Nice é eternamente grata a ela por tê-la incentivado a entrar no ramo dos brigadeiros!), ou seja, ela será atendida mesmo se morar a mais de 20 km da casa da Nice, não pagará a taxa de entrega, e nunca será atendida por bicicleta.

Primeiramente, vamos mostrar como estas mudanças nas regras do negócio seriam modeladas se estivéssemos trabalhando apenas com modelos de processo. Uma vez que agora o cliente tem que aprovar a taxa de entrega ANTES do pedido ser aceito, temos que calcular os valores da taxa de entrega e do valor do pedido durante o processo de aprovação do pedido:

Clique na imagem para ampliar

Notem como mesmo uma pequena alteração no processo, destinada a avaliar a viabilidade de entrega (usando relativamente poucas condições) já aumentou consideravelmente a complexidade do modelo. Além disto, não estou levando em consideração, aqui, questões como o tempo gasto para desenhar um modelo "limpo" (compreensível, completo e semanticamente correto), as inúmeras formas como este processo poderia ser modelado (se você acha que tem uma solução melhor, envie para a Centus! será interessante comparar as diversas soluções possíveis), ou o tempo gasto para verificar se a lógica está correta (o que implica em "seguir o fluxo" de forma manual). Aqui, também, usamos indicações de regras de negócio para indicar as fórmulas de cálculo, em uma tentativa (ineficaz) de simplificar o processo.

Agora, a título de exercício, imaginem se a Nice resolvesse ter um número maior de tipos de cliente, ou outras formas de entrega. Fica evidente o aumento no tamanho, complexidade e dificuldade de manutenção deste modelo de processo, e que a evolução e manutenção do modelo ficará cada vez mais difícil. Começaram a perceber porque a modelagem da lógica do negócio através de modelos de processo pode resultar em modelos que são impossíveis de serem manejados?

No próximo post vamos apresentar a solução deste problema, usando a modelagem de decisão para tornar este processo mais simples e mais fácil de ser modificado e, por consequência, mais ágil. Enquanto isto, mandem seus comentários e apontem os eventuais erros de modelagem (não sou CBPP!) e melhorias possíveis neste processo.

______________________________________________________________________________
Para conhecer mais sobre o Modelo de Decisão, e como ele pode ajudar as organizações a tornarem seus processos mais ágeis, visite o site da Centus e acesse dezenas de artigos, apresentações e webinares sobre modelagem de decisão e arquitetura corporativa.

Evoluindo Processos com o Modelo de Decisão - Brigadeiros da Nice (Parte 1)

Em 01 de Agosto de 2014 Fabrício Laguna, da Gigante Consultoria, publicou em um pequeno vídeo explicando de maneira lúdica e simples como a divisão entre os processos e as regras de negócio pode ajudar bastante a simplificar e gerir organizações. Por razões de clareza e facilidade de entendimento, tanto os modelos de processo como os modelos de decisão (regras de negócio) foram apresentados sem preocupação com o formalismo das notações BPMN e TDM que seriam aplicados em um caso real. Para aqueles que se interessarem em ver a modelagem formal deste caso, apresento aqui os modelos completos usando as notações BPMN para processos(*) e TDM para as decisões.

O processo parece simples: a Nice recebe o pedido do Cliente, verifica sua validade e decide se aceita ou não o pedido. Se o pedido for aceito, ela calcula o preço, fabrica o pedido, entrega e recebe o dinheiro. As regras de negócio que serão modeladas são as seguintes:

• exceto para a D. Creusa, todos os pedidos devem passar por uma análise de viabilidade
• para a D.Creusa os pedidos são sempre atendidos, e o preço é R$1,30/brigadeiro
• para os demais clientes, o prazo de entrega é de pelo menos 1 dia, a quantidade deve ser entre 100 e 1000 brigadeiros, e o cliente, se já comprou anteriormente, deve ser bom pagador, e se não comprou, deve ser indicado; para estes clientes o preço é R$1,60/brigadeiro

Vamos ver, então, como fica este processo quando nós o modelamos usando a notação BPMN:

Clique na imagem para ampliar

Agora, podemos ver todas as regras que a Nice estabeleceu para decidir se aceita ou não o pedido e para calcular o valor a ser pago pelo Cliente (representado como regras de negócio). Aqui, nós podemos analisar uma primeira característica da modelagem da lógica do negócio como se fosse um processo: a imposição de uma sequência às condições! Modelado na mesma sequencia em que foi descrito pela Nice, a decisão de aceitar ou rejeitar o pedido primeiro testa se o Cliente é a D.Creusa. Se for, o pedido será atendido; se não, o processo segue testando se a quantidade está entre 100 e 1000, se o prazo de entrega é superior a 1 dia e assim por diante, rejeitando o pedido se cada uma das condições não for satisfeita. 

Mas por esta sequencia é necessária? Não poderíamos fazer as mesmas perguntas em qualquer sequência (por exemplo, verificando o prazo de entrega ANTES de verificar a quantidade do pedido)? A resposta é SIM! A sequência das condições para decidir a aceitação ou não do pedido é irrelevante. Na prática, esta imposição de uma sequência específica, desnecessária, é uma das principais desvantagens do uso de modelos de processo para descrever a lógica dos negócios. O Modelo de Decisão elimina esta deficiência!

Outro ponto de atenção é o uso de regras de negócio para indicar a fórmula de cálculo do valor do pedido. Esta é uma prática bastante comum, mas ela não muda o fato de que o uso de regras de negócio não elimina a expressão da lógica do negócio através de atividades e gateways espalhados pelo processo. Em resumo, mesmo usando regras de negócio, a lógica do negócio continua "enterrada" no processo, difícil de ser mantida (mais sobre isto no próximo post) e compreendida, sem a simplificação prometida.

Através da aplicação dos conceitos da modelagem de decisão, o processo é significativamente simplificado, e a lógica para decidir a aceitação ou não do pedido, e o cálculo do valor do pedido, são modelados como tarefas de decisão (um tipo de tarefa BPMN 2.0 normalmente associado a tabelas de decisão):

Clique na imagem para ampliar

A mágica acontece quando, agora, modelamos estas tarefas de decisão utilizando o Modelo de Decisão (TDM). Vejamos primeiro a decisão de Determinar a Aceitação do Pedido:

Clique na imagem para ampliar

Aqui, vemos a Estrutura do Modelo de Decisão. Este diagrama mostra, através do octógono azul, qual é a decisão que está sendo modelada e, abaixo, as Famílias de Regra (condições) que estão sendo consideradas pela lógica da decisão. É importante notar que não existe nenhuma sequência implícita no diagrama, ou seja, podemos avaliar esta decisão de cima para baixo, de baixo para cima, pela esquerda ou pela direita. O diagrama mostra que a aceitação do pedido depende das condições "Tipo de Cliente" e "Vale a pena". A primeira condição é determinada (inferida) a partir do "Perfil do pagador", que por sua vez depende da informação se o Cliente já comprou e se pagou no prazo, e do nome do Cliente (para saber se é a D.Creusa). Para concluir se "Vale a Pena", é necessário avaliar a "Quantidade Pedida" e o "Prazo do Pedido".

Mas, vocês devem estar se perguntando, onde estão as Regras de Negócio, ou seja, os valores das condições e os valores da conclusão de cada Família de Regra? A resposta é simples: elas estão em um outro tipo de artefato do Modelo de Decisão, as Tabelas de Família de Regra. No diagrama acima temos quatro Famílias de Regras e, portanto, teremos quatro Tabelas de Família de Regra:

Clique nas imagens para ampliar

Para o cálculo do valor do pedido precisamos modelar uma nova decisão, chamada "Calcular Valor do Pedido", com as respectivas Tabelas de Família de Regra:

Clique nas imagens para ampliar

Notem que não precisamos definir novamente como determinamos o "Tipo do Cliente", pois esta Família de Regra já foi definida anteriormente (na realidade, nem precisaríamos mostrar a Família de Regra "Perfil do Pagador" no diagrama). Isto demonstra como a modelagem de decisão possibilita e estimula o reaproveitamento dos modelos e das regras de negócio associadas de forma natural, o que não acontece quando modelamos a lógica do negócio através de modelos de processo.

No próximo post vamos explorar o que acontece quando a Nice resolve adicionar um conjunto de regras de negócio para tratar da lógica de entrega dos pedidos de brigadeiro.

_______________________________________________________________________________

Para conhecer mais sobre o Modelo de Decisão, e como ele pode ajudar as organizações a tornarem seus processos mais ágeis, visite o site da Centus e acesse dezenas de artigos, apresentações e webinares sobre modelagem de decisão e arquitetura corporativa.

(*) Para aqueles leitores certificados BPMN (eu não sou!): se houver algum erro na notação ou na modelagem, favor me avisar através do email info@centus.com.br

Engenharia de Requisitos - Uma introdução

A Engenharia de Requisitos se ocupa, principalmente, das atividades de Engenharia de Sistemas relacionadas a descobrir, organizar e documentar requisitos de sistemas. Ela busca encontrar soluções para um ou mais problemas que afetam uma organização. Neste processo, duas abordagens são usadas: visão orientada para o problema, que foca no entendimento dos problemas reais, e visão orientada para a solução, que foca no desenho e seleção de alternativas de solução.

Engenharia de Requisitos Orientada para o Problema

A engenharia de requisitos orientada para o problema se origina na engenharia de sistemas e envolve investigar e documentar um domínio do problema. Dentro desta visão o engenheiro de requisitos descreve as situações problemáticas que estão sendo experimentadas, as relações entre estas situações, porque elas são vistas como problemáticas e quem é afetado por ou vive estes problemas.

Uma técnica comum dentro desta visão é a Engenharia de Requisitos Orientada para Objetivos (GORE-Goal-Oriented Requirements Engineering). Esta técnica elicita os objetivos das partes interessadas relevantes para endereçar seus problemas e preocupações. Estes objetivos definem o que uma parte interessada deseja atingir, ao mesmo tempo em que se abstrai do como isto pode ser feito, e por quem.

Os objetivos capturados capturam a razão de ser para a solução que deverá ser desenhada para atingir os objetivos e, assim, resolver os problemas identificados. Como preparação para o desenho da solução, os objetivos podem ser decompostos em objetivos menores e mais concretos, que possam ser realizados de forma mais fácil e direta. Isto resulta nas chamadas árvores de objetivos.

A engenharia de requisitos orientada para objetivos permite uma série de análises. Primeiro, ela facilita estabelecer a motivação e a justificativa para os objetivos e suas soluções. Através de técnicas de modelagem podemos analisar e demostrar que objetivos motivam outros objetivos e que elementos de uma arquitetura empresarial realizam estes objetivos. Segundo, a engenharia de requisitos orientada para objetivos suporta a modelagem e análise do quanto um objetivo contribui positiva ou negativamente para - ou mesmo conflita com - a realização de outros objetivos.

Engenharia de Requisitos Orientada para a Solução

A engenharia de requisitos orientada para solução representa uma abordagem mais tradicional da visão da engenharia de software em relação aos requisitos. Nesta visão a engenharia de requisitos é vista como uma especificação de uma solução. O engenheiro de requisitos especifica o contexto no qual o sistema irá operar, produz uma lista de funções do sistema requeridas ou desejadas, define a semântica destas funcionalidades (requisitos funcionais) e produz uma lista de atributos de qualidade para estas funcionalidades (requisitos não-funcionais).

Soluções alternativas podem ser propostas pelo engenheiro de requisitos. Por exemplo, configurações diferentes do sistema podem ser propostas para suportar diferentes atributos de qualidade da solução. Estas alternativas são analisadas com base em diversos critérios para selecionar aquela que oferece a melhor solução.

Técnicas comumente usadas nesta visão são baseadas na Análise Estruturada e na Análise Orientada para Objetos. A análise estruturada foca no fluxo dos dados através do sistema sendo construído, normalmente através do uso de Diagramas de Fluxo de Dados (DFD). A análise orientada para objetos aplica técnicas de modelagem de objetos para analisar os requisitos funcionais do sistema em construção. Uma técnica importante na análise orientada para objetos é a elicitação e especificação de Casos de Uso. Casos de uso capturam o comportamento da solução em termos de cenários das interações entre o sistema e os seus usuários.

Cadeia de Problemas

As duas visões da Engenharia de Requisitos, orientada para problemas e orientada para soluções, podem ser consideradas como duas fases consecutivas e complementares. Iterações destas fases podem ser aplicadas para endereçar um problema de forma progressiva, isto é, em múltiplas iterações. A partir desta perspectiva nós identificamos o que chamamos cadeia de problemas, onde cada elo conecta um problema com a sua solução, que por sua vez é considerada novamente um problema para o próximo elo. Por exemplo, um analista de negócios pode investigar um problema de negócio e especificar uma solução de negócio para este problema. Esta nova solução pode requerer o suporte da TI, na forma de um sistema novo ou modificado. Este sistema se torna, então, um problema para o Analista de TI. Ao mesmo tempo, a solução de negócio original pode dar origem a outros problemas de negócio, e assim sucessivamente.

Em um próximo artigo vamos explorar como estes conceitos são tratados pela Arquitetura Empresarial.

Fonte: Business Requirement Management Copyright 2010 BiZZdesign Academy

Quando é importante automatizar uma decisão?

A maioria das pessoas é capaz de identificar uma decisão quando vê uma. Ela tem um problema pela frente, determina que fatores devem ser levados em consideração para resolver o problema, levanta os dados que irão suportar sua decisão, e finalmente faz uma escolha entre as diversas alternativas que estão sendo consideradas. 

"Uma decisão é tomada com base em valores de fatos de condições que levam à escolha do valor do fato de conclusão, tomado entre os valores alternativos disponíveis."

Nós tomamos centenas de decisões, todos os dias: que roupa vestir, o que comer, que caminho seguir para o trabalho, que coisas comprar, e assim por diante. As organizações tomam milhares de decisões todos os dias, em todos os níveis hierárquicos: qual o preço da oferta de um produto, que empregados selecionar para uma tarefa, quanto pagar por um insumo, que fornecedores selecionar para fornecer um material ou serviço, que transportadoras utilizar para um dado pedido de venda, que impostos incidem sobre uma venda, e qual o seu valor, e assim em diante.  

Mas não basta saber que as decisões existem e que elas acontecem espalhadas por toda a organização. É necessário estabelecer orientações para quem irá tomá-las, entender quais as condições que devem se avaliadas e quais as opções de conclusão que podem ser escolhidas. Em muitos casos as decisões são total ou parcialmente automatizadas e, neste caso, é necessário estabelecer os critérios para decidir que decisões valem o esforço despendido para a sua automatização.      

Antes de mais nada, é importante entender que as decisões existem na organização independente de sua automatização ou não. Decisões manuais são feitas por pessoas, com ou sem o auxílio de sistemas informatizados. Uma organização que possua um sistema de aprovação de pedidos que mostra em uma tela as informações relativas à situação de crédito do cliente (limite de crédito, saldo em aberto e em atraso, avaliação externa de crédito, etc.) e registra a decisão de um analista de crédito (aprovado, não aprovado) não está, efetivamente, automatizando esta decisão. Ela continua sendo uma decisão manual!

Traduzindo este conceito de uma forma bem direta: Decisões automatizadas são tomadas pelos sistemas SEM a interferência direta de qualquer pessoa ou processo manual.

Decisões automatizadas são particularmente críticas quando é difícil, ou não-econômico, para que pessoas possam se manter atualizadas em relação às condições e valores de condição e de conclusão que uma decisão exige, ou processar este volume de informação em tempo hábil para manter o processo onde esta decisão se insere ágil e eficiente. Tipicamente, decisões com as características abaixo são candidatas naturais à automatização:

• Existe um grande número de regras de negócio (condições) que devem ser avaliadas em curto espaço de tempo
• As regras de negócio mudam com frequência em função de:
• mudanças nas políticas ou na legislação
• as regras são dependentes do momento da aplicação (descontos sazonais, por exemplo) ou da localização geográfica (impostos e taxas locais, por exemplo)
• As regras mudam com frequência em função de variáveis do mercado ou da estratégia da empresa (preços diários - ou horários - em supermercados, por exemplo), tipo de cliente, custos de frete, etc.
• As regras devem ser disseminadas e entendidas por um grande número de pessoas, possivelmente em localizações geográficas diferentes e com níveis de treinamento e entendimento variado

Como decidir que decisões devem ser automatizadas?

Nem todas as decisões são necessariamente adequadas para automatização. As decisões que melhor se prestam à automatização possuem as seguintes características:

• A decisão é repetível
  • Existe um padrão que deve ser seguido para a tomada da decisão e que pode ser automatizado
• A decisão é não-trivial
  • É importante que os benefícios de tornar a tomada da decisão mais acurada, rápida ou confiável sejam maiores que o custo de sua automatização
• O processo ou evento de negócio que contém ou dispara a decisão está claramente identificado
• Sabemos quando, onde e porque a decisão é tomada
• A informação necessária para a tomada da decisão é conhecida
• Podemos identificar todos os dados necessários para a tomada da decisão
• O conhecimento necessário para a tomada de decisão é claro
• Conhecemos toda a legislação, normas, padrões, melhores práticas, objetivos e estratégias do negócio necessários para uma tomada de decisão consciente
• É necessário conhecimento e governança da lógica do negócio
• Precisamos ter a certeza que a decisão está sendo tomada de acordo com as regras estabelecidas
• É necessário garantir que as regras de negócio e os valores dos fatos de condição estão atualizados e de acordo com a estratégia e os objetivos da organização

Identificadas as decisões que devem ser automatizadas, resta escolher a melhor maneira de explorar, analisar, avaliar e definir as alternativas de conclusão e as condições a serem consideradas. Este é o objetivo da modelagem de decisão, e em outros artigos detalharemos como isto é feito através do Modelo de Decisão (TDM).

Fique conosco, compartilhe sua opinião e suas experiências, discuta como as decisões são tratadas na sua organização.

Por que modelar decisões, e por que isto é importante para as Organizações? (Parte 2)

No artigo anterior falamos sobre a evolução ocorrida nas organizações ao longo do tempo e a importância da padronização e melhoria dos seus processos para o seu sucesso. Neste artigo, vamos definir exatamente o que a Lógica de Negócios e o que é uma Decisão de Negócio.

"Lógica de negócios é simplesmente um conjunto de regras de negócio representadas como elementos atômicos de condições que levam à conclusões. Como tal, a lógica de negócios representa o pensamento do negócio a respeito da forma como importantes decisões de negócio são tomadas." (von Halle e Goldberg, 2009).

De acordo com a definição acima, vemos que a lógica do negócio é uma representação da forma como as decisões do negócio são tomadas. Decisões de negócio estão em toda parte, e acontecem milhares de vezes, todos os dias, através de toda a organização. Alguns exemplos de decisões de negócio são:

• Determinar a elegibilidade de uma reivindicação de cobertura de seguro
• Determinar a aprovação de um pedido de compra
• Calcular o valor da taxa de juros de um empréstimo
• Calcular o valor a ser cobrado em um plano de telefonia celular
• Determinar que produtos associados devem ser sugeridos por um site de compras
• Determinar o valor do imposto a ser recolhido em uma operação de venda

Todas estas decisões de negócio possuem algumas características em comum:

• são baseadas em condições que avaliam fatos, e que levam a conclusões que interessam à organização gerenciar
• são repetíveis, ou seja, acontecem diversas vezes e, em todas elas devem seguir as mesmas regras estabelecidas pelo negócio
• são importantes para a sobrevivência e o crescimento do negócio
• são conectadas com os objetivos do negócio e afetam os resultados do negócio, mas são tomadas de forma pulverizada por toda a organização, a ponto de passarem desapercebidas
• possuem existência própria, independente da forma como são tomadas, se são automatizadas ou não
• podem ter valor unitário pequeno, mas quando tomadas milhares de vezes, todos os dias, assumem um valor de grande impacto estratégico e financeiro para a organização

Quando tomamos consciência da existência das decisões de negócio, e as nomeamos, devemos na sequência fazer algumas perguntas:

• nós sabemos realmente como cada decisão de negócio é tomada através de toda a organização?
• nós temos uma associação clara entre cada decisão de negócio e os efeitos que ela tem sobre resultados da organização?
• nós podemos mudar rapidamente a lógica que governa cada decisão quando as condições em que a organização opera mudam?
• a gestão da lógica do negócio é digna de atenção sustentada por parte do negócio - o conceito de regra de negócio está no nível correto de interesses do negócio; ela é algo com o que a direção realmente se preocupe, e pode usar em benefício do negócio, criar estratégias a respeito, e que continua tangível e ágil desde a concepção até a implantação?

Se a resposta para qualquer destas perguntas é NÃO, então a organização precisa reavaliar sua gestão da lógica e das decisões de negócios, sob o risco de perda do controle e da governança do negócio, e da redução da agilidade nos negócios e do aumento dos custos e perda das receitas associados a decisões mal tomadas.

No próximo post vamos analisar algumas estratégias usadas pelas organizações na tentativa de gerenciar sua lógica de negócios.

Capturando a lógica dos negócios através de Modelos de Processos (Parte 2)

Na primeira parte deste artigo introduzimos alguns conceitos sobre modelagem de processos, e mostramos como as atividades de um processo são controladas através dos gateways. Agora, vamos detalhar um pouco mais como os gateways funcionam.

Um gateway recebe um fluxo de entrada e direciona o fluxo de saída de acordo com alguma condição. Potencialmente, um gateway pode ter um número indeterminado de caminhos alternativos de saída, e estes podem ser mutuamente exclusivos (somente um caminho de saída será selecionado) ou não (diversos caminhos podem ser selecionados e serão executados em paralelo). Gateways, em sua versão mais comum, atuam de acordo com alguma condição de dados, embora possam também testar condições de eventos ou mensagens (estes tipos de gateways não serão discutidos aqui).

Mas mais importante, é necessário entender que um gateway não "toma" a decisão; ele somente testa uma condição (no caso, de dados), e direciona o fluxo de acordo com o resultado deste teste. Vamos ver um exemplo para entender melhor este conceito.

Suponha um processo de empréstimo como descrito abaixo (simplificado para facilitar o entendimento):

• coletar as informações do proponente ao empréstimo
• determinar o risco de credito do proponente
• se o risco for baixo, aprovar o empréstimo
• se o risco for médio, solicitar garantias e aprovar o empréstimo
• se o risco for alto, negar o empréstimo

A figura abaixo mostra uma possível solução para o modelo de processo correspondente:

No entanto, este modelo está incorreto, de acordo com a especificação da BPMN: como dito acima, um gateway não pode tomar uma decisão; ele pode, apenas, testar o conteúdo de um dado. Assim, o modelo correto é mostrado abaixo:

Este modelo mostra claramente que existe uma atividade (Determinar risco do empréstimo) que fornece o valor do risco de empréstimo para o proponente. Este valor (Alto, Médio ou Baixo) é, então, testado pelo gateway para determinar qual caminho o fluxo irá seguir. A questão passa a ser, então, como o valor do risco pode ser determinado?

Na próxima postagem vamos discutir algumas alternativas...

Qual a sua experiência? Como você resolve isto na sua prática profissional? Deixe aqui o seu comentário.

Capturando a lógica dos negócios através de Modelos de Processos (Parte 1)

O conceito

A modelagem de processos não é uma atividade nova. Desde o início do Século 20 diversas técnicas de modelagem, como fluxogramas, diagramas de fluxo de controle, diagramas de blocos de fluxos funcionais e outras foram aplicadas, na tentativa de capturar a lógica dos negócios e torná-la palpável, passível de ser analisada e melhorada. No entanto, foi somente nos anos 1990 que a modelagem de processos de negócio saiu da área acadêmica e de sistemas de informação para se tornar popular entre o pessoal de negócios.

Na última década do Século passado o conceito de "melhoria de processos" ganhou força nas organizações. As empresas passaram a ser encorajadas a pensar em termos de "processos", e não de "funções" ou "procedimentos". A ideia central deste novo paradigma é a que as empresas devem se organizar em torno das cadeias de eventos principais que tornam possível seu funcionamento e que realizam o seu objetivo final. Os processos, de acordo com esta abordagem, são multifuncionais e atravessam as barreiras impostas pelas estruturas organizacionais (departamentos), oferecendo uma visão ponta-a-ponta da geração de valor para o cliente.

O aumento na importância da descoberta, documentação e melhoria de processos resultou no desenvolvimento acelerado de metodologias, técnicas e ferramentas destinadas a auxiliar as organizações a melhorar seus processos. Sistemas de automatização de fluxos de trabalhos (workflow) viram seu espaço de atuação se transformar nos atuais sistemas de gerenciamento de processos (BPMS), que se propõem a automatizar de forma flexível e ágil os processos da organização, sem a necessidade de grande esforço de programação. No terreno das notações para a modelagem de processos, o padrão BPMN (Business Process Model and Notation), criado pela OMG (Object Management Group) vem se firmando como prevalente no mercado, e praticamente todas as ferramentas de modelagem de processos hoje no mercado suportam em alguma extensão este padrão.

Modelando Processos

A modelagem de processos e sua posterior melhoria envolvem um conjunto razoavelmente conhecido de atividades, normalmente desenvolvidas por um analista de processos ou analista de negócios:

• levantamento da situação atual ("as-is")
• validação e verificação do modelo
• proposição da situação futura ("to-be")
• implementação do novo processo e monitoramento dos resultados

Em geral as empresas que empregam a modelagem de processos para melhoria do seu negócio efetuam levantamentos iniciais visando identificar os processos mais importantes e que trazem maior valor, e gerenciam um portfólio de projetos de melhoria de processos em um ciclo infinito de avaliação-melhoria-implementação de processos. Abaixo um exemplo simples de um processo de compras (alto nível):

Este nível de modelagem de processos é útil para o entendimento de quais são as principais tarefas do processo e em que sequência são executadas, mas é insuficiente para permitir a sua execução na prática. Além de não detalhar exatamente como cada tarefa é executada (e por quem), este nível de modelagem apresenta apenas o chamado "caso feliz", ou seja, o fluxo ideal que leva o processo do seu início ao seu final esperado, sem qualquer indicação de variação ou alternativa de execução. Este seria, em tese, o fluxo mais comum para este processo mas, na prática, sabemos que este nem sempre é o caso. Por isto, os diagramas de processos são sucessivamente refinados para mostrar cada vez mais detalhes, até o momento em que conseguem demonstrar de forma exaustiva todos os fluxos possíveis de trabalho e de informação que podem acontecer em um processo. Um exemplo do processo acima um pouco mais detalhado (mas ainda em alto nível) é mostrado abaixo:

O modelo acima mostra, de forma muito rudimentar, que o fluxo de atividades do processo pode ser desviado em função de eventos ao longo do caminho, e cada ponto de desvio (chamado "gateway") testa uma condição qualquer para saber que caminho seguir. Simplificadamente, um fluxo de processo é um grande conjunto de atividades encadeadas e governadas por pontos de controle (gateways) baseados na avaliação de informações coletadas em atividades anteriores do processo.

Como estas informações são coletadas para que sejam utilizadas pelos gateways? Este é o assunto da segunda parte deste artigo.

Por que modelar decisões, e por que isto é importante para as Organizações? (Parte 1)

Desde sua criação, nos anos 1950, sistemas de informação tem se tornado cada vez mais parte da vida das empresas e, desde a popularização dos computadores e do advento da Internet, nos anos 1980, das nossas vidas. Nos últimos dez anos, com a popularização dos dispositivos móveis, sistemas de informação se tornaram parte indissociável de nossas vidas, a ponto de não concebermos nosso mundo atual sem o acesso irrestrito a recursos proporcionados por smartfones e tablets turbinados por dezenas de apps.

Mas, a despeito do enorme avanço na tecnologia dos dispositivos de acesso à informação, um gargalo ainda se faz presente nos sistemas de informação atuais: nossa dificuldade em lidarmos com a complexidade da lógica das aplicações, e com a cada vez mais premente necessidade de flexibilidade e rapidez de adaptação dos sistemas que apoiam nossas vidas. Em um mundo super conectado e dependente de informação, a incapacidade de se adaptar às mudanças nas condições de forma quase imediata pode representar a diferença entre o sucesso e o fracasso, entre um sistema que realmente facilita a nossa vida para um que se coloca como uma barreira para a nossa evolução.

O começo de tudo....

Muito antes do advento dos sistemas de informação computadorizados as empresas já operavam seus negócios através de processos, executados por pessoas. Estes processos e suas tarefas eram documentados em volumosos manuais, e cada novo colaborador demandava um enorme esforço de treinamento para dominar toda a lógica de negócio que estava contida nestes processos. Por suas características, os processos das empresas se tornaram candidatos naturais para automatização em sistemas informatizados e, assim, as tarefas e a sua sequência de execução passaram a ser traduzidas em códigos de programas.

Os ganhos de produtividade advindos da automatização de tarefas foram enormes, e a capacidade de processar enormes volumes de informação com um consumo de recursos extremamente reduzido deu origem à sociedade de informação em massa que temos hoje. Muitos serviços que fazem parte de nossas vidas, como bancos e telefonia, seriam impensáveis sem a automatização maciça ocorrida no final do Século passado.

Mas toda esta automatização trouxe consigo um efeito colateral inesperado: toda a lógica e inteligência dos negócios foi, aos poucos, sendo transferida das pessoas que executavam as tarefas para os sistemas automatizados e, por consequência, perdida para os olhos do negócio. A cada nova geração de colaboradores, a cada nova geração de aplicações, mais fundo a lógica do negócio foi sendo enterrada nos códigos dos programas e se tornando invisível, até se tornar uma entidade em si, o "sistema", culpado por todas as nossas mazelas e senhor de nossas vidas (quem não se deparou com a infame resposta de um atendente, dizendo que "o sistema não permite isso, senhor(a)" que atire a primeira pedra).

Nos últimos anos temos visto um enorme esforço das empresas para readquirir o controle sobre os seus negócios. A velocidade de mudança e a adaptabilidade exigida das empresas, hoje, não permite mais que esta situação seja aceita. Não é possível que, ao ser questionado a respeito de uma decisão de negócios, como uma aprovação de crédito ou de um empréstimo, um colaborador tenha que recorrer ao "sistema" para descobrir qual foi a lógica utilizada. Não é aceitável que uma modificação em uma função ou em um produto suportado por um sistema produza efeitos colaterais em outras partes do sistema, afetando as operações da empresa de forma significativa (vejam os índices de reclamações nos órgãos de defesa em relação a cobrança de taxas e tarifas bancárias e de empresas de telefonia).

No próximo artigo vamos discutir as diversas estratégias que estão sendo adotadas pelas empresas para enfrentar esta situação. Enquanto isto, compartilhe suas experiências e questões em relação a este assunto. Participe!