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 [1] (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:
- “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”.
The EPBE: Processos de Negócio by finito, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 2.5 Brazil License.
Artigos relacionados:
{ 6 comments… read them below or add one }
O Diagrama de Linha de Montagem é impressionante. Será que todas as ferramentas case para UML aceitam essa “heresia” gráfica?
Para mim é uma ótima representação gráfica para a interação entre casos de uso de negócios e casos de uso de sistema e como as entidades são afetadas por esses casos de uso de sistema.
Outra coisa, assim que comecei a ler sobre EPBE e falei sobre isso com o pessoal, surgiu a questão da BPMN. Na boa, para mim ela poderia ser uma biblioteca de ícones para UML, mas tudo bem. O que me assustou foi que coloquei EPBE e BPMN na Wikipedia (inglês) e não encontrei nada sobre EPBE. Isso é um pouco assustador.
Sobre o livro, pois é, como estou estudando ITIL e pontos de função e peguei férias, ele acabou ficando para janeiro. Acho que os obstáculos para a adoção de uma extensão da UML não mandatária vem de todos os lados
Oi Kerber,
hehe, já cometi tal “heresia” no Rose, StarUML e Umbrello. Só no segundo eu tinha a extensão. Nas outras duas, só criei os estereótipos. E, pimba! Tava lá.
Só não trato aquelas elipses como casos de uso de negócio. Naquele diagrama são casos do sistema mesmo. Mas, se vc quiser relacionar BUC’s e casos do sistema, também não vejo nada que impeça.
Meu caro, EPBE realmente não tem popularidade nenhuma. Talvez eu coloque alguma coisa na Wikipédia, em pt. Mas quando sobrar um tempinho…
A EPBE está completando seu 8º ano de vida. Era para ser mais conhecida. Não importa: como eu disse em outro lugar, o problema está com o entendimento e adoção da disciplina Modelagem de Negócios. Quando ela for mais praticada, com certeza EPBE crescerá com ela.
Abraços,
Paulo.
Também achei muito interessante a forma de relacionar processos com Casos de Uso de sistema. Estava atrás de algum insight sobre isso em função de uma das possibilidades de temas de dissertação, como te falei anteriormente.
Estava pensando em algo como “Eliciação (ou Gestão) de Requisitos orientada por Processos”.
Quanto à pouca utilização da EPBE como mencionado, será que ainda não tem a ver com o fato (ou minha impressão) de que a Modelagem de Negócio, de uma forma mais estruturada e sistematizada, ainda estar “em formação”? – Quero dizer, ela já vem sendo feita na prática, mas sem um arcabouço consistente de notação, processo… enfim, metodologia.
Como mencionei no outro post, há algum tempo tomei contato com o Zachman Framework, algo criado há muito tempo, que faz muito sentido na minha opinião, mas também pouco utilizado. E vejo o ZF como podendo ser um elemento agregador/orientador/direcionador da AN.
Olá Marcel,
Meu caro, de certa forma é isso que sugiro em meu trabalho. A Análise e Modelagem de Negócios ocorre simultaneamente com o Desenvolvimento de Requisitos. Na verdade, não faz o menor sentido que seja feito de outra forma. Por isso, o “desenvolvimento de requisitos orientado por processos de negócio” parece um tipo de pleonasmo. Mas, dada nossa inocência quando o tema é o desenvolvimento de requisitos, quem sabe a redundância não seja útil?
Sim, você tem razão. A pouca popularidade da EPBE é consequência da baixa adoção de uma abordagem mais consistente da Análise e Modelagem de Negócios.
Como eu disse anteriormente, vou relembrar o ZF, de acordo com sua sugestão. Mas acho pouco provável que, nesta versão do meu trabalho, eu faça alguma alteração mais profunda. E, como eu disse em outro lugar, meu próximo tema “de cabeceira” será Arquitetura Corporativa. Aí, com certeza, vou “sugar” muito do ZF.
Obrigado pelo comentário. Abraços,
Paulo
Nosso colega Marcelo Flemming caiu na ‘lista negra’ do mecanismo que controla spams neste blog. Então coloco aqui os comentários que ele enviou por email:
Só pegando um gancho nessa sua obervação:
“”Por isso, o “desenvolvimento de requisitos orientado por processos de negócio” parece um tipo de pleonasmo. Mas, dada nossa inocência quando o tema é o desenvolvimento de requisitos, quem sabe a redundância não seja útil?”"
De fato, após escrever o post eu fiquei com a mesma sensação.
A minha idéia parte do seguinte: existem sistemas cuja Eliciação/Gestão de Requisitos não é derivada de “processos” – pensando aqui na acepção de processos no contexto de processos organizacionais. Ex.: software embarcado para aplicações militares. Neste casos, os requisitos de software derivam da Engenharia de Sistemas. Até onde eu sei, existe já um arcabouço de notação e atividades (método) mais bem estruturado, consistente e bastante utilizado.
Quando se trata de desenvolvimento (ou modificação ou implantação) de software para processos organizacionais, embora naturalmente a Eliciação de Requisitos origina-se da modelagem de processo, não conheço (e pode ser pura ignorância deste escriba) nenhum método consistente e estruturado que permita “fluir” do desenho de processo para a Eliciação/Gestão de Requisitos de Software. Se quisermos ainda fazer a rastreabilidade de Caso de Uso (ou Funcionalidade) para Requisito de Processo, acho que o problema se agrava.
Em parte, o que me despertou o interesse pelo EPBE foi, com base em seus artigos, a impressão de que esta pode ser esse “elo perdido”. VOu averiguar.
Assim, pode ser que, se eu enveredar por essa linha, a dissertação poderia ser algo como um Método (aqui entendido como Notação+Atividades), com base nas extensões à UML propostas pelos autores, para preencher o “elo perdido” (aqui não sei se cabe, pois não sei se os autores propõem um método).
OUtra linha, que na verdade eu vinha pensando era justamente a de linkar BPMN com UML – mas tenho tido muitos feedbacks que BPMN é complexo. Porém, como trabalho acadêmico…talvez.
Olá Marcel,
Você tem razão, existem situações e projetos que exigirão uma orientação diferente para a engenharia de requisitos. Mas, no meu caso, o foco é o trabalho do Analista de Negócios. Daí minha observação: o desenvolvimento de requisitos será sempre orientado aos processos de negócio. Minha falta de experiência com sistemas embarcados e afins também me impede de aprofundar neste caso.
Os autores da EPBE, Eriksson e Penker, não sugerem um método em seu trabalho. Tratam exclusivamente da notação. E a esticam um pouquinho, apresentando uma série de “Business Patterns”. Portanto, seu trabalho, assim como o que desenvolvo aqui, são relativamente “inéditos”.
Quem te falou que BPMN é complexa? Não acho. E, lembre-se: ela só substitui o diagrama de atividades da UML. Ainda assim, apenas em alguns casos. O diagrama de atividades é mais flexível e abrangente.
Abraços,
Paulo