Modelagem de Processos
&
Business Process Modeling Notation
(BPMN)
Os sistemas de informação, como ferramenta do
negócio, podem estar posicionados em
diferentes quadrantes da estratégia
4
Não é exatamente uma novidade o fato de que
muitos projetos de sistemas de informação
simplesmente fracassam. Em média, menos de 20% dos projetos deste tipo são considerados como de
Projetos de sistema 31,10% 52,70% 16,20% 0,00% 10,00% 20,00% 30,00% 40,00% 50,00% 60,00%
6 Entregar os requisitos que atendam às necessidades dos processos de
negócio, não é tarefa das mais simples.
Requisitos de sistema originais 0,00% 10,00% 20,00% 30,00% 40,00% 50,00% 60,00% 70,00% 80,00% 90,00% >74% das funcionalidades 78,40% 42,00% 60,20% < 75% das funcionalidades 21,60% 58,00% 39,80%
8 Requisitos especificados e entregues
0,00% 5,00% 10,00% 15,00% 20,00% 25,00% 30,00% 35,00% 40,00% 45,00% Projetos 4,60% 27,20% 21,80% 39,10% 7,30% 0 a 24% 25 a 49% 50 a 74% 75 a 99% 100%
Mas, por que tanta dificuldade em construir sistemas que atendam, de fato, às necessidades dos processos de negócio? O que torna os projetos de sistema em projetos de alto risco?
10 Motivos de problemas nos projetos
0,00% 5,00% 10,00% 15,00% 20,00% 25,00% % de respostas 12,80% 12,30% 11,80% 7,50% 7,00% 6,40% 5,90% 5,30% 4,30% 3,70% 23,00% Informações deficientes do usuário Requisitos e especificação incompletos Alterações nos requisitos e especificações Apoio executivo insuficiente Incompetência tecnológica Recursos insuficientes Expectativas irrealísticas Objetivos não definidos claramente Prazos irrealísticos Novas tecnologias Outros
Item Motivos de problemas com requisitos % de respostas
1 Informações deficientes do usuário 12,80%
2 Requisitos e especificação incompletos 12,30% 3 Alterações nos requisitos e especificações 11,80%
4 Apoio executivo insuficiente 7,50%
5 Incompetência tecnológica 7,00%
6 Recursos insuficientes 6,40%
7 Expectativas irrealísticas 5,90%
8 Objetivos não definidos claramente 5,30%
9 Prazos irrealísticos 4,30%
10 Novas tecnologias 3,70%
12
Mais de 50% dos motivos podem ser relacionados a
problemas com os requisitos.
Informações deficientes do usuário Requisitos e especificação incompletos Alterações nos requisitos e especificações Expectativas irrealísticas Objetivos não definidos claramente Prazos irrealísticos
14 Fatores de sucesso 0 5 10 15 20 25 Pontos 20 15 15 15 10 5 5 5 5 5 Envolvimento do usuário Apoio executivo Objetivos de negócio claros Experiência em gestão de projetos Metas menores Requisitos básicos definidos Equipe competente Plajenamento
16 Sujeito
Artefato
Regras Comunidade Divisão do
trabalho
ATIVIDADE AÇÃO OPERAÇÃO
Motivo Meta / Propósito Condição
Comunidade Indivíduo /
Grupo
Indivíduo / Máquina
18 BPMN; ARIS; IDEF; BPM; UML; Petri Nets; CIM/CIMOSA; I*; ORDIT; F3 de Bubenko; EKD. Existem diversas ferramentas
conceituais que são utilizadas para a
modelagem de processos.
20 Ação Identificar dificuldades do usuário Selecionar dificuldades Propor soluções funcionais Documentar solução em forma de requisito Dificuldades em geral Dificuldades específicas Requisitos Soluções Validar requisitos Requisitos validados
As “dificuldades” são problemas que devem ser resolvidos ou oportunidades que podem ser exploradas.
22 As necessidades (problemas ou oportunidades) estão relacionadas ao processo de negócio, e não ao sistema de informação.
O sistema deve resolver problemas do negócio, e não do próprio
Isto significa que as descrições de
necessidades não
devem fazer referências tecnológicas claras,
embora possam haver referências.
24
Por exemplo, neste trecho de modelagem é possível perceber que o atendente pode recomendar um filme para o cliente.
Talvez haja aqui uma oportunidade a ser explorada.
“O atendente recomenda títulos ao cliente, procurando
previamente identificar seu perfil no que se refere filmes
anteriormente alugados. O objetivo primário é atender a
expectativa do cliente, e se possível, fazer circular os filmes
menos alugados, deixando aqueles de maior apelo popular para os clientes que não solicitam apoio para seleção”
26
“O atendente recomenda títulos ao cliente, procurando previamente
identificar seu perfil no que se refere filmes anteriormente alugados. O objetivo primário é atender a
expectativa do cliente, e se possível,
fazer circular os filmes menos
alugados, deixando aqueles de maior apelo popular para os clientes que não solicitam apoio para seleção”
Esta descrição da
atividade está focada no negócio e em suas necessidades, e não distorcidas por alguma influência tecnológica.
“O atendente recomenda títulos ao cliente, utilizando a tela de lista de títulos. Nesta tela haverá possibilidade de busca por nome do filme, pelo
ator(a) principal, pelo tipo de filme (drama, comédia, terror, etc), e ainda informará automaticamente se o filme está alugado no momento e quando retornará, possibilitando inclusive já fazer a reserva antes mesmo do retorno”
Fazer menção do que se espera em termos de tecnologia pode desviar a atenção de quem modela o processo, e produzir resultados mais
distantes das reais necessidades do
processo de negócio. Veja um exemplo ruim, ao lado.
28
“O atendente recomenda títulos ao cliente, utilizando a tela de lista de títulos. Nesta tela haverá
possibilidade de busca por nome do filme, pelo ator(a) principal, pelo tipo de filme (drama, comédia, terror, etc), e ainda informará automaticamente se o filme está alugado no momento e quando retornará, possibilitando inclusive já fazer a reserva antes mesmo do retorno”
“O atendente recomenda títulos ao cliente, procurando previamente identificar seu perfil no que se refere filmes anteriormente alugados. O objetivo primário é atender a
expectativa do cliente, e se possível, fazer circular os filmes menos
alugados, deixando aqueles de maior apelo popular para os clientes que não solicitam apoio para seleção”
Considerando que o objetivo da locadora é obter lucro, qual
descrição contribui mais com o objetivo do negócio? Então, qual descrição está mais próxima do negócio?
Muitas das necessidades identificadas não estarão relacionadas com os requisitos do sistema de informação. Veja o caso desta atividade em particular.
30
“Verificar com o cliente se ele pretende pagar o filme no
momento da locação ou apenas no retorno. Deve-se estimular, sem promover qualquer tipo de constrangimento, o pagamento imediato, no ato da locação”
Deve gerar uma funcionalidade de sistema.
“Verificar com o cliente se ele pretende pagar o filme no
momento da locação ou apenas no retorno.
Deve-se estimular, sem promover qualquer tipo de
constrangimento, o pagamento
imediato, no ato da locação” Não deve gerar uma
funcionalidade de sistema.
32 Ação Identificar dificuldades do usuário Selecionar dificuldades Propor soluções funcionais Documentar solução em forma de requisito Dificuldades em geral Dificuldades específicas Requisitos Soluções Validar requisitos Requisitos validados
Por isso, há uma fase para seleção das necessidades que
poderão gerar funcionalidades de sistema, ou, neste contexto, soluções.
Por conta da diferença de contexto entre negócio e tecnologia, que ainda acontece algumas vezes, pode ser que a
modelagem de processos seja feita por uma parte da equipe, e a
identificação de requisitos por outra.
34
É perfeitamente possível que profissionais de TI façam as duas partes do trabalho.
No entanto, é necessário ter boa visão de negócio e saber separar os papéis.
A adição de requisitos é assunto para outro momento. No entanto, é importante destacar que os requisitos
poderão ser anexados aos processos de
trabalho, diretamente nas atividades que eles suportam.
Continue atualizado
www.sistemamoderno.com.br
Que tal saber mais?
Modelagem de Processos Com Bpmn Autor: André L. N. Campos
