O papel da padronização dos projetos no AS-IS e TO-BE da organização

No último artigo abordamos as dificuldades inerentes ao levantamento do AS-IS de uma organização, não só pela dificuldade que tal levantamento implica como também pela rapidez com que este ficará obsoleto.

Não obstante estas dificuldades, uma organização que tenha em seu pipeline um conjunto de projetos de transformação terá necessariamente que conhecer o “AS-IS” que está diretamente envolvido nesse pipeline de projetos.

A NECESSIDADE

A título de exemplo, consideremos que dentro deste pipeline encontra-se um projeto de transformação que visa substituir um sistema legado por um novo sistema. Este projeto tem uma duração prevista de 3 meses e está planejado para iniciar dentro de 6 meses.

Naturalmente que, durante a fase de preparação e planejamento do projeto importa ter bem presente todas as dependências do sistema legado, tanto em termos de integração com os demais sistemas como com os processos de negócio que suporta. Só assim é possível avaliar os possíveis impactos inerentes ao desligamento deste sistema, e realizar uma estimativa mais fiável do tempo, custo, esforço e recursos necessários para a implementação deste projeto.

Desta forma, a atividade de planejamento do projeto deverá contemplar invariavelmente uma fase de levantamento das dependências do legado. Ou seja o levantamento do “AS-IS”.

Porém, o “AS-IS” a que nos estamos a referir não é o estado atual, mas sim o estado presente mais as alterações provocadas pelo projeto em causa. Ou seja, pretendemos o “AS-IS” tal como será daqui a 9 meses, momento em que o novo sistema entrará em produção e as suas dependências terão que estar todas operacionais.

Em rigor, o “AS-IS” que precisamos para planejar um projeto deve ser desdobrado em dois cenários: o estado da organização aquando do início do projeto e o estado na entrada em produção do projeto. No nosso exemplo, em que o projeto de transformação se inicia daqui a 6 meses e entra em produção daqui a 9 meses, necessitamos portanto do estado da organização nestas duas marcas temporais. Ou seja, necessitamos do TO-BE a 6 e a 9 meses.

Na verdade, as organizações já fazem este planejamento através de “conversas de corredor “ ou mesmo reuniões com os responsáveis dos projetos que poderão impactar o TO-BE da organização. Ainda que de modo informal e muitas vezes inconsciente, este planejamento é fundamental. Pois mesmo que tivessem um mapeamento completo e 100% fiável do AS-IS de hoje, de que serviria este se houvesse dezenas de projetos em andamento a terminar no prazo de 6 meses, ou seja, antes do projeto do nosso exemplo se iniciar?

Até mesmo as pessoas que estão trabalhando no desenvolvimento da TI de uma organização estão também a pensar no estado futuro, ou seja no TO-BE. Os apontamentos que escrevem nos seus cadernos de notas são visões, são excertos, do TO-BE da organização. Muitas das conversas que têm são também relatos dos cenários futuros.

O PROBLEMA

O problema que se apresenta então, é como usar os projetos para ter uma visão de como será o AS-IS da organização no futuro imediato, quando os projetos em curso terminarem. Por outras palavras, o desafio que se coloca é saber quais são os próximos TO-BEs da organização, à medida que os projetos em curso forem terminando.

Inicialmente este desafio pode parecer ambicioso e de difícil realização. Considerando o esforço necessário e a inevitabilidade de uma forte coordenação por parte das equipes de projeto para realizar o levantamento e consolidação das informações que representam o estado futuro da organização, afigura-se uma tarefa praticamente impossível.

Porém, atingir este objetivo é mais fácil do que parece… E pode ser conseguido apenas através da normalização do que já é feito atualmente.

A SOLUÇÃO

Retomando o nosso exemplo do projeto de substituição de um sistema legado por um novo sistema, certamente que durante a fase de aprovação, o sponsor do projeto teve que explicar o que ia fazer, com que recursos (materiais, humanos e financeiros) e em quanto tempo iria ser implementado.

Muito provavelmente teve até que fazer um powerpoint apresentando um justificativo para o projeto, um ROI, e um descrição do que iria ser feito, bem como a forma de intagração/implantação na organização. Tudo isto é normalmente feito pelas organizações como forma, ainda que não sistemática, de controlar custos, tempo e risco associado a cada projeto.

Imaginemos agora que esse powerpoint que descreve os projetos é feito com base em templates normalizados para que a informação nele contida possa ser carregada num repositório de Arquitetura Empresarial. Neste caso, esse repositório teria todas as promessas feitas no início de cada projeto, sem que tal implicasse a um esforço adicional.

Antes pelo contrário, pois para além de não haver esforço adicional este paradigma potencia ainda a redução de esforço na medida que a padronização pode até ser definida de forma a simplificar e agilizar a produção de outros documentos de assaz importância.

Por exemplo, numa versão não padronizada, a informação relativa à integração entre o nosso sistema legado que irá ser substituído, e os demais sistemas, estaria tipicamente presente numa secção textual preenchida manualmente, descrevendo as integrações.

Numa versão padronizada, seria possível pré-definir uma tabela com “Integrações Previstas” onde seria apenas necessário indicar o nome dos sistemas a integrar.

Além de se evitar a escrita de texto em linguagem natural com dezenas de palavras, pois basta escrever o nome do(s) sistema(s), esta padronização permite poupar tempo tanto a quem escreve como a quem lê. Mais ainda, se estiver padronizado pode ser carregado automaticamente num repositório, para ser processado por computadores para, por exemplo, validação das informações segundo regras e normativos, avaliação automática de impactos na arquitetura, etc..

E isso é uma diferença abismal. Na verdade, se a padronização das apresentações for bem definida, esta vai servir tanto para humanos como para computadores entenderem. Isto vai também facilitar o cruzamento de informação sobre o que está prometido, ou seja, sobre os TO-BEs esperados de cada projeto.

Já se sabe que no final, nunca um projeto entrega o que prometeu, e que os desvios podem até ser significativos. Mas isso apenas significa que a apresentação inicial deverá ser revista e reapresentada, como certamente já o é feito.

PARA SABER MAIS

Convido-vos a seguirem o nossos canais de divulgação onde podem acompanhar as últimas notícias sobre o tema de arquitetura empresarial, bem como os artigos que publicamos regularmente: