Análise da implementação de um sistema de Workflow a...
88
Análise da implementação de um sistema de Workflow a partir de um sistema de BPMS: Estudo de caso de uma empresa de gestão de estoque Vitor Andreolli Pestana de Araújo Projeto de Graduação apresentado ao Curso de Engenharia de Produção da Escola Politécnica, Universidade Federal do Rio de Janeiro, como parte dos requisitos necessários à obtenção do título de Engenheiro. Orientador: Renato Flórido Cameira Rio de Janeiro Agosto de 2019
Transcript of Análise da implementação de um sistema de Workflow a...
i
Análise da implementação de um sistema de Workflow a partir de um sistema de
BPMS: Estudo de caso de uma empresa de gestão de estoque
Vitor Andreolli Pestana de Araújo
Projeto de Graduação apresentado ao Curso
de Engenharia de Produção da Escola
Politécnica, Universidade Federal do Rio de
Janeiro, como parte dos requisitos
necessários à obtenção do título de
Engenheiro.
Orientador: Renato Flórido Cameira
Rio de Janeiro
Agosto de 2019
iii
Araújo, Vitor Andreolli Pestana de
Análise da implementação de um sistema de Workflow a partir de
um sistema de BPMS: estudo de caso de uma empresa de gestão
de estoque /Vitor Andreolli Pestana de Araújo. – Rio de Janeiro:
UFRJ/ Escola Politécnica, 2019.
X, 82 p.: il.; 29,7 cm.
Orientador: Renato Flórido Cameira
Projeto de Graduação – UFRJ/ Escola Politécnica/ Curso de
Engenharia de Produção, 2019.
Referências Bibliográficas: p 80-82. ..
1.Workflow. 2. Sistema de Gestão
I. Cameira, Renato Flórido II. Universidade Federal do Rio de
Janeiro, Escola Politécnica, Curso de Engenharia de Produção.
III. Análise da implementação de um sistema de Workflow a partir
de um sistema de BPMS: Estudo de caso de uma empresa de
gestão de estoque
iv
Agradecimentos
Primeiramente a minha mãe, por todo o apoio e confiança depositada em mim. Agradeço
por acreditar em mim em todos os momentos e por toda a força e estrutura que você me
proporcionou em todas as fases da minha vida. Sem você não seria metade de quem sou
hoje. Obrigado por tudo.
À minha família e amigos por todo o apoio e carinho proporcionados.
Agradeço ao meu orientador Renato Flórido Cameira pelos ensinamentos, não somente
com o desenvolvimento deste trabalho, mas com todas as lições aprendidas de suas aulas.
Obrigado por todo o apoio, críticas e orientação ao longo dos anos.
v
Resumo do Projeto de Graduação apresentado à Escola Politécnica/ UFRJ como parte
dos requisitos necessários para a obtenção do grau de Engenheiro de Produção.
Análise da implementação de um sistema de Workflow a partir de um sistema de
BPMS: Estudo de caso de uma empresa de gestão de estoque
Vitor Andreolli Pestana de Araújo
Agosto de 2019
Orientador: Renato Flórido Cameira
Curso: Engenharia de Produção
O avanço da tecnologia tem permitindo as empresas a utilização de softwares cada vez
mais eficientes e robustos. Neste sentido, utilizar-se destes recursos para melhoria dos
processos alinhado a estratégia e planejamento da empresa pode significar a diferença
necessária para o avanço que a organização necessite. Novas tecnologias funcionam de
forma a reduzir o esforço para o andamento de um processo, garantir um controle
adequado das operações e prover maior alcance do entendimento do processo para a
tomada de decisão. Este trabalho tem como objetivo a análise da implementação de um
sistema de Workflow no fluxo de suprimentos de uma empresa de gestão de estoques,
utilizando um sistema de BPMS. Foi avaliado a construção do processo de suprimentos,
sua parametrização, suas regras vigentes, limitações da ferramenta, dificuldades
encontradas e construção de próximos passos.
Palavras-chave: Workflow, Sistema de Gestão, Processos
vi
Abstract of Undergraduate Project presented to POLI/UFRJ as a partial fulfilment of
the requirements for the degree of Industrial Engineer.
Analysis of the implementation of a workflow system from a BPMS system
Vitor Andreolli Pestana de Araújo
August 2019
Advisor: Renato Flórido Cameira
Course: Industrial Engineering
Advances in technology have been embraced by increasingly fast and robust software
companies. The use of resources for improvement of processes for a strategy and planning
of company mean the difference needed for the advancement that an organization needs.
New technologies work to reduce the effort to go through a process, ensure proper control
of operations, and provide greater understanding of the process for decision making. This
work aims to implement a workflow system using a process management system from a
BPMS system. Was evaluated the construction of the supply process, their
parameterization, their current rules, tool limitations, difficulties encountered and
construction of next steps.
Keywords: Workflow, System Management, Supply
1
SUMÁRIO
1 INTRODUÇÃO ........................................................................................................... 4
1.1 Resumo ................................................................................................................. 4
1.2 Objetivos ............................................................................................................... 4
1.3 Metodologia de Pesquisa ......................................................................................... 5
1.4 Limitação .............................................................................................................. 5
1.5 Delimitação ........................................................................................................... 5
2 REVISÃO BIBLIOGRÁFICA ....................................................................................... 7
2.1 Definição de processo ............................................................................................. 7
2.2 Tipos de processo ................................................................................................... 7
2.3 Business Process Management (BPM) ...................................................................... 8
2.4 Modelagem de Processo .......................................................................................... 8
2.4.1 Business Process Model and Notation (BPMN) .................................................... 9
2.4.2 Fluxograma ................................................................................................... 10
2.4.3 Event driven Process Chain (EPC) ................................................................... 11
2.5 Negócios e Tecnologia da Informação ..................................................................... 11
2.5.1 Business Process Management System (BPMS) ................................................. 12
2.5.2 Arquitetura Integrada de Processos (AIS) .......................................................... 13
2.5.3 Arquitetura Orientada a Serviços (SOA/EAI) ..................................................... 15
2.5.4 Sistema Integrado de Gestão (SIG) ................................................................... 16
2.6 Workflow ............................................................................................................. 18
2.6.1 Classificação de sistemas ................................................................................ 19
2.6.2 Arquitetura de um sistema de Workflow ............................................................ 21
3 ESTUDO DE CASO ................................................................................................... 24
3.1 Apresentação das empresas .................................................................................... 24
3.1.1 Análise das necessidades ................................................................................. 24
3.1.2 Substituição dos softwares ............................................................................... 25
3.1.3 Viabilidade financeira e economia esperada ....................................................... 25
3.1.4 O Software SoftExpert .................................................................................... 27
3.1.5 Relacionar o software a partir da pesquisa bibliográfica ...................................... 28
3.1.6 Notação e funcionalidades da ferramenta........................................................... 29
3.1.7 Parametrização do Processo ............................................................................. 32
3.1.8 Parametrização das Atividades ......................................................................... 34
3.2 Planejamento e Levantamento de Informação .......................................................... 36
2
3.2.1 Construção dos Formulários ............................................................................ 39
3.2.2 Construção do Workflow ................................................................................. 41
3.3 Requisição de Compra .......................................................................................... 42
3.3.1 Solicitação de Compra .................................................................................... 46
3.3.2 Alçada de Aprovação da Solicitação de Compra................................................. 46
3.3.3 Categorização ................................................................................................ 48
3.3.4 Seleção de Fornecedor .................................................................................... 51
3.3.5 Subprocesso .................................................................................................. 52
3.3.6 Seleção de Itens Aprovados ............................................................................. 52
3.3.7 Aprovação de Alçada da Requisição de Compra................................................. 53
3.3.8 Criação do Pedido de Compras ........................................................................ 53
3.3.9 Alçada do Pedido de Compra ........................................................................... 54
3.3.10 Cadastro no Alterdata: Fornecedor e/ou Item................................................... 55
3.4.1 Cotação de Materiais e Serviços ....................................................................... 58
3.4.2 Avaliação da Documentação ............................................................................ 59
3.4.3 Avaliação de Documentos ............................................................................... 60
3.4.4 Negociação .................................................................................................... 61
3.4.5 Aprovação da Negociação pelo Fornecedor ....................................................... 62
3.4.6 Escolha do Fornecedor .................................................................................... 62
3.4.7 Avaliação do Fornecedor ................................................................................. 63
3.4.8 Aprovação da Diretoria ................................................................................... 63
3.5 Recebimento de Material ou Serviço (1° Tipo) - Subprocesso .................................... 63
3.5.1 Inclusão do Pedido de Compra ......................................................................... 66
3.5.2 Checklist de Recebimento ............................................................................... 66
3.5.3 Aprovação do Recebimento ............................................................................. 67
3.5.4 Tratativa da Nota Fiscal .................................................................................. 67
3.5.5 Programação de Pagamento ............................................................................. 67
3.6 Recebimento de Material ou Serviço (2° Tipo) ......................................................... 67
3.6.1 Inclusão do Pedido de Compras ....................................................................... 69
3.6.2 Aprovação de Recebimento ............................................................................. 69
3.6.3 Tratativa da Nota Fiscal e Programação de Pagamento ........................................ 70
3.7 Dificuldades e Problemas encontrados .................................................................... 70
3.7.1 Utilização do fornecedor como agente ativo da ferramenta .................................. 70
3.7.2 Cadastro do fornecedor como usuário no sistema ............................................... 73
3.7.3 Implantação, Manutenção e Utilização .............................................................. 74
4 CONCLUSÃO ........................................................................................................... 76
3
5 Referências Bibliográficas ........................................................................................... 80
4
1 INTRODUÇÃO
1.1 Resumo
Este trabalho analisou a implementação de um sistema de BPMS utilizado para
automatizar tarefas e atividades a partir dos recursos de Workflow do sistema. O estudo
foi realizado a partir das funcionalidades disponíveis da ferramenta, as melhorias
pretendidas com sua utilização e as dificuldades encontradas pela equipe envolvida no
projeto. No tópico um foi apresentado os objetivos pretendidos deste trabalho, sua
metodologia, limites e delimitações. No segundo tópico foram abordados os conceitos
teóricos utilizados para referência e associação a implementação realizada. No terceiro
tópico foi apresentado as funcionalidades do software, bem como os detalhes da
construção do Workflow para o fluxo de suprimentos, com suas regras e parametrizações.
Além disso contém os pontos de maior dificuldade levantados pela equipe. No tópico
quatro foi definido sua conclusão, de forma a apresentar a avaliação inicial dos líderes no
período pós implementação e foi apresentado as possíveis ações a serem tomadas como
etapas seguintes.
1.2 Objetivos
As atividades internas de suporte de uma organização, apoiam diretamente ou
indiretamente no planejamento e tomada de decisão de uma organização, servindo como
base para suas atividades principais. A maneira como a estrutura dos processos internos
de uma empresa é definida, reflete diretamente seu potencial de entrega de resultados,
podendo impactar nos tempos do processo, na qualidade das entregas além dos custos
necessários para manter a operação.
O objetivo desse trabalho é o de analisar a implementação de um software de gestão, cuja
finalidade é o de organizar o fluxo das atividades das áreas de Suprimentos, Financeiro,
Tecnologia da Informação, Qualidade e Segurança, de forma a implementar um sistema
de workflow dentro das atividades da empresa para atingir uma melhor coordenação e
sequenciamento das atividades, reduzindo retrabalho e gerando maior controle de cada
etapa do processo.
5
1.3 Metodologia de Pesquisa
O trabalho apresentado foi elaborado no formato de um estudo de caso a partir das
informações adquiridas na implementação de um sistema de workflow em uma empresa
de gestão de estoques. De forma a gerar embasamento para tais aplicações da ferramenta,
foi realizado a pesquisa bibliográfica, para definição dos conceitos utilizados.
Segundo Gil (2002), podemos definir pesquisa bibliográfica como sendo desenvolvida a
partir da utilização mediante fontes bibliográficas, ou seja, que possuem material
elaborado, principalmente a partir de publicações periódicas, livros de referência e artigos
científicos. O mesmo, comenta ainda sobre as vantagens dessa abordagem, de forma a
garantir ao pesquisador maior alcance aos fenômenos possíveis do que os que poderiam
ser encontrados do que os realizados em uma pesquisa direta.
Um estudo de caso, segundo Yin (2001), pode ser definido como uma abordagem de
investigação de um fenômeno ou evento contemporâneo em seu contexto aplicado na
prática. Além disso, o estudo de caso pode ser utilizado para aplicações de projetos para
coleta de dados, de forma a registrar casos únicos ou múltiplos, servindo para futuras
avaliações, de modo a garantir uma perspectiva do mercado em geral.
1.4 Limitação
As limitações definidas ocorrem devido aos prazos de entrega deste trabalho coincidirem
com o término da implementação da ferramenta. Dessa forma a parte referente ao estudo
de caso fica limitada a avaliação da implantação do sistema, de forma a não abranger
avaliações de eficácia após a implementação se restringindo em prever os impactos e as
possíveis melhorias a médio e longo prazo.
1.5 Delimitação
A análise do caso ficará restrita às atividades de suporte da empresa, com destaque para
o Fluxo de Suprimentos o qual teve seu planejamento e construção descritos no estudo de
caso.
Dentre os limites estabelecidos para esse trabalho destaca-se que a avaliação do projeto
ficou restrita a fase de implementação do sistema e construção dos processos, não sendo
abordado temas como os critérios para a escolha do software. Isso ocorre pois foi nessa
6
etapa que o autor foi incluído para o projeto e não acompanhou as etapas anteriores, se
limitando a apresentação da economia esperada pela empresa, sem se aprofundar nos
métodos utilizados para tais resultados. Além disso não serão apresentadas as linhas de
código desenvolvidas como regras das atividades e formulários, se restringindo a
apresentação de seu objetivo e caminhos. De forma a entender os conceitos e
funcionamento das tecnologias envolvidas em torno do BPMS e Workflow, na parte de
referência bibliográfica foi abordado pelo autor temas que tangenciam seu
funcionamento, como a arquitetura integrada de sistemas, arquitetura orientada a serviços,
notação de fluxograma, Event driven Process Chain e os sistemas integrados de gestão,
de forma que estes não irão possuir relação aplicada diretamente no estudo de caso,
servindo apenas para contextualizar os demais temas.
7
2 REVISÃO BIBLIOGRÁFICA
2.1 Definição de processo
A tecnologia atrelada a informação, hoje é tido como base de qualquer planejamento
estratégico e das decisões tomadas pelas empresas. O sucesso dessas escolhas tem um
impacto significativo na maneira como essas tecnologias são aplicadas, controladas e
medidas dentro de uma organização. Para iniciar o aprofundamento sobre o tema, é
preciso identificar e esclarecer o significado de processo.
Segundo ABPMP (2013, p 35), a definição de processo é “uma agregação de atividades
e comportamentos executados por humanos ou máquinas para alcançar um ou mais
resultados.”
Segundo, Davenport (1992, p 5), um processo é “uma ordenação específica das atividades
de trabalho ao longo do tempo e do local, com um começo, um fim e entradas e saídas
claramente identificadas.”
2.2 Tipos de processo
A definição do tipo de processo, auxilia no entendimento da gestão e controle das
atividades exercidas na empresa e no modo como são conduzidas. Diversos autores,
utilizam-se dessas definições, com diferentes nomes, mas com significados similares.
Segundo ABPMP(2013) temos essencialmente três modelos:
• Processo primário: São os processos que proporcionam experiência ao cliente, de
forma a gerar valor. São tidos como primários pois representam as atividades
essenciais que a empresa ou organização executa de forma a cumprir seu objetivo
perante o mercado. São processos que podem ser executados por mais de um setor
ou função, podendo até mesmo fluir entre organizações. Deve-se destacar que se
restringem a essa definição as atividades que imediatamente influenciam e
impactam na geração de valor. Atividade que impactam não de forma imediata
devem ser caracterizadas dentro dos outros tipos.
• Processo de Suporte: São caracterizados por servir como base e auxílio aos outros
processos, não se limitando aos processos primários, podendo servir de apoio de
outros processos de suporte ou gerenciamento. Tem a capacidade de geração de
valor, mas não de forma direta ao cliente e sim a outros processos.
8
• Processo de Gerenciamento: Segundo ABPMP(2013, p 37),
tem o propósito de medir, monitorar, controlar atividades e
administrar o presente e ao futuro do negócio. Processos de
gerenciamento, assim como os processos de suporte, não agregam
valor diretamente para os clientes, mas são necessários para
assegurar que a organização opere de acordo com seus objetivos
e metas de desempenho. podem estar associados a áreas
funcionais ou serem interfuncionais.
2.3 Business Process Management (BPM)
A necessidade de uma abordagem estratégica perante o mercado, não garante somente a
sobrevivência e sucesso de uma empresa. O modo como como tais ações são adotadas
dentro da organização e o comprometimento dos responsáveis por aderir e adequar seus
processos e métricas a tal escolha, são peças fundamentais para atingir os resultados
esperados. Nesse cenário, surge os papéis de analistas e arquitetos de processos, de forma
avaliar a organização não como diversos cenários funcionais diferentes com métricas
separadas, mas como um único sistema complexo e dinâmico. É nessas condições que
surge o Business Process Management (BPM). Não há um consenso, pelos autores, sobre
a definição exata de BPM, porém foi utilizado o conceito segundo ABPMP (2013) de
considerar BPM como um modelo de disciplina gerencial de modo a adaptar as condições
da empresa ao objetivo definido por meio do gerenciamento de processos.
Além disso ABPMP (2013, p 40) define que,
BPM engloba estratégias, objetivos, cultura, estrutura
organizacional, papéis, políticas, métodos e tecnologias para
analisar, implementar, gerenciar desempenho, transformar e
estabelecer a governança dos processos.
2.4 Modelagem de Processo
Segundo Eriksson e Penker (2000), O desenho e modelagem dos processos de negócio é
uma abstração simplificada da estrutura do processo que facilita a comunicação entre
stakeholders, descreve as atividades dentro da organização e como elas se relacionam e
interagem com os recursos do negócio, visando alcançar o objetivo do processo.
Nesse sentido, a modelagem é parte fundamental para a estruturação da integração entre
os recursos da empresa. Pode ser entendida como a criação de uma simulação
simplificada de ponta a ponta do funcionamento do processo. A partir dele, pode-se
utilizar essas informações para organização, instrução, previsão, controle, comprovação,
explicação ou correção.
9
Por conta de sua importância dentro das organizações, a adoção de uma simbologia
padrão e regras para sua modelagem é requerida para facilitar a construção e
entendimento do processo, sendo chamados de notações de modelagem. Tais notações
são representações gráficas de um conjunto pré-determinado de ícones e princípios no
levantamento do fluxo. Cada ícone possui seu significado e auxilia a construção do
modelo de forma a facilitar a comunicação e entendimento comum do processo.
É importante ressaltar que a modelagem de processos tenta reproduzir o cenário proposto
para uma atividade, porém, tratam-se de modelos representativos e por conta disso estão
sujeitas a eventos externos que podem não ser mapeados ou controlados.
2.4.1 Business Process Model and Notation (BPMN)
Segundo Stephen A. White(2004), o objetivo do BPMN é fornecer um conjunto de ícones
que possam ser reconhecidos facilmente por todos os usuários envolvidos na utilização
do mapeamento como os analistas que irão desenhar o processo e os técnicos responsáveis
pela utilização desse modelos para implementação de tecnologias de execução de
atividades. A notação de BPMN visa abordar tanto a facilidade para a criação de modelos
através de recursos simples de visualização quanto conseguir atingir aos casos mais
difíceis, intrínsecos do processo de modelagem. A utilização de tais recursos é
demonstrada na Figura 1, onde é apresentado um modelo genérico de modelagem do
fluxo
Figura 1 - Modelo representativo de modelagem BPMN Fonte: ABPMP (2013, p 81)
Para compreensão de cada ícone e suas representações básicas de BPMN, foi listado os
principais recursos na Figura 2. Vale destacar que essas são as representações básicas da
notação e que cada ícone pode conter um marcador ou imagem associada de forma a
representar uma determinada situação de uso, mantendo a descrição para o ícone
utilizado.
10
Figura 2 - Símbolos da Notação de BPMN Fonte: Elaboração Própria
2.4.2 Fluxograma
Segundo ABPMP (2013) fluxogramas são utilizados à décadas e possuem um conjunto
para sua simbologia de forma a representar atividades, decisões e outras etapas comuns
11
na modelagem. Apesar de possuírem um padrão estabelecido pela American National
Standards Institute – ANSI, existem diversas variações e aplicabilidades não
padronizadas por parte de seus usuários, o que impacta em representações de processos
tidos como mais complexos, por não estabelecer um modelo de fácil compreensão nesses
casos. Alguns dos ícones utilizados no fluxograma estão representados na Figura 3, logo
abaixo.
Figura 3 - Símbolos da Notação de Fluxograma Fonte: https://www.voitto.com.br/blog/artigo/fluxograma 04/08/2019 as 11:12
2.4.3 Event driven Process Chain (EPC)
Conforme definido por ABPMP (2013, p 85),
O EPC varia de muito simples ao muito complexo e descreve
eventos desencadeantes ou resultantes de uma etapa do processo,
chamada de “função”. Assim, o fluxo é normalmente evento-
função-evento. EPC se baseia em operadores lógicos, E, OU e OU
exclusivo chamado de “regras”. Regras expressam decisões,
testes, paralelismo e convergência no fluxo de processo. Um EPC
simples consiste de apenas esses objetos mais setas que definem
suas relações.
2.5 Negócios e Tecnologia da Informação
A importância do estudo de processos dentro da organização tem se destacado, pela
necessidade de alinhamento entre os objetivos das empresas com a infraestrutura
tecnológica necessária para atingir tal resultado. As empresas capazes de aproveitar as
vantagens provenientes da integração entre negócios e tecnologia conseguem melhores
resultados de desempenho, produtividade e presença de mercado (Kearns, 2003).
12
O modo como a tecnologia é aplicada dentro da organização afeta diretamente o modo
como a mesma é organizada, alterando sua forma de trabalho, os processos definidos e
resultados esperados. Ao passo que novas tecnologias surgem, o mercado se adapta para
suprir novas demandas o que aumenta a complexidade do alinhamento entre a tecnologia
e a estratégia da organização. Montilva et alia (2014) comenta uma forte relação entre o
impacto da tecnologia na estratégia na empresa e da própria estratégia na tecnologia ao
passo que ambas se afetam de maneira cíclica com uma relação de causa-efeito-causa,
uma vez que novas tecnologias geram novas abordagens e objetivos para a empresa, e tais
mudanças requerem novas tecnologias na estrutura da organização, iniciando novos
ciclos.
2.5.1 Business Process Management System (BPMS)
À medida que novas práticas e visões eram adotadas pelas empresas, a necessidade de
novos softwares que comportassem tal estrutura também se desenvolveu para facilitar o
controle dos processos e automatização das atividades. Nesse cenário, o BPMS representa
softwares que possuem recursos de execução e delegação automático de atividades, a
partir de regras definidas anteriormente.
Segundo Oliveira et alia (2010), o controle das atividades e das regras de negócio
utilizando-se automatização dos processos a partir de regras e condições, garante maior
eficiência em sua execução e em seu monitoramento. Tais ferramentas facilitam a troca
de mensagens, dados, informações e arquivos de forma regularizada e monitorada,
desenvolvendo ambientes dinâmicos e colaborativos.
13
Figura 4 - Modelo representativo da arquitetura de BPMS aplicado a organização Fonte: ABPMP (2013, p 375)
A evolução desses sistemas, sofreram grandes mudanças, sendo capazes de comportar
cada vez maior volume de transação de dados, transformando-se em ambientes com
suporte lógico necessário para construção de regras e condições a partir da gestão de
processos. Nesse sentido, pode-se relacionar o sistema BPMS à modelagem de processos
de modo a gerar aplicações por usuários, áreas e funções definidas no processo, para
serem executadas a partir dos modelos construídos, que podem ou não funcionar de modo
integrado a outros sistemas. A figura 4 acima, representa essa relação do funcionamento
de um BPMS, a partir da definição do processo, das regras e das interfaces com outros
sistemas.
2.5.2 Arquitetura Integrada de Processos (AIS)
No âmbito estratégico, posicionar-se de forma a aprofundar a utilização de tecnologia as
decisões a serem realizadas tem se tornado cada vez mais crítico para o sucesso da
organização. Oriundo de melhores condições e transformações das tecnologias
disponíveis, as empresas têm adotado e desenvolvido novas abordagens de relacionar de
forma sistêmica e integrado, os processos definidos, as tecnologias aplicadas e os
resultados esperados. Dessa forma, melhorando a resposta da organização a nível de
14
sensibilidade do ambiente, velocidade de resposta, melhor capacidade de geração e
distribuição de informação de forma confiável, com preços cada vez menores.
Segundo Cameira (2003) o conjunto de tais tecnologias geram um cenário de hiper-
integração de modo que os processos das organizações não são mais limitados a uma
estrutura organizacional, podendo desenvolver formas e modelos definidos de forma a
considerar também os sistemas utilizados externamente como componente a ser
considerado no planejamento das decisões.
Tais tecnologias, ganharam larga escalabilidade com a utilização dos chamados web
services, os quais são capazes de utilizar aplicações web executadas em um conjunto de
servidores a partir de uma página na rede de internet, que são utilizados e estruturados a
uma arquitetura orientada a serviços SOA. Segundo ABPMP (2003, p 438),
Aplicação web é um programa ou conjunto de programas de
software que são acessados por meio de uma portal web para
executar uma determinada função de negócio. Essas aplicações
podem ser construídas de acordo com o propósito da organização
ou adquiridos de um fornecedor e normalmente são ligadas a
sistemas legados que podem acessar vários bancos de dados ou
executar determinadas funções em segundo plano, enquanto a
aplicação da web interage com o usuário do aplicativo.
Web Services são um conjunto de padrões que permitem a
integração e a comunicação de diferentes aplicações baseados na
web, independentemente da linguagem na qual foram escritos.
Em automação de processos com BPMS, Web Services podem
ser chamados pelas atividades de serviço para executar tarefas
que não dependem de interação humana, tais como extrair e
processar dados ou efetuar integração com aplicações legadas.
15
Figura 5 - Modelo de uso do Web Service Fonte: Martins (2005, p 47)
A figura 5 representa um modelo do funcionamento de uma aplicação web, o qual é
utilizado juntamente ao BPMS de forma que um executor a partir de uma página da web
possa enviar ou receber informações entre diferentes sistemas, através de servidores de
Web Service.
2.5.3 Arquitetura Orientada a Serviços (SOA/EAI)
De modo que a troca de dados e informações possam ocorrer de maneira estruturada,
bem definida para que não ocorra divergências em suas aplicações e garantir maior
confiabilidade da transação, foi desenvolvido a arquitetura orienta a serviços. Segundo
Oasis (2006) a necessidade de utilização de dados de outros serviços de forma
automática, abriu caminho para a construção das primeiras arquiteturas orientadas a
serviço, sendo o SOA, padrões sugeridos e propostos para serem utilizados no
desenvolvimento de serviços que garantam a troca de dados com aplicações externas.
BIEBERSTEIN, (2006, PG. 5) define como,
um framework para a integração de processos de negócios e para
o suporte da infraestrutura de Tecnologia da Informação que faz
uso de componentes padronizados, que podem ser reusados e
combinados de forma a endereçar as mudanças das prioridades do
negócio.
16
Figura 6 - Modelo de arquitetura SOA Fonte: Martins (2005, p 78)
De forma como representado na Figura 6, a utilização do SOA não atua diretamente na
troca de informação, somente no modo como tais serviços são disponibilizados e
executados refletindo as necessidades e diretrizes da organização. Segundo ABPMP
(2013), o SOA é abordado de forma a guiar o desenvolvimento de sistemas BPMS
facilitando assim a automatização de seus processos de forma que serviços possam
interagir com outros serviços parametrizados de forma similar.
2.5.4 Sistema Integrado de Gestão (SIG)
Sistemas integrados são o conjunto de recursos de software e redes de comunicação que
possuem o papel de executar, transformar e disseminar fluxos, atividades e informações,
em uma organização de forma a agir, monitorar e controlar o funcionamento dos recursos
dos stakeholders envolvidos.
Sperb e Neto (2014) caracterizam os sistemas integrados de gestão como tendo papel
fundamental nas organizações, sendo através deles que um administrador consegue ter
um acesso com facilidade as informações de todos os aspectos de sua organização. A
correta administração dessas informações passa a ser fundamental para seu sucesso, pois,
com base nelas os executivos podem decidir o rumo da empresa
Segundo (Laudon e Laudon, 2004), os sistemas de informação são aplicações de
diferentes fontes que atuam de forma integrada para processar, armazenar e gerar
informação de maneira coordenada de maneira a fornecer controle e facilidade para as
execuções de atividades e tomadas de decisão
17
Segundo Cameira(2003), os sistemas de gestão podem ser classificados como:
• Sistemas de Planejamento dos Recursos Empresariais (Enterprise Resource
Planning - ERP)
Sistemas de Gestão da Cadeia de Suprimentos (Supply Chain Management -
SCM);
• Sistemas de Gestão do Relacionamento com Fornecedores (Supplier Relationship
Management - SRM),
• Sistemas de Gestão do Relacionamento com Parceiros (Partner Relationship
Managemente - PRM);
• Sistemas de Gestão do Relacionamento do Cliente (Customer Relationship
Management - CRM);
• Sistemas de Gestão do Ciclo de Vida dos Produtos (Product Lifecycle
Management - PLM e Product Development Management - PDM);
• Sistemas de Inteligência do Negócio (Business Inteligence - BI)
➢ Entreprise Information Systems e Balanced Scorecard,
➢ Datamining (AMIUNE e KICKINGER, 2001);
➢ Datawarehouses ;
• Sistemas de Gestão do Conhecimento (Knowledge Management Systems - KMS),
parcialmente são também sistemas de BI;
• Sistemas de Automação de Processos (GED e Workflow);
• Sistemas Transversais à Cadeia (Sistema de Gestão do Relacionamento com os
Empregados (Employee Relationship Management - ERM)
18
Figura 7 - Modelo de Integração dos SIG's Fonte: Cameira (2003, p 11)
2.6 Workflow
Conforme a figura 7, no molde de organizações cada vez mais integradas umas às outras,
a capacidade de uma empresa de organizar-se de modo a buscar e gerar informação, bem
como realizar atividades de maneira colaborativa tem cada vez mais impacto nos
resultados de desempenho da organização.
O sistema de Workflow tem como objetivo facilitar a execução e controle dessas
atividades, por meio da automatização de sua execução e delegação de tarefas. Por meio
desse recurso é possível definir previamente os executores das atividades de forma a
solucionar problemas de controle organizacional. Através do workflow é possível
especificar as atividades a serem executadas, as ações a serem seguidas, as rotas
percorridas e sequencia de suas atividades.
19
Figura 8 - BPM para integração de um Workflow
Fonte: Martins (2005, p 70)
Para Fischer (2003) o entendimento do workflow é determinado como um processo
automatizado ao qual possui executores, ações e regras definidas, podendo estar ligadas
ao preenchimento de documentos, informação ou execução de atividades.
A figura 8 apresenta o modelo de uso e interação entre o sistema de workflow e a
utilização das aplicações Web e Web Services a partir de da abordagem de BPM. A partir
da utilização do workflow, podemos definir regras a serem executas em determinadas
atividades de forma a executar aplicações via Web Service, que podem ser realizadas tanto
de forma automática ou com a participação de um usuário. Ainda segundo Fischer (2003)
a utilização dos recursos de workflow permite maior ritmo de execução das tarefas
garantindo maior controle e confiabilidade das informações e eficácia do serviço.
2.6.1 Classificação de sistemas
Apesar de possui o mesmo objetivo, os recursos do workflow, possuem funcionalidades
e propósitos distintos, que podem variar bastante de acordo com as necessidades de
organização, os processos levantados e a capacidade de execução de múltiplas tarefas do
sistema. Segundo SILVA (2001) e Martins (2005), o Workflow pode ser categorizado da
seguinte forma:
20
• Ad hoc: São os de fluxo mais simples e que requerem maior flexibilidade ao longo
de sua construção por conta de não possuir estrutura bem definida necessitando
adaptar-se à medida que é realizada. De forma geral são workflows que priorizam
o compartilhamento de informações. Dessa maneira, possuem pouca segurança
atrelado ao processo e pouca capacidade de tratamento de informação, não sendo
indicado para serem utilizados como processos primários de uma organização
• Administração: São workflows utilizados tipicamente para processos repetitivos,
geralmente envolvendo normas, documentos ou formulários. Por tratar-se de algo
recorrente possuem maior capacidade de tratamento de dados, além de possuir
regras de segurança mais estruturadas de forma a reduzir sua flexibilidade e rotas
possíveis.
• Produção: São utilizados para processos críticos dentro da organização, onde não
há margem para falhas e a execução do roteiro pré-definido deve ser seguida à
risca. São os modelos mais robustos dentre as categorias disponíveis de workflow
possuindo a capacidade de tratamento de um grande volume de dados e alto nível
de segurança no processo.
Alguns autores levantam uma quarta classificação, denominada de Colaboração. Possui
como sua maior característica, os repetidos ciclos de uma mesma etapa de forma a ser
obtido um resultado que seja aprovado por diferentes partes envolvidas no processo.
Possuem uma natureza de atividades dinâmicas de modo a proporcionar colaboração entre
os participantes envolvidos no processo.
A figura 9 resume os tipos definidos para o workflow quanto a suas categorias e
características conforme descrito
21
Figura 9 - Caracterização das categorias de Workflow Fonte: Martins (2005, p 69)
2.6.2 Arquitetura de um sistema de Workflow
O workflow como outros sistemas apresenta subdivisões com características e funções
que trabalham juntas para obter o resultado esperado de automação de atividades. Silva
(2010) apresenta em sua tese um modelo de representação das camadas básicas que
compõe o sistema de workflow, apresentadas pela Figura 10 e descritos a seguir.
Figura 10 - Arquitetura de Workflow
Fonte: Silva (2010, p 27)
• Processos – É a camada superior de toda a arquitetura de forma a comportar os
outros recursos do workflow. Trata-se do sequenciamento das atividades ao longo
22
do tempo para atingir um resultado, podendo ou não possuir regras em sua
parametrização.
• Casos – são as ocorrências propriamente ditas, ou instâncias dos modelos de
processos automatizados pelo sistema de workflow. Ao longo deste trabalho
utilizaremos o termo “instância” para representar esta categoria. Cada vez que um
processo é iniciado, cria-se uma nova instância do caso e as regras e atividades
passam a ser realizadas ou delegadas.
• Pastas – Uma pasta pode ser entendida como um local para armazenamento e
consulta de documentos eletrônicos de diferentes tipos e formatos, incluindo
documentos de texto, planilhas e formulários que servem como conjuntos de
registros de dados em um sistema de informação.
• Regras / Aplicações – A camada de regras é responsável pela determinação das
atividades de um processo. É nessa etapa onde ficam definidas os caminhos a
seguir, associação dos documentos e formulários, os executores de cada atividade
e ações a serem realizadas. Estas regras se dividem em papéis e rotas.
o Os papéis são as definições de responsabilidade de uma atividade dentro
do processo, ou seja, os usuários os quais deverão realizar uma
determinada tarefa delegada pelo sistema. Os papéis podem ser
referenciados a um único indivíduo ou a um grupo de usuários. Podem ser
definidos por localização, função, área, ou nível de segurança.
o As rotas de workflow é que executam o sequenciamento e ordenação dos
documentos e atividades ligadas ao processo. Existem basicamente três
tipos de rotas: rotas sequenciais, rotas paralelas e rotas condicionais
apresentas na figura 11.
23
Figura 11 - Modelos de rota do Workflow Fonte: Traduzido de Silva (2010, p 28)
• Documentos – No último nível a categoria de documentos representam os dados
propriamente ditos. Estes podem ser representados na forma de documentos ou
tabelas, os quais são salvos em grupos de pastas, que estão associadas às
instâncias. Para as situações apresentadas no caso, podem ser representados
também a partir dos formulários eletrônicos, os quais podem possuir regras
associadas ao seu preenchimento.
24
3 ESTUDO DE CASO
3.1 Apresentação das empresas
A empresa escolhida para a análise ao longo deste trabalho não terá sua razão social
exposta diretamente, por motivos de sigilo empresarial e solicitação por parte da
organização como critério de acordo para permissão da exposição das informações
apresentadas ao longo deste projeto. Por conta disso, será caracterizada ao longo dos
textos como empresa Y.
Presente em diversas cidades, a empresa Y, está em mais de 15 estados e com operações
em várias indústrias diferentes, oferece solução completa e inovadora de serviços de
planejamento e gestão de estoque, buscando otimização, aumento de controles,
aprimoramento de gestão e geração de caixa associada à redução de custos e estoque,
oferecendo assim, serviços que cobrem toda a cadeia de suprimentos. A empresa possui
seu próprio sistema de planejamento de estoque e está presente atuando em 15 estados do
Brasil e 3 países da América Latina.
3.1.1 Análise das necessidades
A empresa Y nos últimos anos vem apresentando crescimento relativo constante e está
bem segmentada dentro do mercado a qual se propôs a atender, retornando bons
resultados e com novos contratos à vista. Por esse motivo, foram identificadas
oportunidades dentro da organização. Para que esse crescimento permaneça de forma
sustentável, foram definidas mudanças necessárias dentro dos fluxos de processos da
empresa.
Hoje a empresa Y é composta de 13 áreas as quais possuem diversos processos e fluxos
definidos, ocorrendo de maneira interligada e dependente uma da outra. Ao mesmo tempo
que o fluxo de informação ocorre de maneira conjunta entre as áreas, os sistemas de gestão
dessas informações não possuem qualquer tipo de integração, o que resultava em
dificuldade de aquisição de informação, atrasos por falta de rastreabilidade nas tarefas,
baixa capacidade de utilização de indicadores pela gerência por conta de cruzamento de
dados e um alto custo atrelado a manutenção desses sistemas.
Após diversas reuniões ficou decidido a implementação de um sistema de gestão
integrado para os fluxos da empresa, que assumisse a responsabilidade de controlar as
25
tarefas do dia a dia dos funcionários, garantindo confiabilidade das informações,
segurança dos dados apresentados e que conseguiria realizar todos os recursos dos antigos
sistemas sem que houvesse perda de funcionalidades já presentes.
3.1.2 Substituição dos softwares
O processo de seleção de um novo software para substituir os anteriores levou em conta
os fatores de custo de implantação, custo de manutenção, dificuldade de implementação,
funcionalidades, interface amigável, integração com outros sistemas e estabilidade e
segurança da rede.
Os sistemas substituídos realizavam a função de:
- Gestão Eletrônica de Documentos
- Registro de Inspeções e Checklists
- Intranet da empresa
- Sistema de Ensino a Distância
- Sistema de Abertura de Chamados
Como parte da limitação do trabalho, não será analisado os fatores comparativos da
escolha do software perante aos outros disponíveis do mercado. Será avaliado somente
sua implantação e utilização, pelo fato do autor só ter sido convocado ao projeto após essa
etapa.
3.1.3 Viabilidade financeira e economia esperada
A contratação do serviço tinha objetivo esperado de melhorar os fluxos internos, garantir
maior confiabilidade na informação, gerar melhor controle a diretoria a partir do uso de
workflows e redução dos custos com a substituição dos sistemas anteriormente
apresentados. A análise realizada para obtenção de tais valores não foi abordada nesse
trabalho, de forma a somente apresentar as estimativas de gasto e a economia com
software. Foram consideradas as despesas mensais com os sistemas, os custos de
aplicação do mesmo (Horas da consultoria) e a economia estimada com a saída dos
anteriores. Para conceituação no gráfico, considerou-se como “Receita” a diferença entre
o custo de uso dos sistemas anteriores menos o custo atual com o sistema. A figura 12,
abaixo retorna à avaliação da receita e gastos mensais após o início da implementação,
devendo-se considerar o mês “1” como o 1° mês a partir da contratação do sistema.
26
Figura 12 – Comparação mensal dos gastos pela economia esperada
A figura 13 estima a despesa geral, considerando-se a receita ou economia gerada naquele
determinado mês menos o valor das despesas ocorridas, considerando o custo mensal dos
sistemas e dos custos sobre o investimento. Dessa forma, espera-se que após 11 meses
passados da implementação do sistema, a economia gerada pela implementação
ultrapasse a despesas.
27
Figura 13 - Retorno esperado acumulado Fonte: Elaboração Própria
3.1.4 O Software SoftExpert
O sistema da SoftExpert apresenta uma diversidade de módulos, que funcionam de forma
integrada, com o intuito de servir como base para a elaboração e desenvolvimento de uma
rede de processos colaborativos de gestão de forma a prover a melhoria dos processos e
desenvolver um sistema de melhoria contínua dentro da organização. O mesmo conta com
uma gama de funcionalidades internas para auxiliar as empresas a atingir as metas e
objetivos pretendidas, por meio de processos de gestão em conformidade com as normas,
envolvendo pessoas de vários departamentos, unidades de negócios, fornecedores e
clientes. O controle das delegações e atividades dos fluxos da organização são feitos de
forma automatizada, e podem ser configuradas no próprio sistema conforme as pretensões
da empresa.
Figura 14 - Ícones do Software Fonte: https://www.softexpert.com/pt-br/produto/gestao-formularios/
Acesso em 01/08/2019 as 09:30
28
Para os objetivos requeridos da empresa Y foi contratado um pacote inicial contendo 10
módulos, sendo 3 considerados chaves para a construção dos fluxos, representados na
figura 14.
• SE Workflow: é o módulo responsável pela automatização das tarefas do sistema,
realizando a execução automática de atividades e delegação para os responsáveis.
É nesse nele onde ficam armazenados os registros de instâncias abertos.
• SE Formulário: Esse módulo é utilizado para construção de formulários
eletrônicos, os quais podem ser configurados em níveis de conteúdo, design e
regras
• O SE Processo é o módulo que permite ao usuário a utilização da ferramenta de
modelagem processos. A partir dele é possível desenhar os modelos pretendidos
e utilizar juntamente aos outros módulos, de forma a tornar executável o fluxo (SE
Workflow) e associar formulários (SE formulário) a serem preenchidos pelos
usuários ou pelo sistema
3.1.5 Relacionar o software a partir da pesquisa bibliográfica
Pode-se definir o software da SoftExpert, como um sistema de BPMS, que possui como
objetivo servir como base para os processos da empresa facilitando o gerenciamento das
atividades a partir da delegação e automatização de tarefas e do controle dos processos.
O mesmo utiliza-se de aplicações Web e configurações Web Services para seu
funcionamento, sendo possível acessar e instanciar processos de qualquer localização
com internet, a partir de uma página na rede via computador ou até mesmo pelo celular.
Os componentes do sistema são separados em módulos, os quais podem ser adquiridos
separadamente ou em conjunto, de forma a funcionar como um sistema integrado de
gestão. Ao longo deste trabalho será limitado a discussão da implementação do sistema
de Workflow para automatização das tarefas, porém para fins de caracterização da
ferramenta, pode-se destacar também a possibilidade de implementação de módulos para
construção de Sistemas de Inteligência do Negócio, Sistemas de Gestão do Ciclo de Vida
dos Produtos e Sistema de Gestão do Relacionamento com os Empregados.
29
3.1.6 Notação e funcionalidades da ferramenta
Como descrito anteriormente, para construção do workflow, inicialmente se faz
necessário a utilização do módulo de SE Processos. O sistema emprega a utilização de
recursos a partir de um processo modelado na ferramenta, isso significa que o usuário
deve utilizar-se das representações gráficas disponibilizadas para construir o fluxo e em
seguida parametrizar as regras e funcionalidades em cima de cada ícone ou modelo
gráfico. No sistema, a nomenclatura atribuída a essa ferramenta é chamada de
“Fluxograma” (como será observado mais adiante), porém como visto no tópico de
notações de modelagem, podemos dizer que essa não é a nomenclatura adequada por
conta dos recursos disponíveis. A notação de modelagem adotada pelo sistema
assemelha-se a notação de BPMN, conforme figura 15, porém com uma limitada
quantidade de ícones e recursos disponíveis para construção do modelo gráfico.
Figura 15 - Modelo representativo da modelagem do Workflow Fonte: https://www.softexpert.com/pt-br/solucao/gestao-de-processos-de-negocio-bpm/
Acesso em 01/08/2019 às 14:15
30
Os ícones apresentados no sistema, possuem as mesmas funcionalidades e descrições já
comentadas anteriormente da notação BPMN. O sistema faz uso dos seguintes recursos
para construção do processo:
• Atividade
• Gateway
• Conectores
• Raias
• Evento de Início
• Evento de Final
Para melhor compreensão dos fluxos, a lista dos ícones utilizados e sua descrição são
apresentados nas figuras 16 e figura 17.
31
Figura 16 - Notação dos ícones do Workflow Fonte: Elaboração Própria
32
Figura 17 - Notação dos ícones do Workflow Fonte: Elaboração Própria
3.1.7 Parametrização do Processo
Ao iniciar a modelagem do processo, o responsável terá acesso a uma diversidade de
funcionalidades atribuídas diretamente aquele fluxo, e que afetam o registro do processo
como um todo. Cada funcionalidade pode ser parametrizada da forma como for de melhor
interesse para o responsável pela construção do fluxo, não sendo obrigatório o uso de
todos os recursos dentro do processo. Porém se o usuário optar pela utilização de
determinado recurso, deverá preencher todo os campos obrigatórios, assinalados com
asterisco vermelho como demonstrado no exemplo da figura 18.
33
Figura 18 - Funcionalidades do Processo Fonte: Adaptado de https://www.softexpert.com/pt-br/solucao/gestao-de-processos-de-negocio-bpm/
acesso 25/08/2019 as 19:32
As funcionalidades ficam disponíveis na aba lateral esquerda da tela e no botão de
ferramentas, Figura 18, de modo que são definidas como:
• Dados Gerais: refere-se às características básicas de informação de um
determinado fluxo, como nome, Categoria do Fluxo, Data de criação, Data de
Atualização, Contagem da revisão, Área do processo e Identificador do processo.
• Duração: Refere-se a qual o tempo previsto estipulado do início ao fim do fluxo,
e pode ser customizado de forma a apresentar indicadores de acompanhamento e
atraso (SLA)
• Automação: Habilitar essa funcionalidade garante a integração do módulo de
processo com o módulo de workflow, de forma que as atividades e regras
associadas só estarão operando de forma funcional e autônoma quando esse
recurso estiver habilitado.
• Atributo: São campos que podem ser associados ao processo de modo a registrar
um determinado valor ou lista de valores, como um registro do fluxo.
• Instância: Esse recurso é responsável pela identificação do registro do fluxo.
Cada fluxo instanciado recebe uma numeração única e exclusiva. Essa
identificação pode ser configurável de modo a escolher:
➢ Número sequencial
➢ Identificador do processo + sequencial
34
➢ Máscara de identificação (Nesse modo pode-se customizar a
identificação com prefixos e separadores + sequencial)
• Segurança: Refere-se à proteção e controle das escolhas do nível de acesso dos
usuários dentro do processo. É configurável definir os usuários que terão acesso a
Alteração; Exclusão; Revisão; Conhecimento da Revisão; Visualização e Edição
do Processo; ainda é possível definir a quem é liberado iniciar ou não os fluxos.
3.1.8 Parametrização das Atividades
Após a construção do modelo gráfico, é possível acessar as funcionalidades disponíveis
em cada ícone de forma a definir os parâmetros que serão utilizados para especificar as
regras e medidas para aquela atividade. Cada caixa de atividade pode receber um
determinado conjunto de regras, não sendo necessário que se repitam ou se acumulem,
porém, essas opções estão disponíveis caso seja necessário.
• Dados Gerais: De forma similar ao processo, os dados gerais da atividade
referem-se às características básicas da atividade, como Nome, Tipo da Atividade,
Data de criação, Data de Atualização, Identificador da Atividade e outros. .
• Duração: Refere-se a qual o tempo previsto para determinada atividade, e
também possui a possibilidade de ser customizado de forma a apresentar
indicadores de acompanhamento e atraso (SLA).
• Ação: Esta funcionalidade, define as possíveis execuções da atividade/decisão,
podendo existir uma ou mais ações que possam ser executadas. Por meio deste
recurso, devem ser configuradas informações como nome e os ícones das ações
(Que ficarão visíveis na execução do processo), qual a atividade alvo de cada,
estipular regras para cada caminho, definir impedimentos e requerimentos
exigidos para seguir para tal rota.
• Execução: Neste recurso, deverá ser definido quem ou quais responsáveis serão
registrados pela execução da atividade, sendo possível definir tanto executores
fixos ou variáveis (a partir de uma escolha ou condição que tenha ocorrido no
processo). Pode-se escolher:
o Fixos
▪ Usuário específico;
35
▪ Área; nesse caso a tarefa irá ficar disponibilizada no quadro de
atividades de todos os usuários cadastrados naquela determinada
área;
▪ Área/Função; funciona de forma similar a anterior, porém ficará
disponível apenas para os usuários cadastrados com determinada
função dentro daquela área;
▪ Papel Funcional: O papel funcional atua como grupos pré-
definidos de usuários, que podem ou não ser possuir mesma área
ou função;
o Variáveis
▪ Iniciador do processo;
▪ Líder do iniciador do processo;
▪ Executor de uma atividade específica;
▪ Líder do executor da atividade específica;
▪ Fórmula; é possível definir o executor a partir de uma condição ou
escolha realizado pelo usuário, tanto no processo quanto no
formulário. para utilizar este recurso o responsável pela
parametrização necessita ter conhecimento dos recursos do
programa MySql;
Além disso o recurso de execução permite definir caso o executor seja um grupo,
a associação automática ao usuário com menos atividades em execução, com
menos horas previstas para execução ou mesmo de modo sequencial.
• Formulário: é possível associar um ou mais formulários para preenchimento
dentro de uma atividade. Dentro do formulário o usuário deverá preencher os
campos definidos e requeridos já definidos anteriormente. Obrigatoriamente, todo
formulário, possui uma tabela associada a ele, o qual utiliza-se dos campos
preenchidos pelo usuário para registro das informações. Todo campo do
formulário corresponde a uma coluna da tabela, e os registros preenchidos em um
formulário ficam salvos em uma única linha. Isso permite que um fluxo já
encerrado possa ser consultado a qualquer momento por pessoas autorizadas.
36
• Instância: Em atividades, o recurso de Instância, permite disponibilizar ou não
ao usuário delegar a tarefa para outra pessoa. Como padrão essa ação vem
indisponível para o executor da atividade.
• Requerimento: Neste recurso pode-se exigir ou não anexos e/ou documentos
necessários para finalização da atividade/decisão em questão. Caso o usuário não
insira o anexo, ele não conseguirá seguir com o fluxo.
• Questionário: Esse recurso permite associar um questionário com um conjunto
de perguntas pré-definidas para ser respondidas pelo usuário. São bastante
utilizadas para avaliação da satisfação ao final do fluxo.
• Situação: Toda atividade encaminhada para o usuário ficará pendente do quadro
de tarefas do funcionário, apresentando o identificador do processo e em qual
atividade está. É possível editar o nome que será apresentado para o usuário na
sua lista de tarefas através desta funcionalidade. Este recurso não impacta
diretamente no workflow, se limitando a melhorar a experiência do usuário dentro
do sistema de forma a tornar a informação mais clara. Se não for preenchido, irá
retornar apenas com o identificador da tarefa
3.2 Planejamento e Levantamento de Informação
Para implantação do sistema, a equipe contou com dois profissionais da área de projetos,
um da área de tecnologia da informação e um consultor externo de empresa contratada.
O projeto teve duração de 6 meses e foi dividido em duas etapas. A primeira tendo
duração de 4 meses e com o objetivo de construção de 3 processos já definidos e
mapeados na empresa, que são:
• Processo de suprimentos, tendo o objetivo de tornar todo o processo de compra
do material desde a geração da ordem de compra até a aprovação do lançamento
da nota fiscal via sistema. Vale ressaltar que a declaração dos pedidos e notas
fiscais perante o governo permaneceu sendo feito por outro software.
• Processo de registro de ocorrência, de forma que todo e qualquer acidente, quase
acidente ou ocorrência que aconteça dentro da operação de gestão de estoque deve
ser prontamente registrado e enviado para os líderes da localidade. Com a
utilização de formulários eletrônicos via sistema, é possível utilizar melhores
campos de preenchimento do ocorrido, deixando-os com uma riqueza maior de
37
detalhes e facilitando a descrição para os usuários. Assim esperando que melhores
planos de ação serão gerados e que melhores análises poderão ser feitas para evitar
ou minimizar riscos.
• Processo de registro de não conformidade, de forma similar ao registro de
ocorrência citado anteriormente, qualquer cenário de percepção de desvios,
situações e eventos que fujam do protocolo podendo apresentar risco ao
colaborador devem ser registrados e encaminhados para os líderes responsáveis
pela localidade.
Os três processos se encaixam na definição definida por ABPMP(2013) anteriormente e
podem ser categorizadas como processos de suporte, por servirem de base para outros
processos atuando no sentido de gerar valor de forma indireta para o cliente, pois tratam-
se de garantir o funcionamento da operação (Suprimentos) e da qualidade do serviço (
Ocorrências e Não Conformidade).
Para a implementação do software, a equipe seguiu premissas estabelecidas de comum
acordo com a diretoria da empresa, de forma a alinhar as expectativas com o novo
software com o tempo disponível para a implementação (tempo do consultor). Dessa
maneira, ficou definido para a primeira etapa do projeto que:
• Os processos devem ser elaborados de forma a “replicar” os fluxos já existentes.
Dessa maneira, melhorias ou alterações no processo deixaram para ser realizadas
quando a equipe estiver mais familiarizada com o potencial do software, focando
em 1° momento em tornar o fluxo realizável pelo sistema;
• A explicação das etapas dos processos, com suas condições, executores e
responsáveis já haviam sido mapeada previamente e estavam a disposição da
equipe no formato de manuais em arquivo eletrônico;
• Todos os formulários, de forma similar aos processos, deveriam ter seus
conteúdos “replicados” na ferramenta pelo módulo do SE formulário. Dessa
maneira, os campos disponíveis a serem preenchidos anteriormente deveriam
estar incluídos na nova ferramenta, devendo apenas criar novos campos mediante
necessidade para a utilização no processo.
38
Para a segunda parte, ficou definido a transição dos cursos e treinamentos online,
mapeados por área e cargo, implantação do Fluxo de Chamados e implantação do Fluxo
de Avaliação de Saúde ocupacional, de forma a substituir os sistemas utilizados
anteriormente. Esses processos não formam abordados nesse trabalho.
No início do projeto, foi apresentado a equipe as funcionalidades e recursos disponíveis
em cada um dos módulos, como eles se relacionavam e como poderiam ser utilizados. O
sistema possui funcionalidades de cadastro e registro de usuários, funções, áreas,
empresas, clientes, fornecedores e fabricantes, sendo possível alterar e configurar suas
informações pessoais de forma a serem utilizados nos formulários no formato de lista, o
qual será explicitado nos próximos tópicos. Tal recurso garante maior agilidade e
facilidade no preenchimento das informações pelo usuário, sendo que são informações
necessárias em quase todos os formulários planejados. Para tal, foi necessário realizar o
levantamento dos dados, junto as áreas responsáveis, de cada um dos tópicos
mencionados, ocorrendo de forma paralela a construção dos fluxos. Dois pontos exigiram
maior esforço da equipe em relação a esse assunto:
• Dados dos funcionários ausentes ou incompletos; em alguns casos, a
obtenção de tal informação foi dificultada por não haver registros
destinados a ela, como foi o caso da localização do local de trabalho do
funcionário. O controle era realizado somente via centro de custo, o qual
continha a informação do nome do cliente, a cidade e o estado. Porém
alguns clientes possuem mais de uma localidade, fábrica, galpão ou centro
de distribuição por cidade, e tal informação era requerida nos campos dos
formulários. Para tal foi realizado o levantamento de tais informações
faltantes juntamente aos líderes de cada localidade de forma a mapear o
local de trabalho de cada colaborador.
• Padronização e Tratamento dos dados; cada área é responsável pelo
controle e manutenção das informações a qual são de sua
responsabilidade. Quando recebido os dados pela equipe, foi destacado
grande variabilidade de representações de texto para um mesmo
significado. Um dos casos destacados como exemplo, foi o campo de
“Estado” de empresas, fornecedores e Clientes, o qual possuía diferentes
39
nomes para um mesmo significado como: “Rio de Janeiro”, “RIO DE
JANEIRO”, “Rio”, “RJ”, “Rj”, além dos casos de erro de ortografia. Tal
variabilidade causa grande impacto nos fluxos, como será explicado mais
a frente. Para tal a equipe adotou alguns padrões e regras para inserção dos
dados na ferramenta, como:
o Utilização de caixa alta para todos os nomes próprios;
o Restrição ao uso das siglas para os identificadores, salvo para o
campo de Estado, o qual é obrigatório;
o Proibição do uso de caracteres especiais para documentos pessoais
como CPF, Identidade, Carteira de Motorista;
3.2.1 Construção dos Formulários
Figura 19 - Modelo de Formulário Fonte: https://www.softexpert.com/pt-br/solucao/gestao-de-processos-de-negocio-bpm/
Acesso: 25/08/2019 as 18:32
Os formulários são documentos online programáveis para serem preenchidos pelo usuário
em uma ou mais atividades. Podem ser configurados de forma a possuir campos
obrigatórios ou não, conforme figura 19 além de inserir regras e comandos para
preenchimento automático de campos. Os componentes disponíveis são:
40
• Input: É um campo que permite a entrada de dados do tipo texto, número e
decimal.
• Lista de valores: É um campo que permite a seleção de um valor por meio de
uma tabela ou por meio de uma busca.
• Checkbox: É um campo que permite assinalar a marcação ou não de uma opção.
• Radio Button: É um campo que permite marcar uma opção entre diversas (outros
radio buttons).
• SpinInput: É um campo que permite a entrada restrita de dados do tipo número.
• Texto: É um campo que permite a entrada restrita ao tipo texto.
• Data: É um campo que permite a entrada restrita de dados do tipo data.
• Hora: É um campo que permite a entrada restrita de dados do tipo hora.
• Grid: É uma tabela que permite associar diversos registros como, por exemplo,
itens de um pedido.
• Arquivo: É um campo que permite a seleção de um arquivo.
• Assinatura: É um campo que permite a inclusão da assinatura do usuário.
Além disso é possível inserir elementos com finalidade estrutural como linhas de
marcação, Titulo, imagens e Botões.
Apesar da organização possuir mais de 1000 funcionários, não mais que 200 utilizam o
computador mais que 1 hora por dia, dentro de sua rotina. Por conta disso a equipe
considerou algumas regras e padrões que devem ser adotados no desenvolvimento de um
Workflow na etapa da construção de seu formulário.
• O sistema da SoftExpert possui diversos recursos para coleta e preenchimento de
informações, de forma automática, tornando o preenchimento dos campos menos
desgastante para o usuário e garantindo menor chance de erro. Nesse caso, ficou
definido que quando houver a necessidade de tal informação, deverá ser utilizado
as regras e comandos de forma preferencial. Por exemplo: Nome do iniciador do
processo, data de abertura do fluxo ou numeração do processo.
• Os campos os quais já tenham valores pré-definidos para serem apresentados ao
usuário deverão ser utilizados na forma de uma lista. Dessa maneira, o
41
preenchimento dos campos se torna mais rápido e restringe ao usuário a escolher
dentre os possíveis recursos liberados pelo sistema evitando possíveis erros
durante o preenchimento.
• Todo e qualquer funcionário da empresa têm acesso garantido e liberado aos
workflows do sistema, correspondentes de sua função, assim que é contratado. Foi
definido ao longo da implantação que os atuais funcionários e os que entrem
posteriormente devem receber treinamento básico online de funcionamento do
sistema antes de iniciarem suas funções, garantindo maior entendimento e melhor
adaptação a nova ferramenta. A apresentação inicial da localização dos
treinamentos ficará de responsabilidade do líder do colaborador, após isso o
funcionário terá acesso a diversos cursos explicando o funcionamento do sistema
e os procedimentos que deverá realizar.
3.2.2 Construção do Workflow
Para construção do fluxo de suprimentos foi analisado todo o procedimento realizado
desde a solicitação do material pelo requisitante até seu pagamento pelo setor financeiro.
Foi identificado as atribuições de cada uma das áreas, apresentado na figura 20, suas
tarefas e deveres dentro do fluxo, considerando os cargos responsáveis, o tempo estimado
em cada atividade, as regras de negócio estabelecidas e os possíveis desvios dentro do
fluxo.
42
Figura 20 - Quadro de Responsabilidade Fonte: Elaboração própria
De forma a facilitar a visualização do modelo do processo pelos usuários, optou-se por
dividir o processo inteiro de suprimentos em processos menores. Essa divisão foi
necessária por conta da diversidade de material/serviço, forma de pagamento, urgência
na solicitação e outros casos mapeados, que requerem abordagens diferentes de
tratamento.
O processo do fluxo de Suprimentos tem como objetivo a realização das
compras/contratações de materiais ou serviços de forma regulamentada e formalizada
para a solicitação de fornecimento de uma empresa terceira que pode ou não estar ligado
a um contrato.
3.3 Requisição de Compra
O processo de requisição de compra foi o maior dentre os fluxos construídos pela equipe,
o qual é representado nas figuras 21, 22 e 23 o qual terá cada atividade detalhada nos
tópicos seguintes. Como ocorria antes, e permaneceu definido dessa forma, todo
colaborador pode iniciar um processo de compra, instanciando um processo no painel de
43
suprimentos que fica à vista no portal do funcionário assim que é realizado o acesso ao
sistema.
Figura 21 - Fluxo de Suprimentos Fonte Elaboração Própria
44
Figura 22 Fluxo de Suprimentos Fonte: Elaboração Própria
45
Figura 23 - Fluxo de Suprimentos Fonte Elaboração Própria
46
3.3.1 Solicitação de Compra
Assim, que instanciado o workflow para solicitação de compras, é disponibilizado na tela
do funcionário o formulário de compras. Toda e qualquer requisição deve ser iniciada
através deste formulário denominado Requisição de Compra (RC). Que possui por
objetivo a descrição de forma detalhada das especificações do material e/ou serviço a ser
contratado. Nela o funcionário deverá preencher informações como centro de custo, o
local de entrega, o motivo da compra, se existe urgência e fornecedores de preferência.
Além disso deverá constar a descrição completa do material, a categoria a qual está
inserido, qual quantidade pretendida e seu valor unitário de referência. O funcionário
deverá preencher também o campo “Tipo de requisição, de modo a definir a qual classe
de requisição sua solicitação estará sujeita. As requisições de compra poderão ser do tipo
“Normal de aquisição de materiais ou serviços”, do tipo “Requisição de ativos
imobilizados”, do tipo “Requisições de catálogos”, do tipo “requisição de regularização”
e por último de “Compra delegada”. Essas categorias serão explicadas mais adiante.
O menor valor exigido por requisição de compra é de no mínimo R$ 100,00, regra
definida pela diretoria para evitar sobrecarregar o setor de suprimentos com compras
menores. O requisitante deve planejar suas demandas de materiais e serviços
considerando o valor definido, além do prazo de entrega dos materiais ou de mobilização
para execução dos serviços. Este valor aparece dentro de um campo denominado “Valor
total da requisição”. Ao tentar dar prosseguimento a próxima etapa o sistema realiza a
avaliação do campo. Caso o valor seja menor que 100 reais o mesmo apresenta uma
mensagem de alerta, impedindo o usuário de seguir o envio para próxima etapa. Para
esses casos a compra é feita fora do sistema e não requer processo de pedido de compra.
3.3.2 Alçada de Aprovação da Solicitação de Compra
Após a conclusão do preenchimento do formulário, o workflow segue para seu primeiro
operador de decisão (gateway) dentro do sistema. Nesse recurso tanto as entradas quanto
as saídas são pré-configuradas através de condições para verificação (nas entradas) e
fórmulas (nas saídas). Para este caso foi configurada uma verificação da escolha do centro
de custo, preenchida no formulário pelo requisitante. Para os casos de centros de custo
relacionados diretamente a operação e gestão dos armazéns, estes irão requerer do usuário
selecionar o nome do gerente geral da localidade do requisitante. Para os casos de centro
47
de custo de natureza corporativa, será requerido selecionar o gerente corporativo
responsável pela área. O requisitante só poderá seguir com o fluxo após a escolha do
centro de custo e da seleção dos campos seguintes. Ambos os caminhos possuem mais
alçadas de aprovação que funcionam de maneira a verificar o valor total da requisição.
As requisições de compras deverão ser verificadas pelos responsáveis e em caso de terem
sido preenchidas incorretamente ou possuir irregularidades, serão retornadas para o
solicitante. O processo será reiniciado, sendo obrigatório sua aprovação conforme fluxo
de aprovação definido. O gerente geral, corporativo ou diretores devem indicar o
problema identificado no formulário da RC na devolução ao requisitante. O sistema conta
com um programa de histórico do workflow, onde é possível descrever o motivo do
retorno e os campos a serem corrigidos, podendo enviar alertas para sinalizar o
requisitante do erro cometido. Caso seja realizado o retorno para correção, a RC deverá
seguir novamente para os gestores, sendo necessário a aprovação de todos da alçada mais
uma vez. Além disso as requisições também podem ser rejeitadas na etapa de aprovação
das alçadas.
Após a aprovação do gerente geral/ corporativo, o fluxo seguirá para os próximos
gateways. As regras aplicadas nesses casos são baseadas no valor total da requisição,
considerando o valor de referência definido pelo requisitante e se enquadram nas figuras
24 e 25.
Figura 24 - Regras de Aprovação (Corporativo) Fonte: Elaboração Própria
48
Figura 25 - Regras de Aprovação (Operação) Fonte: Elaboração Própria
Quando há ausência de algum aprovador, o mesmo poderá delegar suas tarefas e
aprovações para outro colaborador, podendo o substituto pertencer a um nível hierárquico
inferior ou superior. Para que a delegação passe a valer, o aprovador que irá se ausentar
deve sinalizar dentro do sistema sua ausência, preenchendo a justificativa e selecionando
o nome do substituto, sendo restrito a uma única pessoa que receberá todas suas atividades
durante o período de ausência, que também deverá ser preenchido.
3.3.3 Categorização
Após a aprovação da requisição de compra ser realizada, o sistema passa para a etapa de
categorização, que é definida por um gateway de decisão que foi construído para verificar
os campos definidos no formulário de forma a definir a qual fluxo o workflow deverá
seguir. Essa etapa é realizada automaticamente pelo sistema e não está atrelada a nenhum
usuário, sendo feito de forma autônoma a partir das regras já pré-definidas pela equipe de
sistema. As categorias apresentadas na figura 21 são definidas como:
3.3.3.1 Compras c/ Ativo
Ativos são os materiais ou equipamentos aplicados nas atividades da empresa ou para fins
administrativos da mesma que possuam vida útil superior a um ano. São critérios
comumente utilizados para classificação de ativos:
• Existir retornos econômicos para a empresa da utilização do mesmo;
• custo do item puder ser mensurado confiavelmente;
• Custos referentes à aquisição ou melhoria de bens ou direitos,
• Cuja vida útil ultrapasse o período de 12 (doze) meses e de valor unitário mínimo
de R$ 1.200,00.
A Requisição de Compra de Ativo Imobilizado deve ser enviada para aprovação do setor
de Controladoria para avaliação das informações, bem como preenchimento dos campos
49
de sua responsabilidade e posteriormente ser encaminhado para o setor Financeiro, que
finalizará o preenchimento dos campos de sua responsabilidade. Após a aprovação do
financeiro, o workflow realiza novamente a aplicação das regras estabelecidas
anteriormente para categorização da RC, dessa vez já com a aprovação de Ativo, indo
diretamente para as outras categorias disponíveis.
3.3.3.2 Regularização
As requisições de compra de regularização são categorizadas dessa maneira para os casos
onde houve solicitação diretamente do requisitante para o fornecedor em nome da
empresa, sem envolvimento ou participação do setor de suprimentos. Além disso, é
destinada a compra de itens de forma fora do padrão, como medidas de emergência que
envolvam a operação de forma a combater ou contingenciar algum acidente ou evento
não previsto. São casos excepcionais, os quais necessitam de entregas rápidas para
responder a esses eventos. Somente nesses casos o requisitante possui autorização para
realizar esse tipo de compra, não devendo ser utilizado para outras situações, conforme
orientação da empresa.
Após o recebimento/prestação do item, o requisitante deverá iniciar no sistema, o fluxo
de Solicitação de compra com esta categoria marcada, informando o valor e o fornecedor
envolvido. Este caso não passará por cotação indo, após a aprovação dos gerentes,
diretamente para a etapa de criação do pedido de forma a “corrigir” o fluxo e gerar
rastreabilidade e controle para esses casos.
3.3.3.3 Delegada
As requisições de compra delegada, são utilizadas dentro da empresa para formalização
da solicitação de um tipo específico de requisição, vale ressaltar que essa modalidade
deverá ser utilizada exclusivamente para prestação de serviços. Essa modalidade destina-
se onde cabe ao requisitante apenas a solicitação de um serviço, mas que não lhe fique
incumbido detalhar as informações técnicas requeridas para tal, sendo de
responsabilidade de um outro colaborador ou área da empresa, como por exemplo
contratação de cursos e treinamentos externos, que são de responsabilidade da área de
Recursos Humanos, o qual possui melhor entendimento da formalização e descrição de
tais solicitações. Nesse caso, o requisitante deve entrar em contato com a área responsável
indicando sua necessidade e a área responsável deverá instanciar o processo de solicitação
50
de compras no sistema. O quadro com a relação de cada um dos serviços delegados é
apresentado na figura 26.
Figura 26 - Serviços delegados por área Fonte: Elaboração Própria
Nessa atividade o usuário deverá selecionar apenas um dos três fornecedores listados na
primeira etapa, já aprovado pelos gerentes, para dar prosseguimento ao fluxo.
3.3.3.4 Catálogo
Requisições de catálogo são definidas como aquelas que possuem acordo de fornecimento
formalizado junto aos fornecedores de materiais para manutenção das condições de preço
e prazo por um determinado período de tempo, que podem ser reajustadas e revalidados
ou não ao término do acordo. Ao selecionar essa opção do formulário um botão passa a
ficar disponibilizado para o funcionário, onde o mesmo poderá ter acesso a todos os
catálogos cadastrados no sistema para download em formato de Excel. Após baixar o
arquivo, o usuário deve deixar na planilha apenas o(s) item(ns) que deseja inserir na
requisição de compra e fazer o upload dela no próprio formulário. Para esse caso, não há
necessidade da etapa de seleção de fornecedores e por isso a atividade é encaminhada
diretamente para a criação de pedido. Tipos de materias de catálogo:
• EPI e EPC
51
• Materiais de escritório
• Material de limpeza
• Uniformes
As regras das atividades de Compra Delegada, Regularização e Catálogo são as mesmas.
Nesse caso a única diferença entre elas são os campos obrigatórios a serem preenchidos
no formulário em cada etapa.
3.3.3.5 Normal
As compras de categoria Normal são aquelas que não apresentam nenhuma dos requisitos
listados previamente na requisição de compra. São materiais que não possuem acordo ou
contrato prévio de aquisição e necessitam passar pelas etapas de seleção de fornecedor e
cotação de preços, que devem ser realizadas pela área de suprimentos.
3.3.4 Seleção de Fornecedor
Esta atividade será delegada ao grupo de compradores, através do recurso de papel
funcional. Dessa forma a atividade ficará disponível na lista de tarefas de todos do grupo.
Assim que selecionado para realizar tal tarefa o sistema irá perguntar se o usuário deseja
associar a tarefa a sua lista pessoal de tarefas, caso o mesmo confirme a associação, a
tarefa deixa de se estar delegada ao grupo para estar somente ao usuário. Esse recurso
garante maior confiabilidade ao sistema de modo a evitar que uma mesma solicitação de
fornecedor possa estar sendo feita por dois compradores diferentes. A visualização dessa
atividade no fluxo fica aparente na figura 22.
Na execução da atividade, o comprador terá disponível acesso a visualização de todos os
dados já preenchidos nas etapas anteriores, e a partir deles deverá realizar a busca por
fornecedores daquele material ou serviço. Para os processos de contratação acima de R$
1.000,00, o comprador deverá realizar pelo menos três consultas com fornecedores que
fornecem na categoria do item solicitado, informar se é requerido proposta técnica e se é
necessário compliance.
A lista dos fornecedores já contratados estará disponível para utilização e consulta dos
compradores com suas informações já registradas no sistema. Para o caso do comprador
querer realizar a cotação com um fornecedor que não esteja incluso na base de cadastro,
o mesmo terá disponível no formulário a opção “Cadastrar novo fornecedor”, que irá
52
solicitar os campos, nome, CNPJ, Nome do Contato, Telefone e e-mail. Ao finalizar a
escolha dos fornecedores, o comprador deverá seguir a atividade para a etapa de Cotação
de Materiais ou Serviços.
Nesse momento, o workflow do processo de compras, instância 3 ou mais subprocessos
(um para cada fornecedor) de Cotação de Materiais ou Serviços, desse modo é possível
seguir o fluxo de maneira independente para cada fornecedor, sem gerar entraves ou
gargalos, caso um dos fornecedores demore ou atrase em disponibilizar as informações
necessárias.
3.3.5 Subprocesso
A descrição do processo de cada etapa da cotação do material será abordada mais adiante
a fim de dar prosseguimento a explicação e raciocínio lógico do fluxo de compras. A
escolha pelo uso de um subprocesso para representar esse conjunto de atividades, foi pela
possibilidade de disparar múltiplas instâncias de forma paralela e dinâmica. Isso significa
que é possível designar o processo de cotação para mais de um fornecedor por vez, de
forma que não seja necessário esperar o término de um para início de outro. Além disso,
a quantidade de fornecedores pode variar, dependendo do material e serviço, de forma
não prevista. Por conta disso, era necessário maior flexibilidade e dinamismo quanto as
atividades de cotação. Por fim, foi definido como melhor opção a utilização desse recurso,
tendo o resultado esperado do subprocesso de cotação a comprovação dos requisitos
legais do fornecedor perante as políticas exigidas pela empresa Y e o valor cotado para o
item pelo fornecedor.
3.3.6 Seleção de Itens Aprovados
Após finalizar a avaliação e seleção dos itens em cada instância, o fluxo irá seguir para a
atividade de Seleção de Itens Aprovados. Vale destacar que o fluxo só estará habilitado
para prosseguir para essa atividade quando todas as instâncias abertas para cada
fornecedor já estiverem finalizadas (no caso de aprovação de cotação do material) ou
reprovadas (no caso de nenhum material ter atingido o melhor preço ou terem sido
rejeitadas pelo fornecedor). Nela estará disponível ao comprador o formulário de
Solicitação de Compra, que deverá constar todos os itens acordados em cada instância do
subprocesso, com seu preço negociado e de qual fornecedor veio tal informação. De
forma a facilitar a visualização dos dados do comprador, o formulário de Solicitação de
53
Compras, foi projetado de forma a coletar todos os itens indicados nas instâncias, de
forma automática e projetá-los no formulário. Dessa maneira, o comprador pode ter uma
visão geral dos materiais selecionados.
Além disso, o comprador deverá selecionar se existe necessidade de uma nova alçada de
aprovação para a requisição de compra. Caso nenhum dos requisitantes tenham atingido
o preço esperado ou que apresente valores acima do praticado pelo mercado, o comprador
terá a possibilidade de retornar a tarefa para a atividade de Seleção de Fornecedor, de
modo a realizar nova busca por fornecedores. Nesse caso, todas as informações
registradas no formulário de solicitação de compras serão perdidas, de forma a não
ficarem mais disponíveis para o comprador.
3.3.7 Aprovação de Alçada da Requisição de Compra
Ao finalizar a atividade, o fluxo segue para um gateway de regras definidas. Em caso do
preço acordado com o fornecedor ser superior a 10% do preço informado pelo
requisitante, o fluxo seguirá para alçada de aprovação, independente de outros fatores. No
caso da variação do preço não atingir os 10%, o comprador poderá sinalizar a necessidade
de uma nova alçada de aprovação, caso o mesmo considere a necessidade. Essa opção foi
incluída para os casos de aquisição/contratação de itens com alto valor agregado, os quais
variações de até 10% possam ser analisados caso a caso visando garantir a organização,
mais segurança e controle orçamentário. Caso o comprador sinalize que não há
necessidade de uma nova alçada e a variação seja menor que 10% o fluxo seguirá para a
criação de pedido.
As regras definidas de responsabilidade de aprovação seguem os mesmos requisitos
definidos na alçada de solicitação de compras, tanto para os executores da aprovação
quanto para a definição dos mesmos.
3.3.8 Criação do Pedido de Compras
O pedido de compra é a formalização do processo de fornecimento dos materiais e
serviços cotados, devendo conter as informações levantadas nos formulários e no
processo de compra como quantidade, prazos, preços, data de entrega, forma de
pagamento e outros. Esse tipo de formalização é exigido em muitas organizações e
garante segurança tanto para a empresa Y quanto para o fornecedor de forma evitar
54
divergências de informações e garantir requisitos legais exigidos pela legislação
brasileira. A visualização dessa atividade no fluxo fica aparente na figura 23
O sistema atual utilizado para elaboração dos pedidos de compras é o Alterdata, não tendo
relação ou integração com o sistema da SoftExpert. Por esse motivo, fica de
responsabilidade do comprador preencher as informações requeridas no sistema do
Alterdata, utilizando os dois formulários de Solicitação de Compras e o de Requisição de
Compras que ficam disponíveis para consulta nessa atividade para o comprador. Após a
geração do documento do Pedido de Compras, no Alterdata, o comprador deverá anexá-
lo (Anexo Obrigatório), na atividade e seguir para etapa de aprovação da alçada do pedido
de compra.
3.3.9 Alçada do Pedido de Compra
A aprovação do pedido deverá ser realizada tanto no sistema da SoftExpert quanto no
sistema do Alterdata, lembrando que nessa etapa de aprovação da alçada na SoftExpert é
apenas para fins de registro, controle e continuidade do fluxo. Para o envio do pedido ao
fornecedor, os responsáveis deverão acessar o Alterdata e realizar a aprovação, por esse
sistema.
De forma similar as outras alçadas, a exigência de aprovação também deverá ser realizada
de forma cumulativa e sequencial. Caso algum erro seja encontrado, o responsável poderá
sinalizar o erro e retornar a atividade para correção na etapa de criação do pedido. Caso
o retorno aconteça, o pedido deverá passar pela aprovação de todos os responsáveis
novamente.
A alçada de aprovação deverá obedecer aos seguintes critérios:
- Pedidos de Compra até R$ 1.000 = Aprovação do Analista de Suprimentos;
- Pedidos de Compra até R$ 5.000 = Aprovação do Coordenador Responsável por
Suprimentos;
- Pedidos de Compra até R$ 10.000 = Aprovação do Gerente Geral de
Planejamento;
- Pedidos de Compra até R$ 50.000 = Aprovação do Diretor de Planejamento;
55
- Pedidos de Compra até R$ 250.000 = Aprovação do Diretor de Planejamento e
Diretor Financeiro, podendo este último ser substituído pelo Diretor Presidente;
- Pedidos de Compra acima de R$ 250.000 = Aprovação via reunião de Diretoria
ou reunião de Conselho de Administração.
Após aprovação do pedido de compra pelos responsáveis, a atividade segue para a última
etapa, onde será encaminhado para um gateway de forma a ser avaliado o tipo de
Requisição preenchida no formulário. Para os casos de compra Normal ou de Catálogo,
o fluxo segue para a atividade de subprocesso “Recebimento de Material ou Serviço –
Subprocesso” onde o responsável pelo recebimento da localidade deverá realizar a
verificação das especificações do produto solicitado, de forma a conferir se a entrega está
de acordo com o que foi pedido. Se estiver tudo certo, a atividade seguirá para pagamento
e por fim, a finalização do subprocesso e do processo de fluxo de compras.
Para os casos de compra delegada e regularização, a etapa segue para a atividade de
“Recebimento de Material ou Serviço”, que apesar do nome e objetivo similares ao outro
caminho possível, requer as regras e fluxos parametrizados de maneira diferente por conta
da forma como é definida o recebimento. Ambas serão analisadas mais à frente. Após a
finalização do subprocesso, o fluxo retorna para a fluxo de suprimentos, onde por fim se
encerra e notifica aos usuários participantes que a instância chegou ao fim.
3.3.10 Cadastro no Alterdata: Fornecedor e/ou Item
O comprador deverá selecionar dentro do sistema do Alterdata uma das opções já
cadastradas como descrição do item, fornecedor, categoria, tipo, etc. Caso um desses
elementos não esteja registrados na lista, o comprador deverá seguir o fluxo para a
atividade de Cadastro no Alterdata Fornecedor e/ou Item, a qual fica de responsabilidade
da área de Controladoria. Eles deverão cadastrar as informações dentro do sistema do
alterdata, seguindo regras e normas já definidas e enfim retornar a atividade para Criação
do Pedido de Compras.
56
3.4 Cotação de Materiais ou Serviços - Subprocesso
Figura 27- Fluxo de Cotação de Materiais e Serviços Fonte: Elaboração Própria
57
O processo de cotação de materiais ou serviços é restrito a utilização a partir do fluxo de
suprimentos, dessa forma, os usuários não tem acesso ou permissão para instanciar esse
fluxo de forma isolada. Todas as informações geradas nesse processo, ficam armazenadas
em tabelas diferentes do processo de fluxo de compra. Isso ocorre por exigência de
funcionamento do sistema e não pode ser alterado pelo construtor do fluxo. Para garantir
o retorno de dados ao fluxo de suprimentos, o sistema faz uso das informações
preenchidas como atributo ao longo do processo e encaminha tais informações para os
mesmos atributos no fluxo de compras. De forma mais simples, o preenchimento dos
campos do formulário é copiado para os atributos do processo de cotação, que por sua
vez, ao chegar ao término da instancia, são replicados nos atributos do processo do fluxo
de suprimentos. O processo de cotação de materiais e serviços é representado nas figuras
27 e 28.
Figura 28 - Fluxo de Cotação de Materiais e Serviços Fonte: Elaboração Própria
58
3.4.1 Cotação de Materiais e Serviços
Na primeira atividade, a tarefa é delegada para o mesmo comprador que executou a
atividade Seleção de Fornecedor. Nessa tarefa, o usuário tem acesso ao novo formulário
denominado “Formulário de Cotação de Material ou Serviço” a qual fica responsável pela
cotação dos materiais requisitados. Para isso fica de responsabilidade do comprador a
busca por fornecedores dos materiais e itens listados, disponíveis no mercado. As
tentativas podem ser realizadas via e-mail ou telefone corporativo de forma a solicitar ou
gerar a cotação dos itens.
Para assegurar o cumprimento dos requisitos, antes de qualquer fornecimento é de
responsabilidade do comprador comunicar ao fornecedor as seguintes informações
(quando aplicável):
a) produtos e serviços a serem fornecidos;
b) as competências requeridas, incluindo qualquer qualificação de pessoa;
c) aprovação dos produtos/serviços, métodos, processos, equipamentos e liberação de
produtos;
d) as formas de interação com a empresa Y
e) controle e monitoramento do desempenho a ser aplicado no fornecedor;
f) e as atividades de verificação ou validação que a empresa Y ou seus clientes, pretendam
desempenhar nas instalações do provedor externo.
Da mesma forma, o fornecedor deve retornar para preenchimento pelo comprador a
seguintes informações:
• Forma de Pagamento (caso seja depósito, deverá informar banco, agência e conta)
• Prazo de Pagamento (10, 20, ou 30 dias)
• Subcontratação
• Prazo de Entrega
• Contato
• Telefone
• Valor do material proposto pela empresa
59
Após o recebimento dessas informações, o comprador deverá preencher o formulário
conforme material enviado pelo fornecedor, para seguir para a próxima etapa de avaliação
da documentação.
3.4.2 Avaliação da Documentação
Cada material ou serviço listado no formulário exige o preenchimento de uma categoria
de compras, que indicada pelo requisitante no momento de preenchimento do formulário
de solicitação de compras. Toda categoria possui uma listagem de documentos
requisitado, onde eles são categorizados como documentos básicos e específicos que
devem ser solicitadas ao fornecedor pelo comprador.
A documentação básica é aplicável a todos os fornecedores e categorias. A
documentação específica é definida conforme as necessidades específicas das categorias
de fornecimento. A responsabilidade por indicar os requisitos específicos de avaliação é
da área de Qualidade, Saúde, Segurança e Meio Ambiente em conjunto com a área de
Suprimentos, tomando como base a aplicação dos aspectos legais para a categoria em
avaliação. O requisito básico de avaliação é possuir comprovante de inscrição e situação
cadastral (CNPJ), exigido para todos os fornecedores. Os documentos deverão ser
enviados ao e-mail do comprador responsável, para que o mesmo revise-os de forma a
validar se os documentos de fato são os exigidos pelo sistema (devido a falta de um padrão
específico para a listagem de documentos recebida, a etapa de verificação deve ser
realizada pelo comprador e não pelo sistema) e por fim, o mesmo deverá inserir toda a
documentação requerida dos fornecedores no formulário na forma de anexo
Os fornecedores são responsáveis pelo fornecimento dos documentos de qualificação. Em
caso de falsidade nas declarações, o fornecedor será notificado oportunamente e terá
direito a expressar os argumentos a seu favor, que considere necessário. Caso seja
comprovado a falsidade nas declarações, o mesmo terá seu cadastro mapeado e impedido
se ser utilizado novamente no sistema.
Seguindo o fluxo, o processo poderá seguir dois caminhos. Para um determinado conjunto
de categorias, a avaliação da documentação pode ser feita de forma simples pelo próprio
comprador. Para outros casos em específico, a análise da documentação deverá ser
60
realizada pera área de Qualidade e Segurança. Essa etapa é requerida, pois foi definido
que não cabe ao setor de suprimentos a avaliação de certos documentos, como contratação
de serviços específicos que exijam conhecimentos legais de normas e regulamentações,
ou nível de prestação de serviço mínimo acordado com os clientes em contrato. Nesse
caso o comprador deverá sinalizar no formulário que há necessidade de avaliação e
aprovação pela equipe de Qualidade, seguindo o processo pra a etapa de Avaliação da
documentação. Para os que não possuem tal requerimento, o fluxo segue para etapa de
Negociação com fornecedor.
3.4.3 Avaliação de Documentos
A avaliação de documentos pode seguir por dois caminhos, tanto de forma paralela ou
exclusiva, a partir do campo sinalizado pelo comprador. Na atividade de “Avaliação de
Documentação pelo SMS”, como o próprio nome indica seguirá para a área de Segurança,
Meio Ambiente e Saúde, de forma a ser avaliado os requisitos técnicos exigidos perante
as normas regulamentadoras do ministério do Trabalho, a fim de garantir o cumprimento
da legislação de segurança e saúde ocupacional. Na atividade de “Avaliação
Documentação Técnica” o fluxo seguirá para um responsável definido pela área de
suprimentos. Este caso é exigido para compra e contratação de bens/serviços, os quais
possuem especificações e necessidades que devem ser avaliadas por especialistas ou o
responsável pelo setor da empresa. São os casos de compra de computadores,
maquinários, Softwares ou até mesmo consultorias
Para esse caso, o responsável deverá indicar notas nos valores de 0 ,1 ,2 ,3 ,4 ou 5 no
formulário para os critérios abaixo, que possuem respectivos pesos dentro da avaliação.
Vale destacar que a valoração dos pesos não foi definida pela equipe, somente replicada,
sendo uma prática já adotado previamente pela empresa.
• Conceito no mercado (5%)
• Metodologia aplicada atende aos requisitos regulatórios/técnicos (20%)
• Tempo de Implantação (25%)
• Qualificação de Equipe Técnica envolvida (20%)
• Qualidade das entregas ofertadas (20%)
• Impacto no Custo Opex (5%)
61
• Entrega da proposta no prazo/ Atendimento (5%)
Cada uma das notas representa respectivamente:
0 - Não atendido
1- Péssimo
2- Ruim
3- Médio
4- Bom
5- Ótimo
Ao final, é realizado a média ponderada dos valores sinalizados pelo especialista, devendo
o mesmo possuir resultado mínimo de 70% para obter o resultado de “Aprovado”. Caso
não atinja esse resultado o mesmo será sinalizado como “Reprovado”. Caso o especialista
sinalize o campo com valor “0” o mesmo será desconsiderado da média.
Caso ambas as atividades sejam requeridas, o fluxo ficará no aguardo da conclusão de
ambas no gateway inserido após as atividades. Caso apenas um tenha sido requerido, o
gateway não irá executar nenhum tipo de espera. Após a aprovação, o fluxo retorna para
a atividade de avaliação da documentação pelo comprador, o qual deverá sinalizar que
não há mais necessidade de avaliação de nova documentação no formulário e seguirá o
fluxo para a etapa de negociação.
3.4.4 Negociação
Nessa etapa, o comprador deverá entrar em contato direto com fornecedor de forma a
explorar oportunidades e tentar adquirir mais benefícios dentro da solicitação, como
reajuste no preço, extensão da forma de pagamento ou redução do custo do frete, de forma
que a proposta seja interessante à ambas as partes. Ao ser finalizado, o comprador deverá
inserir no formulário, a informação do valor negociado de cada material, mesmo que não
tenha ocorrido redução do valor. Isso acontece, pois esse campo é utilizado para análise
do indicador de Saving, correspondente ao quanto o comprador conseguiu de redução de
custos e é apresentado com um modelo gráfico no módulo de Business Inteligence do
sistema. Após finalizado a etapa de negociação o fluxo seguirá para a atividade seguinte.
62
3.4.5 Aprovação da Negociação pelo Fornecedor
Na atividade de aprovação, o comprador poderá baixar o formulário com template de
proposta padrão já com as informações negociadas com o comprador e enviar para o e-
mail do fornecedor para aprovação. O fornecedor deverá verificar os campos preenchidos
e informar se a proposta foi aceita ou não. Caso informe algum erro ou divergência das
informações o fornecedor deverá sinalizar o ocorrido ao comprador o qual deverá retornar
o fluxo para a atividade anterior, para ser analisada e feita as correções dentro do
formulário. Em caso de aprovação deverá seguir para a etapa seguinte.
3.4.6 Escolha do Fornecedor
Nesse ponto, ficarão listados ao comprador todas as informações referentes aos materiais
cotados daquele fornecedor, com seu preço, descrição e outros. Caberá ao comprador
avaliar as outras instâncias de compra abertas para cada fornecedor e realizar a análise
comparativa de melhor provedor dos itens listados. Deve-se lembrar que todos os
fornecedores terão os mesmos itens, porém com preços e documentação informados
exclusivamente por eles. Ficará a cargo do comprador selecionar dentro dessa atividade
(referente a um único fornecedor) qual o(s) item(ns) permanecerá na cotação. Caso um
dos fornecedores não apresente nenhum item que deve permanecer na cotação, o mesmo
deverá ser reprovado e informado de que não participa mais dessa cotação. Após a seleção
dos itens de cada fornecedor, o comprador deverá indicar a necessidade de avaliação de
Compliance.
Todos os fornecimentos que sejam enquadrados nas regras abaixo deverão ser avaliados
pelo programa reputacional da área de Compliance, através da abertura de chamado
específico para área de Qualidade:
• Contratação contínua (prazo igual ou superior a 12 meses ou mais de 4
fornecimentos previstos);
• Compras que não fazem parte do quadro de equipamentos comuns, com valor do
pedido superior a R$ 30.000,00;
• Qualquer contratação que disponibilize mão de obra nas instalações de
responsabilidade da empresa Y independente de valor e prazo;
• qualquer contração em que ocorra subcontratação de fornecedores.
63
O fluxo então poderá seguir por dois caminhos, ou vai direto para aprovação, ou caso seja
necessário irá para avaliação de compliance. Em caso de aprovação a instância é
finalizada e suas informações são salvas e enviadas para o fluxo de suprimentos.
3.4.7 Avaliação do Fornecedor
A atividade de avaliação do fornecedor tem o objetivo de análise de informações de
possíveis fraudes e corrupção por parte do fornecedor. É avaliado se o mesmo tem algum
envolvimento com questões jurídicas que podem prejudicar as negociações ou até mesmo
impactar na imagem da empresa Y perante o mercado. A responsabilidade dessa tarefa é
delegada ao papel funcional de Compliance o qual é formado pelos gestores e
supervisores da área de qualidade. Após a análise, caso não sejam encontradas
informações ou registros envolvendo o fornecedor o usuário pode sinalizar aprovação do
Compliance, finalizando o fluxo. Caso sejam encontradas informações que posam
comprometer a integridade jurídica e social da empresa Y, o usuário deverá anexar tais
informações na atividade e seguir para a análise da diretoria da diretoria.
3.4.8 Aprovação da Diretoria
A execução da atividade será delegada ao papel funcional de diretoria de operações, o
qual é composta pelo diretor de operações de planejamento da empresa Y. O mesmo
deverá analisar o caso, considerando os ganhos e os riscos atrelados. Caso sinalize como
“Reprovado” a instância será encerrada. Caso seja “aprovado” o fluxo será finalizado,
retornado para
3.5 Recebimento de Material ou Serviço (1° Tipo) - Subprocesso
Após a aprovação do pedido pelos responsáveis, a atividade segue para o subprocesso de
recebimento de material ou serviço, e permanece na caixa de atividades do responsável
pelo recebimento definido pelo requisitante, no momento do preenchimento do
formulário na atividade de solicitação de compra. O objetivo deste subprocesso é verificar
64
se o recebimento está de acordo com o solicitado e por fim seguir para pagamento. O
processo de Recebimento de Material ou Serviço (1° Tipo) é representado nas figuras 29
e 30.
Figura 29 - Recebimento de Material ou Serviço (1° Tipo) Fonte: Elaboração Própria
65
O modelo de recebimento físico do material dos fornecedores, envolve a equipe de
logística responsável do setor, e adota a metodologia de “contagem às cegas”. Ela se
apresenta de modo a ter um supervisor com as informações do pedido a qual fica à sua
disposição e um ou mais funcionários realizam a contagem ou pesagem dos itens sem
saber o valor exato do pedido. Esse método reduz a chance de contagens tendenciosas ou
acordos ilegais entre fornecedores e funcionários de modo a entregar menos do que foi
solicitado. Em caso de o resultado da contagem diferir do valor do pedido, a equipe
responsável é orientada a não receber o material e solicitar a retirada dos itens da área.
Além disso a equipe deve entrar imediatamente em contato com área de compras,
informando o ocorrido, que por sua vez irá notificar o fornecedor do erro e solicitar a
correção da quantidade de entrega. Fica de responsabilidade do responsável pelo
recebimento também assinar a nota fiscal atestando recebimento com data e nome legível;
Figura 30 - Recebimento de Material ou Serviço (1° Tipo) Fonte: Elaboração Própria
66
3.5.1 Inclusão do Pedido de Compra
A atividade de inclusão do pedido de compra será executada pelo mesmo executor da
atividade “Criação do Pedido de Compras” que foi o responsável da área de suprimentos
que gerou o pedido. Este terá a responsabilidade de preencher o “Formulário de Pedido
de Compras e Inspeção de Recebimento” de modo a incluir as informações do pedido,
como nome do Fornecedor, forma de pagamento, número do pedido, anexo do pedido e
designar o responsável pelo recebimento ( pode acontecer do responsável designado pelo
requisitante ser diferente do responsável pelo recebimento de fato). De forma a facilitar a
escolha do recebedor pela área de suprimentos, existe uma relação de responsáveis pelo
recebimento em cada localidade a qual pode ser utilizada como padrão de orientação.
Após isso deve seguir o fluxo para atividade de checklist de recebimento
3.5.2 Checklist de Recebimento
Essa atividade será executada pelo responsável pelo recebimento indicado no formulário
da atividade anterior. O responsável deverá realizar o procedimento de recebimento físico
do pedido conforme descrito anteriormente. Após isso o mesmo deverá assinalar “Sim”
ou “Não” no formulário as perguntas abaixo:
- O CNPJ da Empresa Y (Contratante) na nota fiscal, confere com CNPJ no pedido
de compras?
- O CNPJ do Fornecedor (Contratada) na nota fiscal, confere com CNPJ no pedido
de compras?
- O produto/serviço entregue/realizado está de acordo com o que foi solicitado?
- A quantidade dos itens no pedido de compra está conforme a entrega física?
- A quantidade dos itens no pedido de compra está conforme a informação na nota
fiscal?
- O prazo de entrega especificado no pedido foi atendido?
Além disso deverá preencher os campos de número da Nota Fiscal, além digitaliza-la via
scanner ou foto legível do documento e anexar ao formulário.
67
3.5.3 Aprovação do Recebimento
A etapa de aprovação cai para os líderes dos funcionários que realizaram o recebimento,
os quais devem avaliar os campos preenchidos de forma a verificar e validar as
informações, além de servir como controle dos acontecimentos. Caso algo esteja
preenchido de maneira errada ou faltando, o mesmo deverá retornar a atividade para as
etapas anteriores para correção. Se o preenchimento estiver correto deverá clicar em
“Recebimento Aprovado” e o fluxo seguirá para a próxima atividade.
3.5.4 Tratativa da Nota Fiscal
A equipe de controladoria, fica responsável pela conferência da nota fiscal anexada pela
operação no formulário, devendo conferir o preenchimento dos campos, de forma a
averiguar se o pedido realizado no Alterdata coincide com o que foi informado nas
atividades anteriores. Caso algum item tenha sido preenchido errado ou tenham anexado
uma nota diferente do que foi atrelado ao pedido, a equipe deverá retornar à atividade
para o responsável das tarefas anteriores. Caso o preenchimento dos campos e os anexos
estiverem dentro das condições ideais, deve seguir para a próxima atividade.
3.5.5 Programação de Pagamento
A programação de pagamento será encaminhada para a área de financeiro a qual deve
informar no formulário a data programada para o pagamento e finalizar seu fluxo.
Após o encerramento da atividade de programação de pagamento, o subprocesso se
encerra e o fluxo retorna para o processo de suprimentos, onde por fim também é
finalizado. Dessa forma o sistema envia uma notificação para o iniciador do processo,
informando o término de sua solicitação.
Para fins de consulta, auditoria e construção de indicadores, toda instância de fluxo
finalizado ou não, fica armazenado na forma de registro em tabelas.
3.6 Recebimento de Material ou Serviço (2° Tipo)
O 2° tipo de registro de recebimento de material ou serviço foi elaborado para suprir casos
específicos da solicitação de compra e apesar de possuir o mesmo objetivo do 1° tipo
68
possui algumas mudanças em relação aos fluxos e regras definidas. O recebimento de
Material ou Serviço (2° Tipo) é apresentado na figura 31.
Figura 31 - Recebimento de material ou Serviço (2° Tipo) Fonte: Elaboração Própria
69
Este fluxo pode ser iniciado como um subprocesso do Fluxo de Compras ou como uma
instância isolada sem conexão a outro processo em específico, diferente do anterior. Na
primeira análise levantada pela equipe esses casos não haviam sido mapeados e sua
necessidade só foi requerida durante as fases de teste, sendo desenvolvido após o anterior.
Ele visa suportar o recebimento dos casos de Compra Delegada, Regularização de
Compra, e Compras com Fornecimento Contínuo além de servir como registro e
formalização para suprir o recebimento de materiais que já haviam sido solicitados e
requeridos antes/durante a implementação do sistema os quais não necessitavam de passar
por todo o fluxo de compras feito antes da implementação do software.
O workflow foi parametrizado de forma que assim que iniciado, é realizado a busca pelo
atributo de “Responsável pela Atividade”, o qual em caso de estar preenchido enviará a
execução da atividade para esse usuário (Esse atributo é preenchido automaticamente pelo
Fluxo de Suprimentos no caso de um subprocesso). Caso o atributo esteja vazio, o
executor responsável será o próprio iniciador da atividade. Dessa forma é possível
designar a atividade para os executores em caso de Compra Delegada ou Regularização
e dar possibilidade de executarem o recebimento para os outros casos.
3.6.1 Inclusão do Pedido de Compras
Nessa atividade o executor deverá sinalizar se o recebimento possui ou não pedido de
compra. Em caso de confirmação, deverá indicar o nome do fornecedor, o número, valor
e anexo do pedido, quem foi o responsável pelo recebimento e responder o checklist de
recebimento de forma similar ao do quadro 3.5.2, podendo anexar também possíveis
boletos bancários ou notas fiscais. Em caso de não haver pedido, deverá indicar o motivo,
dentro da lista disponível (São despesas fontes de aluguel, multas, taxas, viagens e outros
mais 10 casos), indicando o nome do fornecedor, o nome do responsável pela aprovação,
pelo recebimento e o anexo de sua nota fiscal torna-se obrigatório.
3.6.2 Aprovação de Recebimento
Após preenchimento dos campos obrigatórios, o executor deverá seguir a atividade para
a etapa de aprovação do recebimento. O fluxo seguirá por um gateway que irá avaliar se
o executor sinalizou que há ou não pedido de compra. Para os casos onde há pedido de
compra, o aprovador deverá analisar os campos preenchidos no formulário e sinalizar sua
aprovação quanto ao recebimento do material/serviço. Para o caso onde não há pedido,
70
deverá preencher o campo de “descrição do motivo” e sinalizar seu recebimento. O
responsável pela aprovação é informado na etapa de inclusão de pedido, e em ambos os
casos o responsável poderá retornar a atividade para correção de algum campo.
3.6.3 Tratativa da Nota Fiscal e Programação de Pagamento
Para ambas as atividades, as regras e executores foram parametrizadas de forma similar
aos tópicos 3.4.4 e 3.4.5 respectivamente. As atividades de tratativa da nota fiscal
poderiam ser uma única atividade, porém foi definido de forma a ser dividido para cada
caso para facilitar a área de controladoria a identificar se algum campo deixou de ser
preenchido, ou foi preenchido de forma incorreta, de forma a evitar erros e facilitar sua
correção. Por fim o fluxo é encerrado.
3.7 Dificuldades e Problemas encontrados
Ao longo de todo o projeto foram desenvolvidos possíveis modelos e propostas de ideias
que pudessem ser implementadas no fluxo de suprimentos, de forma a tornar o processo
mais ágil, confiável, controlado e mais simples de ser utilizado por todos os participantes
do fluxo. Muitas foram bem-sucedidas e atingiram o ideal proposto, como a transição da
lista de itens de cada fornecedor de um subprocesso para o processo original, de forma
automática e sem perda de dados. Vale destacar, que a aplicabilidade de tal função exige
um amplo conhecimento de diferentes módulos da ferramenta, além de necessário
conhecimento em análise e tratamento de dados. Por outro lado, algumas outras ideias se
apresentaram como grandes desafios e barreiras identificadas pelo grupo. Para fins de
registro e documentação neste trabalho, é apresentado os principais pontos de aplicação
identificados.
3.7.1 Utilização do fornecedor como agente ativo da ferramenta
Desde o projeto inicial foi proposto a utilização dos recursos de forma a prover acesso
(Limitado) aos responsáveis pelo setor de vendas dos fornecedores. O desenvolvimento
do fluxo com o fornecedor atuando, não apresentou dificuldades relevantes para o
processo de construção, tanto que o primeiro projeto entregável para teste foi
disponibilizado com esse recurso. O problema dessa parametrização se apresentou não de
forma sistêmica, mas sim de maneira cultural perante os fornecedores. Para as empresas
com maior presença de mercado, apesar de uma resistência inicial, foram adeptos a
71
ferramenta e com um pouco de treinamento e melhorias nos manuais, se adaptaram
rapidamente ao novo modelo.
O maior problema foi encontrado com relação aos pequenos varejistas que não aderiram
ao novo sistema. Por conta do modelo de negócio adotado pela empresa, a presença de
mercado da organização se encontra em sua maioria, longe dos grandes centros urbanos,
de forma a negociar com varejos que não possuem necessariamente áreas de venda
minimamente estruturadas. Para esses casos foi relatado resistência muito forte dos
fornecedores, gerando desistências de venda ou longos atrasos pelo não entendimento da
ferramenta. Foram poucos os casos onde pequenos varejistas conseguiram finalizar as
etapas, o que começou a impactar diretamente no tempo de entrega das solicitações e
consequentemente na operação. Por conta disso, foi definido a suspensão temporária da
utilização dos fornecedores como usuários diretos do sistema.
De forma a não gerar grandes impactos no fluxo, as tarefas de responsabilidade antes do
fornecedor passaram a ser agora obrigação dos compradores, que devem entrar em
contato com os fornecedores e inserir tais informações na ferramenta. Essa decisão
estabilizou o fluxo de compra, requerendo poucas mudanças nos fluxos. As atividades
que foram inicialmente delegadas a execução dos fornecedores estão marcadas na figura
32, durante o fluxo de cotação dos materiais.
72
Figura 32 - Atividades executadas pelo Fornecedor Fonte: Elaboração Própria
73
3.7.2 Cadastro do fornecedor como usuário no sistema
Apesar de aparentar ser um único software, o sistema é dividido em módulos construídos
e vendidos separadamente. Tal recurso garante maior flexibilidade e potencial de
aquisição de módulos específicos para as empresas contratantes. Alguns módulos
funcionam “melhor” juntos do que outros, no sentido de disponibilizar, buscar ou enviar
alguma informação de forma nativa, sem que seja necessário customização do cliente,
como o módulo de workflow e processos que atuam de forma conjunta para entrega valor
aos clientes. Outros, apresentam limitada interação entre os recursos sendo necessário a
criação de parametrização entre eles.
O sistema possui algumas ferramentas de forma a facilitar a construção dessas integrações
entre os diferentes módulos, fazendo uso de Web Services dentro do próprio Software.
Como o objetivo inicial era a utilização do fornecedor como agente ativo do sistema, a
criação de seu usuário, portanto, deveria fazer parte do fluxo de Suprimentos. Entretanto
não há disponível no módulo de processo e workflow, recurso que faça o cadastro de
novos usuários. Para isso, é utilizado o módulo de Administração, responsável pela
criação, edição, categorização ou exclusão de usuários, áreas, funções, unidades
organizacionais e clientes. Para ter acesso a esse módulo e a esses recursos é necessário
obter a licença de Gestor do sistema, a qual foram disponibilizadas 4 acessos para tal (
Conforme contrato), enquanto as outras licenças não tem permissão de criação de
usuários, apenas execução de tarefas (São chamadas de licenças de Apoio, e não possuem
quantidade máxima estabelecida). Durante a implantação do fluxo, foi identificado pela
equipe um Web Service com a funcionalidade de inserção de novos usuários através do
módulo de processos.
Após muitas tentativas de configuração e parametrização, a equipe conseguiu configurar
esse recurso com sucesso. Para isso além das informações básicas era necessário
configurar a deixar pré-definido o login e senha de um usuário com licença de gestor.
Dessa forma a equipe de suprimentos que possui acesso de apoio, ou seja, de execução
de tarefas, estava conseguindo inserir novos usuários via fluxo de compras. Após
algumas semanas com esse recurso disponível e funcionando, houve um problema com a
configuração do portal dos usuários. Quando levantado esse “bug” no sistema à
SoftExpert, os mesmos disseram que era necessário atualizar o sistema para uma versão
74
mais recente, o qual já havia sido resolvido o problema com a configuração do portal.
Após a aprovação e atualização do sistema para a nova versão, o problema do portal foi
resolvido, porém o recurso de inserir o usuário via Web Service deixou de funcionar.
Quando reportado a SoftExpert o erro, após análises, disseram que só seria possível a
utilização do cadastro via Web Service a partir de um usuário com licença de Gestor. Esse
fato gerou alguns atritos entre as empresas, pois o fluxo de compras permaneceu parado
por um tempo, por não conseguirem cadastrar o fornecedor, uma vez que não haviam
licenças de gestor disponíveis e a contratação de uma nova adicional é paga.
Para não parar o fluxo de compras, foi disponibilizada uma das licenças de gestor para a
equipe de suprimentos com horários definidos para o cadastro, pois não é possível acessar
mais que as 4 licenças por vez. Após quase 2 meses a SoftExpert retornou o chamado
aberto pela empresa Y, com uma atualização do Software que permitia o cadastro dos
usuários com a licença de apoio via Web Service.
3.7.3 Implantação, Manutenção e Utilização
Um dos maiores desafios encontrados para o desenvolvimento do workflow foi a
construção de parametrizações de forma a considerar tanto a implantação do workflow, a
Manutenção das tabelas e a facilidade de Utilização pelos usuários. A forma mais simples
e rápida de utilização de um campo do formulário é via “campo aberto” o qual o usuário
é livre para escrever o que quiser. O problema encontrado para isso é que campos que
serão utilizados para verificação das regras e definição de caminhos, precisam ter valores
exatos. Na figura 33, se fosse preciso escrever o tipo de RC, o usuário deveria preencher
com por exemplo a palavra “Catálogo” de forma a ser entendida pelo sistema o qual terá
impacto no fluxo a ser seguido. Porém, o usuário poderia esquecer o acento ou errar
durante a escrita, o qual o sistema iria tentar validar com as regras definidas e resultaria
em erro, pois seria necessário escrever a palavra exata.
Figura 33 - Diferenciação do valor dos campos Fonte: Elaboração Própria
75
Por conta disso, para esses casos é recomendado a utilização de listas com valores
predefinidas, a qual o usuário apenas seleciona o valor requerido, de forma preencher os
campos mais rapidamente e evitar erros na validação do processo, facilitando tanto a
implantação quanto a utilização.
Figura 34 - Exemplo do uso de listas Fonte: Elaboração Própria
Para a utilização dessas listas suspensas, como apresentado na figura 34, é necessário
configurar uma tabela no módulo de formulário, com os registros a serem apresentados.
Dessa forma uma única tabela pode ser utilizada em mais de um formulário como lista. É
nessa etapa que se encontra um ponto de decisão importante a ser considerado para a
manutenção do sistema. Sempre que houver a necessidade de alteração de um dos
registros, será necessário acessar a tabela fonte, de forma a adicionar, alterar ou excluir o
item. No caso de tabelas que apresentem pouca ou nenhuma modificação a ser realizada
com o tempo, o esforço despendido com tais modificações é mínimo e são rápidas de
serem corrigidos. Porém, para os casos onde as alterações dos registros apresentem
caráter dinâmico, ou seja, que os valores apresentados sejam alterados com frequência, a
utilização das listas nesse formato torna-se bastante dispendiosa principalmente por conta
da quantidade de tabelas a serem alteradas e do número de alterações em cada uma.
Um exemplo que podemos utilizar é a lista de nome dos responsáveis pelo recebimento
dos materiais, que nada mais é que uma tabela com o nome dos possíveis responsáveis.
Por conta da grande quantidade de localidades em que a empresa Y está presente, tais
responsáveis sofrem mudanças frequentes, o que requerem alterações constantes na lista
de registro.
Conforme informado pelo consultor, muitas empresas utilizam-se deste método mantendo
um ou mais funcionários destinados apenas a esse tipo de controle ou até mesmo
76
contratam mais horas de consultoria apenas para atualizar essas tabelas. Porém é possível
utilizar outro recurso do sistema para a geração de listas a partir da utilização de filtros
via tratamento de banco de dados com a utilização do MySQL. No caso dos responsáveis
por exemplo, o sistema possui uma tabela nativa para registro de todos os usuários com
suas respectivas funções. Sem a utilização do filtro via SQL, é necessário construir outra
tabela apenas com os nomes que devem aparecer. Já com o filtro é possível utilizar as
tabelas nativas da ferramenta para retornar somente os nomes do usuário com uma
determina função. Dessa maneira, quando um novo usuário for cadastrado no sistema
com essa função, o mesmo será retornado automaticamente na lista que faz o uso dos
filtros. Segundo o consultor, apesar de apresentado essa opção de configuração, muitas
empresas optam pela utilização das listas por não possuírem pessoas com essa capacitação
em específica na empresa ou que estejam ligadas a manutenção da ferramenta.
De forma a gerar integração entre Implantação, Manutenção e Utilização ficou definido
que as listas via filtro de SQL deveriam ser utilizadas. Por conta das inúmeras listas e da
quantidade de formulários, a utilização do mesmo foi requerida boa parte das horas
contratadas pelo consultor, o qual ao passo que construía os filtros demonstrava seu
funcionamento e premissas básicas de utilização.
Para auxiliar nas alterações e construção de novos fluxos, a empresa Y adquiriu um
treinamento de SQL online para a instrução dos responsáveis pela manutenção e
construção de novos fluxos, de forma a evitar a dependência da consultoria para
alterações nas listas.
4 CONCLUSÃO
Devido a curta diferença de tempo entre a implementação do sistema e a entrega deste
projeto torna-se difícil avaliações de eficácia em relação ao sistema de BPMS. Porém
pode-se afirmar que a avaliação inicial pelos diretores com os resultados da implantação
foi muito bem recebida, à medida que já foi sugerido a utilização do sistema para suprir
outros processos. Por uma avaliação mais tangível, os prazos estabelecidos para a
implantação foram atingidos, de forma a respeitar as premissas definidas de “replicação”
dos processos na ferramenta.
Entre os objetivos pretendidos pela empresa Y com a implementação do sistema, as duas
que mais se destacaram, dentro das reuniões ou mesmo como feedbacks pessoais, em
77
relação aos benefícios já percebidos foram a redução dos gastos com os sistemas
anteriores e a capacidade de visualização da situação de cada instância do workflow. Os
líderes são capazes de consultar o identificador de uma instância de forma a saber em qual
etapa ela se encontra, qual o executor, o tempo total do processo, os campos preenchidos
nos formulários e as informações que estão pendentes. Antes da implantação do sistema,
não havia esse modelo de apresentação dos status do processo, uma vez que o fluxo era
realizado através de e-mails e anexos, de forma que era necessária questionar os liderados
para saber o andamento de um determina compra.
De forma a avaliar as possíveis tecnologias e recursos que podem ser implementadas
futuramente o autor sugere 3 possíveis aplicações, inerentes do sistema descritras a seguir:
• Web Service e API com outros sistemas; Em alguns momentos do fluxo, há a
utilização do recurso do software do Alterdata para lançamento das notas e criação
dos Pedidos de Compra. Nessas etapas se encontram tarefas semelhantes que
devem ser executadas tanto no sistema da Softexpert quanto no Alterdata, sem
possibilidade de exportação de informação de um para outro, gerando retrabalho.
De forma a reduzir a duplicidade de atividades a serem realizadas, é possível
utilizar de chamadas de API, que se utilizam de recursos de troca informação para
que sistemas construídos e codificados de formas diferentes possam trocar e obter
informações de maneira rápida e segura. Muitas empresas já possuem API
previamente elaborada e podem ser utilizadas livremente pelo usuário.
A partir da aplicação de uma API, poderia ser aplicado na atividade de cadastro
do material, uma chamada direta para adição dos materiais/serviços com suas
informações já previamente inseridas em um único sistema.
• Determinação de Níveis de Serviço (SLA); os níveis de serviço funcionam como
acordos entre o solicitante e o prestador de serviço de forma a garantir métricas e
prazos para uma atividade. A utilização desses abordagem visa também
proporcionar maior visibilidade e controle das atividades envolvidas na prestação
de um serviço. A partir da avaliação de seus executores dentro do sistema é
possível analisar a qualidade dos resultados obtidos. Esse recurso é
disponibilizado como uma funcionalidade dentro do software que pode ser
programa e editada, a partir de algumas condições exigidas pelo sistema; Os
executores de cada atividade, os formulários a serem preenchidos e as possíveis
ações disponibilizadas ao usuário, precisam estar previamente configuradas e
78
definidas ao longo do processo, caso contrário o sistema retorna uma mensagem
de erro, informando que as condições não foram atendidas.
A parametrização de níveis de serviço durante a construção do fluxo, não foi
realizada pelo período de adaptação e mudanças dos sistemas atuais. Entende-se
que a implementação do sistema alterou significantemente o fluxo de suprimentos
e que seria necessário tempo para realização das revisões e correções do fluxo,
além é claro de inserir as melhorias sugeridas pelos próprios participantes das
áreas. De forma que o sistema ainda está em fase de amadurecimento, e que
mudanças ainda podem ocorrer durante a elaboração deste trabalho, a
parametrização dos SLA’s dos processos garantiria maior controle pelos líderes
dos prazos e metas definidos para sua equipe, de forma a conseguir enxergar
oportunidades de melhorias e possíveis problemas dentro do fluxo. Para tal, sendo
necessário o levantamento da definição do tempo médio de execução de cada
atividade na ferramenta.
• Indicadores de Desempenho e Gráfico de Resultados; como descrito no tópico de
objetivos pretendidos para implementação do sistema, uma das metas era dar
maior visibilidade, confiabilidade e controle das informações ao longo do fluxo.
Antes da implementação do workflow, as atividades seguiam o mesmo roteiro,
porém através de e-mail e planilhas. Com a implementação do sistema é possível
gerar maior rastreabilidade dos dados, uma vez que todas as informações geradas
no fluxo são armazenadas no formato de tabelas e podem ser utilizar para geração
de indicadores de desempenho e gráfico de resultados. Por conta disso, um dos
próximos objetivos é a criação de um portal disponível para os gestores
acompanharem seus KPIs, de forma a auxiliar no controle e acompanhamento dos
objetivos, além de facilitar o acompanhamento do planejado com o executado. Foi
elaborado um protótipo, na própria ferramenta, do modelo pretendido a partir da
utilização do MySQL. Os valores demonstrados na imagem são meramente
ilustrativos e não necessariamente representam a realidade.
79
Os gráficos foram construídos a partir de filtros dos campos dos formulários de modo a
apresentar as escolhas realizadas pelos funcionários durante o preenchimento do
formulário. De modo a gerar maior confiabilidade das respostas, os campos retornados
nos gráficos foram gerados a partir de listas, de modo a evitar que possa evitar divergência
por conta de palavras escritas diferentes, porém com mesmo significado o que para o
sistema é entendido como dois de categorias diferentes, como demonstrado anteriormente
no tópico de Implantação, Manutenção e Utilização (casos de erros de ortografia, por
exemplo).
Figura 35 - Utilização de gráficos para controle das instâncias Fonte: Elaboração Própria
80
5 Referências Bibliográficas
ABPMP. BPM CBOK V3.0. guide to the business process management common
body of knowledge. 1. ed. Brasil: Association of Businees Process Management
Professsionals Brasil, 2013.
BIEBERSTEIN, N.; BOSE, S.; FIAMMANTE, M.; JONES, K.; SHAH, R., 2006, Service -
Oriented Architecture Compass: business value, planning, and enterprise roadmap. Upper
Saddle River, NJ: IBM Press - DeveloperWorks Series, Prentice Hall, 1ST Ed.,232p..
CALAZANS, A.; KOSLOSKI, R.; GUIMARÃES, F. Prosposta de Modelo de Medições
para contratação do Gerenciamento de Processo de Negócio (Business Process Management
– BPM). Revista de Gestão da Tecnologia e Sistemas de Informação, v.13, n.2, p. 275-
300, mai./ago, 2016.
CAMEIRA, Renato. Arquitetura Integrada de Sistemas: Modelo de referência em um
contexto de (hiper)integração de processos e sistemas nas organizações. COPPE – UFRJ,
2003 CARDOSO, J.C.; LUZ, A.R. Os arquivos e os sistemas de Gestão da Qualidade. Revista
Arquivo e Administração, Rio de Janeiro, v.3, n.1/2, p. 51-64, jan./dez, 2004.
DAVENPORT, T. Mission Critical: Realizing the Promise of Enterprise Systems. Harvard
Business School Press. Boston, 2000.
DAVENPORT, T. Process innovation: reengineering work through information technology.
Harvard Business School Press, Boston, 1992.
DAVENPORT, T.; HARRIS, J.; CANTRELL, S. Enterprise systems and ongoing process
change. Business Process Management Journal, v.10. n.1, p. 16-26, 2004.
DAVENPORT, T.; MARCHAND, D.; DICKSON, T. Dominando a gestão da informação:
Porto Alegre: Bookman, 2004.
81
ERIKSSON, H.-E.; PENKER, M. Business modeling with uml: business patterns at Work.
1. ed. USA: OMG PRESS, 2000. Fischer, L., Workflow Handbook 2003 , Lighthouse Point , Future Strategies Inc, 2003 GEIGER, M.; HARRER, S.; LENHARD, J.; WIRTZ, G. BPMN 2.0: The state of support
and implementation. Future Generation Computer Systems. 2017.
GIL, A.C, Como Elaborar Projetos de Pesquisa. 4 ed. São Paulo, Atlas S.A., 2002.
Kearns, G and Lederer, A., "A resource-based view of strategic IT alignment: How knowledge
sharing creates competitive advantage", Decision Sciences, Vol. 34, No. 1, pp. 1-29, 2003.
Keairns, H.E.; PENKER, M. “ Business Modeling With UML: Business Patterns at Work ”.
1. ed. New York, NY, USA: John Wiley Sons Inc., 1998
KLUSKA, R.; LIMA, E.; COSTA, S. Uma proposta de estrutura e utilização do
Gerenciamento de Processos de Negócio (BPM). Revista Produção Online, Florianópolis,
SC, v.15, n. 3, p. 886-913, jul./set, 2015.
LAMPERT, S.R.; FLORES, D., Os sistemas de workflow em arquivística: a identificação
dos modelos e a análise das ferramentas. Revista Perspectivas em Ciências da
Informação, v.15, n.3, p.2016-232, set./dez, 2010.
LAUDON, Kenneth C.; LAUDON, Jane P. Sistemas de Informação Gerencial:
administrando a empresa digital. 5 ed. São Paulo: Prentice Hall, 2004.
LOUSÃ, M.; SARMENTO, A. Implementação e utilização de sistemas de Workflow como
suporte á Gestão do Conhecimento: Um Estudo de Caso. Atas da Conferência da
Associação Portuguesa de Sistemas de Informação. V.3.2016
MARTINS, V.M.M. Integração de Sistemas de Informação: Perspectivas, normas e
abordagens. 2005. 193 f. Dissertação de Mestrado apresentada no Programa de Pós-
Graduação em sistemas de Informação. Universidade do Minho, Braga, Portugal, 2005.
82
MONTILVA, J.; BARRIOS, J.; BESEMBEL, I.; MONTILVA, W. A Business Process
Model for IT Management Based on Enterprise Architecture. Clei Electronic Journal, v.17,
n.2, aug. 2014.
NICOLAO, M.; OLIVEIRA, J. Caracterizando sistemas de Workflow. Revista Eletrônica
de Administração, v.2, n.2, set./out. 1996.
OLIVEIRA, A.M.; CARVALHO, R.; JAMIL, G.; CARVALHO, J. Avaliação de
ferramentas de Business Process Management (BPMS) pela ótica da gestão do
conhecimento. Revista Perspectivas em Ciências da Informação, v.15, n.1, p.132-153,
jan./abr. 2010.
SARMENTO, A.M.T. Impacto dos Sistemas Colaborativos nas Organizações: Estudo de
Casos de Adopção e Utilização de Sistemas Workflow. 2002. 356 f. Dissertação (Doutorado
em Tecnologias e Sistemas de Informação) – Universidade do Minho, Braga, Portugal, 2002.
SILVA, A.V. Modelagem de processos para implementação de workflow: Uma avaliação
crítica. 2001. 211 f. Tese (Mestrado em Ciências em Engenharia de Produção) –
Universidade Federal do Rio de Janeiro, RJ, 2001.
SPERB, C.C.; NETO, H. A importância dos sistemas de informação na gestão de empresas.
Recife, 2014. Disponível em:
http://www.cin.ufpe.br/~dmrac/introducao%20a%20s.informacao/artigo_f8z5k8g.pdf.Acesso
em: 14 jul. 2019.
TAIT, T. F.; PACHECO, R. C.; ABREU, A. F. Arquitetura de sistemas de informação:
evolução e análise comparativa de modelos. ABEPRO, v. 9, n.1, p. 55-64. 1999. YIN, R. K. Estudo de Caso – Planejamento e Método. 2. ed. São Paulo: Bookman, 2001.
![Workflow p10[1] Copy](https://static.fdocumentos.com/doc/165x107/5572141d497959fc0b93cd57/workflow-p101-copy.jpg)
