Blog

  • 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?

    .:.
  • Rendiconti do Workshop – Parte II

    “O Workshop pode ser definido como um banho de esclarecimento acerca do papel do Analista de negócios”.
    Rodrigo C Maia
    Blueeye Web Solutions
    Diretor Administrativo

    “Todos os tópicos abordados são relevantes e principalmente aplicáveis, podendo melhorar os resultados no desenvolvimento de novas soluções de negócios”.
    Marlene Aparecida da Silva
    Gerente de Informática
    Química Amparo

    “Esta especialização é uma evolução, tanto na carreira do analistas, tanto na qualidade do produto entregue. No momento em que o mercado entender e demandar por estes profissionais, o ciclo de vida de um projeto, e principalmente a fase de manutenção, mudará radicalmente”.
    Marília F P Lima
    Analista de Sistemas
    FUNDAP

    “Atual e Necessário para os profissionais de TI. Trouxemos toda nossa equipe”.
    Umberto Nanini
    Diretor de Informática
    Prefeitura Municipal de Sorocaba

    “O tema é importantíssimo e realmente esclarecedor. Servirá como orientação daqui pra frente”.
    Fernando Reballo
    Diretor de Tecnologia
    SHC

    .:.

    “Algumas das práticas abordadas no curso eu já vinha estudando, porém ainda não havia conseguido definir com clareza todo o ciclo que envolve o processo, bem como encaixa-la na metodologia de desenvolvimento que havia estudado com mais profundidade até então, o OpenUP/Basic.

    À partir disso, adotar algumas dos pontos abordados no curso, está sendo um pouco mais tranquilo.

    Na questão da Modelagem de Negócios, estou estruturando melhor a Visão do Negócio, utilizando de diagramas para representar os processo de negócio, já que o Core Business do meu projeto envolve muito a interação com terceiros. Aí estou usando o diagrama que contempla metas e saídas do processo, bem como os envolvidos no mesmo (chamados de parceiros no modelo conceitual).

    Estou em vias de apresentar um projeto de integração de nossos sistema com alguns fornecedores envolvidos no processo. Para isso, já estou elaborando um mapa estratégico e estudando melhor o modelo de balanced scorecard.

    Na parte de Engenharia de Requisitos, já reescrevi meus casos de uso, incluindo as informações adicionais relacionadas a ele, tais como Ponto de Vista, Fonte, Tipo, Status, etc….

    Quanto ao orçamento e elaboração das iterações do projeto já vinha utilizando análise por casos de uso e iterações definidas tais como apresentadas no OpenUP/Basic.

    É evidente que alguns pontos ainda não estão maduros e faltam alguns pontos a acrescentar no processo todo, porém , consegui sair do workshop com uma leitura total do projeto, bem como todos os artefatos e pessoas envolvidas no processo.”

    .:.

    Este último depoimento eu surrupiei do grupo de discussão que criei exclusivamente para a turma que participou do workshop. Eu havia registrado aqui, há quase três anos, minha tristeza quando ouvi de uma participante de um evento em Floripa: “Pena que o que a gente vê neste tipo de evento não dá para aplicar no nosso dia-a-dia.” Virou uma provocação que me acompanha em todo evento que participo. Por isso o depoimento acima é muito valioso.

    Assim como todos os outros, que estão também numa página da Tempo Real Eventos, em conjunto com outras fotos do workshop. Como eu disse na primeira parte da rendiconti, a turma era muito boa. Isso enriqueceu demais o evento.

    .:.
  • Surpresa

    Abro o workshop e o livro falando do Analista de Negócios (AN), dizendo que ele praticamente não existe. Profissão ou função mal definida, muito mal apresentada e representada. Mas reforço: ao lado do Arquiteto (ou Arquiteto Corporativo), é a profissão mais promissora da área de TI. Aposta que faço há algum tempo.

    Engraçado é que o estopim para todo esse trampo veio da noção do fundo do poço: num grupo de discussão, no 2º semestre do ano passado, alguém falou que o AN não serve para nada. Ou, em outras palavras, disse que “não via utilidade nos AN’s”.

    Contei a “estorinha” no workshop e muitos pegaram carona na provocação: “você acredita nos AN’s e em sua aposta?” Eu disse que a melhor evidência estava na sala: lotada. Quando a Tempo Real Eventos lançou o workshop não tínhamos a menor idéia sobre qual seria a aceitação. Foi uma aposta mesmo. Seguida de uma gratificante surpresa.

    “Abrir a ‘caixa preta’ que é a organização de TI das empresas”
    Gilson Silva

    “Alinhar TI com o negócio”

    • “O Alinhamento deve mostrar evoluções no plano de negócios”
    • “O Alinhamento se mantém atualizado na medida em que o negócio evolui”
    • “O Alinhamento ultrapassa obstáculos aos seus propósitos”
    • “O Alinhamento é planejado”

    Paul Strassmann

    E aí vieram SOA, BPM, ITIL, SOX… todas buscando, de uma forma ou de outra, o tal “alinhamento”. Por isso eu acredito tanto nos Arquitetos e Analistas. Arquitetos Corporativos (ou De Negócios) e Analistas de Negócios. Por isso eu acho que o BABoK desperdiça uma grande oportunidade. E que os trabalhos que falam que AN’s e AN’s de TI são “negócios” diferentes estão um tanto equivocados . Negócio é negócio. Ponto.

    .:.

    Momento “Catorze Zero Meia”

    Leitores do finito interessados em participar da próxima edição do workshop “Formação para Analistas de Negócios” acabam de ganhar um belo incentivo: desconto de 10% em cima do preço promocional* (para inscrições realizadas até o dia 13/jul).

    Para tanto, basta informar o código promocional (cpvfan) na página de inscrições.

    1406 + “modelito vivarina”: todos os participantes terão acesso ao exclusivo grupo de discussões, e terão garantia de atualização da apostila até ela se transformar no prometido livro.

    “Desgraça pouca é bobagem”, como a gente costuma falar aqui nas Geraes.

    .:.

    * Válido para os 20 primeiros.
    (ps: Nunca pensei que fosse utilizar as detestáveis letrinhas miúdas…)

    .:.

    1. Talvez seja o primeiro AN de facto do Brasil. É um dos melhores, não tenho dúvidas. Aliás, ele é bem mais que um AN. Não sei se foi sorte dele ou azar nosso, mas alguns de seus maiores trabalhos foram realizados em Portugal, Espanha, Austrália, Nova Zelândia, África do Sul…
    2. The Squandered Computer
      Paul A. Strassmann – The Information Economics Press (1997).
    3. UML for the IT Business Analyst
      Howard Podeswa – Thomsom / PTR (2005).
    .:.
  • Rendiconti – Workshop "Analistas de Negócios"

    Maratona das boas. Que começou com um exercício de verdade. O mineiro aqui só tinha ido uma vez ao Centro de Convenções Pompéia, num evento da SUCESU-SP. Ficou com a falsa lembrança de que o centro era “pertinho” da estação Vila Madalena do metrô. Como eu falei para o Anderson da Tempo Real Eventos, gosto de andar um pouco antes d’uma apresentação – preparação final. Mas era para andar “um pouco”… não uns 2,5km!!! Pior: tem um morro ‘a la Minas’ nos últimos 500mts… Resultado: cheguei bufando e transpirando. O “logo ali” de mineiro realmente é um perigo…

    Mas tudo bem.. quase ninguém percebeu. E assim teve início uma maratona de 7 horas.

    Com 55 participantes. Participantes de verdade, que enriqueceram bem o evento (inclusive corrigindo o palestrante em alguns furos). A diversidade da platéia (indústria, comércio, serviços, prefeituras e outros órgãos públicos…) ajudou bastante. Mas tenho que rever minha estratégia de “nenhum exemplo pré-formatado”.

    A intenção era reforçar os conceitos, e forçar uma maior interação do pessoal. Funcionou parcialmente. Em alguns momentos, minha memória me deixou na mão. “Brancos” assim são muito ruins. Percebi também, pelas fichas de avaliação, que tenho que maneirar em alguns ‘cases’. Mas tenho que registrar: só deu Ótimo e Bom em mais de 90% das avaliações. Saber que cada real investido foi compensado não tem preço. Mas tem muita coisa para melhorar…

    Uma é o meu ritmo. Acertei o “tempo” dos temas na mosca. Mas regulei mal o ritmo. Quando cheguei no último quarto, estava muito cansado. A voz (apesar dos 3 Marlboros), não falhou. Mas o cansaço era visível.

    E uma vou ter que aprender com a própria turma que, a partir de hoje, faz parte de um grupo de discussão fechado. Fora o exagero nos ‘cases’, alguns reclamaram da “falta de profundidade”. Em um evento de 7 horas, é coisa crítica.

    Acontece que o tema é imenso. Foram 8 “capítulos”. Vou entender e depois registro aqui, numa segunda parte da “rendiconti”. Fotos e alguns depoimentos também pintarão na 2ª parte.

    Por enquanto é isso: o evento e o material didático utilizado (versão beta do meu livro) foram muito bem recebidos. 3 dias de alívio e satisfação. Na segunda começa tudo de novo. Agora com 55 pessoas muito legais participando do processo. Será divertido…

    .:.
  • O Giro em Falso das Rodas Reinventadas

    Há quem ache que a síndrome NIH (Not Invented Here) é uma exclusividade dos desenvolvedores. Não é. Parece que toda a nossa área adora reinventar rodas, eixos e padrões. O tempo todo.

    Foto de Tom@HK.

    Eu poderia citar n exemplos, como a mal explicada briga da MS com o padrão UML; as metodologias que adoram dar novos nomes e símbolos para coisas que já existem; “oceanos azuis” e outras metáforas criativas para diferenciação; sistemas de help-desk que viram, da noite para o dia, soluções de CRM… Pois é, não é só uma questão de reinvenção. As segundas intenções (as verdadeiras motivações para a “reinvenção”) são ainda mais perigosas.

    Mas a motivação para este post veio de outro lugar. Do BABoK (Business Analysis Body of Knowledge), que é uma das minhas referências para o livro e o workshop/curso para formação de Analistas de Negócios.

    O BABoK é novo. A versão que estou utilizando é apresentada como um “draft 1.6”, de julho do ano passado. Como eu disse em outro post, o BABoK se concentra quase que exclusivamente na Engenharia de Requisitos. Mas trata a disciplina como se fosse algo totalmente novo. Parece que o tema não foi estudado anteriormente e compilado em propostas como o CMMI, SWEBoK etc etc. O padrão da SEI, por exemplo, só aparece como “CMM” em algumas poucas referências. No corpo do “corpo” ele é sumariamente ignorado.

    Caramba, o CMMI tem duas áreas-chave que tratam especificamente de requisitos: REQM (Gerenciamento de Requisitos) e RD (Desenvolvimento de Requisitos). A vinculação do BABoK com ele deveria aparecer, no mínimo, como uma matriz que mostrasse como as práticas ali recomendadas auxiliam na realização dos objetivos do CMMI.

    Mas os “agilistas” não têm motivo para comemorar. Suas práticas e métodos também não existem no BABoK. Aparecem pequenas referências e alertas, dizendo, por exemplo, que “em projetos ágeis e iterativos os requisitos não são baselined (sorry) ao mesmo tempo”. Não há quase nada além disso.

    Acho que nem preciso dizer que “gestão do conhecimento” e “aprendizagem organizacional” também não foram consideradas na elaboração do BABoK. Pois é, infelizmente, a versão atual é só uma compilação de práticas ‘levemente acopladas’. Apresentadas de forma linear, estruturadas de acordo com este diagrama. Como as práticas são relativamente bem documentas (propósito, descrição, técnicas, processo, stakeholders e deliverables – toda prática ou tarefa é apresentada com esta estrutura), o BABoK deve se tornar apenas um tipo de “guia de referência rápida”. Um excelente template para elaboração de provas de múltipla escolha. E talvez, numa versão 3.0, apresente uma disciplina nova chamada “integração” ou algo do tipo.

    Talvez fosse só esse mesmo o seu objetivo. Mas acho que todo mundo espera mais de algo que se apresenta como um “Corpo de Conhecimentos da Análise de Negócios”. A primeira coisa que eu sempre espero é que ele não ignore os conhecimentos existentes. Rodas reinventadas giram em falso.

    .:.
  • Rendiconti: Escrever dá Trabalho

    Algumas notas levemente acopladas sobre o livro para analistas de negócios e o workshop da Tempo Real Eventos.

    Eu escrevo e rabisco desde que me conheço como gente. Gosto de escrever, mas vira e mexe eu passo do ponto. Não tem muito tempo que eu me divertia com propostas técnicas de 66 páginas. Escritas do zero, sem ‘copy+paste’ e afins. A diversão se multiplicava quando eu conseguia encerrar uma frase com um ponto de exclamação! Era o fim…

    Sempre convivi com os prazos. Antes eram os prazos da professora de português, depois o “deadline” para a entrega de propostas. Sempre curtíssimos, insuficientes, assustadores.

    Daí que eu estava curtindo muito esse negócio de escrever um livro sem um prazo determinado. O editor será meu mano caçula, Guz Vasconcellos, e ele tem outras preocupações. Aí pintaram os workshops, e a insana idéia de aproveitá-los como plataforma de testes para os meus escritos*. Pronto: há pouco estava o Anderson da Tempo Real me lembrando: “dia 15 eu preciso dos originais!”

    .:.

    A apostila será uma versão ‘draft’ do livro. Adaptada. Ela contempla exercícios e economiza um pouco nos exemplos. O livro deve ter o inverso, mais estudos de caso e nada de exercícios. Referências teóricas e devaneios acadêmicos serão mais explorados no livro, e quase que totalmente censurados na apostila.

    E assim vai. É o desenvolvimento simultâneo de “variações do mesmo tema”: Apresentação (versão Palestra e versão Workshop), Apostila, Livro, Caderno de Campo, Guia de Referência “Ágil”, marcador de livro, caneca de chá…

    Segundo o Cacá, é uma “boa prática” recomendada em “Pai Rico, Filho Pobre” ou algo do tipo. Não conheço.. acho que nem quero conhecer… Mas esse negócio de sugar um negócio até o último negócio parece ser mesmo um bom negócio (pobre filho pobre).

    .:.

    Três dos caras que mais admiro na literatura tupiniquim são péssimos exemplos quando o assunto é o “processo de escrita”. O Chico Buarque só entrega seus livros quando o editor ameaça suicídio. O Ariano Suassuna tá escrevendo sua obra prima desde 1981. E o Luis Fernando Veríssimo deu uma entrevista desanimadora n’O Globo do último domingo:

    É mais difícil começar ou terminar?
    LFV: Começar e terminar. O meio também não é muito fácil.

    Pura verdade.

    .:.

    No último dia 31/mai esgotaram-se as vagas para a primeira edição aberta do workshop. Não é muita coisa – afinal são só 50 vagas. Mas ficamos muito satisfeitos. Tanto que o pessoal da Tempo Real Eventos já programou o próximo para o dia 2/agosto, uma quinta-feira. Novamente em Sampa.

    * Aos inscritos e interessados: ‘draft’ não que dizer mal feito, ok? A diferença da apostila em relação ao livro, além daquelas citadas acima, é o número de revisões. Estou utilizando um processo “iterativo e incremental”. E conto com o apoio de todos na maturação do material. Como já divulguei em outro local, os participantes receberão uma garantia de upgrade (a la cupons da MS). Só não sei dizer se o livro sairá ainda no final deste ano ou apenas no início de 2008. O editor tem outras preocupações…

    .:.
  • Meme #016 – Diversidade faz Bem

    When solving problems, diversity may matter as much as, or even more than, individual ability.

    Scott Page (professor na Universidade de Michigan e autor de “The Difference: How the Power of Diversity Creates Better Groups, Firms, Schools and Society“).

    .:.

    Meme achado-forçado, que ajuda no debate sobre ‘Especialistas Generalistas’.

    .:.
  • Help Wanted: Especialistas Generalistas

    Perdão. Não, o finito não está contratando ‘especialistas generalistas’. O help necessário é outro. Preciso de ajuda na definição do termo. Queria entender as certezas que aparecem com certa freqüência em algumas listas de discussão e artigos. Normalmente o pessoal cita um artigo do Scott Ambler. Ele fala em ‘Generalizing Specialists’. Tropicalizado, o termo virou ‘Especialistas Generalistas’. Só a ausência do gerúndio já me deixa encucado. Mas o problema não está só na tradução não. Começa no próprio artigo do Mr Ambler. Ele cita Robert A. Heinlein, um escritor de ficção científica:

    A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.

    “Especialização é para insetos!”. O romântico manifesto de Heinlein, em mãos erradas, pode causar um estrago e tanto. Vou surrupiar a réplica de alguém que não tem nada a ver com sci-fi, Peter Drucker :

    … conhecimento, por definição, é especializado. Com efeito, as pessoas realmente detentoras de conhecimentos tendem ao excesso de especialização, qualquer que seja seu campo de atuação, exatamente porque sempre se deparam com muito mais a aprender.

    A organização baseada em informações exige, em geral, muito mais especialistas do que as empresas tradicionais do tipo comando e controle.

    Mixando os dois autores podemos concluir que as empresas baseadas em informações são verdadeiras colméias ou formigueiros, certo? A analogia é interessante, mas não vou brincar com metáforas. Como eu disse em um rendiconti, meu problema é com os ‘especialistas generalistas’. Lá eu disse que um melhor termo seria ‘especialistas não-alienados’: i) Profissionais que reconhecem e respeitam as outras especializações; ii) estão comprometidos com os objetivos do negócio (do projeto); e iii) sabem trabalhar em equipe. Acho que isso não deveria ser um diferencial – em lugar nenhum. É pré-req em qualquer profissão, não?

    Mas a tese de Mr Ambler vai um pouco além. Para ele, ‘reconhecer’ as outras especializações é conhecê-las de fato. Ele chega a sugerir a seguinte trilha de evolução (é só um exemplo fictício, ele diz):

    Não tenho nada contra um profissional buscar outras áreas de conhecimento. Muito pelo contrário. Mas a evolução acima é possível? Se Java, .Net, tecnologias de bancos de dados, metodologias de gerenciamento de projetos e de modelagem fossem congeladas – parassem de mudar e de evoluir, talvez. Mas, definitivamente, não é esse o caso. Alguém que tenha parado de estudar Java há 3 anos seria considerado um especialista hoje? Algumas das áreas de conhecimento citadas por Ambler se entrelaçam. É natural que o especialista em uma delas seja também muito bom em outra. Java e modelagem, por exemplo. Aliás, dependendo da ferramenta, trata-se de uma tarefa só. Um melhor exemplo talvez seja Java e testes, ou Java e deployment. Btw, neste último quesito, muita gente fica devendo. Mas essa é outra história.

    O maior problema com a tese, em minha opinião, é a forma como ela desconsidera a dinâmica que vivemos. Alguém que tenha aprendido Cobol lá nos anos 80 até que poderia se dar bem hoje, com um mínimo de esforço de atualização. Podemos dizer o mesmo em relação ao VB ou Java, por exemplo?

    O fato é que, para ser um especialista hoje em dia, gasta-se muito tempo. As plataformas tecnológicas cresceram muito, para os lados e para cima. A complexidade dos ambientes aumentou exponencialmente. E, pior, ainda são relativamente imaturas. Ou seja, mesmo que o cara não durma e seja um mestre em ‘leitura dinâmica’, é difícil se manter um especialista. O que dizer então de um ‘especialista generalista’ conforme proposto por Ambler? Só se ele já estiver contemplando o uso de um plug como o do Neo em Matrix.

    .:.

    O post ficou longo e, como eu previa, receberá uma seqüência. Quero colocar a questão dos ‘especialistas generalistas’ no contexto dos projetos. Tirando o lado individual, que procurei destacar aqui, trata-se do maior risco. Equipes multi-disciplinares viraram, em alguns lugares, equipes de profissionais multi-disciplinares.

    Sei que a maior parte dos colegas defensores da tese do Ambler são muito bem intencionados. Juan Bernabó, por exemplo, apresenta-a de uma forma muito legal. Mas, infelizmente, não consigo ignorar um tom meio ‘facista’ de alguns. Me desculpem o termo – mas é assim que interpreto. Quando falam de ‘super-desenvolvedores’ que sabem fazer tudo no projeto, e ainda se auto-gerenciam… Sei lá, parece que querem dizer: “o mundo é nosso”. Aliás, achar que dá para ser bom demais em tudo é uma baita falta de respeito com outros especialistas. Mas esse papo fica para a próxima semana.

    .:.

    1. O Advento da Nova Organização
      Peter F. Drucker. Artigo publicado originalmente na edição de jan-fev/88 da Harvard Business Review. Republicado no livro “Gestão do Conhecimento – HBR”, da Editora Campus (2001).

    .:.
  • O Analista de Negócios e o tal BABoK

    Faz pouco tempo que descobri o BABoK (Business Analysis Body of Knowledge). Quem cuida dele é o IIBA (International Institute of Business Analysis). A descoberta aconteceu por acidente, no meio das minhas pesquisas. Usando o Google, não consegui achar nenhuma referência em língua portuguesa. Estranhei. Afinal, a versão atual (1.6) está disponível para download desde 12/jul do ano passado. A versão 2.0 está programada para este trimestre. Mas, como escrevi no meu material, “o analista de negócios não existe. Particularmente aqui no Brasil”. Normal. Quantos gerentes de projetos existiam há uns 10 anos? E quem conhecia o PMI?

    O IIBA segue os passos do PMI. Ou seja, lança um ‘guia para o corpo de conhecimentos’ e, na cola, uma certificação. Tenho minhas restrições ao formato, mas elas ficam para outra hora. O lado bom é que a iniciativa pode ajudar a divulgar e, de certa forma, consolidar a profissão. Em tempos de altas ondas (SOA e BPM), passa da hora de percebermos que o Analista de Negócios desempenha funções cruciais.
    .

    .:.


    Mas o BABoK me assustou um pouco e decepcionou um tanto. Ainda não vi as alterações previstas para a versão 2.0, mas a versão 1.6 cobre, na minha opinião, apenas 50% do trabalho de um AN. Dos seus 8 capítulos, 5 cobrem exclusivamente as atividades de planejamento, desenvolvimento e gerenciamento de requisitos. O gráfico abaixo ilustra as áreas de conhecimento cobertas pelo BABoK:

    “Enterprise Analysis”, segundo capítulo do BABoK, é descrita como “uma coleção de atividades pré-projeto que servem para capturar uma visão futura do negócio, formando assim uma base a a elicitação de requisitos e para o desenho da solução “.

    Como já comentei aqui, e talvez seja uma falha minha, mas não consigo dissociar a Modelagem de Negócios da Engenharia de Requisitos. Lógico, são duas disciplinas diferentes. Mas elas compartilham “momentos”, independente do modelo de processo utilizado. E o BABoK não fala nada sobre Modelagem de Negócios. Se ela não é uma responsabilidade do AN, então é de quem?

    Quero crer que, com a demanda gerada pelas ‘ondas’ BPM e SOA, o BABoK passe a contemplar atividades para modelagem de negócios e de processos de negócios em suas futuras versões. Melhor seria se a incorporação fosse motivada pela percepção de que o trabalho do AN não se restringe à coleta, análise e documentação de requisitos.

    .:.

    Como mostra o conteúdo programático do workshop promovido pela Tempo Real Eventos, a primeira metade do evento tratará exclusivamente da modelagem do negócio e seus processos. Apresentarei algumas práticas sugeridas pelo BABoK na segunda parte do evento.

    .:.