Arquitetura do Negócio

Arquitetura do Negócio

Sequência de “(Pensando alto sobre) Arquitetura Corporativa“. Naquele artigo vimos que a arquitetura corporativa pode ser vista como um conjunto formado por quatro camadas: Arquitetura do Negócio, Arquitetura de Aplicações, Arquitetura de Informações e Arquitetura Tecnológica. Sugeri que sua elaboração só faz sentido se iniciada pela Arquitetura do Negócio. É sobre este desenho o texto de hoje.

.:.

A representação de um negócio, qualquer  negócio, na forma de modelos não é nada trivial. Mesmo quando pequeno e aparentemente simples, um negócio pode apresentar particularidades que dificultam o seu desenho. Não se engane: a elaboração da arquitetura do negócio é um trabalho árduo. Por isso precisamos justificá-la de maneira adequada. Quais são as principais motivações para este trabalho? Relaciono abaixo aquelas que considero mais sensatas:

  • Entender o negócio – compreender todos os seus principais componentes (recursos, processos e regras) e as forças que os definem e guiam (objetivos);
  • Avaliar a prontidão de TI – e assim justificar o desenho de toda a arquitetura corporativa. Queremos aqui mostrar o alinhamento (ou descobrir buracos) entre o negócio e todas as peças, trecos e trampos oferecidos pela TI.

A primeira razão, “Entender o negócio”, pode ser tratada como uma iniciativa única ou espalhada em diversos projetos. Defendo que um analista de negócios entenda bem um negócio, pelo menos a parte afetada por um projeto. Só assim ele consegue contextualizar e, consequentemente, avaliar os requisitos aprendidos. Este *entendimento* se dá através de uma disciplina conhecida como Modelagem de Negócios. Se a empresa conhecer bem seu portfólio de projetos e planejar adequadamente o uso desta disciplina, ela pode elaborar gradativamente o que chamamos aqui de Arquitetura do Negócio. Devo admitir que nunca vi tal possibilidade sendo aproveitada. Sim, diariamente as empresas estão desperdiçando uma oportunidade de ouro.

Por isso veremos um número considerável de projetos guiados pela segunda motivação acima, “avaliação da prontidão de TI”. Claro que o nome da iniciativa vai variar bastante. O termo aqui sugerido é pouco “pop” e muito comprometedor: “como assim, cara pálida, gastar dinheiro para avaliar se tu tá pronto pra me atender?!? Cê tá maluco?” O fato é que vimos surgir nos últimos tempos não só o termo e a necessidade, mas até um papel. Nasceu o arquiteto corporativo, o novo braço direito do CIO ou diretor de TI. E o que você acha que esse cara vai fazer?

Sim, ainda são poucas (e grandes) empresas que demonstram preocupação com o tema. Mas acho que ele vai se espalhar. E isso é bom. Daí a motivação para estes dois artigos. Voltemos então ao que nos trouxe aqui: como desenhar a Arquitetura de um Negócio?

Escrevi acima que o entendimento de um negócio significa o domínio das quatro partes principais que o definem: recursos (estrutura), processos (dinâmica), regras e objetivos. O diagrama ao lado exibe a visão de nível mais alto do “metamodelo” do qual derivamos todos os modelos de um negócio. Pois é, um negócio pode demandar vários modelos para sua correta demonstração e entendimento. Modelos ou conjuntos deles nos ajudam a montar visões, perspectivas diferentes. Podemos ter, por exemplo, um modelo que se preocupe exclusivamente com a estrutura de um negócio, seus recursos. Ou um conjunto de diagramas que trate apenas de sua parte dinâmica, seus processos.

Recomendo o uso da EPBE (Eriksson-Penker Business Extensions), uma extensão da UML para modelagem de negócios, para a elaboração desses modelos. Neste artigo mostro os principais diagramas que podem ser elaborados através desta linguagem. Quero dizer, então, que a Arquitetura de um Negócio é representada por um conjunto de diagramas. E que estes diagramas são estruturados em visões. Mas eu tenho um probleminha.

Falta naquela proposta um diagrama-sumário, um modelo que represente em apenas uma página a visão geral do negócio. Normalmente eu desenho (e recomendo) um grande mapa de processos. Consigo representar neste tipo de diagrama todos os elementos fundamentais de um negócio. Mas eu não consigo explicar, não sem um certo esforço, o negócio em si. Aqui é importante lembrar o estágio em que se encontra esta disciplina que chamamos de Modelagem de Negócios. Ela está renascendo. De certa forma, podemos dizer que está sendo redefinida. Este artigo ilustra um pouco o surreal (e interessante) momento atual¹. Acontece que nenhuma das duas obras comentadas no artigo apresentam uma solução para meu probleminha. Relembrando: precisamos de um modelo que explique um negócio da mesma forma que um A3² explica e justifica um projeto, em uma folha apenas. Mas não se trata da concisão pela concisão. Esta “folha” deve ter uma lógica de leitura, uma estrutura bem definida. E deve, acima de tudo, explicar um negócio.

Encontrei em outro livro “estranho” uma possível alternativa. Estou falando de “Business Model Generation”, de Alexander Osterwalder e Yves Pigneur (publicação própria, BusinessModelGeneration.com, 2010). Um dos elementos do método proposto no livro é o Canvas, que vou adaptar aqui para tabuleiro. Não é tradução e sim uma adaptação, ok? Tabuleiro porque é onde colocamos as peças do jogo. Em nosso caso, do jogo do negócio. O tabuleiro não é um metamodelo nem uma alternativa para a EPBE/UML. Trata-se apenas de um modelo. Mas não interprete mal o ‘apenas’. É um modelo que pode sintetizar ou até mesmo guiar a elaboração de outros modelos. Vamos dar uma olhada no tabuleiro vazio.

No centro do tabuleiro colocamos a proposição de valor do negócio, o que ele está prometendo para seus clientes. No lado esquerdo colocamos as peças que os autores remetem ao lado esquerdo do cérebro – aquilo que deve ser otimizado. Estão ali seus parceiros, processos e recursos principais, além da estrutura de custos. Concluímos então que o lado direito do tabuleiro representa a mesma porção do cérebro, mais quente e subjetiva – mais criativa. Ficam ali as quatro áreas que completam o tabuleiro: clientes, relacionamento com clientes, canais e fontes de receitas.

Conseguimos mostrar ou entender um negócio através do tabuleiro? Sim, e os exemplos do livro – mostrando empresas como Apple, Amazon, Google, Procter & Gamble e Gillette, dentre outras – não deixam dúvidas quanto a isso. A ferramenta parece ser útil tanto para o desenho ou redesenho de um negócio existente quanto para a elaboração de um negócio totalmente novo. No processo sugerido, o tabuleiro seria desenhado em um quadro branco ou equivalente e preenchido com post-it’s ou desenhos. Estou usando termos condicionais ou dizendo que “parece ser útil” porque, a exemplo do que ocorreu com o método do Pensamento Visual um ano atrás, ainda não tive a chance de testar a nova ferramenta. Testá-la em campo. Porque desenhei o modelo do finito em poucos minutos e me diverti bastante. Mas este tipo de teste não conta. Espero em breve poder transcrever aqui outros testes e explicar melhor o uso do tabuleiro.

Por enquanto, como de costume, não posso deixar passar alguns “poréns” ou possíveis correções. No meu modo de entender não basta a fixação da proposição de valor de negócio. O entendimento de sua motivação é crucial. Por isso eu colocaria naquele espaço central a visão, os grandes objetivos do negócio (e respectivos prazos) e também a missão da empresa (caso não esteja redundante com a proposta de valor). Também é cara ao processo de entendimento uma classificação mínima dos processos principais. Quais são primários, de apoio ou de gestão? Aliás, me parece que o espaço dedicado para processos e recursos é muito pequeno. Mas, enfim, apenas um bom volume de testes pode confirmar a utilidade da ferramenta e possíveis correções ou adaptações.

Agora devemos retomar o ponto principal: este desenho, o tabuleiro, pode representar a arquitetura do negócio? Pelo menos em parte, sim. E tal possibilidade é sugerida no livro, na seção “Outlook – Aligning IT with Business” (pág. 272). Em relação ao sanduíche sugerido no artigo anterior o livro só não considera a Arquitetura de Informações (pelo visto, combinando-a com a Arquitetura de Aplicações). É uma pena que o livro dedique apenas duas páginas ao tema. Mas, claro, não era seu foco. Fica com a gente então o trabalho de testar a sugestão e, se for o caso, implementá-la. Tentarei fazer minha parte aqui. Inté!

.:.

Observações:

  1. Surreal? Sim, tanto que o BABoK 2.0, lançado no ano passado, ignora por completo a existência de uma disciplina chamada Modelagem de Negócios. Todas as obras citadas neste artigo e artigos relacionados sinalizam o renascimento da disciplina. O que nos permite concluir que o BABoK comeu bola. Ou você acredita que o assunto não interessa aos analistas de negócios?
  2. O “A3” é uma ferramenta criada na Toyota para solução de problemas. O nome vem do tamanho do papel utilizado na sua elaboração. Oportunamente mostrarei como ele pode completar ou até mesmo substituir o documento de visão de um projeto.