Estudo sobre a aplicação do método de avaliação do modelo de processos de negócio do EKD

A study on the application of the assessment method of business processes model of EKD

Estudo sobre a aplicação do método de avaliação do modelo de processos de negócio do EKD

A study on the application of the assessment method of business processes model of EKD

Silvia Inês Dallavalle de Pádua^*

USP, Brasil. [e-mail]

RESUMO

A modelagem de processos de negócio e a simulação têm sido amplamente utilizadas para realizar melhoria contínua, gestão por processos e mudanças na estrutura organizacional. Assim, este trabalho tem o objetivo principal de apresentar e discutir a aplicação do método de avaliação do modelo de processos de negócios do EKD. O método inclui a simulação do modelo de processos de negócio para verificar se o modelo está livre de travamentos e erros. Essa pesquisa é uma revisão da literatura, com uma aplicação pautada em dados secundários. A aplicação do método mostrou que o desenvolvimento do modelo de processos de negócio com base nos objetivos organizacionais facilita o entendimento por todas as pessoas envolvidas no processo de modelagem e a simulação identificou se o modelo estava correto e livre de travamentos.

Palavras-chave: Modelo de processos de negócio. Simulação. EKD. Modelagem organizacional. Gerenciamento de processos de negócio.

ABSTRACT

Business processes modeling and simulation have been widely used to perform continuous improvement, business process management and changes of organizational structure. Therefore, the main goal of this study was to present and discuss the application of the assessment method of business processes model of EKD. This method includes the simulation of the model of business processes to verify whether it is free of deadlocks and errors. This research is a literature revision, with application based on secondary data. The application showed that the development of business processes model based on organizational goals facilitates comprehension by the whole staff involved in the process of modeling, and the simulation identified whether the model was correct and free of deadlocks.

Keywords: Business Processes Model. Simulation. EKD. Enterprise Modeling. Business Process Management.

1. Introdução

Nos últimos anos a melhoria organizacional por meio da modelagem de processos de negócio tornou-se uma importante forma de realizar mudanças na estrutura para criar uma organização de sucesso e mais competitiva. Processos de negócios são definidos como um conjunto de atividades projetadas para produzir um resultado para um cliente ou mercado em particular (HAMMER; CHAMPY, 1994).

A modelagem de processos de negócio tem sido intensivamente estudada, principalmente depois de 1990 (DOOMUN; JUNGUM, 2008; GREGORIADES; SUTCLIFFE, 2008; KOCK et al., 2009; PÁDUA; INAMASU, 2008b; SIHA; SAAD, 2008). O modelo de processos de negócio permite melhorias, de acordo com Gregoriades e Sutcliffe (2008) e Neubauer (2009), como o benchmarking, a reengenharia de processos de negócio (BPR), gestão por processos (BPM) e melhoria contínua de processos. Na mesma linha, o estudo de Radhakrishnan, Zub e Groverc (2008) mostra que para a tecnologia da informação adicionar valor ao negócio é necessário ter uma perspectiva orientada a processo, ou seja, é necessário ter o conceito da interdependência das partes.

De acordo com Doomun e Jungum (2008), a necessidade de uma metodologia flexível é realçada para aumentar a eficiência e eficácia do ciclo de gerenciamento ou melhoria dos processos. O processo de modelagem de processos de negócio e modelagem organizacional deve trazer respostas a essas questões: por quê, o quê, quem, qual, quando, onde e como. Para tanto, existem diversas técnicas de modelagem na literatura com uma significativa variedade de notações.

A abordagem que será utilizada neste trabalho é o EKD - Enterprise Knowledge Development, uma metodologia que fornece uma forma sistemática e controlada de analisar, entender, desenvolver e documentar uma organização e seus componentes, usando a modelagem organizacional (BUBENKO JUNIOR; STIRNA; BRASH, 1998; PÁDUA; INAMASU, 2008b; NURCAN; ROLLAND, 2003; ROLLAND; NURCAN; GROSZ, 2000). Segundo Kavakli et al. (2006) e Kirikova et al. (2000), o EKD pode ser usado em situações diferentes e com propósitos distintos, como nas seguintes situações:

• Na engenharia de requisitos para definição e especificação de requisitos;

• Na análise do negócio para detecção do problema;

• Na reengenharia de processos do negócio para definição de novos sistemas de negócio;

• No gerenciamento de conhecimento organizacional ou aprendizagem organizacional para formar a base de propagação e ampliação de conhecimento.

A proposta de usar o EKD é prover uma descrição de como a organização funciona atualmente; quais são os requisitos e as razões para a mudança; quais alternativas deveriam ser criadas para encontrar esses requisitos e quais são os critérios e argumentos para avaliação dessas alternativas (BUBENKO et al., 1998; PÁDUA; CAZARINI; INAMASU, 2004; PÁDUA, 2004; INAMASU, 2008a).

Nesse sentido, o EKD é uma abordagem disponível para o esforço para a modelagem de processos de negócio devido a sua configuração flexível, que pode se adaptar a uma mudança incremental ou radical. De acordo com Pádua (2004), a sintaxe e a semântica do modelo de processos de negócio do EKD não são bem definidas formalmente e rigorosamente. Como resultado, o modelo de processos de negócio do EKD pode ser ambíguo e de difícil análise, principalmente em sistemas mais complexos, não sendo possível verificar a consistência e completude do modelo. A ausência de semântica formal dificulta, também, o uso de técnicas mais eficientes de análise.

No método utilizado neste trabalho, os problemas relacionados à ausência de semântica formal dos modelos de processos foram estudados sob uma abordagem baseada em redes de Petri. O formalismo de redes de Petri a torna uma poderosa técnica de modelagem para a representação de processos, permitindo a exibição de concorrência, paralelismo, sincronização, não determinismo e exclusão mútua (PÁDUA; INAMASU, 2008b).

Muitos trabalhos têm valorizado a estrutura formal das redes de Petri para representação de processos de negócios, entre eles pode-se mencionar Guan et al. (2006), Muehlen e Indulska (2009), Ou-Yang e Lin (2008), Pádua e Inamasu (2008b), Pádua et al. (2004), Van der Aalst (1999), Van der Aalst e Hee (2002), Verbeek, Van der Aalst e Hofstede (2007) e Zhang e Shuzen (2006).

Para Wynn et al. (2009), os melhores sistemas para avaliação de modelo de processos de negócio realizam apenas checagem básica e permitem a modelagem com diversos problemas como travamento; além disso, essas ferramentas não verificam processos reais porque assumem modelos altamente simplificados e totalmente desconectados da linguagem organizacional. Nesse sentido, a pergunta que esse trabalho se propõe a responder é:

"Como garantir que o modelo de processos de negócio seja desenvolvido com base nos objetivos organizacionais, seja de fácil entendimento por todas as pessoas envolvidas no processo e esteja correto, livre de travamentos, para que seja base para uma gestão por processos?"

Assim, este trabalho tem o objetivo principal de apresentar o estado da arte de modelagem de processos e discutir uma aplicação do método de avaliação do modelo de processos de negócios do EKD. O método inclui a simulação do modelo de processos de negócio para verificar se o modelo está livre de travamentos e erros.

Nos trabalhos de Van der Aalst e Hee (2002), Van der Aalst e Hofstede (2000), Van der Aalst (1999), Salimifard e Wright (2001), os processos de negócio são modelados diretamente em redes de Petri. Neste trabalho, a construção do modelo de processos de negócio buscará seguir a abordagem de modelagem organizacional EKD e não diretamente em redes de Petri. E espera-se que o desenvolvimento do modelo organizacional utilizando o método EKD proporcione o gerenciamento de mudanças, captura das melhores práticas do negócio, gerenciamento das regras do negócio e gerenciamento do conhecimento organizacional.

Os modelos que serão apresentados fazem parte do estudo de Pinotti (2004). Os modelos representam um estudo no âmbito da Delegacia Regional Tributária de Araraquara, da Secretaria da Fazenda do Estado de São Paulo. O propósito da modelagem é especificar um sistema para o gerenciamento das ausências de funcionários devido a férias, licenças ou outros fatores, e das respectivas substituições desses funcionários, no período em que estão ausentes, caso seja necessário.

Essa pesquisa é uma revisão da literatura, com uma aplicação pautada em dados secundários de Pinotti (2004).

O trabalho está estruturado em seis seções, incluindo a presente introdução. Nas seções 2 e 3 apresentam-se respectivamente a revisão teórica da modelagem de processos de negócio e o método de avaliação do modelo de processos de negócio do EKD. Na seção 4 mostram-se o contexto do modelo de processos de negócio, o modelo de elaboração de escalas e o modelo de elaboração de escalas modificado parte 1 e o modelo de elaboração de escalas modificado parte 2 e os resultados dos testes. A discussão e as considerações finais são apresentadas nas seções 5 e 6.

2. Modelagem de processos de negócio

Davenport (1993) afirma que processo de negócio é uma organização de atividade de trabalho, com início, fim e com entradas e saídas claramente definidas. Para Beretta (2002), processos de negócio indicam onde os recursos e competências da empresa são ativados a fim de criar uma competência organizacional capaz de preencher suas lacunas para gerar uma vantagem competitiva sustentável.

Para Maximiano (1986), a estrutura organizacional é o produto das decisões de divisão e coordenação do trabalho. Seguindo essa linha, para juntar todas as tarefas especializadas é necessário estabelecer uma rede de relações entre grupos de indivíduos ou indivíduos de forma que seus trabalhos sejam coordenados e alinhados com a tarefa final. É relevante notar que a estrutura organizacional influencia significativamente a performance da organização (PINTO, 2002).

A competitividade levou algumas empresas a rever sua estrutura organizacional, não arquitetando-as sobre atividades em torno das suas áreas funcionais, mas na perspectiva de processos de negócio da organização. Para enfrentar os desafios do contexto empresarial, a solução encontrada por Neubauer (2009) e McCormack et al. (2009) é a gestão por processos (BPM) que permite às empresas uma rápida adaptação organizacional. A análise de processo é reconhecida como um estágio muito importante na gestão por processos, de acordo com Lin, Fan e Newman (2009) e ABPMP (ASSOCIATION..., 2009).

As mudanças representam riscos devido ao impacto que podem ter no processo e nos componentes da organização, e muitos esforços da reengenharia ou transformação de processos falham devido ao nível de incerteza (GREGORIADES; SUTCLIFFE, 2008).

Goldkuhl e Lind (2008) propõem que uma visão integrada da organização tem implicações práticas no trabalho de modelagem, análise e projeto de processos de negócio. No estudo de Kock et al. (2009), a qualidade percebida de um modelo é definida como o nível em que o modelo apresenta as seguintes características: facilidade de geração e entendimento, completude e precisão. O estudo sugere que o nível comunicação do fluxo de um modelo de processos de negócio é significantemente relacionado à qualidade percebida do modelo. Por outro lado, a qualidade percebida do modelo é significantemente relacionada ao sucesso do reprojeto dos processos de negócio.

O estudo de Wynn et al. (2009) mostra que os processos de negócio requerem uma execução com interdependências complexas para atender as necessidades do ambiente. Por exemplo, é possível que certas atividades precisem ser canceladas no meio do processo ou ainda algumas atividades paralelas requeiram sincronização e espera.

Van der Aalst, Weske e Wirtz (2003) afirmam que existem três tipos de análise de processos de negócio: validação, verificação e performance. Entretanto, antes de fazer uma análise detalhada do processo, a análise dos processos macros deve ser realizada para saber quais processos são ligados ou alinhados para especificar estratégias organizacionais para atingir os objetivos do negócio. Em outras palavras, para melhoria dos processos ou inovação é necessário identificar os processos mais importantes para um desempenho de sucesso bem como os indicadores de desempenho que são influenciados quando processos específicos são executados (HAN; KANG; SONG, 2009). Depois da análise dos processos macros, as métricas de desempenho são necessárias para a análise de micro processos.

Van der Aalst e Hee (2002) mostram as diferenças entre os aspectos das análises qualitativa e quantitativa do modelo de processos de negócio. A primeira busca a corretitude lógica e pode ser analisada por redes de Petri, já a segunda está relacionada à performance e pode ser analisada principalmente por simulação. Para April et al. (2005 apud HAN; KANG; SONG, 2009), a simulação é importante para habilitar o teste de possíveis mudanças sem prejudicar o funcionamento da organização.

A simulação do modelo permite testar e analisar por diferentes cenários para entender seu impacto nos limites ou fronteiras do sistema e avaliar o retorno antes de realizar mudanças ou planejar a implementação da transformação dos processos de negócio, de acordo com Doomun e Jungum (2008).

Na mesma linha, para Siha e Saad (2008), a simulação do modelo funciona como uma ferramenta de diagnóstico para identificação de rotas causadoras de problemas e ineficiências no ambiente do negócio. Um problema ressaltado por Wynn et al. (2009) é que as ferramentas que simulam e verificam os modelos de processos assumem modelos simplificados e desconectados da linguagem organizacional.

3. Método de avaliação do modelo de processos de negócio

De acordo com Bubenko Junior, Stirna e Brash (1998), os tipos de submodelos da abordagem EKD são: modelo de objetivos, modelo de regras do negócio, modelo de conceitos, modelo de processos do negócio, modelo de atores e recursos e modelo de requisitos e componentes técnicos. A abordagem EKD possui um conjunto de questões que apoia o desenvolvimento de todos os modelos e ainda oferece um conjunto de questões para apoio na verificação das ligações entre componentes de todos os modelos. A abordagem busca identificar as melhores práticas do negócio, o gerenciamento de mudanças e de regras de negócio.

O método de avaliação do modelo de processos de negócio foi descrito detalhadamente em Pádua e Inamasu (2008b). Para que fosse possível realizar o mapeamento do modelo de processos de negócio em redes de Petri foi criada, baseada em Van der Aalst (1999), uma definição formal do modelo de processos de negócio do EKD (MPN-EKD). Dessa forma, foi possível descrever os requisitos que um modelo de processos de negócio deve satisfazer para que o mapeamento seja desenvolvido. A formalização do modelo de processos de negócio foi descrita em Pádua e Inamasu (2008a).

Visando a definição formal do modelo de processos de negócio foi criado um conjunto de conectores para o modelo de processos de negócio do EKD. O conjunto de conectores, representado por C, é composto por C_AND, C_OR, C_J, C_S, C_IP e C_PI. Os conectores C_OR e C_AND foram criados para identificar escolha (exclusiva) e paralelismo para que os casos de paralelismo e escolha não sejam modelados exatamente da mesma forma, criando ambiguidades e dificuldades de compreensão. Os conectores C_J e C_S definem conectores do tipo join e split. Para descrever a natureza do fluxo dos processos e de suas interações existe um conjunto de termos, utilizados em Workflow Management Coalition (1996) e em Van der Aalst e Hee (2002), que são apresentados a seguir:

• AND-Split: ponto em que, de uma única linha de fluxo, partem duas ou mais linhas que são executadas em paralelo;

• AND-Join: ponto em que duas ou mais atividades, executando em paralelo, convergem em uma única linha de fluxo comum;

• OR-Split: ponto em que uma única linha de fluxo faz uma decisão entre um número de opções;

• OR-Join: ponto no qual uma atividade que possui um número de alternativas direciona-se para uma única opção.

De acordo com essas definições de AND-Split, AND-Join, OR-Split e OR-Join, as construções da Figura 1 não são permitidas no MPN-EKD formal.

Os conectores C_IP e C_PI demonstram que um conector C é um caminho de um inf-set para um processo ou um caminho de um processo para um inf-set.

De acordo com Pádua e Inamasu (2008b), o método de avaliação do modelo de processos de negócio consiste em:

1. Desenvolver o modelo organizacional EKD utilizando as diretrizes apresentadas em Bubenko Junior, Stirna e Brash (1998).

2. Desenvolver o modelo de processos de negócio de acordo com a formalização do MPN-EKD apresentada em Pádua e Inamasu (2008a). Conferir se o modelo atende aos seguintes requisitos que previnem rotas causadoras de problemas:

2.1. Todos os processos devem ter condição de entrada e saída. Quando um processo não tem nenhuma condição de entrada, não fica claro quando poderá ser realizado. Quando um processo não tem condições de saída, não contribui para o sucesso do caso e pode ser omitido.

2.2. Deve haver ao menos um inf-set final e um inf-set inicial.

2.3. A entrada do processo deve ser igual a 1.

2.4. A saída do processo deve ser igual a 1.

2.5. A saída do inf-set deve ser igual ou menor que 1. Menor que 1 caso seja um inf-set final.

2.6. A entrada do inf-set deve ser igual ou menor que 1. Menor que 1 caso seja um inf-set inicial.

2.7. A entrada do conector deve ser maior ou igual a 1.

2.8. A saída do conector deve ser maior ou igual a 1.

2.9. Todo conector deve ser do tipo OR ou AND.

2.10. Todo conector dever ser do tipo split ou join

2.11. Todo conector deve ser do tipo PI ou IP.

2.12. Um conector do tipo split deve ter a entrada igual a 1.

2.13. Um conector do tipo split deve ter a saída igual ou maior que 2.

2.14. Um conector do tipo join deve ter a entrada maior ou igual a 2.

2.15. Um conector do tipo join deve ter a saída igual a 1.

2.16. Não é permitido conectar processo a processo.

2.17. Não é permitido conectar inf-set a inf-set.

2.18. Não é permitido utilizar o conector ligando processo(s) a processo(s) e inf-set(s) a inf-set(s).

2.19. Não é permitida a conexão de conector (es) com conector(es).

2.20. Todos os inf-sets que não foram gerados pelo processo devem ser habilitados.

3. Mapear o modelo em redes de Petri. Os inf-sets são representados por lugares e os processos são representados por transições. Para mapear os conectores é necessário seguir as regras apresentadas a seguir:

3.1. O conjunto de lugares é formado pela união de todos os inf-sets com lugares que foram incluídos para representar os conectores.

3.2. O conjunto de transições é formado pela união de todos os processos com transições que foram incluídas para representar conectores.

3.3. O conjunto de arcos da rede é formado pelos arcos de modelo que vão de I (inf-set) a P (processo) e de P a I e a união dos arcos incluídos para representar conectores.

3.4. A regra 1 estabelece que quando o conector c pertence a C_IP (caminho de inf-set para processo) intersecção de C_J (join) intersecção de C_AND, o conector (c C _IP C_J C_AND) corresponde a dois ou mais arcos em redes de Petri.

3.5. A regra 2 estabelece que quando o conector c pertence a C_PI (caminho de processo para inf-set) intersecção de C_J (join) intersecção de C_AND, o conector (c C _PI C_J C_AND) tem o comportamento de uma transição. É acrescentado um lugar para cada processo de entrada do conector.

3.6. A regra 3 estabelece que quando o conector c pertence a C_IP (caminho de inf-set para processo) intersecção de C_J (join) intersecção de C_OR, o conector (c C _IP C_J C_OR) tem o comportamento de um lugar.

3.7. A regra 4 estabelece que quando o conector c pertence a C_PI (caminho de processo para inf-set) intersecção de C_J (join) intersecção de C_OR, o conector (c C _PI C_J C_OR) corresponde a dois ou mais arcos em redes de Petri.

3.8. A regra 5 estabelece que quando o conector c pertence a C_IP (caminho de inf-set para processo) intersecção de C_S (split) intersecção de C_AND, o conector (c C_IP C_S C_AND) tem o comportamento de uma transição seguida de um número de lugares igual ao número de processos.

3.9. A regra 6 estabelece que quando o conector c pertence a C_IP (caminho de inf-set para processo) intersecção de C_S (split) intersecção de C_AND, o conector (c C _PI C_S C_AND) corresponde a um número de arcos em redes de Petri.

3.10. A regra 7 estabelece que quando o conector c pertence a C_IP (caminho de inf-set para processo) intersecção de C_S (split) intersecção de C_OR, o conector (c C _IP C_S C_OR) corresponde a um número de arcos em redes de Petri.

3.11. A regra 8 estabelece que quando o conector c pertence a C_PI (caminho de processo para inf-set) intersecção de C_S (split) intersecção de C_OR, o conector (c C _PI C_S C_OR) corresponde a um lugar seguido de um número de transições igual ao número de processos de saída do conector.

4. Construir a árvore de alcançabilidade. Por meio da árvore de alcançabilidade é possível verificar vários erros que podem ocorrer na definição de processo, mesmo sem conhecimento específico do processo de negócio. Na ausência de ferramenta de edição de redes de Petri é possível verificar a propriedade soundness por meio da inspeção da árvore de alcançabilidade que corresponde ao MPN-EKD.

5. Depois de fazer o mapeamento em redes de Petri, simular o modelo utilizando uma ferramenta de edição de redes de Petri. Neste trabalho, está sendo utilizado Petri Net Tools. Os seguintes itens devem ser considerados:

5.1. Verificação de possível travamento (deadlock), ou seja, quando não é possível executar nenhuma tarefa.

5.2. Eliminação de casos que ficam em loop infinito (livelock).

5.3. Verificação de possíveis tarefas que não podem ser executadas (deadtask).

5.4. Eliminação de conflitos.

5.5. Verificação de possíveis caminhos.

5.6. Observação da existência de marcas nos outros lugares depois que a condição fim foi completada. Uma vez que a marca aparece no lugar fim, todas as outras marcas devem ter desaparecido.

6. Apresentação de relatório de problemas encontrados.

4. Metodologia do trabalho

4.1. Contexto do modelo de processos de negócio de Pinotti (2004)

No ambiente da delegacia existem dois tipos de funcionários: os que executam funções externas (chamados de "externos") e os que realizam funções internas (chamados de "internos"). Os externos são organizados em equipes de fiscalização e executam tarefas relativas à fiscalização de empresas da região. Os internos trabalham nas diversas unidades administrativas da delegacia e seu trabalho refere-se ao andamento dos processos na secretaria.

Cada funcionário tem direito a 30 dias de férias a cada ano, que podem ser usufruídos num único período ou em dois períodos de 15 dias. Dessa forma, ao final de cada ano, os chefes das unidades devem elaborar uma escala de férias dos funcionários de sua unidade para o ano seguinte. Na elaboração dessa escala, devem-se considerar os cursos eventualmente programados para o ano seguinte e as previsões de licenças que serão tiradas pelos funcionários da unidade. Assim, são elaboradas duas escalas: a de férias e a de licenças.

A escala de férias é formal, sendo que os períodos informados na escala são fixos e existe um procedimento para alterar esses períodos, caso seja necessário. Já a escala de licenças é informal, constituindo-se apenas numa previsão. O funcionário que for tirar licença faz a solicitação no período em que for usufruí-la, ainda que esse período seja diferente daquele informado na escala. Assim, para amenizar os problemas decorrentes de solicitações de licenças, relativos à necessidade de substituição do respectivo funcionário, elabora-se, juntamente com a escala de férias, a escala de licenças para o ano seguinte. Porém, nada impede que o funcionário solicite uma licença, desde que tenha direito a ela, fora do prazo previsto na escala.

Existem funções internas que precisam de substituição, ou seja, quando o funcionário ocupante da função está em férias, ou em licença, ou ausente por qualquer outro motivo, é necessário que outro funcionário o substitua na função. São funções dessa natureza, por exemplo, todas as funções de chefia de unidade e a de delegado. Existem, também, funções que não precisam de substituição. Nesses casos, a unidade fica sem o ocupante para a função enquanto o funcionário está ausente.

O funcionário substituto pode ser tanto interno quanto externo. Porém, na maioria das vezes é externo, pois para substituir um funcionário por outro também interno, outra função (a do funcionário substituto) ficaria desocupada. Dessa forma, todas as substituições nos postos fiscais são feitas por funcionários externos, ou, em alguns casos, por um funcionário interno do próprio posto. Já nas outras unidades, a substituição varia. No Núcleo de Informações, por exemplo, na ausência do chefe, um dos assistentes passa a substituir o chefe e a unidade fica com um funcionário a menos.

O fator substituição deve ser considerado na elaboração das escalas de férias das equipes. É necessário haver funcionários nas equipes para substituir as funções internas, além da necessidade de se manter um número mínimo de funcionários na equipe para o andamento dos trabalhos.

No caso de pedido de alteração de férias, o procedimento é similar ao de elaboração das escalas de férias. Caso seja um funcionário interno, o superior hierárquico é responsável pela aprovação da alteração.

Quando o delegado optar por aprovar as escalas de férias e alterações em algum ano, determina que todas as escalas de férias sejam aglutinadas numa única planilha, que usa para fazer consultas para escolher funcionários substitutos para as funções internas ou para tomar decisões sobre as alterações de férias solicitadas. A cada alteração de férias aprovada, essa planilha deve ser atualizada. Isso gera um problema, pois essas alterações não são atualizadas na planilha imediatamente, pois dependem de serem enviadas ao funcionário responsável por essa tarefa e também da disponibilidade do funcionário. Com isso, frequentemente o delegado não tem informações atualizadas para tomar decisões.

Todo esse processo é regulado anualmente. Assim, no final de cada ano, o delegado emite um memorando circular contendo as instruções para a elaboração das escalas de férias e alterações posteriores para o ano seguinte.

4.2. Modelo de elaboração de escalas

Os modelos foram desenvolvidos seguindo as diretrizes da abordagem EKD. Neste trabalho serão apresentados os modelos de processos de negócio de elaboração de escalas. Na Figura 2 é apresentado o modelo de elaboração de escalas original do trabalho de Pinotti (2004). O modelo da Figura 2 apresenta muitas situações de travamento e por isso foi dividido em dois modelos (Figuras 3 e ⁷) e foram realizadas algumas modificações em cada modelo.

O modelo foi modificado por vários motivos:

• Os processos 1 e 2 não atendem ao requisito que afirma que todo conector do tipo join deve ter a saída igual a 1. Para resolver esse problema, os processos foram agrupados (Figura 2).

• O inf-set escala de férias da unidade tem duas saídas e não atende ao requisito que afirma que a saída do inf-set deve ser igual ou menor que 1.

• O inf-set escala de licenças tem três saídas: processo 3, processo 4 e para o processo 14 (atualizar planilha de ausência), por isso não atende ao requisito que afirma que a saída do inf-set deve ser igual ou menor que 1. Neste caso, foi direcionada ao processo 4 (enviar ao gabinete), e quando a escala estiver aprovada será enviada ao processo 3 e 14.

• O processo 13 está com a saída para inf-set escala de férias que tem mais de uma entrada e cinco saídas, não atendendo aos requisitos de nenhum tipo de conector. Dessa forma, a saída do processo 13 foi direcionada para o inf-set 11 escala de férias enviada (Figura 6).

• O processo 14 tem três entradas, o que contraria o requisito que afirma que a entrada do processo deve ser igual a 1. Esse problema foi resolvido na divisão dos modelos.

• Os processos 12 e 11 foram agrupados porque eles têm duas saídas em comum e uma saída apenas do processo 11, não sendo permitido esse tipo de construção com o conector join e split (Figura 6).

• O processo 11 tinha as duas saídas do processo 12 e mais uma saída que é o inf-set função interna não ocupada. Como os processos 12 e 11 foram agrupados, foi criado um novo processo: analisar se a função interna é ocupada ou não. Esse processo tem dois inf-sets de saída: função interna não ocupada ou função interna ocupada (Figura 6).

• O inf-set substituições planejadas tem duas saídas: processo 2 e 12. Não é permitida essa construção porque esse inf-set conecta-se ao conector AND (que conecta aos processos 1 e 2) e ao processo 12. Na divisão do modelo o inf-set substituições planejadas apenas conecta-se ao processo 12, uma vez que esse inf-set vai sempre causar deadlock porque necessita da execução do processo 3 planejar substituições de funções que será executado depois dos processos 1 e 2.

4.3. Modelo de elaboração de escalas modificado (parte 1)

Para iniciar o processo do modelo da Figura 2 é necessário conhecer a previsão de licenças, o modelo de escalas de férias, a programação de cursos, preferências dos funcionários e as substituições planejadas. Os processos do modelo modificado (parte 1) apresentados na Figura 3 são: alterar as escalas da unidade e da equipe, enviar ao gabinete, analisar escala de férias, refazer escala de férias, arquivar escala de férias no gabinete, enviar escala aprovada à unidade, arquivar escala de férias na unidade, enviar ao departamento de RH e atualizar planilha de ausência. O modelo mapeado em redes de Petri é apresentado na Figura 4.

Os elementos de redes de Petri correspondentes aos elementos do MPN-EKD são apresentados no Quadro 1. Os conectores do modelo de processo de elaboração de escalas e suas respectivas regras de mapeamento são apresentados no Quadro 2.

4.3.1. Resultado do teste

Na Figura 5 é apresentado o modelo simulado na ferramenta Petri Net Tools. A árvore de alcançabilidade é apresentada na Figura 6. A árvore demonstra que o modelo (depois de modificado) é seguro, não tem deadlock, livelock, tem lugar início e fim bem definidos, no final do caso existe apenas uma marca no lugar fim, assim, o modelo é sound.

4.4. Modelo de elaboração de escalas modificado (parte 2)

O modelo de processos de negócio de elaboração de escalas modificado (parte 2) é apresentado na ^{Figura 7}. Para iniciar é necessário ter a escala de férias original, relação de aposentadorias e ausências, pedidos e necessidade de alteração de férias.

Os processos do modelo modificado (parte 2) apresentado na ^{Figura 7} são: planejar substituições de funções internas, analisar se a função interna é ocupada, analisar pedido/necessidade de alteração de equipe e função interna, enviar ao departamento de RH e atualizar planilha de ausência.

O modelo de processos de negócio mapeado em redes de Petri é apresentado na Figura 8. Os elementos de redes de Petri correspondentes aos elementos do MPN-EKD são apresentados no Quadro 3. Os conectores do modelo de processo de elaboração de escalas modificado (parte 2) e suas respectivas regras de mapeamento são apresentados no Quadro 4.

4.4.1. Resultado do teste

Na Figura 9 é apresentado o modelo na ferramenta Petri Net Tools. A simulação não foi possível de ser realizada por causa do deadlock na Pr3. O Pr3 só poderá ser executado quando houver marca no IS17. Para que o processo planejar substituições de funções internas seja realizado é necessário conhecer se a função interna não é ocupada. A árvore de alcançabilidade é apresentada na figura 10 e demonstra que existe um deadlock. O modelo não é sound. Os erros encontrados no modelo estão relacionados com o planejamento e ordem de execução das atividades da organização.

5. Discussão

Uma visão integrada da organização tem implicações práticas no trabalho de modelagem, análise e projeto de processos de negócio (GOLDKUHL; LIND, 2008). De acordo com as orientações de Van der Aalst, Weske e Wirtz (2003), antes de fazer uma análise detalhada do processo, a análise dos processos macros deve ser realizada para saber quais processos são ligados ou alinhados para especificar estratégias organizacionais para atingir os objetivos do negócio. Nesse sentido, esses modelos foram desenvolvidos seguindo a abordagem EKD. O primeiro passo do método é desenvolver o modelo de objetivos, buscando identificar oportunidades e pontos fracos.

Seguindo a abordagem EKD e na mesma linha de Kock et al. (2009), a qualidade percebida de um modelo é definida como o nível em que o modelo apresenta as seguintes características: facilidade de geração e entendimento, completude e precisão. Embora o modelo seja relativamente grande, para as pessoas envolvidas no processo é de simples entendimento.

O processo de desenvolvimento dos modelos não foi apresentado por estar fora do escopo do artigo. É relevante salientar que a qualidade do modelo de processos de negócio está relacionada ao fato de o modelo de processos de negócio ter sido desenvolvido com base em diretrizes que apoiam o desenvolvimento de todos os modelos e ainda oferece um conjunto de questões para apoio na verificação das ligações entre componentes de todos os modelos. A abordagem busca identificar as melhores práticas do negócio, o gerenciamento de mudanças e de regras de negócio.

Nos trabalhos de Mold e Valk (2000), Oberweis (1996), Oberweis et al. (1997), Salimifard e Wright (2001), Van der Aalst (1999), Van der Aalst e Hee (2002), Van der Aalst e Hofstede (2000) e Voorhoeve (2000), os processos de negócio são modelados diretamente em redes de Petri.

Nos modelos apresentados neste trabalho, a construção do modelo de processos de negócio seguiu a abordagem EKD e não diretamente em redes de Petri. Dessa forma, os envolvidos no processo de desenvolvimento do modelo tiverem a oportunidade de avaliar os objetivos do negócio, os pontos fracos, as oportunidades, as regras do negócio para depois desenvolver um modelo de processos de negócio. Pode-se observar um diferencial importante na aplicação do método de avaliação do modelo de processos de negócio em relação aos trabalhos que modelam diretamente em redes de Petri. De acordo com Wynn et al. (2009), muitas abordagens realizam checagem básica da sintática e permitem que o modelo de processos de negócio tenha travamentos e outros problemas que afetam a qualidade do modelo.

A simulação funcionou como uma ferramenta de diagnóstico para identificação de rotas causadoras de problemas e ineficiências no ambiente no negócio, assim como no trabalho de Siha e Saad (2008).

Verifica-se que por meio da simulação do modelo é possível testar e analisar por diferentes cenários para entender seu impacto nos limites ou fronteiras do sistema e avaliar o retorno antes de realizar mudanças ou planejar a implementação da transformação dos processos de negócio, na mesma linha do trabalho de Doomun e Jungum (2008).

Foi possível verificar processos reais que, de acordo com Wynn et al. (2009), são a grande deficiência das abordagens encontradas na literatura que não verificam processos reais porque assumem modelos altamente simplificados e totalmente desconectados da linguagem organizacional.

O fato de algumas construções não serem permitidas pode ser considerado uma desvantagem da formalização do MPN-EKD. Porém, durante o processo de modelagem essas construções devem ser analisadas cuidadosamente, sendo importante o discernimento da equipe ou pessoa que está modelando para que o modelo seja desenvolvido de acordo com as definições apresentadas em Pádua e Inamasu (2008b).

6. Considerações finais

A revisão da literatura mostrou que a busca por soluções mais eficazes levou as empresas a rever sua estrutura organizacional, não arquitetando-as sobre atividades em torno de suas áreas funcionais, mas na perspectiva de processos de negócio da organização. Assim surgiu a proposta de reengenharia de processos de negócio que envolve mudanças nas pessoas, processos e tecnologia.

Também foi mostrado que a análise de processo é reconhecida como importante estágio na transformação dos processos. O modelo de processos de negócio permite melhorias, como o benchmarking, a reengenharia de processos de negócio, monitoramento e melhoria contínua de processos.

Foi destacado que o principal problema das abordagens de modelagem organizacional, incluindo-se o EKD, é a ausência de técnicas de análise objetivas. As técnicas de análise com rigor matemático não são usuais para profissionais da área de negócio. Constatou-se que as redes de Petri resolvem esse problema, uma vez que possuem representação gráfica, são de fácil aprendizado, funcionam como linguagem de comunicação entre especialistas de diversas áreas, permitem a descrição dos aspectos estáticos e dinâmicos do sistema a ser representado, e ainda possuem o formalismo matemático que possibilita a utilização de importantes métodos de análise.

Pesquisas anteriores mostraram que ambiguidades e confusões não podem ser prevenidas em um modelo de processos de negócio informal. Para resolver esse problema foi aplicado o método de avaliação do modelo de processos de negócio que permitiu verificar a presença de deadlock (travamento), no qual o processo nunca poderá ser realizado. Além disso, não existe uma condição fim clara e, dessa forma, o modelo não é sound.

Com base nesses problemas, pode-se afirmar que o cuidado no processo de modelagem é fundamental para que o modelo represente fielmente como o processo é realizado e que esses problemas são minimizados quando o modelo é desenvolvido de acordo com o método de avaliação do modelo de processos de negócio do EKD.

Foi apresentado que diversos autores afirmam que a grande conveniência no uso de redes de Petri na modelagem de processos de negócios é a possibilidade de um rastreamento minucioso e não ambíguo de cada etapa da operação.

Nos modelos apresentados neste trabalho, a construção do modelo de processos de negócio seguiu o método de modelagem EKD e não diretamente em redes de Petri. Dessa forma, os envolvidos no processo de desenvolvimento do modelo tiveram a oportunidade de avaliar os objetivos do negócio, os pontos fracos, as oportunidades, as regras do negócio para depois desenvolver um modelo de processos de negócio.

A simulação funcionou como uma ferramenta de diagnóstico para identificação de rotas causadoras de problemas e ineficiências no ambiente do negócio. Por meio da simulação do modelo é possível testar e analisar por diferentes cenários para entender seu impacto nos limites ou fronteiras do sistema e avaliar o retorno antes de realizar mudanças ou planejar a implementação da transformação dos processos de negócio. Dessa forma, é possível que esse modelo seja base para uma gestão por processos.

Assim, a pergunta da pesquisa foi respondida. Nesse exemplo, foi possível identificar como garantir que o modelo de processos de negócio seja desenvolvido com base nos objetivos organizacionais, seja de fácil entendimento por todas as pessoas envolvidas e esteja correto, livre de travamentos, para que seja base para uma gestão por processos. A limitação do trabalho é que como o exemplo utilizado foi pautado em dados secundários, não foi realizado um acompanhamento com métricas para verificar benefícios mensuráveis no ambiente real.

Foi possível verificar processos reais que, de acordo com a pesquisa realizada, são a grande deficiência das abordagens encontradas na literatura que não verificam processos reais porque assumem modelos altamente simplificados e totalmente desconectados da linguagem organizacional.

Como trabalho futuro, sugere-se a construção de uma ferramenta computacional que apoie todos os passos do método de forma bastante intuitiva e simples.

Recebido 26/08/2009; Aceito 22/03/2011

• ASSOCIATION OF BUSINESS PROCESS MANAGEMENT PROFESSIONALS - ABPMP. Guia para o gerenciamento de processos de negócio: corpo comum de conhecimento (BPM CBOK) versão 2.0 - primeira liberação em português. Chicago: Association of Business Process Management Professionals, 2009.
• BERETTA, S. Unleashing the integrationn potential of ERP system. Business Process Management Journal, v. 8, n. 3, p. 254-277, 2002. http://dx.doi.org/10.1108/14637150210428961
• BUBENKO JUNIOR, J. A.; STIRNA, J.; BRASH, D. EKD user guide. Kista: Department of Computer and Systems Sciences, 1998.
• DAVENPORT, T. H. Process inovation. Boston: Harvard Business School Press, 1993.
• DOOMUN, R.; JUNGUM, N. V. Business process modeling, simulation and reengineering: call centres. Business Process Management Journal, v. 14, n. 6, p. 838-848, 2008.
• GOLDKUHL, G.; LIND, M. Coordination and transformation in business processes: towards an integrated view. Business Process Management Journal, v. 14, n. 6, p. 761-777, 2008.
• GREGORIADES, A.; SUTCLIFFE, A. A socio-technical approach to business process simulation. Decision Support Systems, v. 45, n. 4, p. 1017-1030, 2008. http://dx.doi.org/10.1016/j. dss.2008.04.003
• GUAN, F. et al. Grid-flow: a grid-enabled scientific workflow system with a Petri-net-based interface. Concurrency and Computation: Practice and Experience, Chichester, v. 18, n. 10, p. 1115-1140, 2006. http://dx.doi.org/10.1002/cpe.988
• HAMMER, M.; CHAMPY, J. Reengenharia revolucionando a empresa. 15. ed. Rio de Janeiro: Campus, 1994.
• HAN, K. H.; KANG, J. G.; SONG, M. Two-stage process analysis using the process-based performance measurement framework and business process simulation. Expert Systems with Applications, v. 36, n. 3, pt. 2, p. 7080-7086, 2009.
• KAVAKLI, E. et al. Incorporating privacy requirements into the system design process: the PriS conceptual framework. Internet Research, v. 16, n. 2, p. 140-158, 2006.
• KIRIKOVA, M. Explanatory capability of enterprise models. Data & Knowledge Engineering, v. 33, n. 2, p. 119-136, 2000. http://dx.doi.org/10.1016/S0169-023X(99)00048-8
• KOCK, N. et al. Communication flow orientation in business process modeling and its effect on redesign success: results from a field study. Decision Support Systems, v. 46, n. 2, p. 562, 2009. http://dx.doi.org/10.1016/j.dss.2008.10.002
• LIN, H.; FAN, Y.; NEWMAN, S. T. Manufacturing process analysis with support of workflow modeling and simulation. International Journal of Production Research, v. 47, n. 7, p. 1773, 2009. http://dx.doi.org/10.1080/00207540701644151
• MAXIMIANO, A. introdução à administração 2. ed. São Paulo: Atlas, 1986.
• McCORMACK, K. et al. A global investigation of key turning points in business process maturity. Business Process Management Journal, v. 15, n. 5, p. 792-815, 2009. http://dx.doi.org/10.1108/14637150910987946
• MOLD, D.; VALK, R. Object oriented petri net in business process modeling. In: AALST, V. D. W.; DESEL, J.; OBERWEIS, A. Business process management: models, techniques, and empirical studies. Berlin: Springer, 2000. p. 254-273. (Lectures Notes in Computer Sciences, 1806).
• MUEHLEN, M. Z.; INDULSKA, M. Modeling languages for business processes and business rules: A representational analysis. Information Systems, v. 35, p. 379-390, 2009. http://dx.doi.org/10.1016/j.is.2009.02.006
• NEUBAUER, T. An empirical study about the status of business process management. Business Process Management Journal, v. 15, n. 2, p. 166-183, 2009.
• NURCAN, A.; ROLLAND, C. A multi-method for defining the organizational change. Journal of Information and Software Technology, v. 45, n. 2, p. 61-82, 2003. http://dx.doi.org/10.1016/S0950-5849(02)00162-3
• OBERWEIS, A. An integrated approach for the specification of processes and related complex structured objects in business applications. Decision Support Systems, v. 17, n. 1, p. 31-53, 1996. http://dx.doi.org/10.1016/0167-9236(95)00021-6
• OBERWEIS, A. et al. INCOME/WF: a petri-net based aproach to workflow Management. In: KRALLMANN, H. (Ed.). Wirtschaftsinformatik'97. Berlin: Springer-Verlag, 1997. p. 557-580.
• OU-YANG, C.; LIN Y. D. BPMN-based business process model feasibility analysis: a petri net approach. International Journal of Production Research, v. 46, n. 4, p. 3763-3781, 2008. http://dx.doi.org/10.1080/00207540701199677
• PÁDUA, S. I. D. Método de avaliação do modelo de processos de negócios. 2004. 252 f. Tese (Doutorado em Engenharia Mecânica)- Escola de Engenharia de São Carlos, Universidade de São Paulo, São Carlos, 2004.
• PÁDUA, S. I. D.; CAZARINI, E. W.; INAMASU, R. Y. Modelagem organizacional: captura dos requisitos organizacionais no desenvolvimento de sistemas de informação. Gestão e Produção, v. 11, n. 2, p. 197-209, 2004.
• PÁDUA, S. I. D. et al. O potencial das redes de Petri em modelagem e análise de processos de negócios. Gestão e Produção, v. 11, n. 1, p. 109-119, 2004.
• PÁDUA, S. I. D.; INAMASU, R. Y. O método de avaliação do modelo de processos de negócio do EKD. Gestão e Produção, v. 15, n. 4, p. 563-578, 2008a.
• PÁDUA, S. I. D.; INAMASU, R. Y. Mapeamento do modelo de processos de negócio do EKD em redes de Petri. Produção, v. 18, n. 2, p. 260-274, 2008b.
• PINOTTI, M. M. Diretrizes para guiar o processo de engenharia de requisitos a partir de modelos organizacionais desenvolvidos em EKD. 2004. 97 f. Dissertação (Mestrado em Ciência da Computação e Matemática Computacional)-Instituto de Ciências Matemáticas e Computação, Universidade de São Paulo, São Carlos, 2004.
• PINTO, R. L. Evolução da estrutura organizacional ao longo do ciclo de vida do projeto: um estudo de caso. 2002. 170 f. Tese (Doutorado em Administração)-Faculdade de Economia, Administração e Contabilidade, Universidade de São Paulo, São Paulo, 2002.
• RADHAKRISHNAN, A.; ZUB, X.; GROVERC, V. A process-oriented perspective on differential business value creation by information technology: an empirical investigation. International Journal of Management Science, v. 36, n. 6, p. 1105-1125, 2008.
• ROLLAND, C.; NURCAN, S.; GROSZ, G. A Decision making pattern for guiding the enterprise knowledge development process. Journal of Information and Software Technology, v. 42, n. 5, p. 313-331, 2000. http://dx.doi.org/10.1016/S0950-5849(99)00089-0
• SALIMIFARD, S.; WRIGHT M. Petri net based modelling of workflow systems: an overview. European Journal of Operational Research, v. 134, n. 3, p. 664-676, 2001. http://dx.doi.org/10.1016/S0377-2217(00)00292-7
• SIHA, S. M. H.; SAAD, G. H. Business process improvement: empirical assessment and extensions. Business Process Management Journal, v. 14, n. 6, p. 778-802, 2008. http://dx.doi.org/10.1108/14637150810915973
• VAN DER AALST, W. M. P. Formalization and verification of event-driven process chains. Information and Software Technology, v. 41, n. 10, p. 639-650, 1999. http://dx.doi. org/10.1016/S0950-5849(99)00016-6
• VAN DER AALST, W. M. P.; HEE, V. K. Workflow management: models, methods and systems. Cambridge: MIT Press, 2002.
• VAN DER AALST, W. M. P.; HOFSTEDE, A. H. M. T. Verification of workflow task structures a petri-net-based approach. Information Systems, v. 25, n. 1, p. 43-69, 2000. http://dx.doi.org/10.1016/S0306-4379(00)00008-9
• VAN DER AALST, W. M. P.; WESKE, M.; WIRTZ, G. Advanced topics in workflow management: issues, requirements, and solutions. Journal of Integrated Design and Process Science, v. 7, n. 3, p. 49-77, 2003.
• VERBEEK H. M. W.; VAN DER AALST, W. M. P.; HOFSTEDE, A. H. M. Verifying workflows with cancellation regions and OR-joins: an approach based on relaxed soundness and invariants. The Computer Journal Advance, v. 50, n. 3, p. 294-314, 2007.
• VOORHOEVE, M. Compositional modeling and verification of workflow process. In: AALST, V. D. W.; DESEL, J.; OBERWEIS, A. Business process management: models, techniques, and empirical studies. Berlin: Springer, 2000. p. 184-200. (Lectures Notes in Computer Sciences, 1806).
• WORKFLOW management coliation: reference model. Hampshire, 1996. (Document Number WFMC-TC00-1003).
• WYNN, M. T. et al. Business process verification: finally a reality! Business Process Management Journal, Bingley, v. 15, n. 1, p. 74-92, 2009.
• ZHANG, L.; SHUZHEN, Y. Research on workflow patterns based on Petri nets. In: IEEE CONFERENCE ON CYBERNETICS & INTELLIGENT SYSTEMS (CIS) ROBOTICS, AUTOMATION AND MECHATRONICS (RAM), 2006, Bangkok. Proceedings... Bangkok: IEEE Computer Society, 2006. p. 1-6.

*

USP, Ribeirão Preto, SP, Brasil

Datas de Publicação

• Publicação nesta coleção
  14 Out 2011
• Data do Fascículo
  2012

Histórico

• Recebido
  26 Ago 2009
• Aceito
  22 Mar 2011