Blog da iProcess - Compartilhando conhecimento em BPM e RPA

O que BPM tem a ver com requisitos de software? Tudo!

Muitas organizações estão buscando adotar BPM (Gestão por Processos de Negócio) como disciplina gerencial. Isto quer dizer que a empresa começa a se organizar e ter seus negócios gerenciados com base em processos de negócio bem estabelecidos, que definem o quê a organização realiza para transformar matéria prima (ou informações) em produtos e serviços.

Conhecer os processos leva a uma série de benefícios para a gestão da organização, mas de forma especial:

  • Possibilita ter uma visão mais clara de como os clientes participam do negócio da empresa
  • Possibilita que a empresa se organize ajustando seus processos para atender os objetivos do planejamento estratégico
  • Possibilita olhar para o quê e como as áreas da empresa interagem para entregar produtos e serviços, de ponta a ponta (do recebimento de materiais/informações, passando por todas as etapas de transformação e agregação de valor até que o produto/serviço seja entregue).

Com isso, torna possível também à organização identificar situações onde pode gerar grande inovação, destacando-se no seu mercado por um produto de muito mais qualidade, ou muito menor custo – tendo como meta atender à expectativa dos clientes.

Então o processo de negócio bem definido nos ajuda a entender o quê a organização faz, não apenas dentro das áreas, mas também como o processo passa de uma área para a outra.

E o que isto tem a ver com requisitos de software?

Sabendo o quê é preciso fazer (e eliminando aquilo que é feito sem necessidade), a organização pode definir melhor como faz. E o como passa pelos recursos utilizados, inclusive, de software. Como uma pessoa realiza uma determinada atividade de um processo? Usando o sistema X. E o que é necessário para ela interagir com os sistemas nesta etapa do processo? Isso é que determina, da forma mais assertiva, os reais requisitos de software que o sistema precisa ter para que as pessoas façam o que precisa ser feito e como deve ser feito!

As integrações entre sistemas, as interfaces e casos de uso para a interação do usuário com o sistema, quais informações o usuário precisa obter, gerar, editar para poder concluir aquela atividade – tudo isso pode ser identificado e definido com maior clareza se temos a visão do processo.

Pense só: com a visão de processo, é possível identificar claramente que informações um participante de processo precisa gerar, para que os participantes das próximas etapas (que estejam por exemplo em outras áreas) possam fazer a sua parte. E com isso, conseguimos definir de forma assertiva tudo o que (e nada mais que) o usuário precisa fornecer em termos de dados no sistema para que o trabalho continue sendo realizado nas áreas seguintes com o menor risco de falta de informações e de erros possível.

Nós da iProcess (junto com muitos profissionais de processos que atuam na frente de tecnologia) acreditamos que o processo de negócio deve guiar a identificação dos requisitos de software. Esta abordagem se reflete na qualidade e aderência do software às necessidades do negócio quando a solução é implantada.

Veja resultados efetivos dessa abordagem nos cases implementados da iProcess.


7 respostas

  1. Parabéns pelo post. Como sempre, muito bom.
    Coincidentemente este foi o tema de minha monografia da minha especialização no ano passado!

    1. Obrigada Fátima.
      Em nossa Metodologia de Desenvolvimento Orientado a Processos e Serviços, definimos alguns critérios sim, baseados na avaliação dos elementos de BPMN para definir métricas para o desenvolvimento de software.
      Estimar esforço baseado no mapeamento do processo, entretanto, não revela toda a complexidade da implementação da solução.
      Automatizar um processo usando Oracle BPM, Bizagi BPM Suite ou Cryo Orquestra BPM (só para citar algumas das inúmeras suítes de automação de processos), envolve trabalho diferenciado na implementação do processo devido a características das próprias soluções. Além disso, o processo pode ser um dos requisitos, mas não é o único. Cada tela no qual o usuário irá interagir com o processo (tarefas de usuário), outras telas e funcionalidades que não são usadas diretamente em atividades do processo mas que precisam ser disponibilizados (cadastros back office por exemplo), e cada operação realizada automaticamente pelo processo (tarefas de serviço, de script e de regra de negócio) envolve um trabalho adicional que extrapola aquilo que conseguimos definir e expressar com BPMN.
      Assim, para cada tipo de solução que usamos nos projetos para nossos clientes para a automação de processos, definimos métricas baseadas no BPMN mas que consideram as características específicas da suíte utilizada (e que são constantemente revisadas, já que os produtos também estão evoluindo).

  2. Concordo totalmente. Sem a visão de processos de negócio, a elicitação de requisitos parece um navio no mar sem rumo determinado. É preciso ter em mente, sempre, as regras de negócio e os requisitos de negócio. Requisitos funcionais só devem ser elicitados para a parte do domínio do negócio que será informatizada / automatizada seja por um sistema ou por um workflow em BPM. Definir com precisão os limites do sistema é o grande desafio: estes limites são geralmente definidos de forma incompleta, ou os clientes/usuários especificam detalhes técnicos desnecessários (domínio mal definido e mal acordado é uma fonte incessante de problemas); A visão de processo auxilia enormemente, pois os clientes/usuários geralmente não estão completamente certos das próprias necessidades, têm uma pouca compreensão do domínio do seu negócio, omitem informações que julgam óbvias, tentam supervalorizar o próprio trabalho e tem uma relação inicial de desconfiança, por temerem ser expostos ou ficarem sob um controle mais rigoroso de produtividade. Mantendo a visão de processos, fica fácil partir para os requisitos de domínio: esse é o caminho das pedras para facilitar a nossa vida. Deve-se buscar, também, um conjunto de regras de negócio consistente e coerente, neste domínio bem compreendido – é o objetivo maior. Construir um motor de regras, para verificar coerência e consistência, quando há muitas regras de negócio, pode ser uma grande ajuda; Tenho sempre em mente, sempre que possível, três classificações descritas abaixo: Considero que requisitos de negócio são atividades realizadas para identificar, analisar, especificar e definir as necessidades de negócio que um aplicativo deve prover para solução do problema levantado. Estão fortemente associados à visão de processos. Correspondem a: • Objetivos do negócio; • Contexto do negócio; • Contexto do sistema; • Fatores de sucesso. Considero como requisitos de usuário (geralmente são os primeiros requisitos a serem elicitados e são descritos na linguagem do usuário): • Casos de Uso; • Regras de Negócio; • Tipos de Perfis de Usuário; • Objetivos dos Usuários; Considero como requisitos de sistema (explicam como o sistema atenderá aos requisitos de usuário): • Requisitos Funcionais; • Requisitos de Informação; • Requisitos não Funcionais; • Restrições de design. Isso já ajuda muito. Mas é sempre bom não confundir Requisito não Funcional com Meta. Meta é uma intenção geral do usuário tal como facilidade de uso. Requisito não Funcional é uma declaração usando alguma medida que pode ser objetivamente testada. A partir de metas de Usuário, pode-se chegar aos Requisitos não Funcionais, viabilizando a sua verificação. Considero uma visão do sistema a ser construído, como sendo estruturada em três camadas: a) Necessidade (a de nível de abstração mais alto), que reflete os problemas. Estamos no Domínio do problema. Geralmente é documentada pelo Analista de Negócio. Há necessidades estratégicas, táticas e operacionais; b) As Características de Software: é o nível intermediário de abstração. Geralmente documentada pelo Analista de Negócio. Também são chamados de features. É a descrição das necessidades dos stakeholders (geralmente, para stakeholders de nível tático). É aquilo que você apresentaria a um cliente, se tivesse apenas 5 minutos para “vender” o sistema. Há características funcionais e não funcionais; c) especificação de requisitos de software (visão de nível de abstração mais baixo). Documentada pelo Analista de Requisitos. Casos de Uso e Especificação Suplementar. O que você acha ? (Continuo fã de seus artigos publicados na iProcess. São muito bons).

    1. Oi José Ricardo,
      Sem dúvida existe esta relação, e embora as organizações talvez não tenham a visão estruturada de como uma necessidade de negócio é detalhada e transformada até virar um componente de software, são de fato os processos que dão esse direcionamento. A questão está em o quanto a organização percebe a relevância de entender os processos de negócio para então detalhá-los progressivamente até a visão funcional das melhorias de processo que efetivamente serão implementadas como software.
      Em especial, concordo com você a importância também de diferenciar regras de negócio e extraí-las da lógica do software. Elas devem reger o comportamento do sofrware de acordo com as características do negócio, e não o contrário. Estruturar as regras do negócio em um motor de regras é uma prática que ainda vemos ocorrer timidamente, mas que aos poucos começa a se consolidar nas organizações que percebem como isso pode ser chave para um gerenciamento mais flexível sobre o negócio (e menos dependente da TI).
      Obrigada por sua visita!

  3. Tenho a convicção de que o MPN deva anteceder qualquer pretensão de desenvolvimento de software, até mesmo para que se tenha a compreensão e o entendimento o mais precisos possíveis sobre qual processo deva ser ou não automatizado. O software, uma tecnologia de apoio, não deve ser a razão do sucesso, mas um dos meios de se alcançá-lo. Vivenciei por duas vezes esse sucesso: tanto por minha passagem pela Reitoria da UnB, quanto pela minha passagem pelo Datasus/Hemovida. Nas duas experiências profissionais, a modelagem dos processos de negócio e associativamente o levantamento dos requisitos de negócio antecederam ao levantamento e detalhamento dos requisitos de software, o que, nessa ordem, contribui para melhorar o entendimento dos profissionais, Analistas de Requisitos, em suas atividades.

    Parabéns pelo conteúdo didático do texto.

Deixe um comentário para Fernando Guimarães Cancelar resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

MAIS VISTOS

Como transformar as ideias de mudança para um processo TO BE em ações efetivas, controladas... (continuar lendo)
Veja agora as ações que foram realizadas através das doações de todos os participantes deste... (continuar lendo)
Participe deste evento exclusive e gratuIto e se prepare para as transformações que IA irá... (continuar lendo)

Inscreva-se na nossa Newsletter

seers cmp badge