quarta-feira, 27 de janeiro de 2016

ArchiMate na Prática - Demarcando serviços de negócio

A questão: quando é aconselhável decompor (ou agregar) um serviço de negócio?

Uma questão recorrente na modelagem da camada de negócios é a identificação do nível de granularidade (demarcação) dos serviços: quando é adequado desagregar um serviço (criando "sub-serviços") ou, de forma similar, quando é aconselhável agregar serviços individuais em um serviço de mais alto nível?

A solução para esta questão

Um serviço de negócio é, por definição, "consumido" por diversos consumidores. Isto implica que um serviço só deve ser decomposto em sub-serviços se estes sub-serviços puderem, também, ser consumidos de forma independente uns dos outros.

Use as seguintes orientações para distinguir um serviço:
  • Distinga o serviço a partir de uma perspectiva de seu consumidor. O serviço deve ser reconhecível e usável pelo consumidor. As convenções de nomeação devem ser estabelecidas a partir da perspectiva do consumidor do serviço.
  • Distinga os serviços com base nas atividades que são executadas na camada de serviços, e com base nos produtos que estão sendo entregues.
  • Modele os serviços de fora para dentro: definidos pelo seu uso.
  • Distinga diferentes serviços de forma ótima para endereçar diferentes preocupações das partes interessadas.
  • Previna a sobreposição de serviços: serviços diferentes oferecem comportamentos diferentes. A sobreposição do comportamento é um indicador de que o comportamento sobreposto deve ser modelado como um serviço separado.
  • Um serviço é realizado por uma ou mais funções ou processos que representam o comportamento interno da organização. Uma função de negócios pode realizar múltiplos serviços.
  • Sempre modele quais as funções ou processos de negócio realizam um serviço de negócio, e quais processos (no caso de serviços internos) consomem o serviço.
  • Um serviço de negócio interno sempre é usado por uma função ou processo de negócio.
  • Mantenha os serviços coerentes: garanta que comportamento comparável seja oferecido como serviços de uma forma comparável.
  • Use serviços para esconder detalhes de implementação. É suficiente para o consumidor do serviço saber que um certo serviço está sendo oferecido, e como o consumidor pode fazer uso do serviço. O consumidor do serviço não precisa saber como o serviço é realizado.
Se você quer conhecer mais sobre a linguagem ArchiMate, e conversar sobre Arquitetura Corporativa, acesse regularmente este blog e o site da Centus Consultoria

Fonte: ArchiMate Made Pratical, Harmen van der Berg e outros, NAF Working Group "ArchiMate usage"

quinta-feira, 19 de novembro de 2015

ArchiMate na Prática - Serviço de Negócio, Função de Negócio e Processo de Negócio

Para iniciantes no uso da linguagem ArchiMate, uma questão recorrente é: qual a diferença entre serviço, função e processo de negócio? Este artigo procura apresentar uma maneira clara de usar de forma correta cada um destes conceitos.

Serviço de Negócio

Um serviço de negócio representa o valor adicionado que uma organização entrega para o ambiente. É a parte "visível" das atividades da organização, sendo que o termo "organização" deve ser entendido em um sentido amplo: pode ser uma empresa, uma área da empresa (departamento), um conjunto de empresas, em suma, qualquer parte identificável da estrutura organizacional. Os serviços de negócio podem ser internos, quando prestados para outras unidades organizacionais da organização, ou externos, quando prestados para o ambiente externo da organização (clientes, fornecedores, governo, etc.).

Função de Negócio

Uma função de negócio é uma área em que a organização coloca esforços para atingir seus objetivos e metas. Uma função de negócio agrupa comportamento e recursos internos com base em algum critério significativo (por exemplo, localização geográfica, departamento, competências requeridas, recursos e conhecimento compartilhado, etc.). Uma função de negócio representa parte do valor adicionado por uma organização. Funções de negócio, geralmente, conectam O QUE a organização faz com QUEM o faz, sem indicar COMO são feitas.

Processo de Negócio

Um processo de negócio é uma unidade de comportamento interno, ou uma sequência (causal) de unidades de comportamento interno (atividades), com o objetivo de produzir um resultado determinado. Processos podem ser constituídos de sub-processos, e são iniciados por eventos de negócio ou outros processos de negócio. Informalmente, isto significa que um processo consiste de atividades e/ou subprocessos, realizados em uma determinada sequência. Cada atividade é parte de uma função de negócio, como exemplificado abaixo:

Fig.1 - Exemplo de função de negócio em relação a processos de negócio

Conclusão


Um processo nem sempre pertence a uma única função de negócio (como mostrado no exemplo acima); uma função de negócio quase sempre é constituída por várias atividades em múltiplos processos; um processo, quase sempre, é realizado por várias (partes de) funções de negócio.

Funções de negócio, assim como processos de negócio, descrevem o comportamento interno da organização que não é "visto" pelas partes interessadas externas à organização. Serviços de negócio descrevem o resultado e o valor que é percebido pelas partes interessadas externas, sem descrever os detalhes de como o serviço é realizado através de funções e processos de negócio.

Na figura abaixo, são mostrados os principais relacionamentos entre estes conceitos:

Fig.2 - Relacionamentos mais comuns entre os conceitos

Se você quer conhecer mais sobre a linguagem ArchiMate, e conversar sobre Arquitetura Corporativa, acesse regularmente este blog e o site da Centus Consultoria

Fonte: ArchiMate Made Pratical, Harmen van der Berg e outros, NAF Working Group "ArchiMate usage"

quarta-feira, 1 de julho de 2015

Um Novo Paradigma para Sistemas de Informação (Parte 1-Introdução)

Introdução

Há uma importante mudança de paradigma acontecendo no campo dos sistemas de informação (SI). Isto significa que uma nova geração de sistemas de informação está surgindo, assim como novas abordagens para o seu desenvolvimento. A boa notícia é que os analistas de negócios podem ser
mais importantes para este novo paradigma do que foram para os anteriores.

Uma mudança de paradigma é uma mudança sutil, mas importante, de uma maneira de pensar para outra. É uma revolução, uma transformação, uma espécie de metamorfose. Ela não simplesmente acontece; ao contrário, é conduzida por um forte impulso para a mudança. As duas principais áreas de mudança que impulsionam esta nova mudança na TI são o desejo, ou a necessidade, de:

(1) gerenciar os processos de negócio e as regras de negócio como recursos distintos, mas estreitamente relacionados e conectados, e

(2) decompor o código de programação ou software em módulos reutilizáveis, chamados de serviços, geridos por uma infraestrutura de Arquitetura Orientada a Serviços (SOA). A infraestrutura SOA gerencia e media os serviços usados em um processo de negócio.

Pesquisa e prática comprovam que uma mudança de paradigma bem sucedida não pode acontecer sem que aqueles que estão no meio dela sejam treinados e educados. A falta de treinamento e de educação está impedindo esta mudança de paradigma em curso. Há uma escassez nas empresas, hoje, de pessoas treinadas em processos de negócios, gerenciamento de regras, e SOA. Parte da razão para este déficit educacional é que os programas acadêmicos são lentos para responder às sérias mudanças que ocorrem na maioria das empresas, hoje.

Esta série de artigos tem como objetivo fornecer uma visão geral da nova geração de sistemas de informação, incluindo o que um analista de negócios precisa saber, e o que um currículo escolar ou de formação correspondente deve incluir. Voltaremos em breve...

terça-feira, 16 de junho de 2015

Arquitetura Corporativa: Mais do que simples arquitetura de TI

Arquitetura Corporativa - um novo momento

Cada vez mais, as organizações precisam lidar com transformações de alto impacto e melhorias de negócios urgentes, em uma realidade negócio e de TI verdadeiramente complexos. É por isto que a BiZZdesign e a Centus acreditam que as organizações deveriam ter as capacidades de mudança para transformar ou melhorar seus negócios e realizar sua missão. Nós ajudamos nossos clientes a construir organizações fortes, pela transformação e melhoria dos negócios, fornecendo capacidades de mudança através de soluções integradas, formadas por ferramentas de desenho, treinamento, consultoria de negócios, e melhores práticas.

As empresas, em geral, compreendem a necessidade e a importância da arquitetura corporativa. Dez anos atrás, muito esforço foi necessário para convencer a alta direção que a arquitetura era indispensável para o gerenciamento da complexidade de qualquer grande empresa, e ela foi percebida como uma disciplina de TI. Hoje, a arquitetura corporativa prova seu valor no apoio à transformação de negócio de alto impacto, entregando os resultados desejados e fomentando a agilidade da empresa, tudo em um ambiente sob constante pressão do tempo.

A contribuição da arquitetura corporativa é, naturalmente, encontrada na sua relação com as outras disciplinas dentro da empresa, e não dentro de sua própria torre de marfim, ou apenas concentrada na TI. Nos concentramos em ajudar os arquitetos a entregar valor para os grupos de partes interessadas nestas outras disciplinas. Concentramos, portanto, os nossos esforços em cinco áreas principais:

  • Realizar a estratégia da empresa. A arquitetura corporativa em geral e, especificamente, a arquitetura de negócios e o planejamento baseado em capacidade, são instrumentos importantes para traduzir a visão em ação. Além disso, eles fornecem feedback essencial sobre a viabilidade de uma visão estratégica, e também desempenham um papel na definição da estratégia através da modelagem de negócios e da análise de cenários estratégicos.
  • Apoiar as decisões de investimento estratégico. Decisões bem fundamentadas sobre o portfólio de produtos e segmentos de mercado, que estendem o gerenciamento integrado do portfólio de TI, exigem a percepção de suas dependências e de seu valor. O gerenciamento de portfólios baseado em arquitetura fornece estas percepções, e oferece também o suporte perfeito para programas de otimização de custos. Fornecer para os líderes empresariais cenários de investimento, análises de impacto, roteiros e outros produtos de informação baseados em arquitetura é uma tarefa-chave para qualquer arquiteto corporativo.
  • Fomentar a agilidade empresarial. Os processos de arquitetura precisam acompanhar a velocidade das mudanças dentro e fora da empresa; os resultados rápidos fornecidos por iniciativas Lean e Agile são um exemplo importante. Ao vincular sua prática de arquitetura corporativa com processos de entrega contínua, as organizações poderão aumentar consideravelmente sua capacidade de mudança. Os dias dos "planos quinquenais" estão definitivamente terminados.
  • Aproveitar as oportunidades tecnológicas. A arquitetura corporativa é essencial para fazer pleno uso de desenvolvimentos como computação na nuvem, Big Data ou BYOD(Bring Your Own Device-Traga Seu Próprio Dispositivo), para realizar a "empresa digital". Uma visão clara sobre as oportunidades de negócio das novas tecnologias, e uma abordagem estruturada para a sua realização na empresa, são ingredientes essenciais de qualquer abordagem de arquitetura corporativa.
  • Controlar o risco e garantir a conformidade. As percepções trazidas pela arquitetura corporativa são essenciais para conhecer e mitigar seus riscos. Além disto, reguladores e legisladores apresentam cada vez mais demandas explícitas sobre a arquitetura corporativa de, por exemplo, órgãos do governo e instituições financeiras.
Uma abordagem baseada em modelos para a descrição da arquitetura corporativa oferece uma base sólida para a análise e o desenho, e fornece a ligação necessária para os outros domínios. Ela suporta o gerenciamento de portfólios com as análises necessárias para determinar o valor esperado, o custo e o risco de várias iniciativas. Ela fornece os dados necessários para priorizar e planejar as mudanças no panorama do negócio e da TI. Ela proporciona às organizações a coordenação, ao nível de programa, entre as iniciativas que realizam estas melhorias de negócios, de uma forma coerente. Ela fornece as informações necessárias para avaliar e garantir a conformidade com regulamentos e regras, internos e externos. Finalmente, ela ajuda no acompanhamento da realização dos benefícios previstos em todo o panorama de negócio e de TI, do objetivo estratégico ao resultado operacional e, portanto, na correção do seu curso, se necessário.

Nas próximas postagem vamos mostrar tudo o que a nova Suíte de Ferramentas BiZZdesign Enterprise Architecture tem para oferecer, e como a convergência da arquitetura corporativa com outras disciplinas, como a gerência de projetos, pode revolucionar a forma como as organizações lidam com as mudanças.

Até breve...

quarta-feira, 3 de junho de 2015

TDM e DMN - Uma combinação destinada ao sucesso

A OMG aprovou, recentemente, a publicação do padrão DMN-Decision Model and Notation (Notação e Modelo de Decisão), que objetiva fornecer uma notação para decisões que seja compreendida por todas as audiências (negócios e técnica) e que permita o compartilhamento de modelos entre ferramentas de software. Para a comunidade de modelagem de decisões em geral, e para aqueles que adotaram a metodologia TDM em particular, isto é uma excelente notícia!

Por que o DMN é Importante?


O DMN reforça a necessidade de um modelo específico para a lógica de negócios - distinto de todos os outros tipos de modelo. O DMN, como uma especificação da indústria de software, reconhece a necessidade de uma nova classe de ferramentas correspondente. É digno de nota as empresas que integram o Comitê DMN: IBM, Oracle, TIBCO, KPI, Decision Management Solutions, Escape Velocity, Model Systems, e KU Leuven University.

Cinco Filosofias Comuns


A tabela abaixo apresenta os pontos comuns entre o TDM e o DMN

  • Decisões e lógica pertencem ao pessoal de negócios
  • A maneira de modelar decisões é a solução
  • Decisões se conectam com modelos de processos de negócio
  • A lógica das decisões deve ser facilmente automatizada
  • Software de modelagem de decisão é a solução

Modelos de processo


Em 2009, o TDM introduziu o conceito de processos conscientes de decisões, definido como processos que distinguem atividades que realizam o trabalho daquelas que derivam conclusões a partir de modelos de lógica completos. O DMN também relaciona modelos de decisão com processos de negócio, como mostrado abaixo:


Figura 1: Relacionamento entre modelos BPMN e DMN

Cinco Diferenças


1 - Público-alvo


O TDM tem como alvo, desde sua proposição, o pessoal de negócios. Por isto, um de seus princípios é ser completamente isento e independente de dependências em relação à tecnologia usada para a implementação dos modelos.

O DMN é uma especificação direcionada para audiências técnicas e desenvolvedores de ferramentas, e possui cinco componentes principais: notação no nível da lógica e dos requisitos, linguagem de expressões (FEEL-Friend Enough Expression Language), metamodelo, e níveis de conformidade.

2 - Nível de Requisitos


O DMN prescreve uma notação para um Diagrama de Descrição de Requisitos (DRD-Decision Requirements Diagram). Os requisitos incluem as decisões e os elementos relacionados, várias formas de lógica detalhada, e as dependências entre elas. O DMN é uma notação híbrida. O TDM é um modelo de lógica pura, composto de 15 princípios que orientam as funcionalidades orientadas para modelo do TDM. A figura abaixo mostra um DRD típico:



Figura 2: Parte de um DRD DMN

Basicamente, uma caixa de decisão DMN se correlaciona com a Família de Regra de Decisão do TDM. Setas entre as decisões são dependências, similares às relações inferencias no TDM. Outros elementos do DRD incluem o Modelo de Conhecimento de Negócios (BKM-Business Knowledge Model), fonte de conhecimento de negócio, e dados de entrada.

Existem diversas maneiras de representar modelos TDM através da notação DMN. A figura abaixo contém um modelo TDM (à esquerda) e uma possível tradução utilizando a notação DMN (à direita):



Figura 3: Diagrama do Modelo de Decisão TDM e sua tradução no DRD DMN

3 - Nível da Lógica


Uma caixa de decisão DMN pode ter ter uma forma gráfica diferente para expressar seus detalhes - por exemplo, uma expressão de valor ou um BKM. Um BKM pode ser um conjunto de regras de negócio, diversas formas de tabelas de decisão DMN, ou modelos analíticos.

Uma Família de Regra TDM tem somente uma forma gráfica. Seus detalhes não são uma estrutura separada. No DMN, os detalhes da Família de Regra podem se tornar BKMs ou Decisões, com ou sem BKMs.

4 - Automatização


O nível 3 de conformidade do DMN inclui a linguagem FEEL, para automatização das decisões. O TDM não inclui uma linguagem de automatização. Atualmente, organizações que utilizam software TDM, como o SAPIENS Decision e o BiZZdesign Decision Modeler, exportam os modelos de decisão e os convertem para o código nos ambientes de execução desejados.

5 - Glossário de Negócios


O DMN não inclui um glossário de negócios. O modeladores TDM usam os termos do glossário de negócios para especificar as condições e conclusões que formam a lógica das decisões, e para funcionalidade adicional (isto é, validação automática, geração e execução de casos de teste).

Um Momento no Tempo


Estamos em um momento interessante para a modelagem de decisões:

  • O TDM tem mais de seis anos de existência, tem uma grande base mundial de clientes[1], anos de utilização em produção, e funcionalidade sofisticada baseada em modelos[2]
  • O DMN é um novo padrão em desenvolvimento, se conformando com aquilo que os praticantes do TDM já conhecem há anos, e proporcionando uma notação mais ampla para os requisitos das decisões.

Eles possuem similaridades e diferenças. Algumas diferenças são cosméticas, Algumas não são. Estas últimas são o objeto de discussões interessantes, e é onde os praticantes da modelagem de decisões têm muito a ganhar.

Para saber mais sobre o Modelo de Decisão, acesse o site da Centus, ou baixe uma cartilha contendo os conceitos básicos da modelagem de decisões.

Notas:
[1] Até onde sabemos, o TDM é o único modelo de descrição de lógica de negócios largamente automatizado em ambiente de produção, em diversas plataformas e BRMS de mercado, em clientes dos mais variados portes e segmentos de negócio

[2] com a utilização de software de apoio adequado

domingo, 17 de maio de 2015

Que Decisões Pertencem aos Modelos de Decisão?

Em 2009, The Decision Model (O Modelo de Decisão) foi revelado ao público. Em 2011, um novo tipo de software emergiu para suportá-lo. Recentemente, o guia BABOK v3 (Business Analysis Body of Knowledge, publicado pelo IIBA) trouxe a modelagem de decisões como uma técnica aprovada para substituir os modelos de processo na descrição da lógica de negócios. Em 2014, o Object Management Group (OMG) votou pela publicação do Decision Model and Notation (DMN-Notação e Modelo de Decisão) como um novo padrão para o desenvolvimento de software.

Então, o Que Há de Novo?


Decisões não são uma novidade, mas uma mudança está acontecendo. Modelos de decisão estão agora sancionados, e milhares estão funcionando em ambiente de produção em grandes corporações. A questão agora é: que tipo de decisões pertencem aos modelos de decisão? A tabela abaixo mostra os critérios mais comuns usados pelas organizações para responder a esta questão:

Sete Critérios para Modelos de Decisão


  1. Governança do Negócio
Dar ao pessoal de negócios controle sobre a lógica para as decisões importantes para o negócio, desde o início até a implementação
  1. Governança Externa
Gerenciar decisões cujos agentes de mudança de direito são externos à organização
  1. Governança Personalizada
Gerenciar decisões que têm conjuntos diferentes de lógica baseados em contextos de negócio, como diferentes localizações geográficas,jurisdições legais e tributárias, ou categorias de clientes
  1. Flexibilidade Tecnológica
Selecionar e mudar a tecnologia para a automatização de decisões, sem mudar a lógica do modelo de decisão
  1. Retorno sobre o Investimento (ROI)
Prever e medir como uma decisão contribui para a saúde e bem-estar dos negócios
  1. Agilidade e Velocidade de Mudança
Permitir mudanças na lógica de decisão efetivas, rápidas e frequentes
  1. Complexidade da Lógica de Decisão
Simplificar a representação da lógica de negócio, mesmo em modelos de grandes dimensões, ou com lógica intricada
Uma forma de entender como o TDM suporta estes critérios é listar suas características e correlacioná-las com os benefícios que suportam os critérios acima:

As Quatro Características Principais do TDM


  1. Estrutura do Modelo de Decisão
  • Formato único (embora não vinculado a uma notação específica)
  • Bem delimitado (ponto de partida e de término pré-definidos pela estrutura, desde a decisão de negócio até os dados brutos)
  • Formato simples e amigável para o pessoal de negócios (não afetado por considerações tecnológicas)
  • Normalizado até as menores partes gerenciáveis e reutilizáveis
  • Estruturas conectadas por dependências puramente lógicas
  • Visões de modelos de decisão inteiros para suportar lógica personalizada
  • Serve como um ponto único de mudança, sem a necessidade de mudanças no código dos programas
  1. 15 Princípios do TDM
  • Princípios Estruturais, Princípios (declarativos) Independentes de Tecnologia, Princípios de Integridade
  • A combinação da estrutura com os princípios torna fácil e rápido criar e automatizar a lógica as decisões do que com outras abordagens de regras de negócio
  1. Independência de Tecnologia
  • Glossário de termos de negócio, definições de negócio, tipos de fatos e valores de domínio
  • Glossário de negócio independente da tecnologia de dados física
  • Estrutura e conteúdo do modelo de decisão independente da tecnologia de execução
  1. Fundação para Software Inovativo
  • Validação automática dos modelos de decisão em relação aos 15 Princípios, antes da implementação em tecnologia
  • Geração automática de casos de teste e execução de modelos de decisão inteiros antes da implementação
  • Gerenciamento do Ciclo de Vida das Decisões, desde o negócio até a TI
  • Controle de versão das entradas do glossário e das partes do modelo de decisão
  • Mensagens

Já Estivemos Aqui Antes?


Há muito tempo, um novo modelo para os dados, chamado modelo relacional, foi publicado e suportado por um novo tipo de software. Dados não era algo novo. Mas uma mudança se apresentava à frente, enquanto perguntávamos: que tipo de dados pertencia ao modelo relacional? Hoje, nós sabemos que a resposta é: todos os tipos, ou quase todos (especialmente, dados estruturados). As empresas priorizaram e migraram a maioria dos dados operacionais para o formato relacional, que entregou, então, todas as suas promessas.

Então, hoje, que decisões pertencem aos modelos de decisão? A resposta que se apresenta é: todas elas, ou quase todas elas (especialmente, decisões baseadas em condições que levam a conclusões). Assim sendo, é tempo de desenvolver os critérios que são importantes para a sua empresa, priorizar e começar a desenvolver os modelos de decisão que são importantes, com a certeza e a confiança que o modelo de decisão vai entregar as suas promessas.

Para conhecer mais sobre o Modelo de Decisão, acesse o site da Centus, ou solicite um contato.

Fontes: WHICH DECISIONS BELONG IN DECISION MODELS?  Barbara von Halle - SAPIENS Decision blog

sexta-feira, 5 de setembro de 2014

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.

quinta-feira, 28 de agosto de 2014

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.

segunda-feira, 21 de julho de 2014

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