Nos três primeiros capítulos da série determinamos o valor que cada iniciativa tem para o negócio, para a realização de seu grande objetivo (aumentar em 30% a rentabilidade das vendas). O último artigo mostrou como o valor, o peso de cada iniciativa, pode ajudar a determinar o rateio do orçamento¹. Finalmente chegou a hora de definir prioridades.

.:.

Valor e custo são as duas variáveis predominantes quando o assunto é classificação e priorização de projetos. Mas não são as únicas. A complexidade técnica das soluções e as oportunidades de aprendizado também podem interferir na sequência de desenvolvimento de projetos.

Facilitamos a vida da turma do “como” (equipe técnica) ao isentá-la de boa parte do trabalho de estimativas. Seguindo uma ‘filosofia’ mais moderna, trocamos estimativas por restrições. Como vimos nos capítulos anteriores, prazos e limites de custos foram pré-fixados. A equipe técnica foi desafiada a encontrar três alternativas de solução para cada grande requisito apresentado.

A seleção das melhores alternativas deve seguir a mesma lógica que define as prioridades. Aliás, seleção e priorização podem ocorrer no mesmo momento. Veja a matriz ao lado. Nela a equipe técnica posicionou as alternativas de solução para cada necessidade do negócio. O eixo Y, como nos diagramas anteriores, apresenta o valor para o negócio. Os custos são representados no eixo X. Podemos utilizar ícones ou símbolos para indicar as outras variáveis, a complexidade técnica e possibilidades de aprendizado. Neste exemplo usamos apenas o tamanho do círculo para indicar a complexidade² de cada alternativa.

Os quadrantes nos ajudam a tomar algumas decisões de forma rápida. Ninguém deseja pesadelos, por exemplo. Pesadelos são alternativas caras que apresentam baixa ou nenhuma possibilidade de retorno. Eles aparecem quando o “limite do bom senso”, apresentado no artigo anterior, não é respeitado. Qualquer alternativa que caia ali deve ser automaticamente descartada pela equipe.

As bobeiras, por outro lado, são baratas. Mas também têm baixo valor para o negócio. Por isso merecem sempre ficar no fim da fila (de projetos e também do processo de seleção e priorização).

Sonhos são raros. Deveriam ser melhor aproveitados. São aqueles projetos que, apesar do baixo investimento, apresentam grande capacidade de gerar valor para o negócio.

E os desafios são aquelas alternativas ou projetos de alto custo e alto valor para o negócio. É aqui que começamos. Três alternativas, duas para a “Captura de Pedidos em Tempo Real” (h) e uma para a “Melhoria do Sistema de Agendamento” (f) aparecem neste quadrante. Neste ponto do processo a equipe técnica deve apresentar as vantagens e desvantagens de cada alternativa sugerida. Representantes das áreas de negócio envolvidas devem ter a palavra final sobre a melhor ou mais viável solução. Em nosso exemplo, a objetiva empresa fictícia escolhe o óbvio sonho (h1) como melhor opção para a captura de pedidos em tempo real. Decide também pela alternativa f3 – a mais sofisticada (e cara) para a evolução do sistema de agendamento dos vendedores. Aliás, para aplacar o chororô dos vendedores, eles também estudam a possibilidade de tocar a iniciativa cd2, que envolve a “aquisição de aparelhos GPS” e a integração destes com o sistema de agendamento. Antes, fecharam que i1 é a melhor alternativa de “sistema de logística”. Sabem que é uma solução meia-boca em termos de funcionalidades, mas representa um bom ponto de partida para uma empresa que nunca teve de lidar com algo parecido.

Relembrando: no processo descrito no parágrafo anterior nossa exemplar empresa fictícia escolheu: h1, f3, i1, cd2. Esta é a sequência determinada pelo valor gerado para o negócio. É a sequência ideal de desenvolvimento? Não. Nossa tão aguardada “fila indiana” de projetos fica assim: f3, h1, i1, cd2³. Como dita o senso comum, devemos sempre começar um trabalho pela parte mais difícil. A matriz utilizada acima nos ajuda a determinar a sequência ideal de desenvolvimento: Desafios, Sonhos, Bobeiras (e nada de Pesadelos).

.:.

Epílogo: Outra Provocação de nossa Exemplar Empresa Fictícia

Você deve se lembrar, nossa honorável empresa fictícia fixou um orçamento de R$ 300 mil para todas as iniciativas. Ao selecionar as alternativas de solução as equipes técnica e do negócio baixaram seu teto para R$ 245 mil:

• h1 = R$ 60 mil
• f3 = R$ 70 mil
• i1 = R$ 50 mil
• cd2 = R$ 65 mil

O que será feito com os R$ 55 mil economizados? Durante os projetos eles ficam reservados, como um fundo de garantia. Se algo não sair como o previsto (nunca sai), é neste fundo que a empresa buscará recursos. A grana que sobrar após a conclusão dos projetos será dividida entre todos os participantes dos projetos. Em espécie ou na forma de uma belíssima festa (churrasco, balada etc).
Para quando está agendada a sua?

.:.

Observações:

1. Curioso o biorritmo desta série. A audiência, forçada ou não, foi praticamente a mesma para todas as quatro partes já publicadas. Não posso dizer o mesmo da divulgação voluntária. Alguns capítulos mereceram elogios e indicações via Twitter. O último passou em branco. Justo aquele que, segundo meu pretensioso julgamento, deveria merecer mais atenção e debate. Por quê? Porque ele propõe a inversão de duas coisas muito comuns em nossas organizações: a) Um orçamento é definido antes que a equipe de TI conheça o(s) problema(s). Os limites são pré-fixados de acordo com o retorno esperado para o negócio; b) Ao invés de falar de “Custos X Benefícios” o artigo fala de “Benefícios / Custos”. E nem chega perto da matemática financeira que costuma “poluir” este tipo de discussão.
   No mundo do gerenciamento de projetos vivemos bombardeados por siglas e termos como VPL (Valor Presente Líquido),  TIR (Taxa Interna de Retorno), Payback e afin$. Até Mike Cohn, em “Agile Estimating and Planning” (Prentice-Hall, 2006), lança mão de sua calculadora financeira na hora de falar de priorização de projetos (temas, no caso dele) com base em grana. Na realidade ele surrupia e resume os escritos de Steve Tockey em “Return on Software: Maximizing the Return on your Software Investment” (Addison-Wesley, 2004). No caso do Mike há um probleminha que precisa ser mais estudado. Um probleminha que vou chamar de TMNUF (“Too Many Numbers Up Front”.. hehe, algo como “Números Demais, Cedo Demais”.
   Resumo (a ser melhor trabalhado futuramente): Trabalhando em um processo iterativo e incremental eu não consigo prever (com precisão de 50 dólares, como faz Mike) o fluxo de caixa líquido de 8 trimestres!!!
2. Muitos autores preferem falar de “riscos” ao invés de “complexidade”. Como me acostumei a falar de “riscos” para dizer “riscos do negócio”, utilizo “complexidade” para representar os riscos técnicos. Na realidade, “complexidade” pode abranger também a quarta variável citada no artigo, “oportunidades de aprendizado”.
3. Este artigo “esconde” uma pegadinha e uma provocação. Quem matar as duas, em comentário aqui registrado, garante uma vaga em uma das próximas turmas do FAN. Vaga impessoal e transferível! Promoção válida até o dia 25/agosto/2010.
4. Hoje encerro o tema principal: Priorização de Projetos. Depois devo publicar alguns artigos isolados para quitar alguns débitos deixados pela série, particularmente sobre BSc’s e seu uso no Planejamento Estratégico.
5. “Creating Solutions” é o cartoon do HikingArtist que encerra a série.

.:.

Antes, porém, vale a pena revisar o caminho que trilhamos até aqui. No segundo artigo eu sugeri o uso de um diagrama que nos ajuda a classificar processos de negócio e, consequentemente, seus respectivos projetos. Sinto ter tratado esse trabalho de forma um tanto rápida, como se ele fosse natural em nossas organizações. Não é.

O diagrama ao lado já exibe o resultado do trabalho de valorização que vimos no último artigo. Mas, antes de explicar o conteúdo, preciso elucidar o rabisco. É um mapa de processos desenhado em uma matriz de classificação. A matriz é um recurso mais didático do que prático. Pretende apenas criar o costume de diferenciar tipos de processos e tipos de processos primários logo no início de um projeto. Como vimos anteriormente, a coluna à direita exibe os processos mais relevantes para a proposta de valor da empresa. São os processos primários do tipo operacional que aparecem no exemplo que estamos desenvolvendo. Porque a proposição de valor de nossa empresa fictícia é a excelência operacional (“vender baratinho”).

Estou utilizando a UML e sua extensão para negócios EPBE. No mapa destaquei apenas os recursos de TI diretamente afetados pelas iniciativas que a empresa pretende disparar (Aqueles rabiscos ao lado das letras são os ‘pacotes’ da UML e representam sistemas ou módulos de um sistema) . Os recursos são organizados por processos. Temos então uma derivação dos diagramas de processos que na EPBE é chamada de “diagrama de linhas de montagem”. Claro, estou mostrando uma versão absurdamente simples deste artefato.

Três processos serão alterados de alguma maneira para que a empresa possa realizar seu objetivo de aumentar em 30% a rentabilidade das vendas. São eles: “Vendas”, “Entrega” e “PGV – Planejamento e Gerenciamento das Vendas”. Foram vinculados a eles três condições (requisitos) apresentados pelas áreas de negócio envolvidas:

f) Melhorar o Sistema de Agendamento;
h) Capturar Pedidos em tempo real; e
i) Adquirir / Desenvolver sistema de logística.

Os itens c (Comprar sistema GPS) e d (Integrar GPS com sistema de Agendamento), classificados no capítulo anterior como os menos relevantes, foram descartados neste momento do trabalho.

Antes de prosseguir, preciso de sua atenção para o seguinte: a “Captura de Pedidos em tempo real” (h) é a iniciativa que deve merecer 43% de nosso tempo e recursos. Opa… 43%?!? De onde veio esse número? No artigo anterior, utilizando a sequência de Fibonacci, valorizamos as iniciativas em 2, 2, 8, 13 e 5 pontos, respectivamente. Total = 30 pontos de valor. A iniciativa h vale 13 pontos, 43% de 30. Já já mostro a utilidade destes números.

Só quando temos uma visão clara e compartilhada sobre o que precisa ser feito é que devemos envolver a turma do ‘como’ – a equipe responsável por determinar a melhor maneira de atender cada um dos requisitos apresentados¹. A partir de agora a equipe técnica precisa estudar e avaliar alternativas de solução para cada solicitação. Apresentar uma só alternativa é arrogância; Cinco ou mais sugestões é exagero que não se paga. Três é o número mágico. Mas a elaboração das 3 alternativas não carece de magia nenhuma. Basta mostrar: a mais simples; a mais sofisticada; e a intermediária.

Não há nada que justifique que a equipe técnica não conheça a ordem de importância das iniciativas. Aliás, seu trabalho será muito melhor se desenvolvido a partir pleno entendimento das decisões estratégicas que deram origem aos requisitos apresentados. Só isso permitirá que a equipe técnica desenvolva uma linha de raciocínio representada pelo gráfico ao lado.

É o valor, a relevância de cada solicitação (requisito) para realização do objetivo maior, que deve determinar o rateio do orçamento.  Ele está representado pelo eixo Y do diagrama. No eixo X podemos distribuir o orçamento (os custos). Vamos supor que a nossa empresa fictícia tenha destinado R$ 300 mil para todo o programa (conjunto de projetos). Isso significa que a iniciativa h (Capturar pedidos em tempo real) poderá consumir até R$ 130 mil, ou 43% do orçamento total. Indica também que a equipe terá apenas R$ 50 mil para “Adquirir ou desenvolver um sistema de logística” (i). E justifica o descarte dos projetos c e d: com apenas R$ 40 mil ela não conseguiria adquirir aparelhos GPS e integrá-los ao sistema de agendamento. Ou conseguiria? Não importa. Não neste momento.

A linha pontilhada representa o “limite do bom senso”. Traduzindo: é muito difícil justificar qualquer projeto que a ultrapasse. Lembre-se: o eixo X representa os custos. Se, por exemplo, a contribuição dos aparelhos GPS para o aumento da rentabilidade das vendas é marginal ou questinável (2 pontos de valor, 7%), como justificar um investimento de R$ 50 mil (16% do orçamento) para a sua aquisição?

Municiada com esses limites lógicos a equipe técnica não perderá tempo “viajando na mayonaise”. De cara ela descartará, por exemplo, a consulta àquele maravilhoso fornecedor de soluções de logística que apresenta custos de licenciamento começando em R$ 200 mil. Pra que perder tempo? O limite de R$ 50 mil está colocado e não é negociável.

Eu sei, esse papo todo é óbvio demais. Mas quantas vezes você teve a oportunidade de discutir um orçamento amparado por tamanha obviedade? Lá na primeira parte da série eu prometi “apresentar sugestões que ajudem a definir o que é prioritário, o que pode aguardar na fila e o que não passa de bullshitagem sem valor”. Estou quase chegando lá. O problema é que eu também havia prometido ser mais prático e… direto! Mas ainda precisarei de um quinto capítulo. Só torço para que as sugestões apresentadas estejam servindo para alguma coisa. No mínimo como provocações. Inté!

.:.

Observações:

1. Iniciei aquele parágrafo com um medo danado de ser mal interpretado. Uma “visão clara e compartilhada do que precisa ser feito” não significa  BDUF (Big Design Up Front), uma tonelada de documentos nem nada do tipo. Os artefatos mostrados até o momento são mais do que suficientes para mostrar: Porque os projetos são necessários; Quem está envolvido; Quanto valor pode ser gerado por cada iniciativa; Onde mudanças são necessárias; Quando elas ocorrerão; e Como elas serão implementadas². Forcei a barra? Então aguarde o próximo capítulo.
2. Você já viu essa sequência de perguntas antes, não?
3. Não sei porque o tipo de análise apresentado neste artigo é universalmente conhecido como “Análise Custo X Benefício“. Prefiro “Benefício / Custo”. Pode parecer preciosismo de minha parte, mas prefiro ver os Benefícios antes de debater e definir Custos. Gastei 3 das 4 partes desta série preocupado exclusivamente com os Benefícios, com o Valor que devemos gerar para o negócio. Só agora comecei a falar de custos.
4. “Almost There” é o nome do cartoon utilizado. Como sempre, do HikingArtist.com.

Qual é o problema? Muitas empresas lidam com dezenas ou até centenas de iniciativas simultâneas porque não sabem ou não têm coragem de definir o que é mais importante. Organizações de TI se comprometem com coisas demais e quase sempre entregam de menos.

Qual é a intenção deste artigo? Apresentar sugestões que ajudem a definir o que é prioritário, o que pode aguardar na fila e o que não passa de bullshitagem sem valor. Antes que você me acuse, me permita dizer: é claro que seria pretensão exagerada deste que aqui rabisca qualquer tentativa de esgotar assunto tão cabeludo num simples artigo de 1438 palavras. Por favor, receba este texto como meus 2 centavos. Ou como um bê-a-bá – no sentido de ser um ponto de partida.

.:.

Toda organização, independente de seu porte ou ramo de atividades, tem três tipos de processos de negócios:

• Primários: são aqueles que tocam, direta ou indiretamente, o freguês (cliente externo). É o que os letrados chiques gostam de chamar Core Business. É aqui que uma empresa ganha dinheiro, se diferencia ou se estrepa.
• De Apoio: representam tudo o que a empresa não gostaria de fazer mas é obrigada, por necessidade (apoiar os primários) ou por exigência (legal e / ou social). Como representam “só despesa”, foram os primeiros informatizados, terceirizados, reengenheirados etc.
• De Gestão: governam os outros dois. Segundo Gary Hamel, está aqui a última fronteira da Administração². A onda da tal Governança Corporativa, de certa forma, confirma sua tese.

Não deveríamos consumir muitos neurônios para descobrir que projetos que tocam (melhoram ou criam) processos de negócio primários são prioritários. Se é ali que a empresa “faz caixa”, é ali que a empresa deveria se concentrar. Ou, colocando de outra forma, é ali que a empresa deveria concentrar seus melhores recursos. Mas como saber, entre todos os projetos daquela área, quais demandam mais atenção? Vamos mergulhar um pouco mais no core do negócio.

Existem 4 tipos de processos primários:

• Operacionais: são as vendas (e respectivas compras), as entregas ou operações de suporte, por exemplo. Qualquer operação que envolva o cliente externo, mesmo que de maneira indireta, se encaixa nesta categoria.
• De Gestão de Clientes: pensou no famigerado Marketing de Relacionamento ou CRM? Acertou, mas lembre-se que os processos de gestão de clientes não se limitam ao departamento de Marketing, ok?
• De Inovação: qualquer processo ou conjunto de processos que pretenda criar ou melhorar processos, serviços e / ou produtos também deve ser classificado como primário. Mesmo quando ele não envolve diretamente o freguês (no método Steve Jobs de desenvolvimento de produtos, por exemplo).
• Regulatórios ou Sociais: pois é, até a coleta seletiva de lixo – uma mínima prova de preocupação com a sociedade – deve ser classificada como processo primário. O freguês, de uma forma ou de outra, se beneficia com iniciativas dessa natureza.

Com exceção do último, que deveria existir em qualquer organização minimamente responsável, os outros três tipos de processos primários são tratados de maneira bastante diferente dependendo da proposição de valor de uma empresa. Vou usar uma classificação proposta por Kaplan e Norton, os mesmos autores da lista acima.

Antes, o que quer dizer “proposição de valor”? É a forma como a empresa se apresenta para seus clientes – seu fator fundamental de diferenciação. Apesar de afetar tudo dentro de uma organização (objetivos, recursos, processos e regras), a proposta de valor se prova de verdade na realização dos processos primários. Kaplan e Norton³ sugerem a existência de 4 propostas básicas:

• Vendo Baratinho: uma proposição quase unânime em solo tupiniquim (ao ver comerciais de TV, parece ser a única adotada por aqui). Fleury e Fleury⁴ sugerem um nome mais pomposo para esta proposta: Excelência Operacional. O termo é bom porque nos remete diretamente aos processos primários do tipo operacional. Ou seja, em organizações que se diferenciam pelo menor custo são ou deveriam ser prioritários todos os projetos que toquem os processos de negócio primários do tipo operacional. Essas empresas deveriam privilegiar os investimentos em ERP’s, cadeia de suprimentos, sites de comércio eletrônico, logística etc.
• Inovo pra Caramba: tanto que sou quase uma Apple (ou Havaianas). A empresa se diferencia pela criatividade de seus produtos ou serviços. E só isso as torna o exato oposto daquelas que “vendem baratinho”. São antagônicas em tudo. Enquanto quem “vende baratinho” é ou precisa ser “mão de vaca” (pão duro, seguro), empresas inovadoras são ou deveriam ser naturalmente perdulárias. Algumas mais e outras menos responsáveis, mas perdulárias. E sua proposta (inovação) nos leva diretamente aos processos primários de inovação. É aqui que ela concentrará seus esforços. Empresas deste tipo investem em soluções para gestão do ciclo de vida de produtos (PLC), ferramentas de colaboração etc.
• Aqui você Acha: precisou de qualquer coisa que gire em torno de <objeto>, nós temos. Formalmente esta proposta é chamada “Soluções Completas” por Kaplan e Norton. Pense em um banco ou seguradora, por exemplo. Considerando o perfil dos projetos e critérios para priorização, devemos entender que elas são praticamente idênticas às empresas que
• Aprisionam Clientes: aquelas que configuram seus produtos e / ou serviços como plataformas difíceis de serem trocadas pelos fregueses. Você acertou se acabou de se lembrar de sua operadora de telefonia celular. A semelhança com a proposição anterior fez com que Fleury & Fleury as classificasse como uma só: “Orientadas à Serviços”. De fato, seus processos mais relevantes são os mesmos: os processos primários de gestão de clientes. O que significa dizer que sua atenção vai ou deveria ir para projetos de CRM, telemarketing (argh!) etc.

Um necessário resumo: merecem prioridade máxima projetos relacionados com a melhoria, evolução ou criação de processos de negócio primários. O perfil da empresa, declarado em sua proposição de valor, dirá se merecerão prioridade máxima os projetos que toquem processos primários operacionais (perfil = Excelência Operacional); de gestão de clientes (perfil = Orientação à Serviços); ou de inovação (perfil = Inovação em Produtos e / ou Serviços). Simples assim. Basta? Claro que não.

O que acontece se tivermos duas ou mais demandas que se referem ao mesmo tipo de processo? É claro que elas não têm a mesma relevância para empresa. Mas qual deve ser o critério de desempate? Semana que vem eu conto. Inté!

.:.

Observações:

1. Não canso de recontar a origem de meu slogan: em uma matéria especial da revista Business 2.0, em 2005, perguntaram para o Peter Drucker: “O que os executivos parecem não aprender nunca?”. Resposta: “A perguntar ‘o que precisa ser feito?‘”. É tão verdadeira que olha sobre o que estamos conversando aqui.
2. “O Futuro da Administração“, Gary Hamel com Bill Breen. (Campus, 2007).
3. Claro que Robert Kaplan e David Norton não utilizaram termos como “vendo baratinho”. Sua classificação, apresentada em “Mapas Estratégicos” (Campus, 2004) é a seguinte: Baixo Custo Total; Liderança do Produto; Soluções Completas para Clientes; e Aprisionamento (lock in).
4. “Desenvolver Competências e Gerir Conhecimentos em Diferentes Arranjos Empresariais“, artigo de Maria Tereza Leme Fleury (FEA/USP) e Afonso Fleury (Poli/USP), publicado no livro Gestão Estratégica do Conhecimento (Atlas, 2001).
   É importante dizer aqui que a classificação de propostas de valor ainda não é consenso. Michael Porter, por um bom tempo, disse que haviam apenas duas: preço e inovação. Depois ele apresentou uma classificação próxima daquela proposta por Fleury e Fleury, com termos diferentes: Estratégia baseada na Variedade; Estratégia Baseada na Necessidade; e Estratégia Baseada no Acesso. Cá entre nós, Porter reinventa rodas. Prefiro a classificação de Kaplan e Norton (tópico 3 acima), pela objetividade e clareza. Mas sei que em alguns casos é difícil definir apenas uma proposta. Por exemplo: a Apple inova ou aprisiona? Inova aprisionando? Ou aprisiona inovando? hehe..
5. O cartoon utilizado, “Defining targets differently“, foi liberado para uso no Flickr por HikingArtist.com
6. Não é a primeira vez que brinco com o título “Como Fazer Amigos e Influenciar Pessoas“, lançado por Dale Carnegie em 1937 – o pai de todos os autores de livros de auto-ajuda. Acho que já contei por aqui que é o livro que mais ganhei de presente. Por que será?
   Agora falando sério: Priorizar, tomar decisões, é em certa medida uma forma de Fazer Inimigos e Desagradar Pessoas. Desconfio que o título acima (e todos os seus derivados) contribuíram muito para a criação de ambientes assépticos e exageradamente avessos a debates. Ajudaram a criar pessoas e organizações que morrem de medo de errar, de tomar decisões e de falar um simples “Não!”. Mas eu só desconfio.

Portanto, por favor, utilize as sugestões abaixo com moderação. Traduzindo: não é para sair desenhando tudo quanto é diagrama sugerido aqui! Apresento uma variação do “Codex” de Dan Roam (autor de “The  Back of the Napkin”) exatamente para facilitar a escolha de determinado tipo de diagrama, dependendo do problema em questão. Como ainda se trata de uma versão beta, críticas e sugestões serão muito bem vindas. Desde já agradeço.

O gráfico acima representa nosso ‘Codex’ – um guia que nos ajuda a definir o diagrama ou artefato mais indicado para o entendimento ou apresentação de determinado problema ou solução. O desenho é grande demais para o espaço aqui. Clique na imagem para ver uma versão ampliada. Podemos seguir?

As linhas representam as 3 visões – do Negócio, da Estrutura e dos Processos – e suas respectivas perguntas. As colunas representam as 5 decisões SQVID. Lembrando: Simples ou Elaborado; Qualitativo ou Quantitativo; Visão ou Execução; Individual ou Conjunto; e Mudança (to-be) ou estado Atual (as-is). Nas células aparecem ícones que representam um tipo de diagrama ou artefato. Quando a célula estiver vazia é porque aquela pergunta, naquele seletor, não faz sentido.

Abaixo, na sequência das visões, são apresentados todos os diagramas ou artefatos sugeridos.

Visão do Negócio

Aqui tentamos responder uma única questão: Por quê? Ou seja, quais são as motivações do negócio? Quais são os grandes requisitos do negócio? Afinal, quais necessidades do negócio esse projeto ou demanda deve satisfazer? Três ícones apareceram no desenho acima:

O documento é a única representação não desenhada de todas as sugestões do ‘Codex’. É algo que foi antecipado por Eriksson e Penker em “Business Modeling with UML”. Algumas informações obtidas neste momento simplesmente não fazem sentido de outra forma que não seja texto puro. Mas, antes de abrir seu editor de textos, entenda que essas informações podem estar estruturadas em sofisticados formatos, como Mapas Estratégicos, Balanced Scorecards, matrizes SWOT etc. Podem representar também a declaração de Missão ou Visão da empresa. E ainda, num cenário mais pobrezinho, uma lista com os principais requisitos do negócio.

O mapa de processos (neste momento, um ‘modelão’ conceitual) pode ser uma alternativa ao texto puro – uma alternativa mais elaborada. Se estivermos lidando com milhares de palavras, então o desenho pode ser uma boa opção. Afinal, modelamos para simplificar – para facilitar o entendimento. Seu uso também é util para explicar a execução – o meio pelo qual a organização espera realizar a visão, seus objetivos. Como mostra o ‘codex’, este mapa pode ser utilizado tanto para ilustrar o ‘as-is’ como o ‘to-be’, ou seja, como a empresa se vê após a realização de seus objetivos.

Quando lidando com  números, quantidades, não há representação melhor que um belo gráfico – de preferência de barras, que além de muito legível é mais fácil de ser desenhado à mão. Quando utilizado na elaboração da visão do negócio, este gráfico representa grandes números que explicam ou justificam os requisitos do negócio. Estamos falando de aumento de receitas? Ou de redução de custos? Sempre que requisitos assim são apresentados, um gráfico pode ajudar em sua visualização e divulgação.

A construção da visão do negócio é uma tarefa que normalmente não dura mais que poucos dias ou até mesmo horas. O que não significa que ela não seja importante, pelo contrário. Muitos projetos falham porque, a partir de determinado momento, a equipe simplesmente esquece a principal razão pela qual aquele empreendimento foi iniciado. A visão do negócio representa os principais requisitos do negócio. Portanto, ela não é nada menos que fundamental. E todo projeto deveria começar por ela.

Visão da Estrutura

Por estrutura devemos entender todos os recursos que compõem uma organização ou se relacionam com ela de alguma maneira. Três questões devem ser colocadas para a elaboração da visão da estrutura:

• Quem / O Quê? – para identificar partes interessadas (stakeholders) ou recursos envolvidos em determinada situação. Esses recursos podem ser produtos, serviços, máquinas, documentos etc. Ou seja, qualquer tipo de recurso físico, abstrato ou de informação.
• Quanto? – para entender e tratar todas as informações numéricas: volume de vendas, número de colaboradores, salários, giro de estoques, quantidade de clientes etc etc. Enfim, separamos com essa questão todos os dados quantitativos sobre os recursos elencados na pergunta anterior.
• Onde? – agora uma questão para localização, para posicionamento dos recursos na organização ou em seu macro-ambiente (nicho, mercado ou cadeia de valor).

São 4 os diagramas principais usados para elaboração da visão da estrutura:

O diagrama de classes é quase onipresente nesta visão. Não é uma questão de falta de opções, mas sim de uma grande versatilidade desta ferramenta. No entendimento das questões de identificação (quem / o quê), o diagrama de classes pode ser utilizado para representar organogramas ou a composição de produtos ou serviços, por exemplo. Na pergunta que trata de localização (onde), este diagrama pode representar departamentos, seções, filiais, franqueados etc. No ‘codex’ aparece também uma outra versão deste diagrama, simplesmente para indicar a possibilidade de confecção de desenhos mais elaborados e extensos.

Quando é necessário analisar um recurso específico o diagrama de estado pode ser de grande utilidade. Os estágios no ciclo de vida de um contrato ou uma apólice, o status de uma ordem de compra, os estados de determinado equipamento etc. No livro “Business Modeling with UML”, este diagrama é usado na construção da visão do comportamento, opção que não está contemplada nesta sugestão. Independente do nome ou perspectiva, o importante é saber que podemos contar com esta ferramenta sempre que um recurso relativamente complexo exigir um estudo e representação mais detalhados.

Pois é, como já foi citado na visão anterior, não existe representação visual melhor do que um gráfico (de barras, preferencialmente) para as respostas da questão “quanto”. Repare no ‘codex’ que este é o único artefato gerado em todas as variações oferecidas no seletor. Mas é importante colocar que algumas organizações podem apresentar essas respostas em outros formatos. Um balanced scorecard, por exemplo, obrigatoriamente apresenta metas quantitativas para todos os indicadores apontados. O bom analista evita redundâncias.

O artigo anterior chamou a atenção para o fato de alguns diagramas ultrapassarem os limites de uma visão. Eis aqui um diagrama de atividades (ou fluxograma), natural da visão dos processos. Aqui, na visão da estrutura, ele aparece em uma única célula: quando precisamos ver a execução (2ª opção da terceira coluna do ‘codex’) em resposta para a pergunta “onde?”. Colocando de outra maneira, este diagrama pode ser utilizado para explicar onde determinadas atividades ocorrem ou devem ocorrer.

A visão da estrutura é sumariamente ignorada no padrão de modelagem da moda, a BPMN. Claro, não é uma culpa da notação. O problema é que muitos profissionais ainda misturam e chacoalham bolas, acreditando ser possível a utilização da BPMN para a modelagem (o *entendimento*) de negócios. Não é.

Visão dos Processos

Finalmente, a visão que trata da parte dinâmica de uma organização. Todas as tarefas, atividades e processos executados por uma empresa são capturados e analisados através dos artefatos que compõem esta visão. Duas perguntas nos levam até eles:

• Quando? – nos ajuda a  posicionar ações em uma linha de tempo. Quando tal problema ocorre? Quando aquele evento deve ser disparado? Qual é o deadline daquela tarefa? E assim por diante.
• Como? – por fim, a última e mais complicada questão. Como tal atividade acontece? Como aquele processo deve ser executado? É a questão que guia o mapeamento e modelagem de processos e atividades de negócio.

Não por acaso, é nesta visão que temos um conjunto maior de diagramas. São 8 tipos principais, listados abaixo:

Mapas de processos nos ajudam a responder tanto o “quando” quanto o “como”. Geralmente formam o melhor ponto de partida para o desenho das respostas para as duas perguntas desta visão. São particularmente úteis quando os envolvidos não têm um entendimento comum sobre os processos envolvidos em determinado problema. Todos os outros artefatos gerados na construção desta visão, de certa forma, derivam deste.

O mapa, apresentado acima, é na realidade um conjunto de diagramas de processos. Para desenhá-los deveríamos seguir um pattern sugerido em “Business Modeling with UML”. Um padrão que vem de outra notação, a IDEF0. É simples: à esquerda do processo ficam as entradas; na direita as saídas; abaixo, todos os recursos utilizados na produção das saídas; e acima os recursos usados no controle do processo. Este diagrama, que à primeira vista parece simplista e desnecessário, pode dar origem a artefatos mais avançados, como mapas de avaliação (nome tropicalizado para “System Maps”, apresentado por Ralph Smith em “Business Process Management and the Balanced Scorecard”). Outro artefato derivado deste é o diagrama de linha de montagem, que veremos posteriormente.

Analistas de O&M (eles ainda existem?) vão se lembrar da figurinha ao lado. É o velho ‘fluxo-cronograma’. Trata-se do diagrama de atividades da UML acrescido de informações sobre tempo, apontadas em swinlanes ou de alguma outra maneira – isso não importa muito. Uma alternativa é o uso do diagrama de Timing (linha de tempo), que foi introduzido na UML 2. Mas o uso de uma variação do diagrama de atividades deve fazer mais sentido na maioria das vezes, já que o analista reutilizaria um diagrama já elaborado, adicionando apenas informações sobre a duração de atividades e tarefas.

Aliás, a base para o diagrama sugerido acima é esse aqui, o diagrama de atividades (ou fluxograma, como queiram). Quando detalhamos um processo, este é o formato. Podemos nos limitar a um nível mais alto – as atividades, ou descer ao menor nível de detalhamento possível – as tarefas. A ferramenta pode ser sexagenária ou centenária. Se dura tanto é porque ninguém inventou nada melhor, certo? Como eu disse em um artigo anterior, a BPMN nada mais é do que uma revisão (3.0?) deste velho conceito. Aliás, quando no domínio da solução (to be) e tendo como base algum produto BPMS, o analista pode substituir este diagrama por modelos BPMN. Aliás, deve. Mas, em todos os outros casos, particularmente quando ainda estiver *entendendo o negócio*, ele deveria evitar a BPMN. E utilizar UML.

Uma alternativa ao diagrama de atividades é o diagrama de sequência. Atenção: é uma alternativa. O analista desenvolve um ou outro para estudar ou representar determinado processo ou atividade. Quando interações entre as partes envolvidas e uma noção de duração das atividades forem muito importantes, então o diagrama de sequência pode ser mais útil que o de atividades. Quando o analista tiver à sua disposição uma ferramenta CASE, ele ganhará um diagrama quando desenvolver o de sequência – o diagrama de comunicação é gerado automaticamente. E pode ser útil na análise das interações entre as partes interessadas – para identificar gargalos, por exemplo.

O diagrama de linha de montagem é uma variação do diagrama de processo. Serve para análise específica de recursos que apoiam a execução de um processo (como vimos, esses recursos são desenhados abaixo do processo). É especialmente útil quando esses recursos, representados por linhas de montagem (pacotes da UML), são sistemas de informação. O diagrama ilustra todos os dados lidos e gravados em sistemas, demonstrando como eles viabilizam (ou impactam) um processo de negócio.

Repare que o artefato acima é o primeiro que trata especificamente de sistemas. Todos os outros apresentados até aqui são utilizados exclusivamente para o entendimento ou demonstração do negócio e seus diversos aspectos. Vale ressaltar que o diagrama de linha de montagem é particularmente útil quando ainda estamos no domínio do problema. Tanto que ele é apresentado como uma alternativa para responder o “como” é hoje (as-is, última coluna do ‘codex’).

Mas, quando o analista começa a entrar no domínio da solução – capturando requisitos das diversas partes interessadas – quais artefatos ele pode gerar? Abaixo são apresentados dois diagramas que aparecem apenas na coluna D (to be) do ‘codex’:

O diagrama PUCS (Process Use-Case Support) é mais um belo exemplo de toda a versatilidade da UML. Ele é a combinação de dois diagramas, de atividades e de casos de uso. O diagrama de atividades, descrito acima, é a base para a elaboração de um PUCS. O analista pode utilizá-lo para iniciar e facilitar os trabalhos de identificação de casos de uso, ou seja, de descoberta e descrição de requisitos funcionais. No PUCS indicamos explicitamente quais atividades ou tarefas do negócio serão suportadas (incrementadas ou impactadas) por determinados casos de uso. Nenhuma imagem representa melhor o ato de ‘embarcar’ sistemas em um processo de negócio.

Chegamos então ao último artefato de nossa listinha, o mal falado e mal entendido diagrama de casos de uso. Ele pode ser extraído de um PUCS ou ser desenhado do zero, dependendo das necessidades de entendimento do analista. Suspeito que muitos não concordem, mas desconheço outra representação gráfica que ilustre tão bem todo o escopo funcional de um projeto. Além do pouco tempo gasto em sua elaboração, outra vantagem desse tipo de diagrama é sua legibilidade.

Deve ter ficado claro pela listinha acima que a elaboração da visão dos processos é a mais complicada – aquela que exigirá mais do analista. O mais perigoso engano que deve ser evitado a todo custo é o desenvolvimento deste estudo numa tacada só, como se fosse uma fase de um projeto. Devemos brigar pelo pleno uso de um processo que seja iterativo e incremental. Com exceção da visão do negócio, desenvolvida na primeira iteração, todas as outras são maturadas e desenvolvidas durante todo o projeto. Mas isso já é assunto para outra hora, né?

E as Regras de Negócio, onde ficam?

Como citei no artigo que deu origem a esta série, “Modelagem de Negócios: A Encruzilhada“, David Bridgeland e Ron Zahavi defendem em seu livro, “Business Modeling – A Practical Guide to Realizing Business Value”, que as regras de negócio tenham sua própria disciplina. Até aí, tudo bem. O problema começa quando tentamos buscar algum tipo de representação que seja específico para as regras. Cria-se muita confusão desta maneira. Devemos nos lembrar que a motivação para a modelagem é a simplificação.

Regras de negócio podem aparecer, definindo ou restringindo, em qualquer outro elemento básico de um negócio (leia-se: objetivos, recursos e processos). Portanto, parece ser um grave engano a definição de um padrão de apresentação específico para regras. Seu repositório natural deveria ser aquele artefato que estava sendo elaborado quando a regra surgiu. Ou, dependendo do caso, um anexo deste artefato. Por exemplo: a regra apareceu quando desenhávamos um diagrama de atividades. Por que não registrá-la ali mesmo, na forma de uma nota? (a UML tem o recurso ‘nota’ para a colocação de comentários em diagramas. As notas podem inclusive ser ‘ancoradas’ em elementos específicos de um diagrama. E são utilizadas em qualquer tipo de diagrama).

Claro, existem regras muito complexas – extensas pra chuchu. Uma fórmula de cálculo de seguro, por exemplo. Não faz nenhum sentido que uma fórmula de trocentas páginas seja comprimida em um diagrama, certo? Custa grampear a fórmula no diagrama, indicando com um código bobo o local onde ela se aplica? O tema é importante demais para ficar só aqui, no rodapé deste artigo. Voltarei ao tema.

.:.

Agora, para encerrar este longo artigo, apenas um breve comentário sobre a disciplina em questão, a Modelagem de Negócios. O que antes era uma suspeita caminha agora para a certeza absoluta: quase ninguém pratica a modelagem de negócios. E, se depender de iniciativas recentes como o BABoK, a situação pode piorar bastante. Por que isso é um problema? Porque o entendimento do negócio é fundamental para o sucesso de um projeto. E ainda não inventaram disciplina mais eficaz que a modelagem de negócios para a obtenção desse entendimento.

Mas sou teimoso e um incurável otimista. Livros publicados recentemente, particularmente “The Back of the Napkin” (Dan Roam. Portfolio, 2008) e “Business Modeling – A Practical Guide to Realizing Business Value” (David M. Bridgeland e Ron Zahavi. Morgan Kaufmann, 2009) provam que a displina pode ganhar um novo impulso. Eu espero que minhas contribuições mereçam 2 centavos. E um pouquinho de sua atenção. Inté!

.:.

Nota:

• Mais uma imagem surrupiada de Kelbv, agora a flikr0679. É aquela enigmática e colorida figura do topo do artigo. Tudo a ver com modelagem, certo?

A visão dos processos de negócio é a mais complexa das 4 visões propostas na EPBE. É aquela que demandará mais trabalho do Analista de Negócios (AN). Claro, ela é o núcleo da modelagem de negócios. No artigo anterior foram apresentadas a visão do negócio e a visão da estrutura. Ao modelar processos, damos sentido para aquelas vistas, explicando como os recursos (visão da estrutura) são consumidos, utilizados e gerados para satisfazer os objetivos do negócio (visão do negócio).

Na EPBE, utilizamos um Diagrama de Processo para a representação básica de um processo. Veja a imagem acima: trata-se de uma extensão (um tanto radical) do diagrama de atividades da UML. Indicamos nele todos os principais recursos utilizados ou gerados, diferenciando-os através de estereótipos (Info, Físico, Pessoa). Se a visão da estrutura foi corretamente desenvolvida (em uma ferramenta CASE), todos os recursos estão disponíveis na forma de “classes”. Ou seja, ao elaborar o diagrama acima, o AN simplesmente “arrasta” para o diagrama todos os recursos consumidos, utilizados ou gerados por um determinado processo.

Há outro estereótipo no gráfico acima: Objetivo. São informações que foram obtidas no desenvolvimento da visão do negócio. Todo processo, por definição, possui (ou deveria possuir) objetivos bem claros. Mas, neste ponto, podemos ser mais específicos. Como sugerido anteriormente, podemos atrelar ao processo metas, indicadores e iniciativas planejadas na elaboração de Balanced Scorecards e Mapas Estratégicos. Ao formalizá-las em um diagrama de processos, o AN está registrando os primeiros requisitos de um projeto, por exemplo.

Se o projeto exigiu uma análise mais profunda do processo de negócio, também é neste diagrama que registramos os principais achados. Repare na figura do Processo: 4 atributos representam algumas características básicas de um processo. No exemplo acima, Tempo de Ciclo, Custo, Eficácia e Eficiência. Se o projeto demandar, o AN pode desenvolver um diagrama que retrate a situação atual do processo (“as is”) e outro que aponte o cenário desejado (“to be”).

No entanto, como aprendemos com Goldratt (depois de vários outros), melhorias locais podem gerar desastrosos efeitos colaterais em outras partes do negócio. Um processo de negócio sempre se relaciona com outros. Por isso, o AN desenvolve mapas que mostram a interação entre processos. São derivações do diagrama acima, que podem inclusive mostrar as áreas envolvidas.

O diagrama acima pode ser utilizado tanto para a elaboração de um grande mapa de processos quanto para o detalhamento de um processo específico. Neste caso, a figura (estereótipo) que representa um processo (o pontiagudo hexágono) é utilizada para representar partes menores do processo, um sub-processo, atividade ou tarefa (dependendo do nível de detalhamento necessário).

É raro encontrar um processo de negócio que não esteja minimamente amparado por sistemas de informação. Um AN não pode ignorar a influência dos sistemas existentes, mesmo quando um projeto tratar exatamente da substituição destes. Utilizamos então outra variação do diagrama de processos para ilustrar a relação de um processo com os sistemas. Trata-se do Diagrama de Linha de Montagem (Assembly-line):

No exemplo acima estão representados o processo e dois sub-processos (ou atividades, não importa). As “linhas de montagem”, representadas por pacotes da linguagem UML, são os sistemas. Os pequenos círculos brancos representam informações fornecidas pelas aplicações. Os círculos escuros são as informações geradas e “gravadas” pelo processo. Assim, de uma maneira bem simples, mostramos como o processo está automatizado atualmente.

Trata-se de um momento muito importante para o AN. Atenção para as elipses entre o processo e as “linhas de montagem”. São Casos de Uso. Se estiver executando uma engenharia reversa, por exemplo, o AN começa aqui o desenvolvimento de requisitos.

Os três diagramas apresentados acima, como tudo na EPBE (e na UML), não são mandatórios. São ferramentas que auxiliam na compreensão dos processos de negócio e dos requisitos de um projeto. Todos eles são, de certa forma, de “alto nível”. Ou seja, não representam os detalhes da execução de um processo. O menor bloco de construção de um processo de negócio, sua única parte indivisível, é a tarefa. Vários tipos de projetos exigirão que o AN analise e modele um processo no nível “mais baixo” possível. Para tanto, é difícil fugir do nosso velho e bom fluxograma.

Na EPBE utilizamos o diagrama de atividades tradicional da UML. Se necessário, podemos estendê-lo para fornecer informações coletadas nos diagramas desenvolvidos anteriormente, como metas, recursos específicos (e críticos) etc. Outra alternativa, dependendo do projeto, é a utilização da BPMN. Trata-se do único ponto em que BPMN substitui um diagrama da EPBE.

Um projeto pode exigir um estudo ainda mais minucioso da dinâmica de uma organização, do comportamento de recursos e / ou processos. Para tanto, o AN lança mão da 4ª e última visão (básica) proposta pela EPBE: A Visão do Comportamento do Negócio. Não está no escopo desta série o detalhamento desta visão. Mas vale a pena citar que entre seus principais diagramas estão: Diagrama de Estado, Diagrama de Seqüência, Diagrama de Comunicação (muito parecidos com os originais da UML) e variações dos diagramas de Processo e Linha de Montagem.

O principal objetivo desta série, que se encerra aqui, era apresentar o básico da EPBE. Espero que, no mínimo, a adoção da EPBE seja mais debatida. É importante reforçar dois pontos: i) UML já é um padrão de facto para a modelagem de sistemas. Reaproveitar o investimento em ferramentas e treinamento faz muito sentido. Adotar um padrão único para a modelagem do negócio e de sistemas faz mais sentido ainda; ii) BPMN e afins não são suficientes para uma completa e correta modelagem de negócios.

Notas:

1. “A Meta” – 2ª Edição, Eliyahu Goldratt e Jeff Cox. Nobel (2002).
   Considerei seriamente colocar algumas pitadas de TOC (Teoria das Restrições) em meu trabalho para a formação de AN’s. Queria, particularmente, desenvolver algumas extensões para a EPBE. Talvez o cronograma não permita. Mas fica aí o desafio e um requisito do tipo “idéias para implementações futuras”.

É mandatório que o AN conheça o perfil da empresa – aquele pequeno conjunto de características que a torna única. A parte que é (ou deveria ser ) mais evidente é a proposição de valor, dado que norteia praticamente todas as estratégias da empresa. Para Michael Porter existiriam duas proposições básicas: baixo custo ou diferenciação. Robert Kaplan e David Norton , depois de vários autores, fixaram a existência de quatro proposições de valor:

• Baixo custo total;
• Liderança do Produto (ou Inovação);
• Soluções Completas; ou
• Aprisionamento.

Utilizei o “OU” (um XOR – OU Exclusivo) para mostrar que o natural é que a empresa apresente apenas uma proposição de valor. Seria uma questão de identidade. O que não significa que uma empresa reconhecidamente inovadora (Apple, por exemplo), não tenha preocupação com custos ou que ela não lance mão de táticas de aprisionamento (iPod + iTunes + DRM, por exemplo). O fato é que a primeira identificação (Apple = Liderança do Produto, seguindo no exemplo acima) é a sua proposição de valor. Algo como: “a primeira impressão é a que fica”.

Qual a relevância desse aprendizado para o AN e para o projeto em questão? Acontece que a proposição de valor :

• Determina o desenho dos processos de negócio da organização. Afinal, é através deles que ela cria valor;
• Influencia diretamente a forma como a empresa administra seus recursos;
• Caracteriza suas regras de negócio; e
• Direciona seus objetivos e metas.

Por exemplo: se a empresa se caracteriza por oferecer “Baixo custo total”, o AN se concentrará na extrema eficácia e eficiência dos processos de negócio. Gargalos, estoques de segurança e retrabalho são alguns dos principais sintomas que o AN procurará identificar . Assim como o AN deverá dar especial atenção à integração de dados (particularmente de clientes e parceiros), quando a proposição de valor da empresa for oferecer “Soluções Completas”.

Mas a proposição de valor é apenas uma parte da equação. Ela nos diz o QUE a empresa levará para seus clientes e para a sociedade, mas não explica COMO o fará. É aqui que entram os Modelos Operacionais.

Um modelo operacional indica “o nível necessário de integração e padronização dos processos de negócio para que a empresa possa entregar seus produtos e serviços para os clientes” . Trata-se de um conceito relativamente novo, que ainda carece de muitas pesquisas. Ou seja, será difícil encontrar uma empresa, particularmente em solo tupiniquim, que tenha institucionalizado seu Modelo Operacional. No entanto, mesmo que ‘sem querer’, toda empresa possui um modelo operacional (assim como toda empresa apresenta uma proposição de valor, por dúbia que seja).

Na definição acima ficou claro que o modelo operacional possui duas dimensões: Integração e Padronização. O diagrama abaixo mostra as 4 combinações possíveis :

• Diversificação: a empresa possui poucos (ou nenhum) processos integrados e padronizados. As unidades de negócio são autônomas e, geralmente, cuidam de suas soluções de TI (que são descentralizadas). Clientes, produtos e parceiros também não são compartilhados entre as unidades.
• Replicação: processos não são integrados, mas são padronizados, o que garante escalabilidade. Normalmente os clientes não são compartilhados (como em modelos de franquias, por exemplo). O desenho dos processos é centralizado, mas as unidades de negócio são semi-autônomas. TI, na maioria das vezes, é totalmente centralizada.
• Coordenação: processos não são padronizados, mas são altamente integrados. Isso indica que as unidades de negócio compartilham clientes, produtos e/ou parceiros de negócio. As unidades de negócio são autônomas, normalmente cuidando também de suas soluções de TI.
• Unificação: integração e padronização plena dos processos de negócio, o que normalmente é obtido através do uso de sistemas de gestão centralizados (ERPs ou afins). TI também é centralizada.

Não há um modelo melhor. Cada negócio pode exigir uma combinação única, ou até mesmo a adoção de combinações diferentes para alguns conjuntos de processos de negócio. Também não parece ser possível fazer uma vinculação direta da proposição de valor com um modelo operacional. Não de maneira arbitrária. Podemos encontrar, por exemplo, empresas que oferecem “baixo custo total” e utilizem o modelo “diversificação” ou o modelo “unificação” – os dois extremos da matriz acima.

Ou seja, o AN deve levantar as duas informações: descobrir a proposição de valor da empresa e também o seu modelo operacional. Quanto tempo ele deve gastar em tamanha descoberta? Se a empresa for ‘organizadinha’, uns 10 minutos. Caso contrário, meia hora deve ser suficiente. Sem exageros. Como eu disse anteriormente, são informações muito básicas. Mas caríssimas em várias decisões do projeto. Em um futuro artigo tentarei demonstrar essa relevância toda na prática.

Notas:

1. Competitive Advantage: Creating and Sustaining Superior Performance
   Michael Porter. Free Press (1985).
2. Mapas Estratégicos
   Robert S. Kaplan e David P. Norton. Editora Campus (2004).
3. Reparem nos itens em negrito daquela lista: Processos, Recursos, Regras e Objetivos. Através destes 4 elementos básicos devemos ter condições de descrever qualquer negócio. No workshop ‘Formação de Analistas de Negócios‘, mostramos como eles podem ser representados em diagramas UML.
4. Para alguns, o AN deveria ser um mero “coletor de requisitos”. Outros, como este que os aporrinha, crê que um AN pode ser mais útil como um mix de palpiteiro e enfermeiro de processos: um cara que não faz vista grossa para processos de negócio doentes.
   Aliás, ao detectar processos “dodói”, o AN aumenta consideravelmente as possibilidades de antecipar mudanças, reduzir riscos do projeto, etc etc
5. Enterprise Architecture as Strategy
   Jeanne W. Ross, Peter Weill e David C. Robertson. Harvard Business School Press (2006).
6. Menos de 10% (chute meu) dos participantes da 1ª turma do workshop não souberam dizer qual a proposição de valor de suas organizações. A turma que representava órgãos públicos (principalmente prefeituras) titubeou um pouco, mas logo (eu acho) concordaram: Prefeituras = Soluções Completas.
   

Um sintoma que indica que o trabalho da equipe da Anne começa ‘muito solto’ pode ser identificado na seguinte sentença: “Nós organizamos as cento e poucas estórias por processos de negócio…”

Parece que as estórias são coletadas de uma forma aleatória. Os tais ‘workshops para coleta de estórias dos usuários’ não são orientados por um estudo anterior. Parece natural que, com uma granularidade tão fina (estórias são ou devem ser pequenas), o trabalho de planejamento das iterações e priorização das estórias fique bastante confuso.

Se o AN começar seu trabalho “do início”, ele não terá o trampo de “organizar estórias por processos de negócio”. Ele realizará a coleta por processos ou atividades de negócio. Além do levantamento e classificação básica dos processos, que comentei brevemente neste post, o AN também deve determinar (claro – em conjunto com os clientes e usuários) a priorização dos processos e / ou atividades de negócio. Depois, cada workshop (ou qualquer outra técnica de levantamento) é programado para cuidar especificamente de um processo ou atividade.

Claro, as coisas nunca são assim tão simples. Processos se relacionam; atividades geram impactos em outras atividades. O AN deve ter uma clara visão dos relacionamentos e restrições. E essa visão só é possível depois de um estudo e mapeamento dos processos. Antes que gritem: não se trata de nada detalhado, de nenhum tipo de estudo que custe 2 ou 3 meses ao projeto. Um mapa em alto nível, que considere apenas os fatores fundamentais, é suficiente. E pode ser gerado em poucos dias de trabalho.

Me desculpem o rabisco, mas usando uma variação da UML o mapa de processos pode ficar mais ou menos assim:

Os objetivos ou metas de cada processo são praticamente os primeiros requisitos que um AN conhece. Eles derivam dos grandes objetivos do negócio, que podem estar documentados em planos estratégicos ou em coisinhas mais modernas como Balanced Scorecards e Mapas Estratégicos. Nossa área é estranha: já vi várias equipes de projetos trabalhando sem a mínima noção de quais eram os objetivos daquele processo de negócio que eles estavam automatizando ou otimizando. Para que exigir um mapa quando a viagem não tem destino?

Nota: Mapa = um ‘pouquinho’ de planejamento up front‘.

Mas este não foi o único probleminha que vi no depoimento da Anne. Encuco também com as ‘estórias’. Em outro post eu falarei sobre elas e as vantagens dos casos de uso.

Observações:

1. Não se trata de um trabalho isolado. O AN pode ou deve estar acompanhado de outros membros da equipe no momento da coleta, análise ou refinamento dos requisitos.
2. Todos os diagramas da apostila/livro, por enquanto, estão no padrão “rabisco”. Birra minha: queria mostrar um trabalho totalmente isento de ferramentas e seus diversos sabores.
3. EPBE, ou Eriksson-Penker Business Extensions, documentadas no livro “Business Modeling with UML“, de Hans-Erik Eriksson e Magnus Penker – Wiley/OMG (2000).

A mais básica distinção é o tipo do processo: Primário, de Apoio ou de Gestão? Só essa diferenciação pode alterar drasticamente a estratégia de análise adotada pelo AN.

Processos de gestão são todos aqueles que a organização utiliza para coordenar os processos primários e de apoio. Podem ser um tanto informais, marcados pelas características individuais dos ocupantes dos altos escalões da empresa.

Os processos de apoio são aqueles que suportam a execução dos processos primários. Sua baixa contribuição para a realização ou diferenciação do negócio os tornam os primeiros alvos de iniciativas de terceirização. Compras, contratação de pessoal, administração de recursos humanos e contabilização são alguns exemplos clássicos de processos de apoio.

Por fim temos os processos primários, aqueles que lidam diretamente com os clientes da empresa. Formam o que os entendidos chamam de Core Business, e a qualidade da sua execução determina a identidade da empresa: é cara, é lenta, é burocrática, é uma bagunça…

Segundo Kaplan e Norton, podemos classificar os processos primários em 4 sub-tipos:

• Operacionais: produção e entrega de bens e serviços para os clientes;
• Gestão de Clientes: todas as atividades ligadas ao relacionamento com o cliente;
• Inovação: pesquisa e desenvolvimento de novos produtos, serviços ou processos; e
• Regulatórios e Sociais: conformidade com as regras e expectativas do setor, legislação ou comunidade.

Cada tipo ou sub-tipo de processo de negócio pode alterar consideravelmente o escopo, forma e ritmo de trabalho do AN. Pode significar também uma estratégia totalmente diferente para a coleta e análise de requisitos. Portanto, tal classificação deveria ser uma de suas primeiras preocupações.

A classificação pode ser consolidada em um simples mapa de processos, um diagrama que indique, em alto nível, seu escopo de trabalho.

Praticamente no mesmo momento o AN pode descobrir (inferir ou perguntar*) qual a proposição de valor da empresa. Parece coisa boba, mas essa informação também fornece um belo norte para o trabalho do analista. Há uma certa discussão em torno do tema – proposição de valor -, mas Kaplan e Norton chegaram em um classificação simples e útil:

• Baixo custo total (Casas Bahia, Gol);
• Inovação (Embraer, Apple);
• Soluções completas (Bradesco, IBM); e
• Aprisionamento (HP, MS).

Se a empresa tem a intenção de ser barata o tempo todo, seus processos são desenhados para ser extremamente eficientes e enxutos. Organizações que se posicionam como inovadoras possuem um conjunto de processos que não gostam de ser vistos como “processos”. Empresas que oferecem soluções completas exigem um altíssimo nível de integração (entre processos e entre sistemas). E assim por diante.

Tipo dos processos que formam o escopo e o perfil da organização são informações que o AN levanta muito rapidamente. São baratas e simples. Mas podem influenciar praticamente todas as tomadas de decisão no decorrer de um projeto.

1. Mapas Estratégicos
   Robert S. Kaplan e David P. Norton. Editora Campus (2004).

* É um dos primeiros exercícios do workshop: qual a proposição de valor da sua empresa? A pergunta é simples. As quatro respostas possíveis também. Mas muita gente não sabe responder. Então vai aqui um exercício genérico: qual a proposição da valor da Natura? E d’O Boticário? São iguais?

Mais um: se a Apple usa estratégias de aprisionamento (iPod + DRM + iTunes), por que ela figura na lista acima como inovadora?

Fáceis, não?

A UML, particularmente sua versão 2.0, é muito extensa? Muito genérica? Sim. Mas isso não é um acidente – um defeito. O ponto mais forte da UML, fora a coerência e legibilidade de seus artefatos, é a sua extensibilidade. Qualidade óbvia, já que ela é genérica. Tipo: “não faz mais do que a obrigação”. Várias extensões foram desenvolvidas desde o nascimento da linguagem, no final da década passada. Uma delas é muito relevante para esta discussão: a EPBE, ou “Eriksson-Penker Business Extensions“.

Apresentada por Hans-Erik Eriksson e Magnus Penker no livro “Business Modeling with UML” (Wiley, 2000), a EPBE cobre todos os aspectos da modelagem de negócios. Ou quase todos. É curioso, por exemplo, que ela não contemple diagramas de casos de uso. Na visão dos autores, tanto o diagrama de casos de uso quanto os diagramas de componentes e de distribuição (deployment) “são utilizados na análise e projeto de sistemas de informação, mas são pouco relevantes na modelagem de negócios”. Por não conseguir dissociar a modelagem de negócios da engenharia de requisitos (falha minha), coloquei aquele “quase” acima.

Mas a EPBE realmente cobre o essencial na modelagem de negócios, estruturando-se em torno de 4 visões:

• Visão do Negócio: uma visão geral do negócio, destacando aspectos estratégicos e táticos (problemas a combater ou oportunidades a aproveitar);
• Processos de Negócio: mostra a dinâmica da organização, inclusive seu relacionamento com entidades externas.
• Estrutura do Negócio: apresenta a estrutura da organização, a divisão de recursos e a carteira de produtos e/ou serviços;
• Comportamento do Negócio: o comportamento individual de cada recurso ou processo no modelo do negócio.

Apenas nesta breve descrição já fica claro que não é possível comparar UML com BPMN. Seria algo como comparar uma bela melancia com uma simpática jaboticaba. BPMN, como o próprio nome indica, é uma Notação para Modelagem de Processos de Negócio. Ou seja, cobre apenas 1/4 do que é possível realizar com a UML devidamente extendida. Mas a questão não se encerra aqui.

Muitos lembrarão: “ah, mas o debate verdadeiro é BPMN versus o Diagrama de Atividades da UML”. De forma simples e direta: não há nada que eu faça em BPMN que eu não consiga representar em UML. Sim, com BPMN eu consigo diagramas mais ‘bonitinhos’, mas acho que este, definitivamente, não é o caso. Agora vamos elencar algumas coisas que conseguimos representar em UML e que não estão previstas na especificação BPMN:

• Know-Why: um processo de negócio bem documentado justifica sua existência. Precisamos conhecer os objetivos e metas atrelados àquele dado processo. É fácil extender o diagrama de atividades para armazenar essas informações. Mas para que reinventar a roda? O Diagrama de Processos da EPBE já prevê e obriga a inserção desses atributos do processo.
• Métricas: apelando para a batida máxima, “não se gerencia o que não se mede”. Pode não ser verdadeira para tudo mas, em se tratando de processos de negócio, a afirmação é mais que verdadeira. Cada tipo de processo pode ter um conjunto muito específico de medidas relevantes. Mas existem duas que deveriam estar em todo mapa de processo: Custo e Tempo de Ciclo. Para conhecer os custos de um processo é imperativo que mapeemos todos os recursos utilizados em sua realização. BPMN simplesmente ignora-os.
• Informação: na EPBE as informações são tratadas como um tipo de recurso que municia um processo. BPMN, como dito anteriormente, não se preocupa com recursos.
• Pessoas: ou stakeholders, também são recursos na notação EPBE.
• Requisitos: sim, a EPBE também não contempla artefatos para a captura e gerenciamento de requisitos. Mas ela, ao contrário da BPMN, não ignora sua existência. Há um diagrama muito útil na EPBE, o Diagrama de Linha de Montagem (Assembly Line – veja exemplo abaixo), que permite associar processos de negócios (diretamente de seu respectivo diagrama), com pacotes de objetos (ou serviços!) e casos de uso. Ou seja, consigo rastrear – navegar entre o domínio do problema e o domínio da solução. Com uma vantagem imbatível: usando a mesmíssima linguagem: UML.

Conclusão

Não é o caso de simplesmente dizer que BPMN não é útil. Suas boas idéias, particularmente o maior detalhamento de alguns elementos (só obtidos através do uso de estereótipos no Diagrama de Atividades), podem e devem ser aproveitadas. BPMN e UML estão sob os cuidados do OMG. Acredito que num futuro próximo veremos uma mixagem das duas especificações. Ou então a transformação de BPMN em uma extensão da UML. Algo fácil e natural.

Se BPEL é o seu sonho de consumo, saiba que já existem tradutores de diagramas de atividades para ela. Portanto, BPEL não é desculpa para a adoção da BPMN.

Por fim é arriscado mas necessário dizer que não podemos confundir Modelagem de Negócios com a Modelagem de Processos de Negócios. A primeira é uma disciplina muito mais ampla e complexa. Que é muito importante em projetos para desenvolvimento de sistemas. E nada menos do que VITAL em iniciativas SOA.