PAULO FERNANDO VASCONCELLOS NOGUEIRA

Tag: Modelagem de Negócios

  • Rendiconti: A Morte do Patinho Feio, a Gripe Terremoto e outras novas

    Várias novas. Tanto que precisarei d’outro post para apresentá-las por inteiro. Mas antes, nossa tradicional prestação de contas. Aconteceu na última quinta (24/abr), a 2ª turma da oficina “Análise e Modelagem de Negócios” em Sampa. É o meu “patinho feio”. Explico: ao contrário de sua co-irmã, a oficina “Engenharia de Requisitos”, esta não está sexy o suficiente – não é atraente. Tanto que o público foi “só” 1/3 da média apresentada pelo outra. Sigo sem entender (“elas são indissociáveis!”, é meu choro frequente), mas não insistirei no modelo. Teimosia tem limite. Senão vira burrice, hehe. Mas falarei sobre as mudanças depois.

    Turma pequena é turma privilegiada. Posso atender todo mundo de uma forma mais frequente e pessoal. As interações tendem a ser um pouco mais ricas. E que sorte tivemos neste último evento! Experiências com Aris; AN’s (Analistas de Negócios) de uma grande empresa que utiliza XP (eXtreme Programming) como seu principal processo de desenvolvimento (!); um “Dino Coboleiro” (em suas próprias palavras); e, pela segunda vez, uma profissional de marketing interessadíssima na matéria; quatro participantes já haviam participado da outra oficina, o que também enriquece o evento – dois são professores (!); três pessoas foram de Curitiba exclusivamente para o evento; empresas importadoras e pequenas e médias empresas que desenvolvem sistemas. Ou seja, a turma era pequena mas eclética, variada, rica. O evento ganha muito com a diversidade – podemos conversar sobre vários modelos de negócios, estratégias, processos, problemas e oportunidades. Tanto que eu não via a hora de publicar esta “rendiconti”. Tanto que nem esperei pelas fotos. Quando elas aparecerem, publico aqui.

    Pelo resumo das avaliações que recebi, posso concluir que todos gostaram muito do evento. Mesmo assim, recebi 3 belos “puxões de orelha”. Vou aproveitar este espaço para comentá-los e, quando for o caso, rebatê-los.

    Aris

    O Aris vem no SAP R/3; é uma “linguagem” madura; “todo mundo usa”; “o usuário não precisa de treinamento para entendê-la”; “você não pode ignorá-la”. Pois bem, é a primeira vez que alguém me cobra isso. O que, definitivamente, torna o “todo mundo usa” um exagero. Quando iniciei este trabalho, há mais de um ano, naveguei brevemente pelo “mundo Aris”. O ignorei por completo por um simples motivo: meu trabalho simplesmente não cita nada que não seja um padrão aberto. Mesmo que a tentação (e as justificativas acima) sejam muito fortes, não cometerei o pecado de amarrar os conceitos e práticas que apresento em uma tecnologia ou ferramenta proprietária. Seria um suicídio. No mais, trata-se apenas de outra linguagem, assim como BPMN e a EPBE (UML) que apresento. Assim como eu falo sobre UML, deve ser fácil aprendê-la em um treinamento de 4 horas, mais ou menos.

    UML (e a extensão EPBE) seguirão no núcleo de meu trabalho sobre análise e modelagem de negócios. Mas vou considerar seriamente a inserção de um capítulo sobre outras notações. Mais que isso, deixarei em aberto a possibilidade de uma versão deste evento que utilize o Aris ao invés de EPBE. Mais sobre as extensões do programa FAN (Formação de Analistas de Negócios) abaixo e em futuros artigos.

    Inovação

    Veio do mesmo (simpático) crítico que sugeriu Aris: “esperava algo novo”. Ele falava especificamente da parte onde mostro a elaboração de um balanced scorecard (BSC) em EPBE. Juro, sigo achando que isso é novo! E me esqueci de perguntar se isso seria possível em Aris. Agora, se ele esperava uma alternativa ao BSC, acho que seguirei devendo por um bom tempo. Não vi surgir nada – com exceção do irmão do BSC, o Mapa Estratégico – que represente melhor a estratégia de uma empresa. Sério – não vejo nada no horizonte. Posso estar enganado. Mas, como não foi colocado nada no lugar, seguirei com minhas sugestões.

    XisPê

    A dupla (de AN’s) de uma grande empresa nos mostrou como eles trabalham com XP (ou XisPê ou eXtreme Programming). Foi muito legal. Usam stories (e não casos de uso); pair programming; TDD (Test-Driven Development); ou seja, todas as práticas fundamentais de XP. Detalhe: exceto uma! São eles que se sentam ao lado dos programadores, não os usuários. Meio na brincadeira (e meio sério), alertei-os que os “radicais” falarão que então não se trata de XP de verdade. Afinal, os “radicais” detestam AN’s! Não importa: estão felizes com o processo e, mais importante, está funcionando! Atenção pessoal que vive sendo cobrado (inclusive por este que aqui rabisca) por casos de sucesso na implantação de XP: taí um belo caso. Com AN’s!

    Gripe Terremoto

    Tive uma reunião logo após a oficina. Quando ela se encerrou, lá pelas nove, o primeiro tremor. Sinto uma gripe chegando de longe. E esta resistiria até a uma dose cavalar (e perigosa) de Resfenol. Só sei que não tem nada a ver com Dengue e afins porque estou quase sem voz, parecendo um poço artesiano e tremendo mais que prédio de Sampa na última terça. Ou seja: trata-se da gripe terremoto. Problemão: tenho vários compromissos na próxima semana. Se a overdose de chás e outros remédios não adiantar, não sei o que vou fazer. Só sei que o final de semana será diferente, com o note na barriga acompanhando meus tremores, hehe..

    Cadê o Cisne?

    Pois é: se o patinho feio se foi, cadê o cisne? Bom, ele precisa de alguns dias para concluir sua metamorfose. O coração do programa não sofrerá alterações, é lógico. Mas a oficina sofrerá grandes alterações, inclusive na forma como é comercializada. Preciso deixar mais nítida a amarração entre “Análise e Modelagem de Negócios” e a “Engenharia de Requisitos”, mesmo que um dos meus requisitos fundamentais seja o “leve acoplamento” dos eventos (ou seja, um não é e não será pré-req para o outro). Complicado, não? Bom, acho que já tenho a solução, e espero apresentá-la em breve.

  • BABoK = REBoK? Conversando sobre Análise e Modelagem de Negócios

    Nada como um dia (agitadíssimo) depois de outro (não menos agitado). Ao reler o artigo anterior, “O BABoK e a Disciplina ‘Enterprise Analysis’“, reparei que posso resumi-lo assim: O BABoK trata exclusivamente da macro-disciplina Engenharia de Requisitos. Apesar do nome, a KA (Knowledge Area) Enterprise Analsys (ou Análise Corporativa) trata exclusivamente daquilo que Karl Wiegers chama de Requisitos de Negócio . Trata bem e de maneira bem completa, diga-se de passagem. Mas este fato torna o nome BABoK (Business Analysis Body of Knowledge) meio enganador. Aquele conteúdo formaria um bom REBoK – Requirements Engineering Body of Knowledge. Para a Análise de Negócio falta uma metade: exatamente a Análise (e Modelagem) de Negócios!

    Desconfio que a falta já é sentida pelos próprios autores e responsáveis pelo BoK. Em uma das apresentações recentemente utilizadas na divulgação da profissão e do BABoK, eles frisam:

    Análise de negócios não é análise de requisitos de software. Analisar um negócio é compreender:

    • Como a organização trabalha;
    • Qual a razão de sua existência;
    • Seus objetivos e metas;
    • Como ela busca esses objetivos; e
    • O que ela precisa mudar para melhor atender esses objetivos.

    Para ajudar a definir uma solução para um problema de negócio.

    Com certeza, alguém já fez a mesma cobrança que faço desde que conheci o BABoK. Pena, mas a declaração acima (ainda) não está refletida naquele corpo de conhecimentos. Não há no BABoK um conjunto de Tarefas e Técnicas que atenda plenamente a lista acima, exceção feita ao terceiro item. Bom, como prometi no artigo anterior, serei mais “construtivo”.

    Antes de estudar as necessidades ou problemas de um negócio, é necessário conhecê-lo, aprendê-lo. Uma maneira muito eficaz para se *aprender* um negócio é a modelagem. Modelar é simplificar. Modelar é compilar apenas o que é essencial. Indico (teimosamente) o uso da EPBE (Eriksson-Penker Business Extensions) para a criação desses modelos por dois motivos principais: i) Ela é completa – me permite cobrir todos os aspectos de um negócio, sua estrutura e sua dinâmica (processos); e ii) A EPBE é uma extensão da UML (Unified Modeling Language), uma linguagem madura, bem difundida e fácil de aprender. (Já apresentei a EPBE em outra série de artigos).

    Todo e qualquer negócio apresenta 4 *coisas* que precisamos aprender: Objetivos, Recursos, Processos e Regras. Cada um deles pode merecer um ou mais modelos, dependendo da criticidade do negócio ou do projeto em questão. A EPBE nos oferece 4 visões, 4 dimensões – maneiras diferentes de *ver* o negócio: A visão do Negócio propriamente dita; sua Estrutura; Processos e Comportamento. Não há uma seqüência pré-fixada para o estudo. Como sempre, depende do negócio e do projeto. Mas, mesmo em empreendimentos muito simples, não abro mão de um enxuto mapa de processos e do diagrama de processos (ou “linha de montagem“) um pouco mais detalhado. Usando uma boa ferramenta CASE , e não meus rabiscos, obtemos automaticamente outros modelos, como a estrutura de recursos, objetivos e metas (ou mesmo um balanced scorecard).

    Ao estudar os processos, vendo as atividades e tarefas que os formam e toda a estrutura (departamentos e outros recursos) envolvida em sua execução, ganhamos uma visão mais nítida do “terreno que estamos pisando”. Se há um projeto, existem Requisitos de Negócio. São os objetivos (um dos 4 elementos básicos apresentados acima, lembra-se?), as necessidades ou problemas que devemos sanar. São os primeiros requisitos que conhecemos. Na maioria das vezes, bem antes do projeto ser iniciado. Mesmo que sejam mais críticos e essencias para o sucesso do projeto, esses requisitos são tratados da mesma forma – acolhidos em uma mesma estrutura. Destaquei este ponto para mostrar que Análise e Modelagem de Negócios e a Engenharia de Requisitos são atividades que ocorrem de maneira simultânea, e não sequencial. Nem quem mergulha em “cascatas” conseguiria tratá-las como fases distintas de um projeto – são naturalmente indissociáveis, “gêmeas siamesas”.

    Processos Envelhecem

    O que acontece quando um recurso de uma empresa se torna obsoleto? Ele é trocado, certo? Se for um computador ou um caminhão, compra-se um novo. Se for uma pessoa, aposenta-se ou mostra-lhe o bilhetinho azul (ou cartão vermelho, como queira). Mas, e quando um processo de negócio envelhece? O que acontece? As empresas costumam remendá-los e redesenhá-los. Trocas radicais só ocorrem mediante a implementação arbitrária de um pacote de melhores práticas também conhecido como ERP. Mas, mesmo assim, em curto espaço de tempo, voltam os remendos e redesenhos. O mundo não pára.

    O envelhecimento de processos, assim como o nosso, vem com más notícias. Saca aquela dorzinha na coluna que nunca tivemos? Bom, é por aí. E aqui entramos num ponto relativamente polêmico do trabalho dos Analistas de Negócios (AN’s). É mal traçada a linha que os separa daqueles tradicionais Consultores de Negócios. Há quem diga que um AN não deve “se meter” com os problemas do negócio. Oras, o que justificaria tamanha “vista grossa”?

    É claro que, quando em projetos para desenvolvimento ou implantação de sistemas, o foco do AN não é o redesenho (ou reengenharia) de processos de negócio. Mas isso não significa que ele deva ignorar sintomas e doenças que porventura encontre durante seus estudos. Se ele insistir em levar para a solução aquele processo e suas pequenas dores, levará também maiores riscos e chances de mudanças. É exatamente por isso que, ao contrário do RUP, gosto de chamar esta disciplina de Análise e Modelagem de Negócios. Soarei idiota, mas preciso reforçar: é o Analista de Negócios quem executa a Análise de Negócios! E analisar, definitivamente, não se resume ao desenho de belos modelos.

    Portanto, a grande e grave deficiência do BABoK é o fato deste ignorar por completo este estudo, a análise e modelagem de negócios. Acho pouco provável que todo esse “chororô”, que não é só meu, gere alguma mudança significativa na versão 2.0 que está em vias de ser publicada. Resta torcer para que, ao contrário do que ocorre em outras instituições similares, eles não se apeguem de forma intransigente à estrutura atual daquele corpo de conhecimentos. Seria fatal.

    Outros Corpos

    Como eu disse lá em cima, foi uma semana bem agitada. Em nosso grupo de discussão, parcialmente restrito aos participantes de meus eventos, surgiu um conversa meio “subversiva”: elaborar o que o amigo Jefferson chamou de “BABoK Apócrifo”! Acho que (ainda) não é o caso, mas um fruto imediato aquela discussão toda já gerou: nascerá (muito) em breve um Fórum que tratará exclusivamente do BABoK e da profissão AN. Ao contrário do grupo, acho que o Fórum será público. Acho. A turma decidirá.

    : Acontece na próxima quinta-feira (24/abr), em Sampa, a 2ª edição da oficina Análise e Modelagem de Negócios. É um evento de um dia só, mas consigo mostrar nele tudo aquilo que, na minha opinião, foi ignorado no BABoK. Nesta página você tem uma visão geral do programa. É extenso e tem vários exercícios. Mas nada que a gente não consiga conversar em 1 dia.

    Referências:

    1. Software Requirements
      Karl Wiegers. Microsoft Press (1999).
    2. Já utilizei a EPBE no Rational Rose e no Visual Paradigm, além d’outras, menos fechadas. Para quem quiser experimentar, existem duas ferramentas “free” que oferecem a extensão: StarUML e JUDE. (Tks! Marcelo).

  • O BABoK e a Disciplina “Enterprise Analysis”

    O IIBA (International Institute of Business Analysis) liberou no último dia 31 de março a versão 2.0 do BABoK (Business Analysis Body of Knowledge) para revisão pública. O projeto da nova versão tem uns 6 meses de atraso. E eles descontaram nos revisores: temos só até o próximo dia 15 de maio para apresentarmos nossas sugestões / reclamações. Tática estranha, mas não percamos tempo com ela. Abri este post para fazer uma revisão pública de um único capítulo daquela publicação, o capítulo 4, que trata de uma área de conhecimento (Knowledge Area) chamada “Enterprise Analysis”. Ponto que questiono e critico desde a versão anterior do BABoK.

    Antes de descarregar minhas críticas preciso explicar rapidamente a estrutura deste BoK caçula. Ele é formado por 6 KA’s (Knowledge Areas, ou Disciplinas). São elas: i) Planejamento e Monitoramento da Análise de Negócios; ii) Gerenciamento e Comunicação de Requisitos; iii) Análise Corporativa; iv) Elicitação; v) Análise de Requisitos; e vi) Avaliação e Validação da Solução. Cada KA é formada por Tarefas, Técnicas, Entradas e Saídas.

    Tarefas são “peças essenciais do trabalho que deve ser executado na análise de negócio”. As técnicas descrevem “como as tarefas devem ser executadas em determinadas circunstâncias”. Momento ‘dã’: tarefas recebem entradas e geram saídas. ufs.. Mas, por favor, não me entendam mal: a estrutura do BABoK é legal, bem simples. Tanto que consegui explicá-la em dois mínimos parágrafos. Vamos então ao que interessa (neste artigo), a “estranha” KA chamada “Análise Corporativa”.

    O problema já começa no nome. Tiveram que inventar um substituto para “Análise de Negócio”, porque interpretam este nome como um grande guarda-chuva que incorpora outra macro-disciplina, a Engenharia de Requisitos. Tudo bem, há tempos aprendemos a conviver com nomes e definições confusas. Por falar em definição, “Enterprise Analysis” é apresentada da seguinte forma:

    A (disciplina) Análise Corporativa descreve como tratamos uma necessidade de negócio, como refinamos e esclarecemos aquela necessidade, e como definimos o escopo de uma solução viável. Aqui conversaremos sobre a definição e a análise do problema, o desenvolvimento do Business Case, de Estudos de Viabilidade e da definição do escopo da solução.

    Na introdução do capítulo 4 do BABoK, que trata especificamente desta disciplina, é apresentada uma definição mais formal e completa:

    A Área de Conhecimento Análise Corporativa consiste de uma coleção de tarefas para a análise da situação do negócio para a completa compreensão de seus problemas e oportunidades, além de uma avaliação das condições atuais e futuras com o intuito de identificar as mudanças necessárias para a satisfação das necessidades do negócio e seus objetivos estratégicos. As saídas geradas nesta disciplina fornecem a base necessária para o trabalho de elicitação, análise, validação e documentação de requisitos, e também para a identificação de uma solução para uma determinada iniciativa e / ou para o planejamento de longo prazo.

    Escopo da Enterprise AnalysisA definição é legal. Assim como o gráfico ao lado, que ‘explica’ a disciplina em uma apresentação oficial do IIBA. Mas reparem na definição acima e na lista de KA’s do primeiro parágrafo. Se temos lá uma KA chamada “Avaliação e Validação da Solução”, qual a razão da KA “Enterprise Analysis” tratar do desenvolvimento do Business Case e, mais ainda, da elaboração de estudos de viabilidade? Confunde, não?

    Claro, uma avaliação mais profunda das técnicas mostra que estamos falando de coisas diferentes. Para ser mais exato, de momentos diferentes! Então, como fruto de um trabalho notadamente departamentalizado, temos que o estudo de viabilidade não está no escopo da disciplina Avaliação e Validação da Solução. Tudo bem. Como eu já disse, estamos acostumados a conviver com definições confusas e dúbias.

    Em meu entedimento, o problema com a disciplina Análise Corporativa é outro, consideravelmente maior. Ela deveria incorporar aquilo que conhecemos como Análise e Modelagem de Negócios. Não é o que acontece. Veja abaixo a lista de tarefas que formam esta KA:

    1. Definir as necessidades do negócio;
    2. Determinar o gap entre as necessidades e a capacidade do negócio de atendê-las;
    3. Determinar o enfoque recomendado para a solução;
    4. Definir o escopo da solução; e
    5. Desenvolver o Business Case.

    Que estranho: em nenhum momento o Corpo de Conhecimentos da Análise de Negócios fala sobre “aprender o negócio”, “entender o negócio”. Já cai direto na “definição das necessidades do negócio”. Tamanha pressa é medo dos agilistas (muito citados no BoK)? Sigamos, agora sem ironias.

    Alguém pode dizer que está implícito na compreensão das necessidades de um negócio o aprendizado sobre o próprio negócio. Grave engano, e as estatísticas sobre projetos que falham são a maior prova que posso apresentar. Só consigo aprender realmente as necessidades (requisitos) de um negócio depois de conhecê-lo. Façamos uma breve (e covarde) analogia: você saberia dizer as necessidades de sua (seu) namorada(o) ou esposa(o) antes de conhecê-la(o)? Antes mesmo de manifestar suas intenções?

    Se eu não conheço um negócio, aquele domínio, como posso avaliar suas necessidades e oportunidades? Pior, como posso “definir o escopo de uma solução”? Vale aqui ressaltar que conhecer um negócio não se limita ao entendimento daquela entidade, mas compreender todo o seu ambiente, clientes, concorrentes, parceiros, legislação e um monte de etc.

    Por essas e (muitas) outras insisto que o BABoK pode criar uma terrível distorção do trabalho conhecido como Análise de Negócios. Como tempo e espaço ficaram curtos, deixarei para o próximo artigo a porção mais construtiva de minhas críticas.

    Mas, claro (!), sobrou um tempinho para convidá-lo a conhecer uma visão um pouco diferente da Análise de Negócios. Acontece no próximo dia 24/abr, em Sampa, a 2ª edição da oficina “Análise e Modelagem de Negócios”. Nela e em sua co-irmã, Engenharia de Requisitos, apresento as tarefas e técnicas que são utilizadas por um Analista de Negócios. Claro, contemplo todas as boas idéias sugeridas no BABoK. Mas, definitivamente, não o considero um “corpo fechado”. Por isso apresento vários adendos, inclusive o uso da UML para a modelagem de negócios.

    Merchan Parte II: quem participa dos eventos ganha uma versão digital de meu (adiado) livro (com garantia de atualização até a versão 1.0), alguns PPT’s e, o mais importante, acesso ao Grupo de Discussão AN.br. Já somos mais de 200. E no último mês batemos o recorde de mensagens trocadas. Está muito quente e rico. E a última iniciativa do grupo é o estudo conjunto do BABoK. No meio de nosso “toró de parpites”, já pintou até a sugestão de elaboração de um “BABoK Apócrifo”. Pode? Claro que pode! Inté!

  • EPBE: Processos de Negócio

    3ª parte da série sobre EPBE (Eriksson-Penker Business Extensions). A série começou com “EPBE: Introdução” e seguiu com “EPBE: O Negócio e sua Estrutura“. Para um melhor aproveitamento do artigo, talvez seja interessante a leitura de outro pequeno artigo: “Processos de Negócio: São Todos Iguais?“. Eles não são (iguais), e cada um pode demandar estudos e modelos bastante diferentes. Ao contrário do que ocorre em algumas proposições, como BPMN por exemplo, a EPBE oferece toda a flexibilidade necessária para a correta e completa modelagem de processos de negócios.

    .:.

    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”.
    .:.

  • EPBE: O Negócio e sua Estrutura

    Finalmente a continuação da série que começou em “EPBE: Introdução“. Neste artigo vou apresentar duas das quatro visões propostas: a Visão do Negócio e a Visão da Estrutura. Lembrete importante, não mencionado no capítulo anterior: as 4 visões propostas pela EPBE (Processos e Comportamento completam a lista) são básicas, mas não mandatórias nem fixas. Podemos suprimir alguma, dependendo das necessidades e do projeto. Também podemos criar novas visões, como “Papéis e Objetivos das Pessoas”, “Visão dos Efeitos Econômicos”, etc. A EPBE, assim como seu alicerce, a UML, é extensível. Por exemplo, veja neste artigo do IEEE (pago), até onde levaram a EPBE.

    Como colocado anteriormente, o objetivo desta série é apresentar a EPBE e seus elementos básicos. Quem sabe, num futuro próximo, possamos explorar outros usos e extensões. Hoje vou mostrar um pequeno exemplo. Vou incorporar dois elementos que não existem na EPBE original: Balanced Scorecard e Mapas estratégicos. Eles nos ajudarão a documentar a estratégia da empresa.

    .:.

    A Visão do Negócio guia a modelagem das outras três visões. Isso porque é nela que aprendemos e registramos quais são os objetivos do negócio. Portanto, a construção da visão do negócio é o ponto de partida do processo de modelagem do negócio. Das 4 visões básicas propostas pela EPBE, esta é a única que não se consolida na forma de diagramas. Na realidade, em alguns casos, criamos apenas um grande modelo conceitual que destaca os principais elementos (ou conceitos) do negócio. Veja o exemplo (rabiscado) abaixo:

    Por favor, não espere que o desenho acima derive para um diagrama de classes ou algo do tipo. O AN lança mão dessa ferramenta para facilitar sua compreensão do negócio. E, ao consolidá-la, pode utilizar o mesmo desenho para explicar o negócio para outros interessados. Só (isso tudo).

    Crucial no desenvolvimento da visão do negócio é a compreensão de seus objetivos. Na proposta original da EPBE, essa parte principal é registrada na forma de texto. Os principais pontos a destacar são: Missão, Objetivos, Forças, Fraquezas, Oportunidades, Ameaças (obs: as 4 últimas são conhecidas também como matriz SWOT), Fatores Críticos, Estratégias, Competências Principais, Perfis, Unidades de Negócio e Processos-chave. Ao detalhar as estratégias pode ser necessário que também destaquemos: Clientes, Concorrentes, Ambiente, Lucratividade, Potencial de Crescimento e a Percepção que o mercado tem da empresa. O nível de detalhamento deste documento vai depender bastante das necessidades da empresa ou do projeto em questão. Quanto mais estratégico for o projeto, maior a necessidade de um estudo mais minucioso das variáveis listadas acima.

    A EPBE não cita, mas eu gosto de completar o estudo acima com duas informações adicionais: a Proposição de Valor da empresa e o seu Modelo Operacional. Dois artigos publicados anteriormente neste espaço apresentam com um pouco mais de detalhes os dois estudos:

    Parto do princípio de que 90% dos novos projetos abertos pelas organizações têm um cunho estratégico. É raro vermos hoje em dia projetos que lidem com processos de negócio secundários, como folha de pagamento, contabilidade e afins (que, se não estão terceirizados, já foram devidamente informatizados). Sendo assim, a grande maioria dos projetos está vinculada à alguma iniciativa estratégica. Aqui nasce o alinhamento *estratégico* de TI com o negócio. Compreender e se comprometer com a estratégia do negócio é fundamental para o sucesso do projeto.

    Por isso sugiro a incorporação de duas ferramentas que têm se mostrado bastante eficazes na elaboração, execução e acompanhamento das estratégias de negócio: o Balanced Scorecard e seu co-irmão, o Mapa Estratégico . Se a empresa não for usuária destas ferramentas, ou seja, se eles não estiverem disponíveis em sua forma tradicional e “bonitinha”…


    … ainda assim, o AN pode desenvolvê-las:


    Aliás, mesmo que eles existam em sua forma tradicional, é recomendável a elaboração do diagrama acima, em UML. Ao utilizar uma ferramenta CASE, e não o meu tosco rabisco, o AN ganha a facilidade de vincular objetivos, iniciativas e indicadores aos processos (como veremos no próximo capítulo desta série).

    Minha sugestão não deve ser vista como uma substituição àquela da EPBE original, mas como um complemento. Se ela substitui alguma coisa, é o diagrama “Objetivos/Problemas” proposto por Eriksson e Penker. Trata-se de uma extensão, como prometi no início do artigo. Cabe relembrar outra coisa: a Visão do Negócio servirá como *guia* para o desenvolvimento das outras 3 visões. Veremos agora mais uma delas.

    A Visão da Estrutura do Negócio

    Quando falamos de Estrutura do Negócio estamos falando de todos os seus Recursos. No capítulo anterior vimos que recurso é tudo o que a empresa utiliza, consome ou produz. Portanto, com esta visão, detalhamos como a empresa organiza seus produtos e serviços, suas informações e também a si mesma, na forma de unidades de negócios, departamentos, cargos etc. Normalmente utilizamos apenas uma variação do tradicional diagrama de classes da UML para representar todos os tipos de recursos. As informações, por exemplo, são representadas em um grande modelo conceitual que lembra muito um tradicional modelo E-R. Aliás, para ser franco, é o mesmo cara.

    Já o organograma da empresa pode ser traduzido num diagrama mais ou menos assim:


    Estamos falando de documentos que normalmente o AN já encontrará em uma empresa. Portanto, a única justificativa para a sua (re)construção em UML é a facilidade que uma ferramenta CASE pode proporcionar quando o AN entrar na parte “dura” da modelagem de negócios: seus Processos. Assunto do próximo capítulo. Inté.

    .:.

    Bibliografia:

    1. Business Modeling with UML – Business Patterns at Work
      Hans-Erik Eriksson e Magnus Penker. Wiley (2000).
    2. Para quem quiser conhecer o básico sobre Balanced Scorecards e Mapas Estratégicos, recomendo dois títulos:
      a) Medindo o Desempenho Empresarial – Harvard Business Review. Campus (2000).
      b) Mapas Estratégicos – Robert Kaplan e David Norton. Campus (2004).

    .:.

  • EPBE: Introdução

    Chororô só não basta. E não dá para esperar que todo mundo com um mínimo de curiosidade compre o único livro* que documenta a EPBE (Eriksson-Penker Business Extensions) ou participe dos meus eventos. Então, começo agora uma pequena série com um objetivo muito simples: explicar o básico da EPBE e compará-la com outras propostas.

    .:.

    A EPBE (Eriksson-Penker Business Extensions), como o nome indica, foi desenvolvida por Hans-Erik Eriksson e Magnus Penker. Foi apresentada no ano 2000, no livro “Business Modeling with UML – Business Patterns at Work“. Como o título indica, o livro tem objetivos bem maiores. Mas a compreensão da EPBE está em seu núcleo. Mas o que é, afinal, a EPBE?

    A EPBE é uma extensão da UML (Unified Modeling Language). Foi desenhada para possibilitar o uso da UML na modelagem de negócios. A UML é extensível, e várias outras especializações existem: sistemas Web, modelagem de bases de dados, sistemas embarcados etc. Estendemos a UML através de três elementos: estereótipos (stereotypes), valores nomeados (tagged values) e restrições (constraints). Quando uma organização ou equipe faz um uso maduro da UML, ela cria suas próprias extensões. Evita-se a “reinvenção da roda” quando se parte de uma extensão existente, como a EPBE, por exemplo.

    Mas a EPBE “reinventou a roda”, não? Afinal, no ano 2000, já existiam diversos padrões de notação para a modelagem de negócios. A justificativa para sua criação é exatamente essa: existiam diversos padrões – o que é o mesmo que dizer que não existia padrão nenhum. A mesma razão, em outro domínio, motivou Grady Booch, Ivar Jacobson e James Rumbaugh a criarem a UML. E por que utilizar a UML como base para a modelagem de negócios?

    Segundo os criadores da EPBE, a primeira motivação são os “conceitos similares: um negócio pode ser descrito em termos de processos que satisfazem objetivos através da colaboração de diferentes tipos de recursos. Regras definem condições e restrições sobre como os processos e recursos devem se relacionar e como devem se comportar. Tudo isso pode ser mapeado em objetos, relacionamentos e interações entre objetos” .

    Outras razões apontadas por Eriksson e Penker são: i) a maturidade da UML (e da orientação a objetos); ii) a notação padrão (de facto); iii) o aprendizado rápido; e, iv) a nova e fácil maneira de ver a organização e o negócio. Vale reforçar a motivação descrita no parágrafo anterior com outra leitura: negócio e TI teriam uma mesma linguagem padrão de modelagem. Os benefícios são óbvios.

    Do mesmo parágrafo podemos extrair os 4 elementos fundamentais que utilizamos para descrever qualquer negócio:

    • Recursos: é tudo o que a empresa utiliza, consome ou produz. São as pessoas, materiais, informações e produtos. Recursos são manipulados através de processos, ou os manipulam e gerenciam. E são classificados como: físicos, abstratos e de informação.
      Para ficar um pouco mais claro: uma nota fiscal é um recurso abstrato, assim como uma ordem de compra ou um “bilhete azul”. Quando uma nota fiscal é registrada em uma base de dados, por exemplo, torna-se um recurso de informação.
    • Processos: são as atividades realizadas pelo negócio. Eles descrevem como o trabalho é executado na empresa, e são delimitados por regras.
    • Regras: são as definições ou restrições de algum aspecto do negócio. Regras determinam como um negócio deve ser gerenciado ou como os recursos devem ser estruturados e utilizados. Elas podem ser criadas pela própria empresa ou são impostas por entidades externas (governo, associações, sindicatos etc).
    • Objetivos: representam a razão da empresa, ou os resultados que o negócio espera atingir. Objetivos podem ser divididos e distribuídos entre os diversos processos da empresa. Objetivos expressam o estado desejado de determinados recursos (caixa, estoque, market share – por exemplo), e são atingidos através dos processos. O conjunto dos objetivos de alto nível forma a estratégia da empresa.

    A lista acima pode ser resumida da seguinte forma: Os objetivos do negócio são atingidos através da execução de processos que usam, transformam e geram recursos, sempre respeitando e seguindo um conjunto de regras. O diagrama ao lado representa esta lógica.

    Para entender e aceitar a EPBE, além de compreender os elementos fundamentais descritos acima, é necessário entender o que é a Modelagem de Negócios e para que ela serve. Modelamos um negócio com o objetivo de simplificá-lo. Criamos abstrações ou analogias de uma forma que facilite a compreensão, a documentação e a comunicação de todos os aspectos principais de um negócio. Nós modelamos um negócio para:

    • Fornecer uma base que apóie a criação de sistemas de informação;
    • Criar um ponto de partida para iniciativas de melhoria da estrutura e dos processos de negócio;
    • Experimentar novos conceitos e desenhos;
    • Identificar oportunidades de outsourcing; e
    • Facilitar a integração com entidades externas.

    Tratando especificamente de projetos de sistemas de informação, podemos dizer que a modelagem de negócios também serve para :

    • Entender a estrutura e a dinâmica da organização;
    • Compreender os problemas da organização e identificar oportunidades de melhoria;
    • Garantir que clientes, usuários e desenvolvedores compartilham uma mesma visão do negócio; e
    • Extrair requisitos do sistema.

    Do que consiste um modelo de negócio? Ele é formado por três partes principais:

    • Visões: é impossível descrever completamente um negócio sob um único ponto de vista. Existem quatro categorias de visões: Visão do Negócio, Visão dos Processos, Visão da Estrutura e Visão do Comportamento.
      Obs.: nas próximas partes desta série as visões serão apresentadas de forma mais detalhada.
    • Diagramas: toda visão é representada por um ou mais diagramas, que representam partes específicas da estrutura ou da dinâmica do negócio. Diagramas são compostos por objetos e processos.
    • Objetos e Processos: Objetos representam todos os recursos, enquanto os processos representam qualquer atividade ou função executada no negócio.
    .:.

    A mensagem mais importante até aqui é a seguinte: Modelar é Simplificar. Modelamos um negócio para facilitar sua compreensão, entender seus problemas correntes e identificar oportunidades de melhoria. Em projetos de sistemas de informação, a modelagem de negócio é lançada para municiar da melhor forma possível a equipe que criará a solução. A EPBE é “só” um padrão de notação. É diferente de outras propostas porque: i) Usa o mesmo padrão dos sistemas, a UML; e, ii) É completa.

    A EPBE não é um processo ou metodologia nem pretende sê-lo; O uso da EPBE não implica necessariamente em BDUF (big design up front) ou na utilização de processos “waterfall”; A EPBE não concorre com BPMN e afins – na realidade estes podem ser utilizados como um sub-conjunto da EPBE.

    No próximo artigo veremos como a EPBE descreve a Estrutura de um negócio. E no seguinte, como ela é utilizada para modelar Processos de negócio.

    .:.

    Bibliografia:

    1. Business Modeling with UML – Business Patterns at Work
      Hans-Erik Eriksson e Magnus Penker. Wiley (2000).
    2. The Rational Unified Process – An Introduction (2nd Edition)
      Philippe Kruchten. Addison-Wesley (2000).

    Observação:

    * – Para não cometer uma total injustiça: o livro “UML 2.0 – Do Requisito à Solução“, de Adilson da Silva Lima, tem um capítulo inteiro dedicado à EPBE. Pelo que sei, é o único em língua portuguesa que toca no assunto. Se tudo der certo, ele perderá o monopólio em março de 2008, quando meu livro deve chegar em algumas prateleiras. Eu disse lá em cima que o livro de Eriksson e Penker é o único porque o Adilson limita-se, como eu aqui nesta série de artigos, a dar um overview da EPBE. Ou seja: EPBE na íntegra, só no original.

    .:.
    This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Brazil License.

  • EPBE: Quem usa?

    Desde a semana passada estou envolvido em debates sobre a EPBE (Eriksson-Penker Business Extensions), uma extensão da UML para modelagem de negócios. O provocador das discussões foi o mesmo, José Augusto Agnello. O primeiro debate, no grupo UML-BR, começou com BUC’s (Business Use-Cases). Já no grupo BPM o Agnello foi direto: alguém usa? Como ela se compara com BPMN?

    Sem querer o Agnello me possibilitou duas coisas: validar a recepção dos AN’s e da EPBE em um grupo “pesado”, o UML-BR. Poder debater e trocar idéias com José Paulo Papo, MTierno, Juan Bernabó, Rodrigo Yoshima e outros é sempre enriquecedor. O outro “brinde” veio hoje: a “desconfiança” de que ninguém utiliza a EPBE. O grupo BPM tem 500 e poucos participantes. Há duas horas eu só penso nisso.

    Caramba, baseei boa parte do meu trabalho para formação de analistas de negócios na EPBE e nos conceitos apresentados por seus idealizadores, Hans-Erik Eriksson e Magnus Penker, no livro “Business Modeling with UML“. Nessa altura do campeonato, na reta final e de certa forma cansado do tema, a última coisa que eu preciso é de dúvidas sobre uma das partes principais de minha “tese”. Não estou falando das dúvidas e críticas dos outros. Estou falando que eu não posso duvidar de minhas sugestões. Mas, no cansaço e com um probleminha chato nas costas, confesso que hesitei por alguns minutos: “caramba, ninguém usa isso!”.

    Me lembrei que já passei por isso antes. No final de 98, por exemplo, quando falava que ia utilizar UML em um grande projeto, um monte de gente me olhou com cara de interrogação, tipo: “que p**** é essa?”. Dali até os primeiros diagramas de seqüência com algum sentido passou um certo tempo. Dali até uma certa aceitação da UML foi outro tanto de tempo. Mês que vem a UML completará 10 anos de existência. Sob um prisma – caramba, é uma linguagem! – ela é muito nova. Por outro – pô, informática! – ela é velha. Mas a EPBE é do ano 2000. E parece não ter aceitação nenhuma*! O que pode estar errado?

    Richard Lingner, em sua participação na thread do BPM, apresentou algumas razões: “a EPBE não é mantida pelo OMG e também não é difundida ou suportada por empresas e ferramentas”. Seria outro caso de uma boa idéia carente de um bom marketing.

    Mas quem a considera uma boa idéia? Definitivamente, eu não estou sozinho. Vejam, por exemplo, as avaliações que os leitores do livro “Business Modeling with UML” no site da Amazon. Surrupiarei alguns trechos:

    “The ‘Eriksson-Penker extensions for business modelling’ are important because several UML-based case tools have now implemented them as an emerging standard for business process modelling with UML. If you want to fully understand how these work, this is the book to read.”
    – A.K. Johnston

    “Sometime ago I have been wondering if somebody will try to bridge the gap between business modeling (the one used by consultants) and software engineering. It would certainly make it easier for people to understand and explain business operations. This book is an application of the UML into the realm of business modeling. It is very good in the sense that it explains and goes through the patterns that form business models.”
    – J. Chong

    Claro, tem também algumas críticas negativas (ao livro). Mas sua média é 4 estrelas! As avaliações que citei são de 2003 e 2000, respectivamente. E, sabe-se lá a razão, parece que pouquíssimos conhecem a EPBE.

    Suspeito que o buraco é mais embaixo. Como eu disse no post anterior, a análise e modelagem de negócios é a disciplina mais ignorada em nossos projetos. E quando ela aparece, em modelos RUP-like, é meio capenga**. Se a disciplina é negligenciada, o que esperar das ferramentas que devem suportá-la? Correndo o risco de ser (muito) chato, vou reforçar minha suspeita: currículos, processos e metodologias dão atenção desproporcional para o domínio da solução; Parecemos adorar “analistas-programadores”; Esquecemos que sem o correto domínio do problema podemos gerar falsas e caras soluções.

    Essa questão me preocupa bem mais que a aceitação ou não da EPBE. A EPBE é só uma extensão de uma linguagem. É só uma ferramenta. Ferramentas passam. Mas eu acho que o OMG e todos os fornecedores de ferramentas CASE que ignoram a EPBE estão perdendo uma bela oportunidade. O OMG, por exemplo, poderia incorporar a extensão e adicionar a opção BPMN à ela. Reforçariam assim a UML, expandindo consideravelmente o seu público. Sendo chato (de novo!), reforço as motivações para sua utilização:

    1. UML já é uma linguagem madura e consolidada;
    2. Utilizada amplamente no domínio da solução;
    3. Por que não utilizá-la também para a modelagem do problema?
    4. Assim, TI e negócio teriam pela primeira vez em sua história uma mesma língua – mesmo que ela seja “só” para modelagem.

    Pronto, minhas dúvidas já se dissiparam. E as suas?

    .:.

    Observações:

    * Os workshops para formação de analistas de negócios já contaram com mais de 150 participantes. A EPBE é apresentada neles, mas de forma breve. Então, só depois do treinamento que ocorre agora em novembro poderei dizer se a EPBE ganhou novos adeptos.

    ** Adjetivos pouco nobres (como o “capenga” acima) vivem me criando problemas. Um dia foram as “bullshitagenzinhas ágeis”. Hoje foi o BPMN “bonitinho”. Não adianta, não me livro deles. Não acho sinônimos que passem exatamente o que quero expressar naquele momento. Até me arrependo depois. Mas, na hora – na lata, não edito não. Também não edito depois, a menos que alguém se diga ofendido. Nunca aconteceu.

    No UML-BR, “brigando” com o MT na questão “BUC’s X EPBE”, eu usei “fraquinho” no lugar do “capenga”. É a mesma coisa. Fica feio do mesmo jeito. Peço desculpas.

    Mas aqui cabe uma explicação: sou fã do Jacobson. Seu “The Object Advantage – Business Process Reengineering with Object Technology” é fonte frequente de consulta para desenvolvimento do meu material. Mas, definitivamente, casos de uso de negócio e modelos de objetos de negócio não são ferramentas legais para a análise e modelagem de negócios. Probleminha básico: assim como a BPMN, são incompletos. A arquitetura de um negócio é descrita em quatro visões: Negócio, Estrutura, Processos e Comportamento. Qualquer proposição que vise a análise e modelagem de negócios deve cobrir as 4 visões. Ponto.

    .:.

    Dica levemente acoplada: não percam o artigo de hoje do Philip “Shoes” Calçado, no Fragmental.

    .:.

  • Proposições & Modelos

    Em “Processos de Negócios: São todos iguais?” eu escrevi que o classificação básica dos processos e a identificação da proposição de valor da organização são algumas das primeiras informações que um Analista de Negócios (AN) aprende para guiar seus trabalhos. Neste post vou explorar um pouco mais o tema, acrescentado outro dado que pode ser muito importante, dependendo do tipo de projeto: o Modelo Operacional da organização.

    .:.

    É 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.

    .:.

  • Agile BA Parte II – Os Problemas da Anne

    Seqüência deste post, onde a Anne, uma Scrummaster, tenta justificar seu desejo por um pouquinho de ‘planejamento up front’ em seu projeto. Reforço o ‘pouquinho’ para dizer que não se trata do combatido BDUF (Big Design Up Front). BDUF, BPUF, SPUF… ufs…

    .:.

    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).

    .:.

  • Processos de Negócios: São todos iguais?

    Essa é a impressão que se tem quando vemos algumas discussões, referências e tendências: processos de negócio são todos iguais. É uma perigosa armadilha que todo analista de negócios (AN) deve perceber logo no início de seus estudos e trabalhos. Os processos são diferentes, e deveriam merecer um tratamento diferente.

    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?

    .:.