Gerenciamento de Decisões

Modelando Regras de Negócio usando a Linguagem ArchiMate®

postado em 15 de fev de 2017 11:28 por Antonio Plais   [ 2 de mar de 2017 06:00 atualizado‎(s)‎ ]

Há algum tempo, uma pergunta foi postada no grupo ArchiMate do LinkedIn: Como modelar ou representar regras de negócio em modelos ArchiMate? Várias respostas foram apresentadas, tentando abordar a questão a partir de diversas perspectivas. Como praticante da modelagem de decisões, e profissional certificado ArchiMate®, decidi apresentar uma solução unindo estes dois corpos de conhecimento. Qualquer comentário, questão ou sugestão são bem-vindos.

Em primeiro lugar, precisamos reconhecer que as regras de negócio podem aparecer em vários domínios da arquitetura, de forma que existem várias formas "corretas" de modelá-las no ArchiMate®. Vamos ver, aqui, como modelar alguns exemplos de regras e decisões de negócio, sem ter a pretensão de esgotar o assunto ou todas as abordagens possíveis. Afinal, o ArchiMate® é uma linguagem e, como tal, permite que a mesma "história" seja contada de formas diferentes, dependendo de quem conta e de quem escuta!

Uma Regra de Negócios da Motivação até o Núcleo do ArchiMate

Gladys Lam, uma das maiores autoridades em regras de negócio no mundo, fornece uma excelente percepção sobre regras de negócio e requisitos de negócio neste artigo. Nele, ela estabelece uma separação clara entre regras e requisitos, e fornece uma série de exemplos bem elaborados para explicar a diferença entre eles. Em suas palavras, "Regras de negócio são listas de declarações que dizem se você pode ou não pode fazer alguma coisa, ou lhe dá critérios e condições para tomar uma decisão", e "um requisito de negócio é o que você precisa fazer para permitir a implementação de, ou a conformidade com, uma regra de negócio". Claro como água, não?

No entanto, o ArchiMate não fornece um elemento nativo na Extensão de Motivação para exprimir regras de negócio, como estas mostradas abaixo (tiradas do artigo de Gladys):
  • Um Cliente deve ter um Endereço de Email válido
  • Um Endereço de Email deve ser considerado Válido se uma mensagem enviada para o Endereço de Email não retorna "não entregue" dentro de 60 minutos
Na página 65 do padrão ArchiMate 3.0, é sugerido claramente que regras de negócio podem ser modeladas como uma especialização de Requisito. Eu discordo desta afirmação, pois entendo que (com base nos trabalhos de Ronald Ross e outros) uma Regra de Negócios é uma especialização de um elemento Princípio, como mostrado abaixo:
Figura 1 - Modelagem de regras de negócio usando um elemento "Business Rule"

Este mecanismo de especialização é padrão do ArchiMate, e nesta postagem eu não entrarei em maiores detalhes sobre como ele funciona.

Da Regra de Negócio para o Requisito de Negócio

Seguindo o exemplo de Gladys, estas regras de negócio devem ser realizadas de alguma forma na arquitetura, através de requisitos de negócio:
Figura 2 - Requisitos de Negócio que realizam as Regras de Negócio

Seguindo o padrão do ArchiMate, você pode usar estes requisitos para ligar as regras de negócio com os elementos do núcleo (do ArchiMate) na arquitetura que os realizam:
Figura 3 - Elementos do núcleo do ArchiMate realizam os Requisitos de Negócio

Uma regra de Negócio como uma Decisão

Eventualmente, você pode modelar também a decisão de negócio que faz cumprir a regra de negócio no processo, como mostrado abaixo:
Figura 4 - Decisões de Negócio realizam Regras de Negócio
 
O Modelo de Decisão pode, eventualmente, ser detalhado usando, e.g., o padrão DMN-Decision Model and Notation, do OMG, ou mesmo a antiga (e ainda útil) notação TDM, mas não trataremos disso nesta postagem.

Continuando Estrada Abaixo...

Nesta postagem não irei mais fundo para mostrar como modelar as Camadas de Aplicativos e de Infraestrutura do ArchiMate, onde eventualmente encontraremos um motor de regras (BRMS-Business Rule Management Systems) ou um gerenciador de decisões (BDMS-Business Decision Management Systems) que efetivamente irão executar o modelo de decisão, mas tenho a certeza que você já entendeu como as regras de negócio podem ser modeladas usando a linguagem ArchiMate.

Além disso, ficará para uma próxima postagem a discussão sobre como estas regras de negócio se conectam com as motivações, partes interessadas e regras externas (e.g. leis e regulamentos) que as justificam.

Se você tiver alguma dúvida, ou desejar compartilhar suas experiências, entre em contato com a Centus Consultoria, e teremos o máximo prazer em conversar sobre este assunto.

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

postado em 16 de ago de 2016 09:16 por Antonio Plais   [ 16 de ago de 2016 09:30 atualizado‎(s)‎ ]

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

Quando é importante automatizar uma decisão?

postado em 16 de ago de 2016 09:05 por Antonio Plais   [ 16 de ago de 2016 09:07 atualizado‎(s)‎ ]

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 as pessoas  se mantere 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
  • informação necessária para a tomada da decisão é conhecida
    • Podemos identificar todos os dados necessários para a tomada da decisã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ões, e em outros artigos detalharemos como isto é feito através de notações como o DMN-Decision Model and Notation, do OMG, e metodologias como o TDM-The Decision Model.

5 Passos para o Gerenciamento de Regras de Negócio de Sucesso

postado em 10 de ago de 2016 04:44 por Antonio Plais   [ 10 de ago de 2016 04:49 atualizado‎(s)‎ ]

O gerenciamento da lógica que rege o funcionamento das organizações está, cada vez mais, atraindo
a atenção dos executivos. Em diversas indústrias, como bancos, seguradoras, financeiras, serviços de
saúde, telecomunicações, aviação civil, governos, e outras, este gerenciamento é, de fato, crucial
para a sobrevivência das empresas. Mas como encarar este desafio, e vencê-lo com sucesso? Apenas
gerenciar as regras de negócio através dos sistemas informatizados é suficiente? Quais as melhores
práticas para o gerenciamento das decisões de negócio, uma nova classe de ativos organizacionais?

Com base em dezenas de projetos e iniciativas de mudança que fizeram uso do gerenciamento de
decisões, e obtiveram estrondoso sucesso no gerenciamento de sua lógica e regras de negócio, cinco
passos fundamentais podem ser sugeridos para levar ao caminho do sucesso:

Compreenda a disciplina

Antes do advento dos conceitos do gerenciamento e modelagem de decisões, expressos no livro The
Decision Model: A Business Logic Framework Linking Business and Technology, escrito por Barbara
von Halle e Larry Goldberg em 2009, a lógica de negócios era encontrada espalhada e enterrada em
documentos de requisitos, modelos de processos, interfaces de aplicativos, e mesmo na cabeça das
pessoas que operavam e desenvolviam os sistemas. Mesmo sendo uma disciplina recente, e que
ainda está em evolução, o gerenciamento de decisões rapidamente encontrou seu lugar ao sol, e,
hoje, é estudado e discutido por pessoas, empresas e instituições ao redor do mundo (veja o artigo).

Existem diversas fontes de conhecimento sobre modelagem de decisões disponíveis. O Capítulo 7 do
livro acima descreve como começar com bastantes detalhes. No site da Centus está disponível uma
série de artigos a respeito. Outros sites e autores podem ser pesquisados, e muita informação
começa a se tornar disponível. Com este conhecimento em mãos, você poderá avaliar melhor os
impactos da modelagem de decisões na sua empresa, e o melhor caminho e os recursos necessários
para um projeto de sucesso.

Conheça e documente suas dores

Antes de se decidir por uma nova abordagem para o gerenciamento de suas regras de negócio, é
importante que você documente suas práticas atuais, e identifique as áreas de lacuna e as
oportunidades de ganho que podem ser obtidas com a aplicação do gerenciamento de decisões.
Procure por iniciativas que podem gerar um impacto significativo na sua empresa, tanto do ponto de
vista tangível como intangível. Pense não só no curto prazo, mas também nos benefícios de agilidade
e facilidade de adaptação que já se tornaram comuns nas empresas que adotaram a modelagem de
decisões para o gerenciamento de sua lógica de negócios. Fazendo isto, você poderá, no futuro,
comparar os resultados previstos com os resultados obtidos, e mensurar o impacto real do
gerenciamento de decisões na sua empresa.

Escolha o projeto piloto correto

O objetivo do projeto piloto é provar a viabilidade do gerenciamento de decisões, através da criação
de benefícios tangíveis. O piloto deve ser suficientemente complexo para mostrar a extensão e a
profundidade da nova abordagem, mas deve ser limitado o suficiente para ser concluído em um
período de 3 a 6 meses. O projeto deve ter suficiente atenção das principais partes interessadas, e
deve ser capaz de resolver um problema real de negócio.

A utilização de conceitos e metodologias ágeis, como a metodologia KPIStep, pode ser uma
importante medida para reduzir os riscos e os custos do piloto. A orientação de um time de
especialistas com experiência de sucesso em implementações de gerenciamento de decisões é
crucial. Um bom modelo de engajamento usa uma abordagem "lidere, treine, oriente", onde a
competência de gerenciamento e modelagem de decisões vai sendo construída através de iterações
sucessivas cada vez mais autônomas. A modelagem de decisões vai muito além de uma simples
notação ou ferramenta; a abordagem correta e o gerenciamento do processo de modelagem têm
papel fundamental na adoção com sucesso da disciplina.

Preste atenção na sua arquitetura

O gerenciamento de decisões impacta a arquitetura corporativa, a modelagem de processos, o
gerenciamento de dados, e o desenvolvimento de sistemas da empresa. Arquitetos de decisão
devem estar atentos aos obstáculos à frente, para desenvolver um roteiro de integração do
gerenciamento de decisões com as outras disciplinas em uso na organização que leve ao sucesso.
Não empregar um arquiteto de decisão capacitado nos projetos de gerenciamento de decisões leva a
uma abordagem de "tentativa e erro", que poderá por a perder todo o esforço colocado na iniciativa,
e impedir que os ganhos planejados sejam efetivamente obtidos.

Comunique

É muito fácil ficar completamente imerso no projeto em andamento, e se esquecer de manter as
diversas partes interessadas a par dos avanços. A utilização de técnicas ágeis, como reuniões diárias,
listas de backlog, sprints curtos, gestão à vista, e outras, são fundamentais para avaliar
constantemente o andamento dos trabalhos, corrigir os desvios da rota planejada, e levantar lições
aprendidas que possam ajudar na evolução dos trabalhos. Um esforço extra deve ser dedicado à
avaliação e discussão de eventuais dificuldades, e o alinhamento constante das entregas do projeto
com as expectativas dos patrocinadores e das partes interessadas.

Conclusão

Ao seguir os passos descritos acima, você estará no caminho de construir um repositório centralizado
da lógica do seu negócio e da sua empresa, o que garantirá a consistência e a acurácia através das
diversas funções, departamentos, regiões e processos. A agilidade e velocidade de mudança
aumentarão na medida em que a maturidade no gerenciamento de decisões evoluir, e a governança
do negócio e a conformidade com as políticas, regulamentos e legislação que afetam a empresa
diminuirão o risco e os custos de fazer negócios.
 
Este artigo contém ideias e conceitos do Modelo de Decisão originalmente publicados em
SapienDecision Blog: 5 STEPS FOR SUCCESSFUL BUSINESS RULES MANAGEMENT, 31 de Julho de 2015,
por Michael Grohs

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

postado em 5 de ago de 2016 10:22 por Antonio Plais   [ 5 de ago de 2016 10:35 atualizado‎(s)‎ ]

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

 2. Governança Externa

Gerenciar decisões cujos agentes de mudança de direito são externos à organização

 3. 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

 4. 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

 5. Retorno sobre o Investimento (ROI)

 Prever e medir como uma decisão contribui para a saúde e bem-estar dos negócios

 6. Agilidade e Velocidade de Mudança

 Permitir mudanças na lógica de decisão efetivas, rápidas e frequentes

 7. 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

 2. 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

 3. 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

 4. 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

1-5 of 5