Modelagem ArchiMate na Prática - BriteLite (Parte 7)

postado em 10 de ago de 2016 08:49 por Antonio Plais   [ 2 de set de 2016 10:05 atualizado‎(s)‎ ]
Publicado originalmente no blog da BiZZdesign, por Bas van Gils & Sven van Dijk. Sua tradução e publicação no blog da Comunidade Centus foi autorizada pelos autores. Uma versão para impressão pode ser acessada na biblioteca da Centus Consultoria.

Na sétima e última postagem desta série, a equipe de Brenda finalmente passa para a fase de definição do roteiro para a arquitetura alvo e o planejamento de sua implantação, e criação de um portfólio de projetos de mudança, finalizando este estudo de caso.

Planejando a realização 

O trabalho de análise de lacunas está em pleno andamento. A equipe concluiu que a abordagem significa "muito trabalho, mas é realizável". Um dos membros da equipe observou, justamente, que "obter e modelar as informações é uma coisa, mas a manutenção será outra". Isto é verdade, e Brenda está feliz que a equipe esteja amadurecendo rapidamente, já pensando no próximo ciclo e mantendo as informações arquitetônicas atualizadas e válidas. Ela decidiu que, por enquanto, o foco deve estar no trabalho atual. No espaço de trabalho da equipe, ela reservou um espaço no quadro para "coisas para resolver no futuro próximo", para se certificar de que não serão esquecidas.

A equipe começou sua análise de lacunas com os sistemas de informação que fazem parte do panorama. Eles mantêm a análise em um nível relativamente alto, e o foco está em mostrar que as funcionalidades do sistema, em grande medida, são equivalentes às funcionalidades existentes, mas os sistemas reais mudarão de acordo com a nova visão e com a arquitetura alvo. Parte da equipe também começou a trabalhar em uma análise de lacunas de alto nível para a camada de negócios, focando nos processos de negócio e nas estruturas departamentais.

Durante a reunião semanal com a Diretoria, Brenda informou que a equipe está quase pronta para pensar sobre a realização da arquitetura. A ideia é configurar um roteiro com platôs, e depois se preocupar com pacotes de trabalho e entregáveis. A fim de conseguir mais apoio, e acelerar o trabalho tanto quanto possível, ela solicitou a ajuda de um dos gerentes de programa da BriteLite. Afinal, o gerenciamento de programas é uma habilidade e disciplina por si só, e a estreita cooperação certamente será benéfica. A Diretoria rapidamente nomeia Matt, que é muito experiente e um grande defensor da abordagem de Brenda.

Todos os caminhos levam a Roma

Juntos, Matt e Brenda trabalham em um informativo para a equipe. Sua primeira prioridade é se certificar de que a equipe compreende que " todos os caminhos levam a Roma"… em outras palavras, há uma escolha a ser feita. Matt apresenta um diagrama simples que - após alguns ajustes propostos por Brenda - se resume ao seguinte:




Ambos estão bem conscientes de que a escolha de uma abordagem exigirá apoio da Diretoria, mas eles estão confiantes de que eles seguirão qualquer proposta que venha da equipe. Cada uma tem suas próprias vantagens e desvantagens. Depois de alguma discussão, eles decidem apresentar isto para a equipe antes de iniciar o planejamento real.

Brenda conhece bem a sua equipe, e garante que isto seja apresentado durante um encontro de almoço, concordando em liderar a discussão. Matt é o tipo de pessoa que busca resultados, e não se importa com isso. Durante a reunião da equipe, a discussão vai e volta. Argumentos são levantados e discutidos para as três abordagens. Por exemplo, a abordagem rápida é considerada muito arriscada, além do fato de que migrações maciças (big-bang) têm uma reputação muito ruim. Uma contra argumentação é levantada: uma abordagem lenta reduzirá o risco, mas não nos levará onde queremos ir rápido o suficiente. Ninguém parece concordar com a abordagem "barata", que é, portanto rapidamente descartada.

Finalmente a equipe concorda com uma abordagem simples:
  • Trabalhar no CRM primeiro: remover todas as “coisas” do antigo CRM e substituí-las de acordo com a nova arquitetura. Este será um grande platô, uma vez que provavelmente incluirá um grande bloco da camada de integração, a solução de MDM, etc.
  • Com o CRM no lugar, as duas próximas iterações devem ser menores e estender o que foi construído na primeira iteração. Primeiro o ERP será construído em cima da infraestrutura, e finalmente os sistemas de produção serão adicionados.
  • A equipe considera que essa abordagem gradual dará segurança adequada, enquanto também caminha para uma solução com velocidade suficiente.
A direção ainda é bastante alto nível, mas fornece uma boa base para o início dos trabalhos de planejamento e roteirização.

Um roteiro de alto nível

Com a abordagem acordada - pelo menos por enquanto - Brenda e Matt voltam à prancheta de desenho. Eles estão usando os resultados da modelagem da linha de base e alvo para rascunhar um roteiro de alto nível como segue:




O cronograma mostra não só os pacotes de trabalho (projetos) a serem executados, como também os platôs: Quando o CRM e o MDM entrarem em operação, nós basicamente passamos do estado de linha de base para o primeiro estado intermediário. Neste momento começaremos a preparar e configurar o sistema ERP, o que nos levará para o segundo estado intermediário quando ele começar a operar, etc.

A equipe também começa a detalhar o roteiro, construindo sobre os modelos e as análises de lacunas feitos na fase anterior. O roteiro completo, descrito pelos platôs e pela ordem na qual eles são organizados (o platô de linha de base dispara o primeiro platô intermédio, etc.), é trazido pela equipe para o modelo de arquitetura. Em um nível detalhado, objetos (aplicativos, nós, software de sistema representando plataformas executando nos nós, etc.) são atribuídos ao roteiro. Isso permite que a equipe execute análises de lacunas em um nível mais detalhado do roteiro. Os exemplos abaixo mostram os (uma parte dos) efeitos da passagem da linha de base para o primeiro estado intermediário, a partir de uma perspectiva da arquitetura da aplicativos, e da perspectiva da implantação, respectivamente:


Do roteiro para o planejamento de programas

Os resultados a partir do roteiro de alto nível são apresentados para a equipe por Matt, com o apoio da Brenda: uma boa conversa durante o jantar para alinhar as ideias de Matt com a forma de trabalho que Brenda tem em mente é toda a preparação que eles precisam. A ideia é que Matt ajudará a configurar o programa, de modo que parece fazer sentido dar a ele uma plataforma para que ele também apresente suas ideias e abordagem. Embora todos concordem que a abordagem é sólida e que a análise é válida no alto nível, a equipe sugere que (a) a análise seja revisada na medida em que mais detalhes se tornarem disponíveis e (b) a Diretoria seja também envolvida na discussão. Intervindo, Brenda concorda, e salienta que ela quer apresentar a abordagem, o roteiro e passos intermédios, e um plano de alto nível do programa como um todo, para a Diretoria assim que possível.

Para dar início à discussão sobre o planejamento, Matt apresenta o diagrama a seguir, que ele preparou junto com Brenda:




A atribuição para a equipe é desenvolver um esboço de decomposição das lacunas entre a linha de base e o primeiro platô intermediário em termos de entregáveis. Matt gostaria que isto fosse tão concreto quanto possível, e incluísse as coisas "duras" (ou seja, sistemas instalados, redes a serem construídas, etc.) bem como os aspectos 'suaves’, tais como treinamento. A equipe recebe uma pilha de notas adesivas para a sua análise, com o aviso de Matt que esta é uma análise preliminar com tempo limitado a metade de um dia.

Depois de estudar cuidadosamente os resultados e agrupar as entrega em pacotes de trabalho em uma sessão de modelagem com Brenda, os resultados que estão prontos para apresentação são os seguintes:



Na linguagem ArchiMate, bem como na ferramenta BiZZdesign Enterprise Studio utilizada pela equipe, a perspectiva de implementação e migração é totalmente integrado. Isto significa que a equipe pode modelar, visualizar e analisar coisas como programas, projetos e estruturas de distribuição do trabalho. O exemplo acima mostra como o trabalho para a Fase 1 é organizado como uma abordagem faseada, que consiste de três etapas executadas em ordem consecutiva. Cada uma das etapas resulta em entregáveis. Não apenas essas estruturas podem ser visualizadas como podem, também, ser naturalmente ligadas a outras partes da arquitetura corporativa. Usando essa abordagem, a equipe pode usar as funcionalidades da ferramenta para executar a análise e apresentar os resultados em, por exemplo, diagramas como abaixo. Os diagramas mostram o resultado de uma análise do impacto das diferentes etapas da Fase 1 da iniciativa de transformação da BriteLite. O primeiro exemplo mostra isto a partir da perspectiva do panorama de aplicativos em escopo para a primeira fase. O segundo exemplo mostra os resultados da mesma análise de impacto, mas a partir da perspectiva da entrega dos pacotes de trabalho, e como eles impactam arquitetura corporativa:



Estas análises realizadas pela equipe definem o ambiente para a próxima fase de planejamento de transformação da BriteLite. A fim de construir um consenso sobre o roteiro entre os membros da equipe de liderança da BriteLite, Matt e Brenda necessitam se concentrar no desenvolvimento do caso de negócios: quais são os custos, resultados de negócio, riscos e requisitos de recursos relacionados com o roteiro. Não é uma tarefa fácil para Matt e Brenda colocar os números corretos no lugar, mas como veremos a seguir, o BiZZdesign Enterprise Studio será de grande ajuda para que a equipe possa adicionar os dados relevantes ao repositório e apresentar visões e painéis de controle convincentes para envolver a Diretoria!

Portfólio de Mudanças 

O burburinho na organização está aumentando à medida que o tempo passa. As pessoas têm notado que a equipe de Brenda está passando de "apenas arquitetura" para a roteirização das mudanças, e há muita conversa em torno da máquina de café sobre a forma como as coisas terão início no futuro (próximo). Através de informativos e participação em reuniões (de gerenciamento), Brenda garante que todos estão atualizados em relação ao andamento dos trabalhos. O "movimento positivo" parece ter efeito, uma vez que não há muita resistência até o momento. Além disso, a boa notícia é que as pessoas estão se acostumando a ver Brenda e Matt juntos, enquanto eles comunicam as próximas alterações. A atmosfera positiva torna mais fácil para eles fazer também as perguntas mais difíceis.

O desafio do Gerenciamento de Projetos

Uma das questões que devem ser abordadas é o acompanhamento da realização dos projetos: A BriteLite não tem uma boa prática de gerenciamento de projetos em uso. Até agora, a maioria dos projetos da BriteLite foram bastante limitados no escopo, com alguns poucos projetos "grandes" em execução ao mesmo tempo. A maioria dos relatórios de andamento são feitos através de gerenciamento por planilhas, com poucos indicadores de desempenho (KPIs) "duros" com dados sólidos para suportar os relatórios. Tanto Matt como Brenda concordam que esta situação tem de mudar. Eles também concordam que é uma má ideia tentar “ferver o oceano”…

Durante a hora do café, Matt mostra a Brenda alguns trabalhos que ele fez em uma atribuição anterior em outra empresa - há décadas. Resumidamente, seus relatórios foram baseados nas seguintes métricas[1]:


Ele afirma, justificadamente, que estas questões tornam possível começar de forma simples e crescer em maturidade na medida em que a capacidade de gerenciamento de programas e projetos amadurece. Em primeiro lugar, essas perguntas podem ser respondidas em uma escala de 5 pontos, e mais tarde métricas mais elaboradas podem ser utilizadas para medir o desempenho de execução dos projetos. Brenda - naturalmente - gosta desta abordagem. Ela menciona o fato de que a ferramenta de arquitetura que a equipe usa, o BiZZdesign Enterprise Studio, tem excelentes capacidades para a modelagem de portfólios e aspectos relacionados, tais como:
  • O que compõe o portfólio?
  • Quem é o dono do portfólio?
  • Quais são os objetivos associados a este portfólio?
  • Que elementos do modelo (de arquitetura) representam o conteúdo do portfólio?
  • Quais são as métricas?
  • Quais são as recomendações (atuais) com respeito ao portfólio?
Com base nisto, é possível também definir um painel de controle específico sobre a situação do portfólio, tornando simples manter o acompanhamento do progresso.

A partir daí as coisas aceleram rapidamente: ambos concordam que manter tudo em uma única ferramenta será benéfico para a organização, resultando uma única versão da verdade para gerir a transformação. Uma estrutura simples é acordada entre Matt e Brenda:
  • Cada projeto tem seu próprio portfólio
  • Os objetivos estão estreitamente relacionados com os (a finalidade dos) entregáveis do projeto
  • A população é definida como sendo os pacotes de trabalho no projeto: este é o trabalho que desejamos acompanhar
  • As métricas do trabalho anterior de Matt serão usadas
  • Os painéis de controle terão de ser definidos posteriormente, mas Matt e Brenda concordam que estes devem ser publicados semanalmente
  • Eles também discutem a necessidade de uma reunião semanal de atualização do status, onde eles acompanharão as recomendações para os projetos
A fim de obter o apoio necessário, eles também discutem esta configuração com seu patrocinador. Ele está um pouco curioso a princípio, e tem um milhão de perguntas, mas parece gostar da configuração na medida em que Matt e Brenda discutem os detalhes com ele. Ele sugere usar esta configuração para a primeira iteração e - por enquanto - preenchê-la com dados fictícios para que a Diretoria possa ter uma ideia de como será sua aparência na prática.

Configurando o portfólio para a primeira iteração

Se sentindo orgulhos pela resposta positiva do seu patrocinador às suas ideias, Matt e Brenda mal podem esperar para construir um primeiro exemplo. Eles decidem tomar a primeira fase da iniciativa de transformação como seu escopo primário, uma vez que um planejamento de arquitetura bastante detalhado para isso já foi feito anteriormente pela equipe. Matt e Brenda usam o BiZZdesign Enterprise Studio para definir um portfólio que eles possam integrar com os dados já disponíveis no repositório. Isto inclui os objetivos definidos em uma fase anterior do trabalho de arquitetura, e os pacotes de trabalho como definidos durante o exercício de roteamento realizado pela equipe. O escopo, ou população, para seu portfólio consiste das três etapas da primeira fase da iniciativa de transformação da BriteLite:

O BiZZdesign Enterprise Studio ajuda Matt e Brenda a medir o progresso e o desempenho dos pacotes de trabalho ao longo do tempo. Isso é feito com base em KPI's, ou métricas, que podem ser ligadas ao portfólio, de modo que os pacotes de trabalho que fazem parte do portfólio podem ser pontuados contra essas métricas. Matt assume a liderança para descobrir quais métricas são relevantes e que poderiam efetivamente ser avaliadas considerando os dados possivelmente disponíveis na organização BriteLite. Os nomes das métricas são visíveis na definição de portfólio mostrada na figura acima: custos do projeto, benefícios do projeto, riscos do projeto, e excedente ao orçamento esperado.

No BiZZdesign Enterprise Studio, as métricas são definidas através da interface da ferramenta. Além disso, as métricas podem ser criadas como uma estrutura hierárquica. Por exemplo, o risco do projeto é avaliado com base na probabilidade do risco e no impacto do risco. A tabela abaixo mostra como essa estrutura é implementada no BiZZdesign Enterprise Studio. Na coluna da esquerda são listadas as métricas “pai”. Elas podem ser ligadas a um portfólio para a pontuação dos objetos contidos naquele portfólio. Na linha superior são listadas as métricas “filho”, ou de base. Estas podem ser atribuídas às métricas “pai”. Os números nas células indicam o peso de uma métrica “filho” para uma métrica “pai”:


Após a vinculação de uma métrica a um portfólio, os dados reais para os objetos em um portfólio podem ser trazidos para uma tabela de forma manual, ou através de carga (possivelmente) automatizada. Matt e Brenda encontram as seguintes informações para os três pacotes de trabalho no escopo do seu exemplo:


A partir daqui, é muito fácil visualizar os dados em painéis de controle de gerenciamento. Matt e Brenda usam o BiZZdesign Enterprise Studio para construir gráficos de pizza, gráficos de barras, bem como gráficos de bolha, para visualizar os KPI's dos projetos em um formato que eles podem apresentar facilmente para a Diretoria:


Sucesso

Configurar o portfólio para a primeira iteração correu de forma relativamente fácil, de forma que não demora muito para Matt e Brenda agendarem uma hora com a Diretoria para apresentar os seus resultados. Como antes, todos parecem estar ansiosos para colocar a mão na massa, iniciar a implantação em vez de ficar falando sobre planejamento e "sentado sem fazer nada". Felizmente Matt se preparou bem, e lhes recorda da confusão que eles costumavam ter anteriormente em relação ao estado dos projetos. Isto assenta um pouco o debate e abre o caminho para uma boa apresentação sobre uma estrutura de governança com base em reuniões semanais, mantendo o acompanhamento através de métricas simples, colocando a Diretoria em uma boa posição para gerenciar essa transformação.

Embora haja alguma relutância inicial, as pessoas podem ver o mérito de manter o controle sobre os projetos. Durante a sessão de perguntas e respostas, eles exploram um cenário onde um projeto está atrasado, e descobrem como isto é mostrado nos painéis de controle. Brenda também lhes mostra como é fácil navegar a partir de um painel de controle até os pacotes de trabalho, e daí para os elementos da arquitetura real envolvidos, gastando apenas dez minutos para descobrir o impacto do atraso de um projeto na entrega da arquitetura…

A Diretoria está impressionada, e com base na percepção presente dá luz verde para finalizar o roteiro nas próximas duas semanas e configurar o portfólio para fins de governança.

Conclusão 

Evidentemente, este caso é uma obra de ficção e os nomes dos personagens, as empresas, os locais e os eventos são produtos da imaginação do autor ou usado em uma forma fictícia. Qualquer semelhança com pessoas ou eventos reais é, naturalmente, inteiramente incidental.

Tomamos muito cuidado para elaborar uma imagem de como um projeto de arquitetura poderia se parecer na prática, com base na nossa experiência em diversas organizações tanto na Europa como na América do Norte. Temos trabalhado com várias organizações em muitos setores diferentes, e aspectos destes projetos encontraram seu caminho para dentro desta série de postagens.

Aprender a linguagem ArchiMate não é muito difícil. A estrutura básica e os princípios da linguagem são bastante diretos. Como sempre, porém, a prova do pudim está em comê-lo: apenas através da aplicação efetiva da linguagem ArchiMate podemos realmente aprender a usá-la. Com esta série de artigos esperamos proporcionar aos modeladores novatos algumas orientações sobre como começar. Além disso, esperamos ter inspirado os modeladores mais experientes a experimentar coisas novas e a compartilhar suas histórias. Estudos de caso reais - de projetos bem-sucedidos ou completos fracassos - são muito úteis para a comunidade de modelagem em geral.


[1] Adaptado de https://www.cprime.com/2010/07/metrics-in-project-management/ (acessado em: 14 de Setembro de 2015)

Comments