segunda-feira, 24 de abril de 2017

Estudo de caso aberto em Mineração de Processos – parte 2

Continuando o último post apresentamos mais detalhes do Business Process Intelligence Challenge - BPIC 2017, que nos propõe atualizar a análise de um caso tratado no desafio de 2012. A organização dona do processo implementou algumas das recomendações recebidas em 2012 e reapresenta o caso para nova análise.

Antes de examinar o log de eventos fornecido, vamos estudar as informações disponíveis para buscar um entendimento preliminar do processo. Na página do BPIC  2017 temos algumas informações e, excepcionalmente este ano, também temos aqui os artigos apresentados no desafio de 2012. Para compensar o fato de não podermos resolver dúvidas e obter esclarecimentos adicionais acessando diretamente a organização dona do processo, o Fórum de Discussões do ProM (Process Mining) abriu aqui um canal de discussão específico para o BPIC 2017. Representantes da organização acompanham este fórum e tentam responder às questões colocadas pelos participantes do desafio.

Pelas informações disponíveis nessas várias fontes verifica-se que o processo a ser analisado tem como objetivo controlar a concessão de empréstimos solicitados por pessoas físicas. O processo é apoiado por um sistema de informação, através do qual são executadas e registradas as ações do processo. O sistema é também responsável por dois artefatos de negócio produzidos pelo processo, a Solicitação de Empréstimo e a Proposta Financeira.

O processo inicia quando o Cliente submete uma Solicitação de Empréstimo. Após avaliação preliminar, a Organização rejeita o pedido ou oferece uma Proposta. Se o Cliente aceitar a Proposta, uma nova avaliação é realizada que, mais uma vez, pode resultar numa aprovação ou rejeição. Na mesma Solicitação o Cliente pode receber múltiplas Propostas, mas pode aceitar apenas uma. O processo pode encerrar de várias formas, pela aprovação da Solicitação após o aceite de uma Proposta, pela rejeição da Solicitação pela Organização ou pela desistência do Cliente.

O Log de eventos fornecido para o desafio contém 3 fluxos de eventos distintos interligados. Dois fluxos tratam de eventos associados a mudanças de estado dos artefatos sistêmicos: Solicitação e Proposta. Ou seja, os eventos registram o resultado de ações ou decisões que determinam os estados da Solicitação de Empréstimo e da Proposta Financeira. O terceiro fluxo trata dos eventos associados às atividades executadas no processamento da Solicitação, em geral corresponde às ações manuais executadas pelos funcionários da organização que participam do processo.

Os nomes dos eventos no Log são identificados por um prefixo associado a cada fluxo. Os eventos referentes aos estados da Solicitação são identificados pelo prefixo “A” de Application e os referentes aos estados da Proposta são identificados pelo prefixo “O” de Offer. Os eventos que se referem às atividades executadas no tratamento da Solicitação são identificados pelo prefixo “W” de Workflow.

Neste ponto, já podemos arriscar uma primeira tentativa de modelo descrevendo os passos do processo e estados da Solicitação e Proposta:
  1. Cliente faz uma Solicitação de empréstimo através de uma página web. A Solicitação é criada no estado A_Submitted 
  2. Sistema faz primeira checagem e Rejeita ou Aceita a Solicitação. Uma Solicitação pode ser criada pela organização ser avaliada diretamente sem passar pelo estado A_Submitted 
  3. No caso de rejeição, a Solicitação é automaticamente encerrada com estado A_Denied 
  4. No caso de aceite, a Solicitação passa para estado A_Concept e continua sendo processada 
  5. Funcionário analisa a Solicitação e verifica as informações registradas. Se necessário, contata Cliente para pedir informações adicionais 
  6. Funcionário avalia a Solicitação e conclui pela rejeição ou aprovação 
  7. No caso de rejeição, a Solicitação é encerrada com estado A_Denied 
  8. No caso de aprovação, a Solicitação passa para o estado A_Accepted 
  9. Funcionário cria uma ou mais Propostas de Empréstimo no estado O_Created 
  10. Funcionário envia Proposta ao Cliente (e-mail e/ou correio), a Solicitação passa para o estado A_Complete e a Proposta para o estado O_Sent 
  11. Caso o Cliente não aceite nenhuma Proposta a Solicitação é encerrada no estado A_Denied 
  12. Caso o Cliente desista da Solicitação ou abandone sem dar retorno, a Solicitação é encerrada no estado A_Cancelled 
  13. Caso o Cliente aceite, devolve a Proposta assinada junto com documentos necessários (identificação, renda, etc.). A Solicitação passa para o estado A_Validating, a Proposta é marcada como O_Selected e colocada no estado O_Sent Back 
  14. A Solicitação é novamente analisada e, se necessário, o Cliente é contatado para prestar informações adicionais. Havendo pendências do Cliente a Solicitação é colocada no estado A_Incomplete 
  15. Funcionário avalia a Solicitação para decidir pela rejeição ou aprovação 
  16. No caso de rejeição, a Solicitação é encerrada com estado A_Denied e a Proposta passa para o estado O_Declined 
  17. No caso de aprovação, o Valor do empréstimo é disponibilizado ao Cliente e a Solicitação passa para o estado A_Pending, a Proposta passa para o estado O_Accepted

As intervenções manuais no processo acontecem através de atividades criadas pelo Sistema quando a Solicitação é colocada em determinados estados, e disponibilizadas para serem executadas pelos Funcionários participantes do processo:
  • W_Handle leads – é a primeira verificação automática realizada no registro da Solicitação. Se aprovada aciona Complete application. Na ocorrência de problema técnico esta atividade é redirecionada para execução manual
  • W_Complete application, W_Call incomplete files – correspondem a contatos com o Cliente para completar informações e documentação necessários para a Solicitação
  • W_Call after offers – atividade realizada após envio da Proposta ao Cliente para reiterar oferta, esclarecer dúvidas, etc.
  • W_Validate application – atividade de avaliação do Cliente e Solicitação
  • W_Assess potential fraud – atividades adicionais de avaliação do Cliente e Solicitação
  • W_Shortened completion – é uma atividade acionada quando o Cliente tem perfil de baixo risco que justifica uma avaliação mais simples e rápida
  • W_Personal loan collection - é uma atividade acionada em determinados casos para definição de data de pagamento das prestações

O Log contém todos os eventos referentes às solicitações de empréstimos registradas em 2016 e seu processamento até fevereiro de 2017. No total, contém 1.202.267 eventos, distribuídos nos 3 tipos de fluxos, que se referem a 31.509 Solicitações e 42.995 Propostas. No total, existem 36 eventos distintos distribuídos entre os 3 fluxos.

No Log, os eventos do tipo “A” e “O” registram a data/hora da mudança de estado e seu nome está sempre marcado pelo complemento “complete”, sinalizando que o evento registra o final de uma ação. Os eventos do tipo “W” registram a data/hora de 3 situações possíveis, a colocação da atividade em uma fila (“schedule”), o início de execução da atividade (”start”) e sua finalização (“complete”). 

Os dados de cada Evento são:
  • Etapa do ciclo de vida (ex.: ”start” ,“complete”, “schedule”,...)
  • Nome do evento
  • Recurso responsável pelo evento
  • Data/hora da ocorrência do evento

Os dados da Solicitação são:
  • Identificador da solicitação (ID)
  • Valor solicitado pelo Cliente (euros)
  • Tipo de solicitação
  • Motivo da solicitação

Os dados da Proposta são:
  • Identificador da proposta (ID)
  • Valor da proposta
  • Valor da retirada inicial
  • Número de parcelas para pagamento
  • Custo mensal
  • Pontuação de crédito do cliente
  • Funcionário responsável pela proposta
  • Indicação de que a Proposta foi “selecionada” 
  • Indicação de que a Proposta foi aceita pelo cliente

No próximo post veremos mais detalhes do Log de eventos e padrões de formato para leitura pelas ferramentas de mineração.

Até lá.

Você conhece os autores do Blog Comunidade Áreas de Integração?


quarta-feira, 19 de abril de 2017

O FACIN e a EGD - O Framework de Arquitetura Corporativa

No artigo anterior, apresentamos a Estratégia de Governança Digital (EGD) do Governo Brasileiro. Pensar e agir, nesse modelo de transformação digital, raramente nos permite atuar em um modelo chamado “green-field”, ou seja, refazer completamente novas soluções e serviços “do zero” e de forma integrada e otimizada. Salvo exceções, o custo, esforço e tempo é, muitas vezes, proibitivo.

Desenvolver uma visão global e comum para todas as partes envolvidas em uma iniciativa de transformação digital, a fim de que ações mais pontuais e ágeis, possam coexistir com o ambiente atual, em um plano de longo prazo, é a missão principal das práticas de Arquitetura Corporativa.

Estruturado a partir das novas necessidades que tratam aspectos de interoperabilidade de informação e serviços para a era digital e das práticas de governança, como parte da evolução da ePing, o FACIN - Framework de Arquitetura Corporativa para Interoperabilidade no apoio à Governança – apresenta-se como um conjunto de práticas comuns e necessárias para implementação e operacionalização de soluções e serviços públicos digitais integrados.


O FACIN foi desenvolvido a partir de modelos existentes e atuais de Arquitetura Corporativa orientada a Governo, seguindo uma trajetória comum em diversos países, como parte da evolução dos padrões de apoio ao governo eletrônico, bem como da governança digital. Suas práticas e orientações seguem padrões estabelecidos de mercado, sendo uma das características inovadoras do FACIN a sua orientação aos Serviços Públicos Digitais a partir das necessidades e experiências da Sociedade.

Enquanto framework, o FACIN organiza práticas e componentes de diferentes disciplinas, de forma integrada e simplificada, a fim de assegurar os elementos mínimos e viáveis para o desenvolvimento e oferta de serviços públicos digitais. Não compete ao FACIN a aplicação de todos os padrões existentes e necessários, bem como as definições técnicas e atribuições operacionais individuais de todos os serviços, mas a orientação sobre quais são os elementos vitais e comuns, organizados em nove "Visões", a fim de permitir maior interoperabilidade, eficiência e homogeneidade entre os serviços e atores responsáveis por tais ofertas.

Estruturado em 4 principais componentes - Governança de Arquitetura (como gerir), Método de Desenvolvimento de Arquiteturas (como implantar), Framework de Conteúdo (o que implantar) e Padrões e Modelos de Referência (o que referenciar) – o FACIN representa o  “como fazer”, em relação aos direcionamentos da EGD.

O Framework está em fase de desenvolvimento porém, você pode ter acesso aos Modelos de Referência, disponibilizados anteriormente em Consulta Pública neste link. Sugiro também a leitura dos ótimos e recentes artigos dos parceiros de Blog, Antonio Plais e Hadeliane Iendrike, envolvendo a arquitetura corporativa!

No próximo artigo apresentaremos como o FACIN suporta a EGD.

Comunicando Arquiteturas Corporativas (Parte 1)

Por Antonio Plais (*)

Muito se tem falado aqui neste espaço sobre o tema da “arquitetura corporativa”. Os trabalhos de desenvolvimento do FACIN- Framework de Arquitetura Corporativa para Interoperabilidade no Apoio à Governança estão avançando de forma significativa, rumo à realização das oficinas de validação dos modelos de referência e conteúdo propostos, e atraindo a atenção de outras esferas de Governo (veja aqui).

Na Introdução do documento do FACIN é declarado que “Por meio do estabelecimento da Arquitetura Corporativa e de padrões de interoperabilidade, o FACIN apoiará a Estratégia de Governança Digital Brasileira, ampliando a colaboração entre as organizações do Governo Federal e melhorando a eficiência dos serviços de governo eletrônico para a sociedade (cidadãos, governos, organizações e empresas)”.

O termo “arquitetura corporativa” admite duas interpretações: por um lado, ele pode se referir à estrutura e aos princípios de funcionamento de uma organização, e, por outro, à descrição desta estrutura e destes princípios. Enquanto no primeiro sentido admitimos a ideia de que não possa existir uma organização sem que, de alguma, forma, exista uma arquitetura subjacente (mesmo que não documentada), no segundo sentido está clara a necessidade de algum método de descrição desta arquitetura. O FACIN é, desta forma, uma proposta de criação de um método comum de descrição das arquiteturas corporativas das organizações governamentais. Sendo assim, em última instância, o FACIN descreve um conjunto de conceitos, técnicas e artefatos que proporcionem a COMUNICAÇÃO das descrições das arquiteturas corporativas das várias organizações, permitindo que, através de uma linguagem comum, estas organizações possam efetivamente colaborar para a melhoria dos serviços prestados à Sociedade.

Esta discussão inicial nos leva, então, ao tema desta série de artigos: como comunicar arquiteturas corporativas? Que tipo de conhecimento é necessário transmitir, com qual objetivo, para quem?

Descrever uma arquitetura é comunicar

“Descrever arquiteturas tem a ver com a comunicação. Se alguma descrição de arquitetura não é usada como meio de comunicação de alguma forma, então esta descrição não deveria jamais ter sido criada” (Erik Proper)
O padrão IEE 1471 (2000) relaciona uma série de usos potenciais para descrições da arquitetura corporativa:

  • Expressão de um sistema e sua (potencial) evolução
  • Análise de arquiteturas alternativas
  • Planejamento de negócios para fazer a transição de uma arquitetura legada para uma nova arquitetura
  • Comunicação entre organizações envolvidas no desenvolvimento, produção, estabelecimento, operação e manutenção de um sistema
  • Comunicação entre adquirentes e desenvolvedores como parte da negociação de contratos
  • Critérios para a certificação da conformidade da implementação de arquiteturas
  • Desenvolvimento e manutenção de documentação, incluindo material para repositório de reuso e material de treinamento
  • Entrada para o subsequente desenho de sistemas e atividades de desenvolvimento
  • Planejamento e suporte para orçamento
  • Revisão, análise e avaliação do sistema ao longo do seu ciclo de vida
  • Especificação para um grupo de sistemas que compartilham um mesmo conjunto de funcionalidades

Cada um destes usos da arquitetura envolve a comunicação. A comunicação proporciona a interoperabilidade. A interoperabilidade leva à evolução e ao aumento da eficiência!

Cabe notar, aqui, que o termo “sistema” é usado acima em um sentido amplo, e não apenas restrito a sistemas de informática. Um sistema é definido como:
“Uma coleção de componentes organizados para desempenhar uma função, ou conjunto de funções, específica. O termo sistema abrange aplicativos individuais, sistemas no sentido tradicional, subsistemas, sistemas de sistemas, linhas de produção, famílias de produtos, organizações completas, e outras agregações de interesses” (IEEE 1471)
Para a descrição de arquiteturas, diversas formas de comunicação podem ser usadas: textual, verbal, visual, ou qualquer combinação destas. Independente da forma utilizada, uma série de condições e requisitos se aplicam. Para definir os requisitos para a comunicação das arquiteturas, vários fatores devem ser levados em consideração: os objetivos da comunicação, as preocupações que devem ser endereçadas, os objetivos do desenvolvimento do sistema, as metas, habilidades e atitudes dos atores envolvidos, etc.

Próximos passos

Na continuação desta série de artigos, vamos discutir:
  • O desenvolvimento de sistemas como um processo de transformação do conhecimento
  • Estratégias de conversação (para a comunicação em geral)
  • Conversações para a comunicação da arquitetura
  • A linguagem ArchiMate como meio de descrição de arquiteturas

Até a próxima!!

(*) Baseado no livro Enterprise Architecture at Work, 4ª edição (2017), Marc Lankhorst et al

terça-feira, 18 de abril de 2017

A Arte de Modelar


Aqui eu comento sobre a arte de pintar e finalizo questionando sobre a analogia entre a pintura e a modelagem da arquitetura corporativa.

O ponto é que quando desejamos modelar algo, como, por exemplo, a arquitetura corporativa de uma empresa, primeiro é necessário saber sobre qual realidade o modelo será construído, ou seja, a “coisa” existente na realidade que será representada. Depois precisamos ter o conceito, ou seja, a abstração que será feita para traduzirmos a realidade. E por último, o símbolo que utilizaremos nessa representação, ou seja, os instrumentos que serão utilizados.



Esses três aspectos estão totalmente interligados em qualquer modelagem que façamos. Outra analogia que podemos utilizar é a fala, visto que esta também pode ser vista como uma forma de modelagem. Nela temos o “do que” estamos falando – a realidade –, o conceito que ele representa e o símbolo que utilizamos que é o idioma, ou seja, as palavras em si. Repare que quando fazemos uma tradução, estamos mudando apenas os símbolos. Os conceitos e a coisa continuam os mesmos e é justamente por isso que conseguimos nos comunicar.

Arquitetura Corporativa é, em essência, os modelos que representam uma organização. É claro que temos todas as práticas associadas à construção e uso desses modelos, mas não temos como praticar Arquitetura Corporativa sem modelagem.

Analise, por exemplo, o diagrama abaixo:



Essa imagem, apresentada dessa forma, sem que digamos sobre qual realidade ela está se referindo, sem indicarmos os conceitos que estão sendo abstraídos e sem identificarmos a linguagem que utilizamos, tem seu poder de representatividade reduzido a retângulos coloridos!


Essa é a Arte de Modelar!

quinta-feira, 13 de abril de 2017

Modelo de Maturidade em Governança Corporativa e a Lei das Estatais - Parte 3

No post anterior abordamos algumas práticas do Nível 2 - Expandido de Maturidade em Governança Corporativa, o roteiro de recomendações proposto pela Lei das Estatais, o Decreto nº 47.154 e o FACIN.

Nesta postagem abordaremos o alinhamento das demais práticas do Nível 3 - Institucionalizado de Maturidade, com a legislação e com o FACIN, para que possam ser aplicadas nas empresas públicas através do Modelo em Rede de Maturidade em Governança Corporativa.

O Modelo da figura 1 pode ser acessado em: https://kumu.io/Guto/maturidade-em-governanca 

Figura 1 – Dimensões e Níveis de Maturidade em Governança 

O modelo é constituído de dois componentes: elementos e conexões. Navegue por ele selecionando a Dimensão ou o Nível que deseja visualizar, com um clique do lado esquerdo da tela, para filtrar as práticas diretamente relacionadas.

Em seguida selecione o elemento, clicando sobre a bola do lado direito, para acessar as práticas relacionadas aos níveis de maturidade e os respectivos Capítulos, Seções e Artigos do Decreto, de acordo com a figura 2.

Figura 2 – Detalhamento das práticas relacionadas aos níveis e o Decreto

Para voltar à tela inicial basta clicar em qualquer lugar vazio do lado direito da tela.

Os elementos são conceituados de acordo com sua especificidade e são relacionados a outros elementos por intermédio de conexões.

As conexões são estabelecidas de acordo com o elo de ligação entre os elementos identificados no modelo objeto dessa avaliação.

Siglas utilizadas nesse artigo: Conselho de Administração (CA), Comitê de Auditoria Estatutário (CAE), Conselho Fiscal (CF), Governança Corporativa (GC), Assembléia Geral (AG) e Recursos Humanos (RH).

O mapa com as Práticas do Nível 3 - Institucionalizado de Maturidade foi desenhado de acordo com a figura 3.

Figura 3 – Mapa das Práticas do Nível 3 - Institucionalizado de Maturidade

O mapa destaca as conexões do Nível 3 - Institucionalizado de Maturidade com as seguintes Práticas:

A remuneração paga à Diretoria, ao CA e ao CF é divulgada em blocos distintos.
Decreto nº 47.154 - Capítulo II - Do regime societário das empresas estatais
Seção II - Da gestão de riscos e controle interno
Artigo 19, inciso I

CA e CF têm orçamentos próprios e autonomia para gerenciá-los.
Decreto nº 47.154 - Capítulo II - Do regime societário das empresas estatais
Seção IX - Do Comitê de Auditoria Estatutário
Artigo 36, § 7º

Cargos de Diretor-Presidente e Presidente do CA não são ocupados pela mesma pessoa.
Decreto nº 47.154 - Capítulo II - Do regime societário das empresas estatais
Seção III - Do estatuto
Artigo 21, inciso VII

Há canal direto de comunicação com o CA (ouvidoria e/ou canal denúncias).
Decreto nº 47.154 - Capítulo II - Do regime societário das empresas estatais
Seção II - Da gestão de riscos e controle interno
Artigo 18, incisos III e IV

Há política de operações com partes relacionadas.
Decreto nº 47.154 - Capítulo II - Do regime societário das empresas estatais
Seção I - Das normas gerais
Artigo 13, inciso VII

Há política de prevenção e combate a atos ilícitos.
Decreto nº 47.154 - Capítulo II - Do regime societário das empresas estatais
Seção II - Da gestão de riscos e controle interno
Artigos 18, incisos II, V e VI e 20
Seção VIII - Do Conselho de Administração
Artigo 29, inciso I

Há política sobre atos gratuitos.
Decreto nº 47.154 - Capítulo II - Do regime societário das empresas estatais
Seção II - Da gestão de riscos e controle interno
Artigo 18, inciso I

Há políticas de divulgação de informações e uso de informações privilegiadas (insider information).
Decreto nº 47.154 - Capítulo II - Do regime societário das empresas estatais
Seção I - Das normas gerais
Artigo 13, incisos IV e VIII
Seção VIII - Do Conselho de Administração
Artigo 29, inciso III

Há procedimento sistemático de convocação, realização de reunião e registro de deliberações em AG, reuniões do CA, reuniões do CF e Comitês.
Decreto nº 47.154 - Capítulo II - Do regime societário das empresas estatais
Seção IX - Do Comitê de Auditoria Estatutário
Artigo 36, § 3º ao § 6º

Há profissional ou área dedicada ao tema GC.

Há, como um dos comitês de assessoramento ao CA, o Comitê de Auditoria.
Decreto nº 47.154 - Capítulo II - Do regime societário das empresas estatais
Seção II - Da gestão de riscos e controle interno
Artigo 15, inciso III e 17, incisos I e III 

Há, como um dos comitês de assessoramento ao CA, o Comitê de GC.

Há, como um dos comitês de assessoramento ao CA, o Comitê de RH e remuneração.

O CA e o CF têm agendas anuais de prioridades e calendário de reuniões.

O CA é o principal componente do sistema de GC da Companhia e seu principal protetor.
Decreto nº 47.154 - Capítulo II - Do regime societário das empresas estatais
Seção VIII - Do Conselho de Administração
Artigo 29, inciso I

Visões do FACIN relacionadas aos Artigos do Decreto 47.154:
Governança, Risco e Conformidade: 13, 15, 17, 18, 19, 21, 29 e 36
Dados: 13, 19 e 36
Aplicações: 13, 19 e 36
Infraestrutura: 13, 19 e 36
Segurança: 13, 19 e 36

Acesse aqui o detalhamento completo das práticas de governança.

No próximo artigo abordaremos as práticas do Nível 4 - Aprimorado de Maturidade em Governança Corporativa, fiquem ligados! 

Autores: Guttenberg Ferreira Passos, João Souza Neto e Pedro Bramont