PAULO FERNANDO VASCONCELLOS NOGUEIRA

Tag: Pensamento Visual

  • Vídeo: Desenhando Negócios – As Ferramentas Fundamentais

    Vídeo: Desenhando Negócios – As Ferramentas Fundamentais

    Desenhar negócios é uma arte – exige imaginação e criatividade. É ciência também. Aliás, muitas ciências. Demanda exatas; é impossível sem as humanas. Tamanha variedade não cabe em um único modelo.

    Se pretendemos estudar, criar e impulsionar negócios, precisamos de vários modelos. Não de um amontoado de diagramas, jogos e canvases, mas de ferramentas que, em conjunto, nos ajudem a contar histórias.

    Este é o objetivo desta videoaula: apresentar uma caixa de ferramentas fundamentais para o desenho de negócios – peças para boas histórias.[videoembed url=”https://youtu.be/M05FktlYJVE”]

    Observações

    • A aula foi transmitida ao vivo, via Youtube, no dia 19/9/2017.
    • Existem pequenas falhas no vídeo. Peço desculpas por isso.
  • Vídeo: Imagens da Organização

    Vídeo: Imagens da Organização

    Como você enxerga o seu negócio? E como você o explica? Quais metáforas e analogias te ajudam? Elas são eficazes?

    A sua organização é viável? Como ela estará quando a crise passar? O que lhe diz isso? A contabilidade? Um canvas? Sério?

    Este vídeo mostra um jeito diferente de olhar, desenhar e diagnosticar negócios. Veja como um modelo bem pensado pode trazer novas questões, perspectivas e possibilidades.[videoembed url=”https://youtu.be/Bz3dwRu9Kyk”]

    Observações

    • A aula foi transmitida ao vivo no dia 26/7/2017.
    • Existem algumas pequenas falhas no vídeo. Peço desculpas por isso.

  • Priorizar

    Priorizar v. {mod. 1} t.d. tratar de (algo) em primeiro lugar e com mais empenho (Houaiss).

    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.

  • Benefícios / Custos

    No capítulo anterior vimos como atribuir valor para projetos. Aprendemos que as possíveis iniciativas devem ser avaliadas como um conjunto e nunca de forma isolada. Nosso foco até agora esteve no peso, na contribuição de cada iniciativa para que a empresa alcance seu objetivo maior. Neste quarto artigo da série vamos olhar para o outro lado da moeda, aquele formado pelos custos.

    .:.

    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.

  • The Back of the Napkin

    Autor: Dan Roam é presidente da Digital Roam Inc., empresa que consultoria que já atendeu clientes como Google, eBay, GE, Boeing e Wal-Mart. Seu método já foi apresentado no Senado dos EUA e em canais de TV como CNN, MSNBC e Fox News, dentre outros.

    Editora: Portfolio (EUA, 2008).

    Do que se Trata: “Resolver problemas e vender ideias com figuras” (subtítulo do livro). Roam apresenta o Pensamento Visual, um método que se baseia na seguinte premissa: uma imagem vale mais que mil palavras. Aprendemos aqui que a imagem certa vale bem mais que mil palavras.

    A quem se destina: Todo mundo que resolva problemas e / ou venda ideias.

    Dê de presente para:

    • Analistas de Negócios e de Sistemas
    • Líderes de Projetos
    • Desenvolvedores
    • Executivos
    • Seu colega que fala e / ou escreve demais.

    Contra-indicações: Nenhuma. E Roam prova que todo mundo pode aprender a desenhar.

    Prós:

    • Leitura fácil e muito agradável.
    • Roam é muito didático. E os exemplos utilizados são bons.
    • A diagramação esperta evita idas e vindas.

    Contras:

    • A base da neurobiologia, relevante que é, não deveria estar no apêndice. O autor nos convida a visitá-lo várias vezes no início do livro. Aceite o convite.
    • Os exemplos são bons mas poucos. Por isso o autor se apressou em lançar um complemento, “Unfolding the Napkin” (mais sobre ele abaixo).
    • Quem já tem o costume de desenhar para entender ou explicar pode achar o livro meio “basicão”. Mas, inexplicavelmente, anda raro encontrar pessoas com tal hábito. Mais difícil ainda é encontrar quem o faça de maneira sistemática, amparado por um método consistente.

    Apresentação / Complementos:

    Trilha de Estudo:

    1. Obrigado pela Informação que Você NÃO me Deu!
      Normann Kestenbaum – Campus / Elsevier (2008).
      Apresentado anteriormente na biblioteca do finito.
    2. Unfolding the Napkin
      Dan Roam – Portfolio (2009).
      Um método “hands-on” – um workshop de 4 dias com vários exemplos e exercícios. Complemento obrigatório de “The Back of the Napkin”.
    3. Business Modeling with UML
      Hans-Erik Eriksson e Magnus Penker – Wiley (2000).
      Aqui pisamos em solo pedregoso. Livro indicado apenas para quem quer megulhar de cabeça no uso da UML para a modelagem de negócios. Para analistas de negócios, considero um caminho inevitável. É interessante notar que, a exemplo do que acontece no FAN, o método de Dan Roam facilita bastante esta viagem. Dois artigos de minha autoria mostram um pouco deste ‘casamento’:
      Modelagem de Negócios: Uma Sugestão
      Modelagem de Negócios: Os Diagramas
    4. Business Modeling – A Practical Guide to Realizing Business Value
      David M. Bridgeland e Ron Zahavi. Morgan-Kaufmann (2009).
      Citado anteriormente por aqui. Não concordo nem um pouquinho com as sugestões dos dois autores: 4 linguagens ou padrões de notação diferentes para cada aspecto do negócio (BPMN se encaixa aqui). Prefiro o uso de uma única língua, UML. Mas preciso dizer que é um caminho alternativo para analistas de negócios e afins.

    .:.

    PS: Eu prometi uma trilha por mês. E falhei em abril. Portanto, aguardem outra entrada em nossa Biblioteca ainda em maio.

  • FAN – Ano III

    Como foi antecipado, a estreia do novo formato do FAN acontecerá neste final de semana, em São Paulo. Além do conteúdo programático, mexi também na estrutura do treinamento e no visual do material de apoio. Destaco neste artigo as principais modificações e as justificativas para elas.

    O programa para Formação de Analistas de Negócios é um eterno trabalho em desenvolvimento. Aliás, eu acho que todo programa de treinamento é ou deveria ser assim. Sempre encontraremos algo que pode ou precisa ser melhorado. Durante os dois primeiros anos o conteúdo foi diferente em todas as turmas, para desespero do pessoal que confecciona as apostilas. A primeira grande alteração se deu após a quinta edição, quando dobramos a carga horária. A principal reclamação que recebíamos via fichas de avaliação era: “Puxa, a gente gostaria de exercitar suas sugestões”. Esticamos a duração do treinamento para poder incluir os módulos práticos.

    Alteramos também o material didático. Além das apostilas, os alunos também recebiam material de apoio para execução dos exercícios. Não bloquinhos de rascunho, como de costume, mas modelos que, apesar de extremamente simples, apoiavam o aprendizado ao reforçar os conceitos apresentados.

    Depois veio “The Back of the Napkin”, de Dan Roam (Portfolio, 2008), e com ele um novo método para o trabalho de modelagem de negócios. O núcleo das sugestões, baseado no uso da UML e sua extensão EPBE (Eriksson-Penker Business Extensions), foi mantido. Mas o método do pensamento visual facilitou tanto o aprendizado quanto a aplicação prática e imediata da modelagem de negócios.

    Só em agosto de 2009 eu resolvi “congelar” o conteúdo do FAN. Queria testar sua estabilidade em turmas abertas e fechadas. O “descanso” e relativo distanciamento do material foi proveitoso. Há pouco mais de um mês, quando o reencontrei, sabia exatamente o que alterar.

    A sequência do treinamento é madura, está bem resolvida. Mas slides envelhecem! Cerca de 70% dos slides têm a idade do FAN! De tanto apresentar o material, sempre com alguma variação, aprendi uma separação mais adequada entre o que vai na apresentação e o que é falado. É uma reengenharia gostosa de fazer, cheia de surpresas. Tem momentos em que 5 slides vão para o lixo. No momento seguinte, 7 novos slides berram para ver a luz. Ou seja, o tamanho da apresentação utilizada seguirá parecido: imenso.

    Aproveitei o esforço para “dar um tapa” no visual do material didático. Se os slides já eram minimalistas pra caramba, agora eles ficaram mini-minimalistas. Influência viciante de duas obras: “Presentation Zen”, de Garr Reynolds (New Rider Press, 2008) e “The Presentation Secrets of Steve Jobs”, de Carmine Gallo (McGraw-Hill, 2010). Treinamentos como o FAN são muito cansativos. Dois dias inteiros consecutivos fazem com que os alunos percam muita coisa, principalmente ao final dos dois dias. E a gente sabe que bullets, cores, efeitos e muita ladainha escrita e falada cansam. É claro que um treinamento assim tem muito pouco em comum com os imbatíveis keynotes do Steve Jobs, por exemplo. Mesmo assim, as duas obras citadas ajudaram a desenvolver um material de apoio que: i) Cansa menos; ii) Registra aquilo que é estritamente fundamental; iii) É de fato *Visual*; e iv) Foge das perigosas e feias armadilhas do Powerpoint e afins. Estou muito satisfeito com o produto final. Tanto que em breve, finalmente (!), vou liberar uma versão light na área de downloads deste site e também no Slideshare. Só peço que aguardem um pouquinho, até a conclusão do teste de verdade que farei neste final de semana.

    A distribuição dos exercícios também ajuda a tornar o evento mais produtivo e agradável. Distribuídos de maneira homogênea e com duração fixa, eles acabam ditando um ritmo. Sim, tô surrupiando aqui uma prática muito eficaz dos projetos guiados por métodos ágeis. O ritmo constante, estou apostando, deve tornar os exercícios ainda mais produtivos e eficazes. E, de quebra, os alunos mergulharão um pouco mais no modelo iterativo e incremental de desenvolvimento. As versões anteriores do FAN também tinham essa intenção. Mas existiam módulos muito extensos de teoria, seguidos de dois ou três exercícios consecutivos. Consegui encontrar um formato mais equilibrado. E sem nenhum prejuízo para a parte teórica. Ok, chega de blablablá. Que venham os testadores! Inté.

    .:.

    “Pô Paulo, que sacanagem! Se você tivesse avisado a gente teria aguardado essa nova versão…”

    Pessoal, a AUI! (angústia pelos upgrades infinitos) veio para ficar. Você acaba de gastar aquela bela grana num celular novinho e daqui a uma semana  aparecerá um melhor e mais feito pra ti. Será sempre assim. No caso fo FAN não se preocupem porque: i) Todo o material estará disponível para vocês, através de nosso grupo AN.br; e, ii) Estou programando dois eventos de atualização que serão disponibilizados para todos os 2.000+ participantes das turmas anteriores do FAN. Um deles será “na faixa”, “vasco”, “grátis”. Aguardem!

  • Modelagem de Negócios: Os Diagramas

    Sequência obrigatória de “Modelagem de Negócios: Uma Sugestão“. Como prometido, apresento neste artigo um conjunto básico de diagramas que um analista pode desenvolver para entender um negócio. Opa… vale repetir o mantra: Modelamos um negócio para entendê-lo. Este é o principal objetivo da disciplina conhecida como modelagem de negócios. Assim como o principal alvo da engenharia de requisitos é a compreensão dos desejos, necessidades e restrições dos usuários.

    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 'Codex' da Modelagem de Negócios
    O 'Codex' da Modelagem de Negócios

    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:

    0documentoO 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.

    0mapa_processosO 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.

    0grafico_simplesQuando 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:

    0classes_simplesO 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.

    0estadoQuando é 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.

    0grafico_elabPois é, 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.

    0fluxo_swinlanesO 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:

    0processo_seqMapas 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.

    0processoO 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.

    0fluxo_cronogramaAnalistas 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.

    0fluxo_swinlanesAliá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.

    0sequenciaUma 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.

    0assembly_lineO 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’:

    0PucsO 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.

    0use_caseChegamos 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?

  • Modelagem de Negócios: Uma Sugestão

    Finalmente a prometida sequência de “Modelagem de Negócios: A Encruzilhada“. Justifico a demora: passei os últimos meses envolvido em serviços de treinamento e consultoria para 3 grandes empresas. Nelas tive a oportunidade de experimentar e validar a sugestão que apresento neste artigo. Trata-se de um teste ao qual são submetidos todos os métodos e práticas que formam o programa FAN: a aplicação real, em empresas e projetos de verdade.

    Encerrei o último artigo prometendo um ‘remix’ do método proposto por Dan Roam em “The Back of the Napkin” com a EPBE (Eriksson-Penker Business Extensions), uma extensão da UML para a modelagem de negócios. Essa é a sugestão apresentada neste artigo.

    .:.

    A principal ferramenta do método proposto por Dan Roam é a sequência de 6 perguntas conhecida como “6 W’s”. As questões são: Quem / O quê (who/what); Quanto (how much); Onde (where); Quando (when); Como (how) e por quê (why). Como vimos no artigo anterior, há um tipo de desenho mais indicado para cada pergunta.

    A modelagem de negócios compreende a elaboração de visões. Cada visão é formada por um conjunto de diagramas. Há sempre uma visão mais indicada, dependendo do objeto que está sendo modelado / analisado. No trabalho que lançou a EPBE, “Business Modeling with UML”, são apresentadas 4 visões: do Negócio, da Estrutura, dos Processos e do Comportamento. Hans-Erik Eriksson e Magnus Penker, os autores, lembram que podem ser criadas outras visões, dependendo da necessidade do analista e do projeto. As visões Econômica, de Sistemas de Informação e de Recursos Humanos são alguns exemplos.

    Visões

    Foi necessário um pequeno (mas sensível) ajuste na ordem das perguntas sugerida por Roam. Todo projeto ou estudo deve começar com o entendimento da motivação do negócio. Ou seja, “por quê?” não é a última e sim a primeira questão. Claro, ela também pode ser executada no final do ciclo. Serviria assim como um tipo de teste, uma validação dos trabalhos de modelagem e análise do negócio. A resposta para o “por quê” determina aquilo que na EPBE chamamos de Visão do Negócio. Trata-se da apresentação dos requisitos do negócio que, dependendo do projeto, podem incluir a transcrição da Missão e Visão – seus mais altos objetivos.

    As três primeiras perguntas de Roam – “Quem / O Quê”, “Quanto” e “Onde” – nos levam a construir a Visão da Estrutura. Vale lembrar que essa visão trata de todos os recursos que pertencem ao negócio ou que se relacionam com ele de alguma maneira. Estamos falando de recursos físicos (instalações, máquinas, veículos, computadores etc), humanos (colabodoradores, clientes, parceiros etc), de informação (sistemas, bancos de dados, documentos etc) além de outros não menos relevantes como produtos, serviços, concorrentes etc.

    Por fim, as duas questões  que fecham os “6 W’s”: “Quando” e “Como”. Suas respostas geram os modelos que formam a terceira perspectiva, a Visão dos Processos. Dan Roam, mesmo num contexto que é muito diferente da modelagem de negócios ‘pura’, avisa que a resposta para o “como” é a mais difícil. De certa forma ela consolida e valida tudo o que foi respondido anteriormente.

    Cabe aqui uma comparação com um tipo de modelagem mais conhecido pela maioria dos leitores do finito. A modelagem de sistemas envolve a construção de diagramas que representem dois aspectos: estrutural (diagrama de classes, por exemplo) e dinâmico (diagrama de sequência, por exemplo). Neste ponto a modelagem de negócios é idêntica. Também temos a visão da estrutura e da dinâmica (processos). A grande diferença é a existência de uma visão maior, a Visão do Negócio, que deve justificar e dar sentido para todas as outras.

    Outra observação sobre o diagrama acima: as interseções existem de fato. Há diagramas que ultrapassam as fronteiras de uma visão. O diagrama de linhas de montagem, por exemplo, combina recursos (as linhas, que podem representar sistemas de informação) que pertencem à Visão da Estrutura, com processos de negócio. A UML, de uma maneira geral, facilita a criação desses cruzamentos.

    SQVID

    Outra ferramenta apresentada em “The Back of the Napkin” é o SQVID, um seletor que nos ajuda a configurar um diagrama. Cada letra representa uma decisão que o analista deve tomar antes de começar o desenho. A lista abaixo apresenta as alternativas:

    • imples ou Elaborado: o diagrama deve ser simples ou mais completo, mais elaborado. Dan Roam lembra que o oposto de simples não precisa ser complexo.
    • ualitativo ou Quantitativo: o que é mais importante para aquele determinado diagrama, os aspectos qualitativos (e, de certa forma, subjetivos) ou quantitativos?
    • isão ou Execução: mostraremos apenas o destino (a Visão) ou é importante que o diagrama mostre como chegamos / chegaremos lá (a Execução)?
    • ndividual ou Comparativo: o diagrama tratará apenas um item ou todo o conjunto?
    • elta (Mudança – to-be) ou Como é (as-is): por fim, o diagrama mostrará o estado futuro daquilo que estamos modelando ou seu estado atual?

    Uma curiosidade sobre o SQVID. Segundo Dan Roam, sua configuração default (que forma a sigla) nos levaria a utilizar o lado direito do cérebro – ou seja, aquele que é mais “quente”, abstrato, visionário e emocional. Consequentemente, a outra configuração do seletor forçaria um raciocínio mais “frio”, objetivo, analítico, quantitativo e orientado à execução – características do lado esquerdo do cérebro. Como eu já disse no artigo anterior, Roam ampara suas sugestões em estudos da neurobiologia. Me limito a afirmar que o seletor SQVID é de uma utilidade impressionante. Ele deve ser configurado antes que uma linha seja traçada. Desta forma o analista fixa os objetivos daquele modelo, levando em consideração o perfil das pessoas que farão uso dele e o tipo de problema que pretende entender ou resolver.

    Relembrando: cada uma daquelas 6 perguntas apresentadas anteriormente nos leva a elaborar um ou mais diagramas. O SQVID nos ajuda e configurar um diagrama ou a selecionar um determinado tipo de diagrama. Cruzando essas duas variáveis geramos uma matriz, o Visual Thinking Codex, que foi apresentado no artigo anterior. Fazendo uma ‘conta de padaria’, podemos dizer que teríamos 60 tipos de diagramas diferentes (6 perguntas X 5 seletores X 2 alternativas). Não precisamos de tanto, mas o número de diagramas à nossa disposição pode ser bem maior do que aquele proposto por Dan Roam, que fixa apenas um tipo para cada questão.

    .:.

    No próximo artigo, que não demorará outros 4 meses, apresentarei as sugestões de diagramas para cada pergunta e cada opção SQVID. Inté!

    Atualização: O artigo já foi publicado – “Modelagem de Negócios: Os Diagramas“.

    Nota:

    • A imagem utilizada no topo deste artigo, flikr0627, é do flikr ou Kelbv, fotógrafo profissional que também elabora criativos desenhos (diagramas?). A variação 0627 acima foi escolhida por um simples motivo: olhares atentos perceberão 2 pessoas no centro do desenho, um AN atendendo seu cliente. Duvida? Então olhe a imagem de novo. Ou veja o destaque no Flickr.

  • Modelagem de Negócios: A Encruzilhada

    Se não vai no atacado, vai no varejo mesmo!1 Há tempos ameaço retomar a publicação de artigos técnicos aqui no finito. Tardei. Espero não falhar.

    Já comentei por aqui: a modelagem de negócios é, entre todas as disciplinas que dão forma para a engenharia de software, a menos compreendida. Consequentemente é pouco e mal utilizada. No entanto, surgem evidências e suspeitas de que esta situação deve mudar. Iniciativas SOA, BPM e de Arquitetura Corporativa, em níveis diferentes, exigem a existência ou a criação de modelos de negócios. Mas não se trata de outra demanda ‘falsa’, parida exclusivamente nos domínios de TI. O pessoal do mundo do negócio também começou a perceber os benefícios de bons modelos de negócios. O que nos traz para a encruzilhada do título. Neste artigo vou apresentar duas alternativas de modelagem, uma bem TI e outra bem “negócio”. Ambas foram apresentadas em livros lançados recentemente. E indicam um momento crítico para a evolução da disciplina.

    Encruzilhada

    Modelando Negócios, segundo TI

    Acabou de sair, pela Morgan Kaufmann/OMG (Object Management Group), o livro “Business Modeling – A Practical Guide to Realizing Business Value“, de David M. Bridgeland e Ron Zahavi. Como obras que tratam exclusivamente a modelagem de negócios ainda são raríssimas, este lançamento merece destaque. E vai receber. Repare, não se trata de um livro sobre BPM e afins. O papo aqui é apenas sobre modelagem. Os autores, otimistas, começam mostrando que a tendência é de uma crescente adoção da disciplina. E apostam que por volta de 2011 ela atingirá “massa crítica”2. Justificam suas apostas de forma simples: “a Modelagem de Negócios se tornou mais popular porque transformações em negócios se tornaram mais comuns“. E explicam que “modelos ajudam na implementação de mudanças. Se nada muda, você não precisa de modelos, assim como não precisa de mapas se não pretende viajar para lugar nenhum“.Business Modeling

    Os autores mostram que a modelagem pode gerar valor para o negócio de oito maneiras: i) Comunicação entre pessoas; ii) Treinamento e Aprendizado; iii) Persuasão e Vendas; iv) Análise de alguma situação do negócio; v) Gestão de Conformidade; vi) Desenvolvimento de Requisitos de Software; vii) Execução direta dos modelos através de mecanismos de software; e viii) Gestão do Conhecimento e Reuso.

    A lista, apesar de extensa, me parece incompleta. Neste ponto os autores não citaram a possibilidade de simulação e experimentação de novas ideias e a identificação de oportunidades de outsourcing de processos (BPO), por exemplo. Mas as omissões são relativamente pequenas. O que me preocupa de verdade são as sugestões apresentadas no livro.

    Bridgeland e Zahavi partem do princípio de que não há um padrão completo para a modelagem de negócios. E não deixam de reclamar em diversos momentos do texto a total ausência de ferramentas que contemplem uma “completa” modelagem. Eles apresentam a modelagem como um conjunto de 4 disciplinas: Modelagem da Motivação do Negócio, da Organização, dos Processos e das Regras. Completo, na visão deles, seria um padrão que possibilitasse a criação de modelos das 4 disciplinas. Eu acredito que o problema foi criado pelos próprios autores, no “quebra-cabeças” de padrões que eles selecionaram.

    Para a modelagem da motivação do negócio eles optaram por um novíssimo e único padrão existente, o BMM (Business Motivation Model), um trabalho do BRG (Business Rules Group) aceito pelo OMG em agosto de 2008. Como os próprios autores acusam, o OMG cometeu grave pecado ao aceitar e liberar o padrão antes de definir seu perfil visual – um padrão para os diagramas. O BMM cuida da visão (fim) e da missão (meios) de um negócio, de maneira abrangente e consistente. Mas parece uma ilha isolada do resto do mundo. Não se relaciona com nenhum padrão existente. Talvez o OMG tente incorporá-lo futuramente a algum metamodelo. No entanto, quando o assunto é o OMG e seus constituintes, tudo é incerto.

    Há tempos eu joguei todas as minhas fichas na EPBE (Eriksson-Penker Business Extensions). E sempre reconheci que a forma como essa extensão trata dos objetivos (motivações) do negócio é fraca. Por isso apresento mapas estratégicos e BSC’s (Balanced Scorecards) como complementos. Como a EPBE é extensível como sua base, a UML, não tive nenhuma dificuldade em incorporar a ela o BMM. Oportunamente eu falo mais sobre BMM e EPBE. Mas se você não aguenta de curiosidade, relembre aqui o metamodelo EPBE e obtenha aqui uma visão geral (bem alto nível) do BMM.

    O problema dos autores aumenta quando eles entram em sua segunda disciplina, a Modelagem da Organização. Eles afimam que não haveria um padrão para a construção desses modelos. Quem diria, nossos velhos e bons organogramas carecem de um padrão. Mas a questão não é só essa. Bridgeland e Zahavi ignoram outros recursos, outros elementos da estrutura de um negócio. Não citam, por exemplo, a necessidade de modelagem de produtos, serviços etc. A EPBE fala em Visão da Estrutura, não de Modelagem da Organização. A EPBE contempla, portanto, a modelagem de qualquer tipo de recurso.

    É fácil entender a omissão ao vermos o padrão que eles selecionaram para a Modelagem de Processos. Sim, eles optaram pela BPMN. Um padrão cheio de promessas e com um futuro promissor, mas que entrega muito pouco quando o assunto é *Modelagem de Negócios*.Sigo aguardando ansioso pelo dia em que uma boa alma apareça dizendo: “gente, BPMN é só um fluxograma 3.0 – um falso padrão3 sacaneado por ilustres fornecedores que deveriam defendê-lo. Um falso padrão que tem pouco ou nenhum valor quando nossa preocupação é entender um negócio“.

    Os autores justificam sua não opção pela UML dizendo que esta é muito ‘complicada’ para usuários finais. Concordo. Mas, apesar deles citarem o trabalho de Eriksson e Penker, “Business Modeling with UML“, ignoram por completo a EPBE. Ao relacionarem UML exclusivamente com o diagrama de atividades, demonstram desconhecer todas as outras opções de diagramas apresentadas no trabalho da dupla escandinava. Sigo desconfiado de que é este pequeno detalhe geográfico que segue fazendo da EPBE uma ilustre desconhecida.

    Problema dos autores, que tiveram que se revirar ainda mais no momento de fixar um padrão para sua última disciplina, a Modelagem de Regras. Acertam na escolha do SBVR (Semantics of Business Vocabulary and Business Rules), outro padrão adotado pelo OMG em 2008. Mas não conseguem deixar de mostrar a fragilidade das ligações desta com as outras 3 disciplinas que formam sua proposta. Eles reclamam muito da deficiência de ferramentas. O buraco é mais embaixo: os 4 padrões sugeridos pelos autores carecem de um alicerce único, de um metamodelo. Ao jogarem todas as suas fichas em padrões do OMG, implicitamente os autores apostam que esta entidade será capaz de suprir essa imensa necessidade. Ao ver os probleminhas que o OMG tem enfrentado só com a BPMN 2.0, sou obrigado a ‘mineiramente’ desconfiar. Com seus passos de cágado, talvez lá em 2037 o OMG apresente uma bela sugestão de metamodelo para uma completa modelagem de negócios. Vamos esperar sentados?

    O Negócio pelo Negócio

    É um livro de modelagem?!?Aí vem aquele “velho” cara de negócios e pergunta: “meu caro, diz aí, o tal OMG entende de negócios?” Antes que uma resposta (ou desculpa) pinte em nossas cabeças, o velho saca de sua estante um estranho livro quadrado: “The Back of the Napkin“, de Dan Roam (Portfolio – 2008). O velho nos diz: “Parece que o tal do Dan aí entende de negócios, e presta serviços de consultoria para empresas como Google, eBay, GE, Wal-Mart…”

    Se o livro de Dan Roam usou o termo “modelagem” em algum momento passou despercebido. Ele prefere o termo “Pensamento Visual”. Mas seu livro é só sobre isso: Modelagem de Negócios. Saca só o subtítulo: “Resolvendo Problemas e Vendendo Ideias com Figuras”. Não espere ver nada sobre UML, BPMN e coisinhas afins. Dan é um cara de negócios. E, por isso mesmo, insiste que devemos fugir de ferramentas informatizadas: “mão, caneta e guardanapos são suficientes para resolvermos qualquer problema de negócio!” Radical? Não, prático e pragmático mesmo. E, preciso dizer, ágil!

    Dan apresenta uma metodologia completa, formada por 4 elementos. Ele a apresenta como um “canivete suiço”. Sua primeira parte é formada por “3 ferramentas básicas para o pensamento visual”: nossos olhos, mente e mãos. Na sequência ele apresenta as 4 fases do pensamento visual: Ver, Observar, Imaginar e Mostrar4.Aí vem o SQVID5, uma série de 5 perguntas que “nos ajuda a abrir os olhos da mente: simples ou elaborado, qualitativo ou quantitativo, visão ou execução, individual ou comparações, mudança ou ‘as-is’?” Por fim as 6 formas como enxergamos que também são as formas como deveríamos mostrar, os 6W’s: “Who/what, hoW much, Where, When, hoW e Why”. Parece bobinho, não? Se você não reparou, até a sequência como o “canivete” é apresentado é “simplificadora”: 3 (ferramentas básicas), 4 (passos), 5 (perguntas) e 6 (formas de ver/mostrar).

    Parece bobinho, mas Dan escora suas sugestões em bases muitos fortes, como pesquisas muito recentes no campo da neurobiologia. Os 6 W’s, por exemplo, realmente representam a sequência pela qual nossos olhos passam informações para o cérebro. Por isso seriam intuitivas, naturais. Logo no início do livro o autor se preocupa em “escorar” suas sugestões. Em três páginas quase consecutivas ele nos convida a visitar o apêndice A, “A Ciência do Pensamento Visual”. Justamente para derrubar nossas possíveis desconfianças e mostrar que, apesar de simples, suas propostas são sérias. Aliás, a simplicidade é uma grande qualidade de seu trabalho. Porém, mais que o alicerce científico, são os casos reais apresentados que atestam a utilidade e força de seu método.

    O ‘Codex’ do Pensamento VisualAcontece que, a primeira vista, as sugestões de Dan Roam parecem totalmente incompatíveis com a disciplina que conhecemos como Modelagem de Negócios. Em nenhum momento ele cita o OMG ou coisinhas mais ‘pop’, como BPMN. Trata-se realmente de outro mundo.

    O diagrama acima mostra do “CODEX” do Pensamento Visual, uma grade que cruza os 6 W’s com as 5 decisões que tomamos no SQVID. Repare que, para cada W, Dan sugere apenas um tipo de desenho: retrato para o “quem/o que”; gráfico de barras para o “quanto”; mapas para o “onde”; cronograma ou linha de tempo para o “quando”; fluxograma para o “como”; e um gráfico comparativo (plot) para o “porque”. O SQVID ajuda a definir uma versão diferente para cada tipo de desenho.A única sugestão de Dan que se aproxima minimamente de nosso mundo é o fluxograma. Todos os outros desenhos parecem distantes de tudo que conhecemos para a modelagem de negócios: retratos, mapas, gráficos de barras…

    Precisa ser assim? Digo, TI e negócio precisam ser tão distantes até nisso, numa disciplina que deveria ajudar um a compreender melhor o outro? O mundo de TI precisa seguir insistindo em padrões lentamente definidos e sistematicamente desrespeitados?

    Como a Modelagem de Negócios é uma disciplina ainda em fase de definição, acho que é hora de revermos alguns caminhos, particularmente aqueles trilhados pelo OMG e fornecedores de ferramentas como SAP, IBM e Oracle.

    Em paralelo, os Analistas de Negócios, principais usuários da Modelagem de Negócios, devem procurar uma base que combine o melhor dos dois mundos. No próximo artigo apresentarei uma sugestão, um ‘remix’ das ideias de Dan executado na vitrola da EPBE/UML. Inté!

    Notas:

    1. O “atacado” seria o livro, que já toca neste assunto (com outras palavras. Aliás, muito mais palavras e figuras). Mas, como eu já disse em um pequeno post-agenda, não se trata apenas de um livro, mas também de um novo negócio e um sistema. Adiei o lançamento para costurar melhor todas as partes. Conto com a compreensão e paciência de todos.
    2. Em dinâmica social, massa crítica é a mentalidade de um grupo que é suficiente para, em quantidade e qualidade, permitir, propiciar e sustentar determinada ação ou comportamento. (Wikipedia).
    3. Digo que BPMN é um falso padrão porque ele não é respeitado por quase ninguém. Grandes fornecedores, como IBM, Oracle e SAP, insistem em ter seu “sabor” do padrão. Claro, assim eles dificultam a debandada de clientes insatisfeitos. Nada de novo no front de TI: SQL, HTML, COBOL e várias outras coisinhas também nasceram um dia para serem “padrões”.
    4. Minha tradução livre para Look, See, Imagine e Show.
    5. SQVID é uma sigla estranha mas de fácil compreensão: Simple, Quality, Vision, Individual e Change (D é de delta, mudança). O SQVID é apresentado como um seletor ou equalizador. O nome indica as primeiras opções. O contraponto, na mesma sequência, é: Elaborate, Quantity, Execution, Comparison e As-is.  Como o gráfico acima ilustra, para cada um dos 6 W’s escolhemos um lado do SQVID. Simples ou Elaborado, por exemplo.

    A foto utilizada neste artigo é de Kevin Slavin (Flickr). Aliás, vale a pena olhar o curioso jogo “Crossroads” que ele montou com GPS, usando Manhatan como tabuleiro.