Análise de Negócios

Gostei desse "negócio", mas por onde começar?

Modelagem de Negócios


Para conhecer tudo o que é importante para o projeto em relação à organização é necessário efetuar a modelagem de negócios. Por modelagem não estou me referindo estritamente a modelos gráficos como organogramas ou UML e BPMN, me refiro a conhecer a empresa a partir de várias visões. Aliás, modelamos para aprender, comunicar, e só por último, para documentar.

Como no projeto de uma casa, você só o entende de verdade se ver a planta, as vistas, cortes, hidráulico, elétrico, sanitário e memorial descritivo. Não é a casa em si, são representações que se limitam a partes importantes para o projeto, por isso chamamos de modelos.

Em uma organização, essas visões passam pelo planejamento estratégico, pelo organograma e pelos diferentes tipos de processos.

-“É necessário saber tudo isso para fazer um pequeno projeto?“ - Não. Voltando para a analogia da casa, se você for reformar uma parede colocando uma janela pode bastar você mapear aquele cômodo dando especial atenção para os eventuais canos e fios que cruzam as suas paredes.

A arte de definir o que é ou não relevante para a construção do modelo chama-se “capacidade de abstração”. Abstrair é “remover”. Tudo a tem em maior ou menor grau.

Um bom exemplo de abstração é quando você conta uma anedota para seus amigos. Um bom contador foca na história e jamais vai se ater a detalhes como o nome do papagaio safado. O nome é “abstraído”.

- “Odeio essas coisas de planejamento estratégico, objetivos, metas, participação em mercado me dá arrepios. Prefiro J2EE, eu mando e ele obedece.” -  Amigo, é melhor você criar gosto ou permanecer no lado da solução. Sabe, nenhum lado é mais importante do que o outro e o trabalho dos diferentes profissionais é complementar e igualmente importante, então prefiro ter você trabalhando comigo como analista de sistemas, arquiteto, ou Srcum Master feliz da vida.

Bom, voltando ao pessoal interessado, no “domínio do problema” – é assim que chamamos o estudo do “quê” deve ser feito, infelizmente ainda existe apenas uma pessoa falando sério sobre modelagem de negócios, eu vou falar dela mais adiante junto às referências.

Da estratégia ao requisito - fazendo sentido

Falei anteriormente que projetos ligam a estratégia aos resultados. Vamos ver como isso ocorre do ponto de vista dos requisitos, partindo de algo que apareceu na sua mesa, digamos que, escrito em um post-it amarelinho:

“Como um caixa da lanchonete, eu posso digitar os pedidos durante a venda para que o pessoal da montagem possa ver no telão o que deve ser feito.”

Requisito interessante, não? O caixa vai digitando o pedido e ele vai aparecendo em uma fila de pedidos para o pessoal que monta os hambúrgueres e as batatas fritas. Mas de onde ele surgiu?

Bem, é evidente que este requisito está ligado a um sistema. Esse sistema é utilizado para apoiar o processo de venda da lanchonete. Ele ajuda muito, pois permite que pessoas com diferentes responsabilidades tenham informações em tempo real do que está acontecendo além de possibilitar pagamento através de diferentes meios e de guardar registros para a administração. Show de bola. É em busca disso que as empresas investem tanto em sistemas de informação.

O processo de venda da lanchonete depende de diversos fatores para que ocorra de forma satisfatória. Os ingredientes devem estar à disposição, o atendente deve saber quem do pessoal que lota o balcão deve ser atendido agora, deve haver troco no caixa, a conta de luz deve ser paga, entre outras inúmeras coisas, a “tecnologia da informação” deve trabalhar para que a informação corra livremente através da tecnologia.

Essa interdependência entre as diferentes funções se chama “nível operacional”. O sujeito que monta a bandeja sabe que o sujeito das batatas entrega novas batatas a cada três minutos, e esse por sua vez sabe que sempre vai ter batatas novas cortadinhas no pote ao lado.

Isso tudo pode parecer bastante industrial e arcaico, mas lembremos que bons processos são aqueles que são executados com o mínimo de distorção possível. O mundo pode sentir falta da criatividade em muitos campos, inclusive no nosso, contudo, a maior parte das coisas que você vê funcionando ao seu redor nesse exato momento, depende de processos repetitivos.

Esta série de responsabilidades encadeadas formam o nível de serviço do negócio. Um exemplo muito comum de nível de serviço no nosso dia a dia está ligado à contratação de serviços de infraestrutura. Contratamos hospedagem em serviços que nos garantem funcionamento durante 98% do tempo com resposta para chamados em até duas horas. Tanto o 98% quanto as duas horas são níveis de serviço que são acordados durante a contratação (Service Level Agreement – SLA).

Os níveis de serviço existem em todos os tipos de negócios, mesmo quando não são declarados de forma tão direta quanto nos contratos de infraestrutura. Pensando na nossa lanchonete, os usuários sabem, mesmo que instintivamente, que serão atendidos em até no máximo quatro minutos, e que depois de efetuar o pagamento, não esperarão mais de sete ou oito minutos pelo lanche. Essa “imagem” se constrói ao longo dos anos e é fundamental para quem trabalha no ramo de “fast” food.

Os níveis operacionais são chamados em inglês de OLA (operational level agreement). A equação do nível de serviço é algo como: SLA = OLA + OLA + OLA... ou SLA = ∑ OLA.

Olhando essa equação fica claro que o elo mais fraco da corrente pode trazer problemas para o negócio. Você pode estar com a sua bandeja quase pronta, mas precisa esperar até chegar as batatas fritas.

E aquele requisito, de onde veio? Ou melhor, de onde ele deveria ter vindo? Da estratégia da lanchonete.

A alta cúpula da lanchonete descobriu através de pesquisas mercadológicas que se conseguisse diminuir o seu SLA médio de entrega de pedidos em pelo menos 8% conseguiria papar mais 5% do mercado. Parece que uma boa parte dos clientes da lanchonete trabalha com software e está sempre na correria para atender aos prazos de seus projetos.

Alguém - imaginamos que o analista de negócios ou quem o acionou – estudando o processo (recomendo nesses casos a observação passiva, ou seja, ficar parado ao lado da lanchonete observando atentamente como o trabalho é realizado) notou que gritar os pedidos traz alguns erros que no final acabam atrasando o SLA médio da lanchonete.

Em suma, você como analista de negócios da lanchonete sabe que para ela é crítico diminuir o tempo de entrega de um pedido (e também os erros que ocorrem no escopo dos hambúrgueres) e através do estudo dos processos chegou até aquele requisito que está sobre a sua mesa.

Agora você pode ter pensado “mas isso nunca aconteceu comigo, eu costumo ser jogado em um projeto que tem um escopo mais ou menos claro e saio atrás de levantar e detalhar os requisitos”. Isso é normal e ocorre o tempo todo. O que eu peço é para que você faça um esforço para sempre buscar os por quês, as razões daquilo estar sendo feito. Esses questionamentos poderão levar a grandes revelações e permitir que seu projeto traga mais valor para a organização, e no final, é isso que interessa para um analista de negócios.

Requisitos são tinhosos, em empresas bagunçadas como as nossas eles costumam pipocar de todos os lados e você ás vezes o pegará “lá embaixo” e seguir o caminho acima tentando entender o “porquê” dele. Vale a pena. Mesmo parecendo idealista, o caminho lógico é de cima para baixo, removendo um pouco da abstração a cada passo. Esse é o objetivo a se seguir.

Aqui aproveito para falar da área de conhecimento do BABOK que considero mais importante, a elicitação. Veja, se você trabalha em uma área de TI voluntariosa, que faz todo o possível para entregar o que os clientes pedem, descasca os chamados assim que eles chegam, pode ser que você não esteja fazendo um bom trabalho.

Esta devoção cega ao trabalho costuma levar a grandes problemas (que geralmente aparecem na base de dados e através de bugs misteriosos), pois as coisas são implementadas fora de contexto e ao sabor do vendo.  O analista de negócios deve sempre ter o todo em mente e, através da elicitação, buscar conhecer o que o cliente precisa e não somente o que ele quer.

Voltando às abstrações, os diferentes níveis foram tirados do livro do Cockburn, que trata sobre como escrever casos de uso eficazes. Ele definiu diferentes níveis de abstração para os casos de uso sendo que os de baixo sustentam os de cima:

  • Nuvem – Lá encima, é o nível de serviço (SLA), o que você entrega para o cliente. Seu fluxo é a interação do cliente com a empresa. Em marketing é “a experiência”.
  • Pipa – Mais embaixo, é o nível operacional (OLA), mostra como as coisas acontecem dentro da empresa enquanto ela luta para atender o SLA. Essa parte é conhecida como operações.
  • Nível do mar – É a funcionalidade do sistema que apoia o usuário na execução da sua parte do processo. Essa parte é conhecida como “aquele maldito sistema”.


Mesmo que você não utilize casos de uso no seu trabalho, essa lógica ajuda muito a conectar as coisas. Se você trabalha, por exemplo, com histórias do usuário, coloque elas no nível do mar, as conexões vão funcionar tão bem quanto com casos de uso, afinal, as histórias, como os casos de uso, também são objetivos do usuário realizados através da interação com o sistema.

Esse trabalho que busca os porquês dos requisitos tem tudo a ver com uma coisa chamada eficácia. A eficácia é fazer a coisa certa, nadar na direção correta, é o alinhamento, no nosso caso, o alinhamento do nosso projeto com os objetivos da organização.

Falando em nadar, eu fiz travessias em águas abertas por um tempo e o pessoal desse ramo sabe que saber nadar bem é só parte da equação, levantar a cabeça e saber onde você está e para onde está indo compensando a correnteza é fundamental. Eu era muito bom em fazer trajetórias curvas. Uma prova de 1600 metros nunca acabava comigo nadando menos de 2000.

Vale ressaltar que o fruto do trabalho nem precisa ser software. Talvez outra solução como remodelar a disposição dos equipamentos na lanchonete possa surtir o mesmo efeito, ou melhor. O analista de negócios está fazendo o seu trabalho também quando descobre alternativas às intervenções no software.

Lá no EAN, por exemplo, nosso foco era entender os clientes dos produtos (hardware e software) que desenvolvemos e vendemos. Como são milhares de clientes, devemos conhecer a realidade do ramo para criar um modelo de cliente que represente o que há de comum entre eles além de estudarmos todas as demandas particulares.

É comum descobrirmos maneiras criativas dos clientes resolverem ou contornarem seus problemas utilizando, mesmo que temporariamente, a versão atual do produto sem alterações no código. Não se trata de fazê-los engolir o problema, mas de se encontrar uma solução de contorno enquanto a solução definitiva não sai da fila. Copiamos isso do gerenciamento de incidentes do service desk da ITIL que por sua vez deve ter copiado isso da medicina. Vai uma morfina aí?

Bem, até agora falei da eficácia da análise de negócios, a modelagem de negócios. Agora é necessário falar sobre o que traz eficiência ao trabalho, que faz você nadar mais rápido, a engenharia de requisitos.