quinta-feira, 25 de maio de 2017

Planejamento das Entregas em conformidade com a Lei das Estatais - Parte 1

Na série Modelo de Maturidade em Governança Corporativa e a Lei das Estatais abordamos o alinhamento entre o roteiro de recomendações proposto pelo Decreto nº 47.154, as boas práticas em Governança Corporativa e o FACIN.

Já sabemos o que temos que fazer, nesta nova série abordaremos uma proposta de como fazê-lo para que possamos estar em conformidade com a Lei no dia 01 de julho de 2018.

Sugerimos inicialmente a criação de um Comitê de Governança Corporativa para liderar o processo de adequação.

Após a identificação do alinhamento entre o roteiro de recomendações e as boas práticas de Governança Corporativa inicia-se a fase de implementação nas empresas públicas.

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

Essa fase é composta de entregas que são relacionadas às práticas do Nível 1 - Iniciado de Maturidade e priorizadas de acordo com a Matriz RACI de Responsabilidades destacadas na figura 1.

Figura 1 – Entregas do Nível 1 - Iniciado de Maturidade

O mapa destaca as entregas do Nível 1 - Iniciado de Maturidade relacionadas com as seguintes Práticas:

·        A companhia possui um CA.
§  Regimento CA
o   Estatuto Social
o   Política de Transações
o   Análise de Riscos
o   Análise de Atendimento das Metas
o   Planejamento Estratégico
o   Estratégia de Longo Prazo
o   Política de Divulgação
o   Plano de Negócios
o   Política de Gestão de Pessoas
o   Código de Ética

·        A companhia possui um CAE.
§  Regimento CAE
o   Processo de Avaliação dos Administradores
o   Relatório Anual CAE
o   Canal de Denúncias
o   Análise de Riscos
o   Política de Transações
o   Estatuto Social
o   Área de Integridade e Riscos
o   Demonstrações Financeiras

·        As demonstrações financeiras são auditadas por auditor totalmente independente da gestão: contratação, destituição, honorários, escopo e avaliação.
§  Demonstrações Financeiras

·        Matriz RACI 1 – Entregas priorizadas para o nível 1:
§  Planejamento Estratégico
§  Código de Ética
§  Plano de Negócios
§  Análise de Riscos e Oportunidades (Estratégia de Longo Prazo)

O planejamento da execução de cada entrega do Nível 1 pode ser acompanhado pelo Comitê de Governança Corporativa através da seguinte matriz:

Figura 2 – Matriz RACI das Entregas do Nível 1 - Iniciado de Maturidade

A entrega Planejamento Estratégico está relacionada com a visão Estratégia do FACIN.

Acesse aqui o detalhamento completo das práticas de governança e suas respectivas entregas em conformidade com a Lei.

No próximo artigo abordaremos as entregas referentes às práticas do Nível 2 Expandido de Maturidade em Governança Corporativa, não percam!

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

terça-feira, 23 de maio de 2017

Transparência como estímulo a uma Sociedade mais participativa - Melhor entendimento aumenta a participação

Hoje vou falar sobre como a Transparência Pública pode ajudar a incentivar o envolvimento e participação da Sociedade em questões públicas.

Existem discussões sobre como conversas sobre os serviços públicos e como eles são oferecidos pode tornar mais estreitos os laços entre Sociedade e Governo. No Brasil, existem iniciativas governamentais que focam em fornecer informações sobre os serviços públicos, afim de estimular o maior envolvimento da Sociedade nestas questões. Fazendo uma rápida busca na internet é possível identificar uma série de iniciativas, algumas que foram ficando pelo meio do caminho e outras ganhando força. [1][2][3]

Uma iniciativa, talvez simples porém importante, é a "Carta dos Serviços", documento que deve ser preparado por qualquer instituição pública para informar os cidadãos sobre o tipo de serviços oferecidos, como acessá-los e como esta organização pública se compromete a fornecê-los. Outra iniciativa compreende consultas públicas, a fim de coletar contribuições da Sociedade sobre ações a serem realizadas em diferentes questões públicas.

Enfim, existem diferentes níveis de participação em contextos democráticos através do uso das TICs (tecnologias de informação e comunicação). Essas classificações mostram o grau de participação democrática em uma escala, desde a provisão de informações governamentais (como é o caso da Carta de Serviços) até a deliberação pública (como é o caso dos sites de consultas públicas como o Participa.br e diversos apps que focam em assuntos específicos do universo público). A cada nível, a participação, a discussão e o poder de decisão são aumentados.

Vou citar um trabalho[4] bastante interessante, e que foca no nível mais básico de participação democrática que é o de prover informações básicas sobre serviços públicos.

Normalmente o que se vê nos sites dos governos é um link para “Contato”, ou ainda, “Fale conosco”. Os cidadãos podem enviar mensagens pré-classificadas (sugestões, elogios, críticas, etc.) para serem recebidos por um agente público interno, e podem ser respondidos ou não, de acordo com a política de relacionamento da organização pública. Porém, apesar de termos avançado na oferta de serviços públicos de forma digital e de oferecer formas de comunicação do cidadão com o Governo, ainda estamos engatinhando em uma cultura mais participativa onde o cidadão discute com o Governo sobre o serviço prestado.

Neste trabalho que cito como exemplo vejam a proposta simples de uma ferramenta para apoiar a discussão e compartilhamento de informações sobre processos públicos que também permite o uso de informações de conversas dos usuários para identificar melhorias nos serviços. 

Veja a figura abaixo de um processo (desculpem, mas está em inglês pois o trabalho foi publicado em um veículo internacional). Uma estudante, clicou em um serviço (de uma lista de serviços oferecidos pela Universidade) para saber como proceder para realizar o registro em disciplinas para o próximo período letivo. Ela se depara com uma descrição gráfica e textual de todos os passos deste procedimento e após ler começar a ter dúvidas sobre o mesmo.
O que aconteceu é que no último semestre o sistema teve um problema e não completou o registro dela em uma disciplina. Ela só descobriu isso quando não encontrou seu nome na lista de disciplina. Ela acredita que um passo está faltando no procedimento pelo qual os alunos nessa situação são informados desta situação. Mas como comunicar esta situação?

Ela nota então que existem 3 tipos de círculos em cores diferentes e curiosa ela clica e nota que eles marcam comentários positivos, neutros e negativos sobre os passos do procedimento de registro em disciplinas.

Lendo seu conteúdo (a), ela descobriu que eles estavam relacionados com o "registro de veteranos na disciplina" e que tinham sido feitos por membros do colégio (Mark era seu professor e diretor do colégio e John era um Estudante veterano que foi a disciplinas com ela). E é possível estabelecer um diálogo entre as pessoas (b).


Ela acha interessante e descobre que pode inserir suas próprias sugestões.
   
A proposta dos autores ajuda a organizar as sugestões e críticas dentro do contexto de uma atividade do serviço que é prestado (provendo inclusive estatísticas), o que ajuda a organizá-las para análise de melhoria do serviço prestado. 

Claro que a primeira coisa que eu penso é: E se me deparar com 300 comentários? Como analisar? Ah! Já existem mil técnicas e tecnologias baratas e disponível para análise de linguagem natural em textos não estruturados. Mas isso fica para um próxima conversa! 

Este exemplo mostra como precisamos sim pensar em abordagens mais complexas e completas para apoiar a participação democrática através do uso de TIC, mas como podemos começar com coisas simples. O custo é baixíssimo. 

Basta boa vontade. 

Até a próxima!





[2] http://g1.globo.com/tecnologia/noticia/2014/04/prefeituras-comecam-usar-app-para-receber-reclamacao-de-cidadaos.html

[4] Bruna Dirr, Renata Araujo and Claudia Cappelli, 2011, Talking about Public Service Processes, Third IFIP WG 8.5 International Conference, ePart 201,  pp. 252- 261, Delft, The Netherlands

segunda-feira, 22 de maio de 2017

Lei de Acesso à Informação: 5 anos de avanços, desafios e oportunidades - Parte 02

Por Thiago Ávila

Dando continuidade à série de três artigos sobre os avanços, desafios e oportunidades dos 5 anos da Lei de Acesso à Informação do Brasil, neste artigo vamos explorar alguns dos principais desafios para a ampla consolidação desta moderna lei em todo o Brasil.



No artigoanterior, apresentamos o que representa a Lei de Acesso à Informação do Brasil(Lei Federal 12.527/2011[1])bem como pontuamos os grandes avanços conquistados e fortalecidos com o adventodesta legislação. Por outro lado, apesar dos avanços consideráveis, ainda há muito o que fazer para que a LAI atinja a sua plena consolidação. Dentre os principais desafios pontuamos os seguintes:

1. O cumprimento da LAI deve ser visto como um dever cívico e uma oportunidade de melhoria da administração pública - Infelizmente, considerando especialmente alguns casos de insucesso no acesso a informações públicas, o cumprimento da Lei de Acesso à Informação ainda é visto apenas como uma obrigação legal e não como uma oportunidade de melhoria no relacionamento Governo-Sociedade. A partir da oferta e dos pedidos de informação, o Poder Público passa a dispor de uma grande oportunidade de direcionar suas políticas aos anseios da sociedade de forma mais direta, priorizando seus esforços para o que a sociedade mais demanda. Além disso, a LAI funciona como um importante instrumento de compliance na Administração Pública, considerando que todas as ações do Estado passam a estar disponíveis ao escrutínio público, contribuindo para a prevenção da corrupção e o maior zelo com a coisa pública;

2. A administração pública precisa ser transparente e aberta prioritariamente de forma ativa, e não passiva - Apesar do bom funcionamento do Serviço de Informação ao Cidadão, apenas no Governo Federal, foram gerados quase 500 mil pedidos de acesso à informação através do SIC[2]. E consequentemente, um esforço gigante para o atendimento de todo este volume de pedidos. A ampliação de plataformas de dados públicos, como os Portais de Dados Abertos e outros sistemas de informações governamentais, visa evitar que o cidadão precise solicitar a informação, esperando pelo menos 20 dias para recebe-la (conforme determina a lei), dispondo de tal informação em tempo real;

3. A LAI precisa ser cumprida efetivamente em toda a administração pública brasileira, em nível Federal, Estadual e Municipal, no Executivo, Legislativo, Judiciário, Ministério Público e Cortes de Contas - Sem dúvida este é um dos maiores desafios do cumprimento da Lei de Acesso à Informação. Segundo a última edição do Ranking da Transparência do MPF, o Brasil alcançou apenas um índice nacional de 5,21, numa escala de 0 a 10.0. Este mesmo Ranking destaca que, apesar da Administração Pública Estadual ter apresentado boas notas no geral, as Administrações Públicas Municipais ainda deixam muito a desejar em todo o Brasil. A título de exemplo, o Executivo Estadual de Alagoas obteve nota 9,8 nesta escala (2º lugar no ranking), entretanto, a média da nota dos 102 municípios alagoanos foi de apenas 3,10 (26º lugar no ranking).




a.    Em relação aos demais Poderes, ainda há muito o que avançar. Segundo a Estratégia Nacional de Combate a Corrupção - ENCCLA[3], apenas 8 dos 27 Tribunais de Contas Estaduais obtiveram notas boas ou ótimas (acima de 70 pontos) no Índice de Transparência do ano de 2016. No Poder Legislativo a situação é ainda mais grave, pois apenas o Legislativo do Estado de Santa Catarina obteve uma nota considerada boa. Além disso, a ENCCLA sequer conseguiu obter dados para avaliar o Legislativo dos Estados do DF, ES, MA, MG, MS, PA, PR, RJ, SE e SP. Já nos legislativos das capitais dos estados, apenas o município de Porto Alegre obteve uma nota considerada como boa.



b.    Por outro lado, segundo o mesmo estudo, o Ministério Público obteve uma avaliação bastante satisfatória em todas as suas representações, em nível estadual e federal, com todas as instituições obtendo notas acima de 80 pontos.

4. A transparência ativa precisa priorizar a oferta de Dados Abertos – Apesar do artigo 8º, §3, incisos II e III da Lei de Acesso à Informação serem muito claros quanto a obrigatoriedade de que todos os dados públicos sejam disponibilizados em vários formatos, preferencialmente não proprietários e processáveis por máquina, a grande maioria das instituições públicas brasileiras ainda não prioriza o cumprimento deste mandamento legal de forma estruturada com a criação de Portais de Dados Abertos. Segundo estudo elaborado pelo Governo de São Paulo, além do Portal Brasileiro de Dados Abertos (www.dados.gov.br), apenas os Estados de Alagoas, Espírito Santo, Goiás, Pernambuco, Minas Gerais, Rio Grande do Sul e São Paulo possuem portais estaduais de Dados Abertos (no Rio Grande do Norte, o portal é da Universidade Federal do Rio Grande do Norte). No nível municipal, apenas 6 dos 5.565 municípios brasileiros já possuem portais municipais de Dados Abertos.


No terceiro e último artigo desta série iremos explorar as oportunidades que a Lei de Acesso à Informação no Brasil está trazendo para a sociedade brasileira. Até a próxima!!!           



[1] http://www.planalto.gov.br/ccivil_03/_ato2011-2014/2011/lei/l12527.htm
[2] https://esic.cgu.gov.br/sistema/Relatorios/Anual/RelatorioAnualPedidos.aspx
[3] http://www.justica.gov.br/noticias/enccla-divulga-ranking-da-transparencia-dos-tribunais-de-contas-ministerio-publico-e-poder-legislativo/indice.pdf

sexta-feira, 19 de maio de 2017

Estudo de caso aberto em mineração de processos – parte 4

Nos posts anteriores vimos uma descrição resumida do processo de aprovação de empréstimo pessoal proposto no Business Process Intelligence Challenge 2017. Agora, aplicaremos as ferramentas de mineração para produzir automaticamente modelos do processo com base no Log de eventos.

Neste post, usaremos como ferramenta de análise o Celonis, um dos dois produtos comerciais que disponibilizaram licenças temporárias para participantes do desafio. Porém, não cabe aqui entrar em detalhes sobre como importar o Log de eventos fornecido ou como operar a ferramenta, vamos direto aos resultados.


Começamos mostrando um diagrama de processo gerado pela ferramenta, onde os eventos de cada fluxo estão diferenciados pela cor: laranja para o fluxo da Solicitação, verde para o fluxo da Proposta e azul para o Workflow. Notem que os 4 segmentos verticais foram recortados de uma figura maior, por isso os círculos vermelhos numerados foram acrescentados para dar continuidade na sequência de atividades entre os segmentos.
Os números junto ao nome do evento indicam sua frequência de ocorrência no Log. Por exemplo, o primeiro evento do diagrama (A_Create Application) foi executado 31.509 vezes, enquanto que o último (A_Pending) foi executado 17.228 vezes. Os números nas setas que interligam os eventos indicam o número de vezes que tal caminho foi seguido no Log. Por exemplo, o caminho que sai do evento A_Create Application foi percorrido 7.697 vezes, enquanto que o caminho que sai do evento A_Concept foi seguido 9.231 vezes.

O leitor atento notará que os números nesse diagrama parecem inconsistentes. Por exemplo, a frequência indicada nos caminhos é menor que a dos eventos na origem e destino, e a frequência dos eventos varia ao longo do diagrama sem justificativa aparente.

Na verdade, o diagrama mostrado é uma visão simplificada do processo. Ele mostra apenas o mínimo de eventos e caminhos necessários para representar o processo do início ao fim. Pode-se dizer que é o diagrama mínimo do processo, onde apenas os principais eventos registrados e caminhos seguidos são mostrados.

Essa versão simplificada do processo inicia pelo Cliente criando uma Solicitação de empréstimo na web (A_Create Application), seguida por uma primeira verificação que rejeita ou aceita a Solicitação (A_Concept). Após avaliação por um agente de Atendimento (W_Complete application) uma Proposta é gerada para as Solicitações aceitas (A_Accepted e O_Created) e enviada ao Cliente (O_Sent e A_Complete). Enquanto o Cliente avalia a Proposta o agente contata o Cliente para prestar informações e resolver dúvidas (W_Call after offers). Quando o Cliente devolve a Proposta assinada (O_Returned) uma avaliação final é realizada para aprovação da Proposta e Solicitação (O_Accepted e A_Pending).

Pelos números do diagrama vemos que 31.050 Solicitações de empréstimo foram processadas e 31.362 Propostas foram apresentadas aos clientes, sendo que 21.768 foram aceitas pelo cliente, mas apenas 17.228 foram aprovadas para concessão do empréstimo, resultando em uma conversão de 55,48% das Solicitações.


Mas é só isso? É fácil ver que não estão no diagrama os eventos e caminhos dos casos em que a Solicitação é rejeitada (A_Denied e O_Declined), ou quando existem pendências de documentação do Cliente (A_Incomplete). Não posso ver o processo completo, com todas suas atividades e caminhos?


Sim, pode. Mas não em um diagrama possível de ser apresentado nesta página. Na vida real, os processos de negócio costumam ser mais complexos do que transparece nos diagramas convencionais que são produzidos nas atividades de modelagem e documentação. Ao se trabalhar com um grande número de execuções do processo, as variações possíveis nas sequências de execução das atividades frequentemente resultam em um número excessivo de linhas que transformam qualquer diagrama em um emaranhado incompreensível de fios.


Para lidar com essa complexidade, as ferramentas de mineração oferecem funcionalidades para segmentar e filtrar os casos de processos em análise. Esses mecanismos podem ser implícitos ou explícitos. No exemplo acima aplicamos um filtro implícito, reduzindo a zero a frequência dos eventos e caminhos e deixando que o algoritmo da ferramenta encontre o mínimo de eventos e caminhos necessários para construir o diagrama.


Um exemplo de aplicação de filtro explícito segue no diagrama abaixo, onde restringimos o diagrama apenas aos eventos da Solicitação (A_*), excluindo os da Proposta (O_*) e os do Workflow (W_*). Além disso, conforme mostram os controles na margem direita da figura, definimos que devem ser mostrados 100% dos eventos e caminhos associados.
Apesar de menor, o nível de detalhamento nesse diagrama visivelmente aumentou. Agora todos os eventos do fluxo Solicitação estão presentes e surgem diversas alternativas de caminhos que não estavam visíveis no diagrama anterior. Inclusive os que tratam os casos em que se pede mais informações ao cliente (A_Incomplete), os casos em que o cliente abandona o pedido (A_Cancelled) e os casos rejeitados pela organização (A_Denied).


Notem também que a legenda nos caminhos agora aponta o intervalo de tempo entre os eventos de origem e destino, no lugar da frequência de execução do caminho mostrado no primeiro diagrama. Além disso, a cor e a espessura com que o caminho é desenhado varia conforme o valor desse intervalo, dando maior destaque aos caminhos potencialmente mais problemáticos em termos de desempenho do processo.


Como último exemplo segue abaixo outro diagrama, onde agora apresentamos apenas os eventos da Proposta (O_*), de novo com os controles de complexidade regulados para mostrar 100% dos eventos e caminhos associados. Mais uma vez é visível o aumento de complexidade do diagrama ao mostrar todas as variações de caminhos seguidas pelo processo extraído no Log.

Com os dois exemplos acima deve ficar mais claro porque um diagrama que apresente simultaneamente a interação entre os 3 fluxos com 100% de detalhamento, só é viável de visualizar diretamente na tela da ferramenta de mineração, onde podemos contar com funcionalidades de zoom e navegação. De certa forma, acontece como na visualização de mapas, onde o nível de detalhamento mostrado é aumentado ou reduzido, na medida em que se aumenta ou diminui a área geográfica visualizada.


No próximo post trataremos de responder às questões colocadas pela organização dona do processo.



Até o próximo post.

 

quinta-feira, 18 de maio de 2017

O FACIN e a EGD - A relação entre seus Princípios (parte 2)

Olá! No artigo anterior apresentamos a tabela abaixo, indicando a correlação entre os Princípios da EGD - Estratégia de Governança Digital - e do FACIN - Framework de Arquitetura Corporativa para Interoperabilidade em Apoio à Governança.

Para um melhor entendimento sobre a correlação existente entre tais Princípios, no artigo de hoje detalharemos cada um deles.

Princípios da EGD

Foram definidos nove Princípios que orientarão as atividades de governança digital na APF:

1. Foco nas necessidades da sociedade: as necessidades da sociedade, tanto de pessoas físicas quanto jurídicas, são os principais insumos para o desenho e a entrega de serviços públicos digitais.
2. Abertura e transparência: ressalvado o disposto em legislação específica, dados e informações são ativos públicos que devem estar disponíveis para a sociedade, de modo a dar transparência e publicidade à aplicação dos recursos públicos nos programas e serviços, gerando benefícios sociais e econômicos.
3. Compartilhamento da capacidade de serviço: órgãos e entidades deverão compartilhar infraestrutura, sistemas, serviços e dados, de forma a evitar duplicação de esforços, eliminar desperdícios e custos e reduzir a fragmentação da informação em silos.
4. Simplicidade: reduzir a complexidade, a fragmentação e a duplicação das informações e dos serviços públicos digitais, otimizando processos de negócio, com foco na eficiência da prestação de serviços à sociedade.
5. Priorização de serviços públicos disponibilizados em meio digital: sempre que possível, os serviços públicos serão oferecidos em meios digitais, sendo disponibilizados para o maior número possível de dispositivos e plataformas.
6. Segurança e privacidade: os serviços públicos digitais devem propiciar disponibilidade, integridade, confidencialidade e autenticidade dos dados e informações, além de proteger o sigilo e a privacidade pessoais dos cidadãos na forma da legislação.
7. Participação e controle social: possibilitar a colaboração dos cidadãos em todas as fases do ciclo das políticas públicas e na criação e melhoria dos serviços públicos. Órgãos e entidades públicas devem ser transparentes e dar publicidade à aplicação dos recursos públicos nos programas e serviços do Governo Federal, fornecendo informação de forma tempestiva, confiável e acurada para que o cidadão possa supervisionar a atuação do governo.
8. Governo como plataforma: o governo deve constituir-se como uma plataforma aberta, sobre a qual os diversos atores sociais possam construir suas aplicações tecnológicas para a prestação de serviços e o desenvolvimento social e econômico do país, permitindo a expansão e a inovação.
9. Inovação: devem ser buscadas soluções inovadoras que resultem em melhoria dos serviços públicos.

Princípios do FACIN

As organizações que adotarem o FACIN devem se preparar para aderir aos Princípios aqui descritos. Tais Princípios direcionam a criação e uso do framework, de forma que as necessidades de integração e interoperabilidade sejam atendidas. Dessa forma, ao desenvolver e ofertar serviços de TIC – ou baseados em TIC, tais Princípios devem ser considerados:

1. Centrado na sociedade: Que corresponde a ver o governo de fora para dentro, ou seja, a compreensão das necessidades e expectativas da sociedade torna-se o princípio orientador preeminente para todos os serviços de governo.
2. Infraestrutura comum e interoperabilidade: Refere-se ao uso de padrões e melhores práticas entre os órgãos de governo de modo a incentivar e possibilitar o compartilhamento de informações e serviços de forma contínua.
3. Desenho Integrado de Serviços Públicos: No âmbito de Governo Conectado é requerido que órgãos públicos colaborem entre si, com uso compartilhado de serviços de TI, evitando sua duplicação, o que se dá com práticas integradas de desenho de serviço. 
4. Governança Pública (setor público): Governança no setor público compreende essencialmente os mecanismos de liderança, estratégia e controle postos em prática para avaliar, direcionar e monitorar a atuação da gestão, com vistas à condução de políticas públicas e à prestação de serviços de interesse da sociedade, inerentes ao Governo Conectado.
5. Entregar valor para os cidadãos e as empresas: Os serviços públicos digitais (baseados em TIC) devem definir e publicar suas métricas qualitativas à sociedade, como parte complementar das cartas de serviços.
6. Transparência e Governo Aberto: Dados e informações são ativos que possuem valor, devem ser gerenciados com segurança e privacidade, mas sempre que apropriado, estar acessíveis para a sociedade.

No próximo, e último artigo da série, mostraremos como o FACIN, através de seus Princípios, vem suportar os Princípios da EGD. 

Até lá!

quarta-feira, 17 de maio de 2017

Comunicando Arquiteturas Corporativas (Parte 2)

Por Antonio Plais (*)

Na nossa postagem anterior  abordamos a importância da arquitetura corporativa para a transmissão do conhecimento sobre a estrutura e o funcionamento das organizações, e para a efetiva melhoria dos seus serviços para a Sociedade. Mostramos como os usos potenciais das descrições da arquitetura envolvem a comunicação, nas suas mais diversas formas: textual, verbal, visual, ou qualquer combinação delas. Nesta postagem, discutiremos o desenvolvimento de sistemas como um processo de transformação do conhecimento.

O desenvolvimento de sistemas como um processo de transformação do conhecimento


O processo de desenvolvimento de sistemas pode ser considerado um processo de transformação do conhecimento, onde conversações são usadas para compartilhar e criar o conhecimento necessário tanto ao sistema sendo construído, como ao próprio processo de desenvolvimento. O termo ‘conversação’, neste contexto, deve ser interpretado no sentido amplo, ou seja, desde uma elicitação um-a-um como uma oficina reunindo diversas partes interessadas, através de qualquer meio de comunicação.

Comunidade de desenvolvimento de sistema


Se o nosso foco está no processo de comunicação, é importante identificar os atores que desempenham um papel na comunicação que ocorre durante o desenvolvimento do sistema. Estes atores provavelmente têm algum interesse em relação ao sistema sendo desenvolvido, como por exemplo, responsáveis pelo problema, futuros usuários do sistema, especialistas de domínio, patrocinadores, arquitetos, engenheiros, analistas de negócio, etc.

No entanto, estes atores não são os únicos ‘objetos’ que desempenham um papel importante no desenvolvimento do sistema. Documentos, modelos, formulários, regulamentos, etc., que representam partes do conhecimento pertinentes ao sistema em desenvolvimento, também são uma classe importante de objetos a serem considerados. O conjunto completo de objetos (atores e conhecimento) que desempenham um papel no desenvolvimento do sistema formam a comunidade de desenvolvimento de sistema.

Os atores em uma comunidade de desenvolvimento de sistema possuem algum interesse específico em relação ao sistema em desenvolvimento. Este interesse implica em interesses relacionados com as (o conteúdo das) descrições do sistema que são comunicadas dentro da comunidade. Estes interesses são definidos pelo padrão ISO/IEC/IEEE42010:2011 como as preocupações das partes interessadas.
Preocupação: um interesse de uma parte interessada em relação à descrição da arquitetura de algum sistema, resultado das metas das partes interessadas, e pelo(s) papel(éis) presente(s) ou futuro(s) desempenhados pelo sistema em relação a estas metas.
Alguns exemplos de preocupações são:
  • A situação atual em relação ao apoio de um sistema computadorizado a um processo de negócio
  • Os requisitos de uma parte interessada em relação a uma situação desejada
  • As melhorias que o novo sistema em desenvolvimento pode trazer, em relação ao custo de aquisição de um sistema padronizado de prateleira
  • O impacto potencial do novo sistema nas atividades dos seus futuros usuários

Conhecimento do desenvolvimento de sistema


A comunicação que acontece dentro de uma comunidade de sistema tem como objetivos essenciais a criação, desenvolvimento e disseminação do conhecimento sobre o sistema que está sendo desenvolvido. Dependendo das suas preocupações, as partes interessadas estarão interessadas em diferentes tópicos deste conhecimento. Mas que tipo de conhecimento é relevante para o desenvolvimento de um sistema ou, em outras palavras, que tópicos de desenvolvimento podem ser distinguidos?

Entre os diferentes tópicos que podem ser criados e compartilhados entre os membros da comunidade de desenvolvimento, podemos distinguir entre o domínio alvo pertencente ao sistema em desenvolvimento, e ao domínio do projeto, do processo, de desenvolvimento em si. Estes dois grandes domínios de conhecimento podem ser refinados em tópicos mais específicos, de acordo com algumas caracterizações:
  • Perspectivas: os artefatos que compõem a descrição do conhecimento podem ser considerados a partir de diferentes perspectivas:
    • Os aspectos de negócio, aplicativos e tecnologia de um sistema de informações (computadorizado)
    • Os aspectos social, simbólico e físico de um sistema
    • Os processos, informações, lógica, atores e tecnologia incorporados em um sistema
A ideia das perspectivas sobre um sistema nos remete ao conceito de ‘ponto de vista’, que é definido como sendo ‘um ponto de vista a partir do qual uma perspectiva de um sistema é descrita’. A definição de um ponto de vista inclui não somente a definição da perspectiva que ele toma em relação ao sistema, mas também a linguagem que será usada para descrever o sistema, bem como orientações sobre a sua construção e interpretação. Em contraste, uma perspectiva é puramente “conceitual”.
  • Escopo: Dado um domínio, podemos identificar diversos escopos para a abordagem do problema: corporativo, departamental, do projeto, ou mesmo de uma atividade específica.
  • Cadeia de desenho: Ao considerar o desenho de um artefato, podemos distinguir algumas características:
    • Propósito: para que propósito o artefato é necessário
    • Funcionalidade: que funcionalidade o artefato deve prover para seu ambiente
    • Desenho: como esta funcionalidade deve ser realizada
    • Qualidade: quão bem ele deve fazer isso
    • Custo: a que custo ele deve fazer isso e qual o custo para o seu desenvolvimento
  • Perspectiva histórica: Dado um artefato como um desenho, podemos distinguir as suas diferentes versões que este desenho pode apresentar ao longo do tempo: a versão corrente que está em uso, uma versão futura que orienta o desenvolvimento do sistema, (o rascunho de) uma versão futura posterior ao desenvolvimento em curso (e que serve como guia para o seu desenvolvimento no longo prazo), e quaisquer outras versões intermediárias. Podemos considerar ainda, no âmbito do próprio processo de desenvolvimento, o planejamento/estratégia de execução que está sendo adotado, e o planejamento/estratégia que estava em uso no passado.
  • Nível de abstração: Quando considerando um domínio, diversos níveis de abstração podem ser utilizados, como, por exemplo, tipo-instância, generalização/especialização, encapsulamento, ocultação de detalhes de implementação etc.
Como mencionado anteriormente, as diferentes partes interessadas podem, dependendo de suas preocupações, estar interessadas em diferentes tópicos do conhecimento. Por exemplo, um executivo financeiro pode estar interessado em uma perspectiva de investimentos, no nível corporativo geral, de um sistema, enquanto um desenhista pode estar interessado em todos os aspectos e detalhes da cadeia de desenho das diversas perspectivas.

Explicitação do conhecimento


Os atores em uma comunidade de desenvolvimento de sistemas precisam comunicar o conhecimento sobre o sistema entre si. No campo do gerenciamento do conhecimento, uma distinção é feita entre o conhecimento tácito e o conhecimento explícito. Este último se refere àquele conhecimento que pode ser representado de alguma forma, e a explicitação do conhecimento sobre o sistema é o processo de codificá-lo (representá-lo) através de algum meio e linguagem, por exemplo, de modelos de arquitetura. O conhecimento tácito, por outro lado, não pode ser facilmente representado através de algum meio, e não é o foco desta discussão.

Descrições da arquitetura (de sistemas) são formas de conhecimento explícito sobre um sistema existente ou futuro: seu desenho, seu processo de desenvolvimento, as considerações subjacentes etc. Considerando este foco, a explicitação do conhecimento pode ser avaliada de acordo com algumas dimensões:
  • Formalidade: indica o tipo de linguagem e o quanto ela é formal (ou seja, sujeita a rígidas regras de semântica) ou informal (como a linguagem natural ou diagramas livres).
  • Quantificabilidade: Diferentes aspectos do artefato sendo desenhado podem ser quantificados através de medidas como, por exemplo, volume, capacidade, carga de trabalho, esforço, recursos, uso, tempo, duração, frequência, etc.
  • Executabilidade: O conhecimento representado pode (quando relativo a artefatos com comportamento operacionais) ser tão explícito que permita sua execução. Esta execução pode tomar a forma de uma simulação, protótipo, animações geradas, ou operação real.
  • Compreensibilidade: A representação do conhecimento deve ser compreensível pela audiência pretendida. Ajustar o nível de compreensibilidade requerido para a representação, em particular a linguagem utilizada, é crucial para o sucesso da comunicação.
  • Completude: A representação do conhecimento pode ser completa, incompleta, ou sobrecompleta em relação ao tópico de conhecimento que ela pretende cobrir.

Transformação do conhecimento


Durante o desenvolvimento do sistema, o conhecimento sobre ele e sobre o seu desenvolvimento evolui. Novas percepções emergem, desenhos são criados, visões são compartilhadas, opiniões são formadas, decisões de desenho são feitas, etc. O conhecimento que está presente na comunidade de desenvolvimento pode ser visto como evoluindo através de vários estados. Ele deve ser, inicialmente, introduzido na comunidade e, em seguida, compartilhado com os membros da comunidade. Este compartilhamento leva a mudanças no “estado do conhecimento” dos atores da comunidade de desenvolvimento, que progridem através dos estágios descritos abaixo:
  • Consciente: Um ator pode se tornar consciente do conhecimento (possível) através do compartilhamento de outro ator.
  • Acordado: Uma vez que o conhecimento é compartilhado, um ator pode fazer sua própria avaliação e decidir concordar ou não com o conhecimento compartilhado.
  • Compromissado: Atores que concordam com um tópico de conhecimento específico podem decidir efetivamente se comprometer com ele. Em outras palavras, eles podem decidir moldar seu comportamento futuro de acordo com este conhecimento.
Não existe uma forma de determinar objetivamente o nível de consciência, concordância ou compromisso de um dado ator ou conjunto de atores com um certo tópico de conhecimento. É uma questão de avaliação, e esta avaliação será feita por (alguns) atores da comunidade de desenvolvimento, e comunicada e discutida de forma aberta e transparente por toda comunidade, de forma a ensejar o entendimento e compromisso de (possivelmente) todos os seus membros.

Próximos passos


Na continuação desta série de artigos, vamos discutir:
  • 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