automaÇÃo de processos de negÓcio utilizando … · 2016-10-20 · muito obrigado a todos. v...
TRANSCRIPT
AUTOMAÇÃO DE PROCESSOS DE NEGÓCIO
UTILIZANDO BPMS: PROPOSIÇÕES A PARTIR DE
UM ESTUDO DE CASO NO DEPARTAMENTO DE
ENGENHARIA INDUSTRIAL DA ESCOLA
POLITÉCNICA UFRJ
Felipe Lima Baldissera
Fernando Souza de Oliveira
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: Prof. Vinícius Carvalho Cardoso, D.Sc.
Rio de Janeiro
Setembro de 2016
ii
AUTOMAÇÃO DE PROCESSOS DE NEGÓCIO
UTILIZANDO BPMS: PROPOSIÇÕES A PARTIR DE UM
ESTUDO DE CASO NO DEPARTAMENTO DE
ENGENHARIA INDUSTRIAL DA ESCOLA POLITÉCNICA
UFRJ
Felipe Lima Baldissera
Fernando Souza de Oliveira
PROJETO DE GRADUAÇÃO SUBMETIDO AO CORPO DOCENTE DO CURSO
DE ENGENHARIA DE PRODUÇÃO DA ESCOLA POLITÉCNICA DA
UNIVERSIDADE FEDERAL DO RIO DE JANEIRO COMO PARTE DOS
REQUISITOS NECESSÁRIOS PARA A OBTENÇÃO DO GRAU DE
ENGENHEIRO DE PRODUÇÃO.
Examinado por:
________________________________________________
Prof. Vinícius Carvalho Cardoso, D.Sc. (Orientador)
________________________________________________
Prof. Renato Flórido Cameira, D.Sc.
________________________________________________
Prof. Lino Guimarães Marujo, D.Sc.
RIO DE JANEIRO, RJ - BRASIL
SETEMBRO de 2016
iii
Baldissera, Felipe Lima
Oliveira, Fernando Souza
Automação De Processos De Negócio Utilizando BPMS:
Proposições a Partir de um Estudo de Caso no Departamento
de Engenharia Industrial da Escola Politécnica UFRJ – Rio de
Janeiro: UFRJ/ Escola Politécnica, 2016.
XIII, 78 p.: il.; 29,7 cm.
Orientador: Vinícius Carvalho Cardoso
Projeto de Graduação – UFRJ/ POLI/ Curso de
Engenharia de Produção, 2016.
Referências Bibliográficas: p. 73-74.
1. Automação de Processos de Negócio. 2. Gestão de
Processos de Negócio. 3. Sistemas de Gestão de Processos
de Negócio. I. Cardoso, Vinícius Carvalho. II. Universidade
Federal do Rio de Janeiro, UFRJ, Curso de Engenharia de
Produção. III. Automação De Processos De Negócio
Utilizando BPMS: Proposições a Partir de um Estudo de Caso
no Departamento de Engenharia Industrial da Escola
Politécnica UFRJ.
iv
Agradecimentos
Felipe Lima Baldissera
Meu agradecimento vai, primeiramente, àquele que sempre esteve comigo nas
inúmeras vezes que pensei não ser forte o suficiente para prosseguir: Deus. Em
segundo lugar, gostaria de agradecer a toda a minha família por não ter medido esforços
para que eu pudesse me formar engenheiro. Toda a minha gratidão, em especial aos
meus pais, Antemir e Rejane, por tudo. Agradeço também aos meus amigos, pois, sem
eles, a estrada teria sido muito mais tortuosa. E, não posso esquecer-me de agradecer
a todos os professores do DEI por me transmitirem todo o conhecimento que hoje
possuo. Muito obrigado a todos.
v
Agradecimentos
Fernando Souza de Oliveira
Agradeço a minha família, em especial meus pais, Maria Deuza e Fernando e
irmãos Janaína e José Victor, por todo o apoio, afeto e carinho durante toda a minha
vida. Sei que sem eles por perto não teria chegado onde cheguei.
Faço um agradecimento especial ao ISMART, ONG que apoiou os meus estudos
desde 2006, acreditando no meu potencial e me dando as condições necessárias para
chegar até aqui.
Agradeço também os meus professores e amigos do curso de Engenharia de
Produção, em especial o Jean e o João Gabriel, que estiveram sempre ao meu lado ao
longo desta jornada. Sei que ganhei amigos para a vida.
Gostaria de agradecer meus amigos do Colégio de São Bento Rafael, João
Gabriel, Roberto, Alan, Luís Filipe, João Marcos, José, Helder, Matheus, Raphael,
Gabriel, Felipe Diogo, Gil, Paulo, João Vitor e Najan, por todo carinho, amizade e por
todos momentos de descontração que passamos juntos.
Em conjunto, eu e o Felipe agradecemos o professor Vinícius Cardoso, que se
mostrou sempre interessado, paciente e presente para que nós pudéssemos realizar o
melhor trabalho possível. Suas orientações foram sempre precisas e esclarecedoras.
Certamente pudemos aprender muito através do conhecimento transmitido durante todo
o processo de orientação.
vi
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.
Automação de Processos de Negócio Utilizando BPMS: Proposições a Partir de um Estudo de
Caso no Departamento de Engenharia Industrial da Escola Politécnica UFRJ
Felipe Lima Baldissera
Fernando Souza de Oliveira
Setembro/2016
Orientador: Vinícius Carvalho Cardoso
Curso: Engenharia de Produção
O presente projeto possui o objetivo de realizar um estudo de caso no Departamento de
Engenharia Industrial (DEI) ao projetar, com o auxílio de ferramenta BPMS, a automação do
processo de planejamento de turmas. Inicialmente, foi realizada a revisão da literatura acerca de
temas relacionados à automação de processos de negócios utilizando sistemas de apoio de
gestão de processos. Em seguida, foi elaborada a caracterização do DEI com o intuito de
compreender o ambiente onde o processo é realizado, bem como as dinâmicas de
relacionamentos do departamento com outros agentes que afetam o planejamento de turmas e
os critérios de desempenho que o regem. Posteriormente, modelou-se o processo em seu estado
atual de forma a compreender a sequência de tarefas, participantes e regras de negócio
inerentes ao processo. Após a modelagem, foi realizada a análise do processo por meio da
identificação de causas raízes dos problemas levantados a priori. Em sequência, foram
levantadas as necessidades de automação com base no julgamento da viabilidade da
automação e das causas relacionadas a cada atividade do processo realizada pelo DEI. Com
essas informações definidas e a ferramenta BPMS selecionada, foram aplicadas tecnologias de
gestão de processos de negócio à sequência de atividades determinada na etapa anterior de
modo a especificar seu funcionamento e requisitos, uma vez automatizada. Para finalizar, os
resultados esperados do projeto de automação foram analisados com a finalidade de atestar se
estão alinhados com os critérios de desempenho do DEI.
Palavras-chave: Automação de Processos de Negócio, BPM, BPMS
vii
Abstract of Undergraduate Project presented to POLI/UFRJ as a partial fulfillment of
the requirements for the degree of Industrial Engineer.
Business Process Automation Using BPMS: Propositions from a Case Study in the Department
of Industrial Engineering at the Polytechnic School of UFRJ
Felipe Lima Baldissera
Fernando Souza de Oliveira
September/2016
Advisor: Vinícius Carvalho Cardoso
Course: Industrial Engineering
This project has the objective of carrying out a case study in the Department of Industrial
Engineering (DEI) to design, with the aid of BPMS tool, the automation of the class scheduling
process. Initially, the literature review was conducted on topics related to the automation of
business processes using process management support systems. Then the characterization of
DEI was developed in order to understand the environment in which the process is carried out as
well as the dynamic relationships between the department and other agents that affect the
planning of classes and the performance criteria that govern it. Subsequently, the process was
modeled in its current state in order to understand the sequence of tasks, participants and
business rules inherent to the process. After modeling, the process was analyzed by identifying
root causes of the problems recognized a priori. In sequence, the automation needs were raised
based on the judgment of the viability of automation and related causes of each process activity
undertaken by DEI. With this information and set the selected BPMS tool, business process
management technologies were applied to the sequence of activities determined in the previous
step to specify its functioning and requirements, once it had been automated. Finally, the
expected results of the automation project were analyzed in order to verify whether they were
aligned with the DEI performance criteria.
Keywords: Business Process Automation, BPM, BPMS
viii
Sumário
1. INTRODUÇÃO ................................................................................................... 1
1.1 TEMA ............................................................................................................... 1
1.2 OBJETIVO ........................................................................................................ 3
1.3 UNIDADE DE ANÁLISE ....................................................................................... 4
1.4 LIMITAÇÕES ..................................................................................................... 4
1.5 MÉTODO .......................................................................................................... 5
1.5.1 Descrição do Método .................................................................................. 5
2. REVISÃO BIBLIOGRÁFICA .............................................................................. 7
2.1 PROCESSOS DE NEGÓCIO ................................................................................. 7
2.2 GESTÃO POR PROCESSOS ................................................................................ 8
2.3 GESTÃO DE PROCESSOS DE NEGÓCIO – BPM ................................................. 10
2.3.1 Conceituação ............................................................................................ 10
2.3.2 Ciclo de Vida BPM .................................................................................... 10
2.3.3 BPMN ....................................................................................................... 13
2.3.4 Sistemas de Gestão de Processos de Negócio – BPMS ........................... 17
3. CARACTERIZAÇÃO DO DEI .......................................................................... 21
3.1 HISTÓRIA ....................................................................................................... 21
3.2 ESTRUTURA E INFRAESTRUTURA DO DEI ......................................................... 22
3.3 SUBÁREAS DO DEI ......................................................................................... 23
3.4 PRINCIPAIS ATIVIDADES .................................................................................. 23
3.4.1 Planejamento de Turmas .......................................................................... 24
4. MODELAGEM DOS PROCESSOS DE PLANEJAMENTO DE TURMAS ....... 27
4.1 O PROCESSO DE PLANEJAMENTO DE TURMAS ................................................. 27
5. ANÁLISE DO PROCESSO .............................................................................. 32
5.1 AVALIAÇÃO GERAL COM BASE NOS CRITÉRIOS DE DESEMPENHO ...................... 32
5.2 EFEITOS INDESEJÁVEIS ................................................................................... 33
5.3 IDENTIFICAÇÃO DAS CAUSAS ........................................................................... 35
5.3.1 Árvore da Realidade Atual para o Processo de Planejamento de Turmas. 37
6. DEFINIÇÃO DAS NECESSIDADES DE AUTOMAÇÃO .................................. 39
6.1 ATIVIDADES AUTOMATIZÁVEIS – PROCESSO DE PREVISÃO DE TURMAS .............. 39
ix
6.2 SELEÇÃO DO FOCO DA AUTOMAÇÃO ................................................................ 43
7. PROJETO DE AUTOMAÇÃO .......................................................................... 44
7.1 SOLUÇÃO DE AUTOMAÇÃO .............................................................................. 44
7.2 MODELAGEM DO PROCESSO ............................................................................ 45
7.3 MODELAGEM DE DADOS .................................................................................. 47
7.4 CRIAÇÃO DE FORMULÁRIOS ............................................................................. 52
7.4.1 Registra solicitações no SIPT .................................................................... 52
7.4.2 Atualiza planejamento do curso no SIPT ................................................... 53
7.4.3 Avalia solicitações pendentes ................................................................... 55
7.4.4 Atualiza grade de horários no SIPT ........................................................... 56
7.4.5 Verifica se o planejamento atende suas necessidades ............................. 58
7.5 DEFINIÇÃO DAS REGRAS DE NEGÓCIO .............................................................. 59
7.6 DEFINIÇÃO DOS PERFIS DE USUÁRIOS .............................................................. 64
7.7 DEFINIÇÃO DAS INTEGRAÇÕES ........................................................................ 65
8. ANÁLISE DOS RESULTADOS ....................................................................... 67
9. CONCLUSÃO .................................................................................................. 69
10. REFERÊNCIAS BIBLIOGRÁFICAS ................................................................ 71
x
Lista de Figuras
Figura 1 – Método utilizado para elaboração do projeto ................................................ 5
Figura 2 – Visão sistêmica do processo de negócio ..................................................... 8
Figura 3 – Visão departamental x Visão de processos .................................................. 9
Figura 4 – Ciclo de vida BPM ...................................................................................... 11
Figura 5 – Objetos de fluxo da notação BPMN ........................................................... 14
Figura 6 – Objetos de dados da notação BPMN ......................................................... 14
Figura 7 – Objetos de conexão da notação BPMN ..................................................... 15
Figura 8 – Swimlanes (notação BPMN) ...................................................................... 15
Figura 9 – Artefatos (notação BPMN) ......................................................................... 16
Figura 10 – Layout geral do ambiente de processo .................................................... 17
Figura 11 – Ciclo BPMS .............................................................................................. 19
Figura 12 – Adaptação ao Ciclo BPMS ....................................................................... 20
Figura 13 – Organograma do Departamento de Engenharia Industrial ....................... 22
Figura 14 – Funções do Departamento de Engenharia Industrial ............................... 24
Figura 15 – Planilha de planejamento de turmas ........................................................ 29
Figura 16 – Quadro de horários da Engenharia de Produção (1º período – 2016.1) ... 30
Figura 17 – Ambiente geral do processo de planejamento de turmas ......................... 31
Figura 18 – Quadro de horários da Engenharia de Produção (2º período – 2016.2) ... 35
Figura 19 – Abordagem para leitura da ARA .............................................................. 36
Figura 20 – Modelo de dados ..................................................................................... 50
Figura 21 – Formulário para registro das solicitações ................................................. 53
Figura 22 – Formulário para planejamento do curso pelo aluno .................................. 54
Figura 23 – Formulário para consulta de disciplina ..................................................... 54
Figura 24 – Formulário para consultar docente ........................................................... 55
Figura 25 – Formulário com a solicitação do docente consultado ............................... 56
Figura 26 – Formulário busca do curso ....................................................................... 57
Figura 27 – Formulário para visualização e edição da grade do curso ........................ 57
Figura 28 – Formulário para busca da grade do docente ............................................ 58
Figura 29 – Formulário para visualização das turmas do docente............................... 58
Figura 30 – Regras de negócio 1 ................................................................................ 60
Figura 31 – Regras de negócio 2 ................................................................................ 61
Figura 32 – Regras de negócio 3 ................................................................................ 62
Figura 33 – Regras de negócio 4 ................................................................................ 63
Figura 34 – Regras de negócio 5 ................................................................................ 63
xi
Figura 35 – Camadas de integração do Bizagi Studio ................................................. 65
Figura 36 – Informações necessárias para geração da grade de turmas .................... 66
xii
Lista de Tabelas
Tabela 1 - Critérios de desempenho do processo de planejamento de turmas ........... 26
Tabela 2 - Necessidades de Automação..................................................................... 40
Tabela 3 - Melhorias incorporadas ao processo de planejamento de turmas .............. 47
Tabela 4 - Conjunto de informações necessárias para a execução do processo ........ 48
Tabela 5 - Descrição das entidades ............................................................................ 51
Tabela 6 - Atividades possibilitadas pelo SIPT por usuário ......................................... 64
Tabela 7 - Relação entre as soluções, causas raízes e efeitos indesejáveis .............. 68
xiii
Lista de Abreviaturas e Siglas
ARA Árvore de Realidade Atual
BPM Business Process Management
BPMN Business Process Modeling Notation
BPMS Business Process Management System
CAPES Comissão de Aperfeiçoamento de Pessoal do Nível Superior
CEP Curso de Engenharia de Produção
CRM Customer Relationship Management
DEI Departamento de Engenharia Industrial
EAI Enterprise Application Integration
EI Efeito Indesejável
ERP Enterprise Resource Planning
IF Instituto de Física
IM Instituto de Matemática
OMG Object Management Group
SAD Sistemas de Apoio à Decisão
SIGA Sistema Integrado de Gestão Acadêmica
SOA Arquitetura Orientada a Serviços
SIPT Sistema Integrado de Planejamento de Turmas
SQL Structured Query Language
TI Tecnologia da Informação
TQM Total Quality Management
UFRJ Universidade Federal do Rio de Janeiro
1
1. INTRODUÇÃO
A introdução da tecnologia de informação aos processos das empresas as
colocou em um novo patamar de desempenho. A possibilidade de automação de
atividades críticas para o desempenho das organizações ampliou os horizontes de
escala, promoveu o aumento da confiabilidade e a redução de custos e de tempos de
execução, além de diminuir e/ou extinguir trabalhos manuais, entre outros.
As organizações precisam adaptar os seus processos de negócio com rapidez e
eficiência para garantir o sucesso do negócio e uma sobrevivência de longo prazo.
Processos que não são completamente automatizados, claramente visíveis para todos
stakeholders e capazes de suportar de forma transparente determinada organização
geograficamente distribuída, não podem lidar adequadamente com necessidades de
negócio dinâmicas (SCHEER et al., 2004; MOHAPATRA, 2009).
Assim, a automação de processos de negócio se mostra como uma solução
promissora para organizações no mundo moderno que buscam consolidar vantagens
competitivas ou alcançar outros benefícios inerentes, conforme as necessidades das
mesmas.
Dessa forma, foi compreendido que a automação de processos de negócio está
completamente ligada aos desafios enfrentados pelo Engenheiro de Produção, uma vez
que o mesmo está inserido em organizações dinâmicas e complexas e, desenvolvendo
um projeto de graduação, espera-se demonstrar ainda mais a importância desta
temática para a formação deste profissional.
1.1 Tema
Definiu-se “automação de processos de negócio” como tema central do presente
projeto. Venki (2014) explica que a automação de processos de negócio consiste na
racionalização, otimização e automação dos processos-chave que impulsionam uma
organização, através da integração de aplicações de software e suporte de hardware.
Entretanto, muito além do conceito, a automação de processos de negócio está ligada
a uma nova concepção de gestão observada nas organizações – a gestão por
processos – aliada à evolução de diversas iniciativas de gestão de processos.
Os efeitos da globalização das economias e o acirramento da competitividade
entre organizações elevaram a necessidade de adaptação das mesmas de modo a
continuarem existindo. É nesse contexto que a gestão de processos se destaca, ao
facilitar os processos de mudança exigidos, promovendo melhoria no projeto de
processos, além de coordenar os fluxos nas atividades dos processos, possibilitando o
2
constante aprendizado em gestão de processos por parte das organizações (PAIM et
al., 2009).
Segundo Cruz (2010 apud SANTOS, 2013), a gestão por processos é resultado
da evolução de diferentes abordagens que buscavam, dentre outros objetivos, dar
suporte tecnológico ao trabalho cooperativo, amenizar os efeitos da desorganização
informacional e buscar a qualidade utilizando os processos organizacionais como foco
de melhorias. Dentre estas abordagens, destacam-se ferramentas clássicas de gestão
de processos, como: Gerenciamento de Qualidade Total (TQM), Seis Sigma, Balanced
Scorecard, Reengenharia de Processos de Negócio, Sistemas Integrados de Gestão
Empresarial (ERP), Sistemas de Apoio à Decisão (SAD) e Workflow.
Mais recentemente, surgiu uma nova visão em gestão de processos: O
Gerenciamento de Processos de Negócio (BPM). Segundo Paim et al. (2009), nesse
novo modelo, a habilidade para mudar é mais importante que a habilidade para criar um
processo pela primeira vez. O BPM permite que organizações tenham conhecimento de
informações pertinentes de como os processos são executados para que melhorias
possam ser realizadas constantemente, permitindo maior eficiência, assertividade e
dinamismo frente às mudanças ocorridas no ambiente de negócios. Assim, Paim et al.
(2009) defende que o BPM se mostra como uma importante abordagem de
gerenciamento adaptável que permite que organizações sejam capazes de monitorar,
melhorar continuamente e otimizar suas cadeias de valor. De forma a orientar o
gerenciamento de processos de negócio, a literatura disponibiliza diferentes modelos
que, em sua grande maioria, assumem orientação cíclica.
Atualmente, segundo Carrara (2011), um novo patamar da gestão por processos
foi estabelecido através da automação dos processos, o que se tornou possível graças
aos avanços realizados na área de tecnologia da informação. Mais precisamente,
artefatos tecnológicos que suportam a gestão de processos – sistemas de gestão de
processos de negócio (BPMS) – encontram-se em destaque por permitirem a simulação,
automação, gerenciamento e monitoramento dos processos de negócio (PAIM et al.,
2009).
As melhores práticas de negócio adotadas por empresas nem sempre
configuram as melhores escolhas, uma vez que as mesmas possuem limitações1 que
1 Segundo Scheer et al. (2004), tais limitações estão ligadas à inviabilidade de alterar a
definição dos processos de negócio em sistemas tradicionais de automação, requerendo a
modificação ou a criação de software.
3
não permitem que se alcancem benefícios significativos enquanto se atendem às
mudanças dinâmicas nas condições de ambiente de negócios. Assim, muitos processos
de negócio não são ou são insuficientemente automatizados (SCHEER et al., 2004;
MOHAPATRA, 2009).
Dessa forma, as novas práticas de negócio, representadas no presente projeto
por softwares BPMS, se destacam ao permitir a redefinição dos processos e regras de
negócio com o auxílio de tecnologias de automação como web services, workflow,
Enterprise Application Integration (EAI), entre outras, ocasionando, assim, a adaptação
do comportamento da organização de forma correspondente (SCHEER et al., 2004).
A automação de processos de negócio apresenta diversos benefícios, além dos
já mencionados. Dentre eles, pode-se citar: garantia de execução do processo conforme
projetado, eliminando as possibilidades de infração das regras de integridade do
processo, seja por fraude, desconhecimento ou negligência; realização de tarefas a
partir de locais de trabalho virtuais, em que os funcionários operam remotamente entre
si ou com a gerência; rastreabilidade do processo; identificação e resolução de pontos
de ineficiência, desperdícios e má aplicação de recursos (CAPIOTTI, 2012).
Vale destacar, por outro lado, que os benefícios oriundos da automação
possuem caráter dependente da organização em estudo, não havendo um conjunto
fechado de possibilidades.
1.2 Objetivo
O objetivo geral do estudo proposto é projetar, com o auxílio de ferramenta
BPMS, a automação do processo de planejamento de turmas do Departamento de
Engenharia Industrial (DEI) da UFRJ, visto atualmente como crítico, de forma a trazer
melhorias para todos agentes em contato com o Departamento, incluindo gestores,
funcionários, docentes e discentes.
Dentre os objetivos específicos, pode-se citar:
Definir indicadores-chave para as propostas de automação;
Padronizar fluxo de trabalho do processo;
Levantar problemas e identificar causas raízes do processo;
Identificar necessidades de automação;
Aprimorar a gestão de informações;
Aumentar a resiliência do processo.
4
1.3 Unidade de Análise
O Departamento de Engenharia Industrial foi fundado na década de 1970.
Localizado no primeiro andar do bloco F do Centro de Tecnologia, o DEI é o principal
responsável pela oferta de módulos que compõem o curso de graduação em Engenharia
de Produção. O mesmo vale para os cursos de especialização e de extensão, cuja
responsabilidade é do coordenador do curso, membro do DEI. Além disso, o DEI oferece
disciplinas que são ministradas em outros cursos de engenharia (DEI, 2016).
Segundo Félix e Cagido (2016), o DEI se organiza em torno de quatro grandes
áreas de conhecimento. São elas: gerência da produção, engenharia econômica,
métodos quantitativos e engenharia do petróleo.
Baseado no projeto de graduação de Félix e Cagido (2016) percebe-se que,
atualmente, o processo de planejamento de turmas é crítico, uma vez que possui
complexas relações de interdependência entre diferentes agentes, além do fato de
envolverem múltiplos recursos (p. ex: salas de aula, professores, disciplinas, etc.).
Sendo assim, são suscetíveis a falhas que geram transtornos às demais atividades do
DEI.
Por fim, vale ressaltar que o chefe do departamento confirmou que já existe um
projeto de automação do processo de planejamento de turmas sendo executado no
departamento. Desta forma, enxergou-se como uma oportunidade o desenvolvimento
de um estudo de caso da automação deste processo.
1.4 Limitações
Devido ao fato de o tema central “automação de processos de negócio” ser muito
abrangente, o presente trabalho limita-se à fase de levantamento e modelagem de
processos de negócio seguida pela especificação da solução de automação,
restringindo-se à definição de seu funcionamento e requisitos, sem considerar a
execução da mesma, conforme será discutido na seção 2.3.4.
Além disso, a seleção entre sistemas BPMS disponíveis no mercado não será
realizada. Ao invés, fica estabelecido previamente o uso do pacote de ferramentas
Bizagi2 ao longo de todo o trabalho, uma vez que os autores deste projeto possuem livre
2 Composto por Bizagi Modeler, Bizagi Studio e Bizagi Engine. O primeiro permite desenhar,
diagramar, documentar e publicar os processos utilizando o padrão BPMN. O segundo permite a
automação dos processos de negócio e fluxos de trabalho ao definir os aplicativos de processo
(interface do usuário, formulários, regras de negócio) associados. O terceiro permite o
5
acesso ao mesmo na universidade de ambos, que abrange todo o ciclo de vida BPM,
que possui suporte à notação BPMN, que permite integração com outros sistemas e que
é gratuito para até 20 usuários. Entende-se, portanto, que a ferramenta escolhida atende
às necessidades do presente projeto.
1.5 Método
De forma a alcançar os objetivos citados, é proposta a execução do método
apresentado no esquema da figura 1 e descrito a seguir.
1.5.1 Descrição do Método
O método sintetizado no esquema da figura 1 é formado pelas seguintes etapas:
1. Revisão bibliográfica:
Revisão bibliográfica sobre o tema que norteia o presente trabalho, ou seja,
“automação de processos de negócio”, a partir de pesquisa na base CAPES, leitura de
livros recomendados, busca em sites especializados e busca de dissertações e
monografias relacionadas ao tema.
Espera-se com isso extrair as informações necessárias que capacitarão os
autores a atingir os objetivos propostos.
2. Caracterização do DEI:
Em seguida, entender mais a fundo o contexto onde o processo de planejamento
de turmas ocorre. Para isso, torna-se fundamental compreender o propósito do DEI, os
monitoramento do processo e a distribuição da solução de automação pela organização. No
presente projeto, serão usadas as duas primeiras ferramentas, sendo que a segunda será utilizada
com restrições.
1.Revisão Bibliográfica
2.Caracterização do DEI
3.Modelagem do processo
4.Análise dos processos
5.Definição das Necessidades de
Automação
6.Projeto de Automação
7.Análise dos Resultados
Figura 1 – Método utilizado para elaboração do projeto
Fonte: Elaboração própria
6
desafios e limitações enfrentados, bem como sua relação com outros agentes. Dessa
forma, serão realizadas entrevistas com agentes integrantes e coletas de dados.
Ademais, cabe definir ainda neste momento, através de observação e entrevistas,
critérios de desempenho considerados essenciais para o DEI que posteriormente
auxiliarão na análise dos resultados organizacionais esperados decorrentes da
aplicação da automação do processo em questão.
3. Modelagem do processo:
A próxima etapa consiste em modelar o processo de planejamento de turmas na
situação atual de modo a entender melhor as atividades desempenhadas e identificar
pontos de alavancagem.
Como o objetivo da modelagem é encaminhar uma solução por automação, Juric
e Pant (2008) sugere a utilização da linguagem Business Process Modeling Notation
(BPMN), que será a notação utilizada neste projeto por intermédio do software Bizagi
Modeler.
4. Análise do processo:
Analisar a modelagem do processo de modo a detectar os principais problemas
e suas causas raízes. Para alcançar este objetivo, foi utilizada a ferramenta Árvore de
Realidade Atual (ARA) proposta por Goldratt, bem como as Categorias Legítimas de
Reserva que ajudaram a chegar a um resultado mais confiável.
5. Definição das necessidades de automação:
Em seguida, levantar as necessidades de automação, baseando-se na
viabilidade da solução de automação e nos problemas identificados a partir da
modelagem de processo e suas causas raízes.
6. Projeto de automação:
Com o auxílio da ferramenta BPMS definida, aplicar tecnologias de gestão de
processos de negócio ao fluxo de trabalho de modo a especificar seu funcionamento e
requisitos.
Serão levados em consideração ferramentas de modelagem de processos, de
workflow e de gerenciamento de regras de negócio, dentre outras.
7. Análise dos resultados:
Análise dos resultados esperados da solução proposta na etapa anterior, onde
será exposto o que se espera a partir da implantação do sistema proposto, bem como
os impactos para o chefe de departamento, professores e alunos do DEI.
Além disso, foi realizado um paralelo com as causas raízes levantadas para
entendermos quais aspectos foram sanados a partir da solução.
7
2. REVISÃO BIBLIOGRÁFICA
Neste capítulo, foi realizada a revisão da literatura em busca de conceitos e
temas que forneçam embasamento teórico para o trabalho. O capítulo está dividido em
3 partes: processos de negócio, gestão por processos e gestão de processos de
negócio.
2.1 Processos de Negócio
Davenport (1993 apud PAIM, 2009, p. 101) define processo como “uma
ordenação específica de atividades de trabalho através do tempo e do espaço, com um
início, um fim e um conjunto claramente definido de entradas e saídas”. Já o BPM CBOK
(2013, p. 35) apresenta a seguinte definição: “processo é uma agregação de atividades
e comportamentos executados por humanos ou máquinas para alcançar um ou mais
resultados”. Oliveira (2006 apud CARRARA, 2011, p. 33) apresenta processo “como um
conjunto de ações ordenadas e integradas para um fim produtivo específico, ao final do
qual serão gerados produtos e/ou serviços e/ou informações”.
Segundo Carrara (2011), a definição de “processo” vem sofrendo alterações ao
longo dos anos, de modo a agregar novas características, incorporando em si conceitos
de valor e cliente. Assim, surgem os “processos de negócio”, cuja definição, segundo
Chang (2006 apud CARRARA, 2011, p. 33), é: um fluxo de atividades coordenadas e
padronizadas, executadas por máquinas ou pessoas, que pode atravessar fronteiras
funcionais e departamentais, cujo objetivo é obter um resultado que crie valor para os
clientes externos (e internos). Cabe ressaltar que a padronização das atividades permite
a mensuração do valor que as mesmas entregam aos clientes.
A figura 2 caracteriza o conceito de processo de negócio sob o ponto de vista
sistêmico.
8
Figura 2 – Visão sistêmica do processo de negócio
Fonte: Baldam et al., 2007 (p. 16)
2.2 Gestão por Processos
De acordo com BPM CBOK (2013), a gestão por processos significa “uma visão
mais ampla posicionando processos como pedra angular da estruturação
organizacional”. Dessa forma, o valor gerado passa a ser administrado de forma
horizontal, em uma visão que transcende as fronteiras funcionais da organização.
McCormark e Johnson (2001 apud PAIM et al., 2009, p. 128-129) explicam que, na
gestão por processos, os processos são priorizados como um eixo gerencial de maior
importância que o eixo funcional e, devido a isso, ocorrem alterações na estrutura
organizacional e em outros elementos integrantes do projeto organizacional.
Dessa forma, segundo Baldam et al. (2007), as tarefas não são definidas
exclusivamente em função dos departamentos da organização. Ao procurar entender “o
que precisa ser feito e como fazê-lo”, a gestão por processos prioriza identificar
inicialmente as atividades que agregarão valor à organização, sendo que o processo
pode cruzar departamentos e solicitar serviços de cada um deles caso seja necessário
para a execução das atividades.
A figura 3 esquematiza as diferenças entre organizações com enfoque
departamental e por processos.
9
Figura 3 – Visão departamental x Visão de processos
Fonte: Malamut, 2005 (p. 19)
Netto (2006, apud CARRARA, 2011, p. 37-38) ressalta algumas características
relacionadas à gestão por processos.
São objetivos:
8. Aumentar a percepção por parte do cliente do valor de produtos e
serviços;
9. Aprimorar a competitividade da organização;
10. Dar suporte à estratégia competitiva adotada;
11. Aumentar a produtividade com eficiência e eficácia;
12. Tornar processos mais simples ao alterar ou eliminar atividades que não
agregam valor.
São pontos negativos:
Aumento de conflitos internos ligados à existência de estruturas
matriciais;
Aumento de custos de gerenciamento ligados à necessidade de
coordenação de estruturas matriciais;
São riscos associados:
Resistência à mudança e problemas de integração;
Falta de trabalhadores capacitados;
Desperdício de esforços e recursos ao trabalhar em processos que
deveriam ser eliminados.
Por fim, vale o destaque para a definição de gestão de processos, que difere do
conceito de gestão por processos. Diferentemente da gestão por processos, que está
relacionada a uma alternativa para gestão da organização de uma forma geral, como já
visto nesta seção, a gestão de processos busca, de acordo Lindsay et al. (2003), obter
10
melhorias no desempenho mensurável das atividades. Isto quer dizer que a gestão de
processo, além de tornar explícito o processo, deve-se preocupar com a gestão contínua
dos processos que sempre irão mudar.
2.3 Gestão de Processos de Negócio – BPM
2.3.1 Conceituação
Segundo BPM CBOK (2013), Gestão de Processos de Negócio pode ser definida
como:
“(...) uma disciplina gerencial que integra estratégias e objetivos de
uma organização com expectativas e necessidades de clientes, por
meio do foco em processos ponta a ponta. BPM engloba estratégias,
objetivos, cultura, estruturas organizacionais, papéis, políticas,
métodos e tecnologias para analisar, desenhar, implementar, gerenciar
desempenho, transformar e estabelecer a governança de processos”.
BPM, segundo Leite e Rezende (2007, apud OLIVEIRA et al., 2010, p. 135), é:
“(...) uma evolução do workflow, que tratava dos fluxos de trabalho com
a possibilidade da visão e redefinição dos processos da organização.
De acordo com os autores, o BPM consegue ir além da automação do
fluxo de trabalho e da modelagem gráfica dos processos, pois também
envolve a monitoração dos processos enquanto executados e uma
integração ponta a ponta, englobando as tarefas humanas e as
operações automatizadas”.
Scheer et al. (2004) afirma que, em um mundo em constante mudança, é
necessário que organizações sejam capazes de adaptar os seus processos de negócio
de modo a garantir uma sobrevivência de longo prazo. Smith e Fingar (2003, apud
CARRARA, 2011) defendem que a habilidade de realizar mudanças nos processos se
torna uma característica importante para as organizações, uma vez que permite o
monitoramento, melhoria e otimização de maneira contínua de toda a cadeia de valor.
Assim, a organização se torna capaz de moldar seus processos de forma a atender
demandas internas ou externas que fomentam eficiência e diferenciação.
2.3.2 Ciclo de Vida BPM
De modo a orientar o gerenciamento de processos de negócio, a literatura
propõe diversos modelos. Entretanto, cabe ressaltar que nenhum deles corresponde
exatamente à realidade, uma vez que é impossível prever, a partir de um esquema
teórico, como se dará efetivamente o BPM, pois as pessoas que implementam ou
11
operam o BPM são fundamentais para o sucesso da sua aplicação (BALDAM et al.,
2007).
Baldam et al. (2007) propõem um ciclo de implantação de BPM composto por
quatro etapas, conforme esquematizado na figura 4.
Segundo Carrara (2011), neste método não se faz necessário mapear todos os
processos, nem todos os níveis de processos. Ao invés, devem-se identificar os
processos prioritários de modo a manter o foco e obter resultados satisfatórios.
Recomenda-se, inclusive, que se trabalhe com um processo por vez.
A seguir, será feita uma descrição de cada uma das etapas que compõem o
modelo.
Planejamento do BPM: tem o propósito de definir as atividades de BPM
que contribuirão para o alcance das metas organizacionais em todos os
níveis, considerando tarefas como a verificação dos pontos de falha nos
processos que causam danos à organização, definição de planos de ação
Figura 4 – Ciclo de vida BPM
Fonte: Baldam et al., 2007 (p. 46)
12
para implantação e definição dos processos que necessitam de ação
imediata (BALDAM et al., 2007). Santos (2013) defende que a seleção
correta dos processos a serem automatizados é muito importante, pois
evita a alocação desnecessária de esforços e recursos na
automatização, o que pode prejudicar os resultados esperados e até o
sucesso do processo de implantação.
Modelagem e otimização de processos: engloba atividades que permitem
gerar informações sobre o processo atual (As Is) e/ou sobre a proposta
de processo futuro (To Be); documentar os processos; prover dados de
integração entre processos; empregar metodologias para otimizar os
processos; fazer simulações, inovações e redesenhos; adotar as
melhores práticas e modelos de referência; gerar especificações para
implementação, para configuração e customização (caso o processo
ainda não esteja em uso), para execução e para controle (BALDAM et
al., 2007).
Execução de processos: engloba atividades intimamente ligadas à
automação dos processos de negócio. Com o auxílio de uma notação
pré-estabelecida, diferentes aplicações de software são executadas de
acordo com a sequência de atividades definidas na modelagem.
Segundo Mohapatra (2009), a execução do processo é sustentada por
provedores de serviços desenvolvidos, usualmente, utilizando web
services e Arquitetura Orientada a Serviços (SOA). Baldam et al. (2007)
complementa afirmando que treinamentos também são necessários
nesta etapa, além de o acompanhamento do processo implantado,
monitoria e controle da execução de instâncias de processo.
Controle e análise de dados: engloba atividades responsáveis por
monitorar os processos após os mesmos terem sido implementados.
Com isso, é possível obter dados estatísticos que permitirão formar a
base para o próximo nível de melhorias de processo. Tal procedimento é
possibilitado por meio de comparação com os resultados esperados do
modelo teórico, e permite identificar gargalos nos processos e
discrepâncias entre os modelos e os processos reais (MOHAPATRA,
2009). Segundo Baldam et al. (2007), tais atividades geram informações
que posteriormente realimentarão as atividades de otimização e
planejamento.
13
2.3.3 BPMN
O BPMN é uma notação para modelagem de processos atualmente mantida pelo
Object Management Group (OMG). De acordo com Juric e Pant (2008), esta notação foi
desenvolvida, particularmente para se modelar processos de negócio em conformidade
com o SOA. Apesar disso, o BPMN é utilizado como um modelo de notação para
diferentes finalidades, que vão desde a padronização de um processo específico até a
preparação para um projeto de automação de processos de negócio.
A notação BPMN pode ser utilizada para modelar partes de um processo ou todo
o processo, podendo focar apenas no ponto de vista de uma única organização,
definindo as atividades que são internas, ou mostrando a interação entre todos negócios
e empresas envolvidas.
Em janeiro de 2011, a OMG publicou a versão 2.0 do BPMN, cujo principal
objetivo é fornecer uma notação facilmente compreensível por todos os usuários de
negócio, desde os analistas de negócio que criam os primeiros esboços dos processos,
para os desenvolvedores técnicos, responsáveis pela implantação da tecnologia que irá
executar esses processos e, finalmente, para as pessoas que irão gerenciar e monitorar
esses processos.
ELEMENTOS GRÁFICOS DA NOTAÇÃO BPMN
A notação BPMN apresenta uma série de elementos gráficos que permitem a
modelagem de um processo de negócio. Estes objetos se dividem em cinco grupos de
elementos:
Objetos de Fluxo
OMG (2011) define os objetos de fluxo como os principais elementos gráficos
para definir o comportamento de um processo de negócio. Correspondem aos símbolos
de atividade (ou tarefa), subprocesso, eventos e gateway, como ilustra a figura 5.
14
Figura 5 – Objetos de fluxo da notação BPMN
Fonte: Adaptada de OMG (2011)
Dados
Os dados são representados por quatro elementos: objeto de dados, entrada de
dados, saída de dados e depósito de dados. Alguns desses elementos podem ser
observados na figura 6.
Figura 6 – Objetos de dados da notação BPMN
Fonte: Adaptada de OMG (2011)
Objetos de Conexão
De acordo com OMG (2011), existem quatro formas de conectar os objetos de
fluxo entre si ou com outras informações. Existem quatro objetos: fluxo de sequência,
associação, fluxo de mensagens e associação de dados. A figura 7 apresenta alguns
destes símbolos.
15
Figura 7 – Objetos de conexão da notação BPMN
Fonte: Adaptada de OMG (2011)
Swimlanes
Através das “Swimlanes” é possível agrupar os elementos da modelagem
primária. São dois tipos: pools e lanes. A figura 8 apresenta estas formas de
agrupamento.
Figura 8 – Swimlanes (notação BPMN)
Fonte: Adaptada de OMG (2011)
Artefatos
Artefatos são utilizados para possibilitar a adição de informações ao modelo do
processo. Existem dois tipos de artefatos: grupos e anotações de texto. A figura 9
apresenta estas duas formas de informação adicional.
16
Figura 9 – Artefatos (notação BPMN)
Fonte: Adaptada de OMG (2011)
LAYOUT GERAL DO AMBIENTE DE PROCESSO
O diagrama do ambiente do processo, de acordo com Juric e Pant (2008), mostra
uma vista superior do processo de negócio, onde ele pode ser apresentado como uma
única atividade. Neste diagrama é mostrado:
O gatilho do processo, que nos mostra como o processo é iniciado;
As informações de entrada, necessárias para o processo;
Os resultados do processo;
As funções envolvidas no processo;
As métricas utilizadas para mensurar a eficiência do processo;
Eventos que podem interromper o fluxo regular do processo e a compensação
lógica do processo;
Conformidade com padrões ou referências do processo;
As metas de negócio que o processo contribui.
17
Figura 10 – Layout geral do ambiente de processo
Fonte: Adaptada de Juric e Pant (2008)
2.3.4 Sistemas de Gestão de Processos de Negócio – BPMS
Os BPMS podem ser entendidos como um conjunto de instrumentos que buscam
a melhoria do sistema de gestão, contribuindo para a implementação de mudanças que
mantenha a empresa com os fluxos de trabalho claramente definidos, automatizados e
racionais (PAIN et al., 2009).
Vale ressaltar, entretanto, que existem vários entendimentos distintos para o que
são BPMS, de forma que existem diferentes tipos de sistemas que podem ser
considerados como um sistema de gestão de processos de negócio, como por exemplo:
sistemas de gerenciamento de regras de negócio, pacotes BPM, sistemas de
monitoramento dos processos de negócio, sistemas de modelagem de processos,
sistemas de workflow, CRM – ERP, entre outros sistemas (HALL et al., 2006, apud PAIM
et al., 2011).
18
Entretanto, segundo Baldam et al. (2007), é necessário um conjunto de
diferentes ferramentas para compor uma solução total de BPM, e elas não necessitam
estar obrigatoriamente integrados em uma única suíte de produtos de software de um
único fabricante. Devido às limitações das ferramentas sob a ótica individual, observa-
se uma tendência de integração entre os mesmos de forma a obter melhores resultados.
A tendência é a padronização do uso das ferramentas para plataformas rodando sob o
modelo SOA, o que facilita a integração dos processos envolvidos.
Gart Capote (2013) afirma que as ferramentas BPMS devem dar apoio às
organizações na realização de atividades importantes das fases do ciclo de vida do
BPM, sendo elas principalmente:
1. A apresentação dos seus processos (Modelagem)
2. Definição das informações geradas (Dados)
3. A forma como o trabalho será realizado (Formulários)
4. O comportamento dos processos (Regras de Negócio)
5. Definição e alocação de recursos (Participantes)
6. Reutilização dos sistemas da informação (Integração)
7. Validação das mudanças nos processos (Simular)
8. A realização do trabalho definido no processo (Execução)
9. A verificação de resultados do processo (Monitorar)
Ainda de acordo com Gart Capote (2013), a representação cíclica mais comum
para a utilização de ferramentas BPMS é a sugerida na figura 11.
19
Figura 11 – Ciclo BPMS
Fonte: Gart Capote, 2013 (p. 126)
Cabe ressaltar, entretanto, que no presente projeto o ciclo BPMS apresentado
foi utilizado de forma adaptada, desconsiderando as etapas “Definir Participantes”,
“Definir Integrações”, “Simular Processos” e “Executar Processos” por uma série de
razões. Dentre elas, pode-se citar: necessidade de conhecimentos avançados em TI,
inexistência do software de elaboração do planejamento de turmas apontado no capítulo
7, além de ser necessário um tempo hábil para implementar, testar e monitorar o novo
sistema proposto, não sendo possível pois dependeria de pelo menos 1 período letivo
completo para validação. Assim, um novo ciclo foi construído, considerando a adaptação
proposta, conforme a figura 12.
Modelar Processos
Modelar Dados
Definir Formulários
Definir Regras de Negócio
Definir Participantes
Definir Integrações
Simular Processos
Executar Processos
Monitorar Processo
20
Figura 12 – Adaptação ao Ciclo BPMS
Fonte: Adaptada de Gart Capote (2013)
Modelar Processos
Modelar DadosDefinir Formulários
Definir Regras de Negócio
21
3. CARACTERIZAÇÃO DO DEI
Neste capítulo, foi realizada a caracterização do Departamento de Engenharia
Industrial com o objetivo de compreender o seu propósito, os desafios e limitações
enfrentados, bem como sua relação com outros agentes. Além disso, foram definidos
critérios de desempenho, considerados essenciais para o DEI, que posteriormente
auxiliarão na análise dos resultados organizacionais esperados decorrentes da
aplicação da automação do processo de planejamento de turmas.
3.1 História
O Departamento de Engenharia Industrial (DEI) foi concebido a partir do antigo
Departamento de Estudos Econômicos e Sociais para formar engenheiros com
conhecimentos técnicos, segundo Cosenza (2015), “nos campos do planejamento, na
estratégia empresarial, na organização científica do trabalho, nos estudos de mercado,
na definição de escalas de projeto e na localização industrial”. Assim, foi criado o DEI
com a finalidade de conferir sustentação ao curso de Engenharia de Produção. Segundo
DEI (2016), o curso foi aprovado em 1971 como curso de Engenharia Industrial, tendo,
em 1974, sido aprovado pelo conselho universitário a alteração do nome do curso para
Engenharia de Produção, obtendo o reconhecimento oficial em maio de 1975. Com o
passar dos anos, o curso adquiriu maior abrangência ao agregar disciplinas voltadas
para a área financeira e o mercado secundário especulativo, constituindo o atual curso
de Engenharia de Produção (COSENZA, 2015).
Pode-se afirmar que o curso de Engenharia de Produção da Universidade
Federal do Rio de Janeiro, ao lado do da Universidade de São Paulo, é o pioneiro no
país, servindo para o desenvolvimento da Engenharia de Produção em âmbito nacional,
motivando a criação do curso em outras universidades do estado, tais como
Universidade Federal Fluminense, Universidade do Estado do Rio de Janeiro e
Pontifícia Universidade Católica do Rio de Janeiro (DEI, 2016).
Atualmente, os propósitos do DEI são: manter a estrutura e infraestrutura que
suportam o funcionamento das atividades acadêmicas do departamento, além de
oferecer módulos que compõem o curso de graduação em Engenharia de Produção e
outros cursos de engenharia da Escola Politécnica, além de cursos de especialização e
de extensão, cujas responsabilidades são dos coordenadores de cada curso, membros
do DEI.
22
3.2 Estrutura e Infraestrutura do DEI
O DEI está localizado no térreo do bloco F do Centro de Tecnologia da UFRJ e
conta com as seguintes instalações: secretaria, salas de professores (três salas), salas
de aula (seis salas) e o laboratório LIG Produção (DEI, 2016).
Com relação aos recursos humanos, no momento de elaboração do presente
trabalho, o departamento tinha à disposição um corpo docente composto por 29
professores, dentre os quais 24 eram permanentes e 5 eram substitutos.
Além disso, o chefe de departamento era o professor Vinícius Carvalho Cardoso
e o subchefe era o professor Amarildo da Cruz Fernandes; a célula acadêmica era
composta por 3 funcionários próprios: Maria José Caetano do Amaral, Waldecleide
Andrade de Souza e Arnaldo Souza Vieira; e a célula administrativa era composta por
Carlos Carvalho, os funcionários terceirizados de serviços gerais Ana Cristina da Silva
Mota e João Evangelista de Farias Barros, e Isaque Procópio, que compunha a equipe
de suporte de TI. O organograma do departamento está representado na figura 13.
Figura 13 – Organograma do Departamento de Engenharia Industrial
Fonte: Elaboração própria
Além disso, a infraestrutura do DEI era composta por componentes de TI –
hardware, software, tecnologia de gerenciamento de dados e tecnologia de rede e
telecomunicações – e ativos físicos do departamento, para o desempenho de suas
funções.
Chefe de Departamento
Corpo DocenteCélula
AcadêmicaCélula
Administrativa
Chefe Suplente do
Departamento
23
3.3 Subáreas do DEI
O DEI é composto por três subáreas formais de ensino: Gerência da Produção,
Engenharia Econômica e Métodos Quantitativos. Na prática, existe uma quarta área que
tem como foco a Engenharia do Petróleo. As disciplinas do curso de Engenharia de
Produção foram distribuídas entre estas áreas do conhecimento para que fosse possível
alocar os docentes de acordo com sua formação.
Além de ser importante para a organização das linhas de conhecimento
difundidas pelo CEP da UFRJ, esta divisão é importante para o planejamento das
disciplinas a serem lecionadas a cada semestre, principalmente o dimensionamento do
quadro de professores.
3.4 Principais Atividades
O Departamento de Engenharia Industrial, como já mencionado, tem o objetivo
central de suprir e sustentar a estrutura e a infraestrutura necessárias para que os
cursos de Engenharia de Produção e Engenharia de Petróleo possam, principalmente,
manter suas atividades. Para atender este objetivo, o DEI concilia quatro funções, como
se pode verificar na figura 14: acadêmica, gerencial e administrativa, de manutenção e
de realização de projetos de infraestrutura.
A função acadêmica engloba todas as atividades que geram algum impacto na
vida cotidiana do docente, do ponto de vista da entrega de conteúdo didático e
pedagógico aos alunos. São exemplos de atividades de função acadêmica: concurso
para professores substitutos, concurso para professores permanentes, alocação de
professores, previsão de turmas, alocação das disciplinas às salas, processo de
afastamento, progressão docente e compra de materiais didáticos/pedagógicos.
A função de manutenção compreende atividades que envolvem a manutenção
da estrutura e infraestrutura do DEI, tais como a manutenção das redes elétrica,
eletrônica, hidráulica e de telefonia das instalações do departamento.
Além da função de manutenção, cabe ao departamento a realização de projetos
de infraestrutura quando necessário. São exemplos de obras de infraestrutura a
implantação de uma nova rede de internet sem fio, cobrindo toda a extensão física do
departamento, e a criação do laboratório LIG Produção.
Por fim, o DEI desempenha uma função que compreende atividades gerenciais
e administrativas. Existem dois principais conjuntos de processos nesta função: os
processos de compras de materiais básicos, para o funcionamento diário do
departamento, e os processos financeiros, responsáveis pela administração e controle
24
dos recursos financeiros do DEI, atualmente, comandado pelo subchefe do
departamento.
Figura 14 – Funções do Departamento de Engenharia Industrial
Fonte: Elaboração própria
Dentre as atividades do DEI, foi destacado pelo chefe do departamento que o
processo mais importante e recorrente é o de planejamento de turmas. Assim, além de
ser um processo destacadamente importante para o DEI, este processo foi escolhido
pelo fato de já estar sendo realizadas iniciativas para automação de parte deste
processo. Este fato fez do processo de planejamento de turmas um objeto interessante
para o desenvolvimento deste projeto, já que se pode aproveitar a experiência prévia na
tentativa da busca de soluções para as dificuldades do planejamento de turmas.
Para melhor compreensão do processo de planejamento de turmas, foco do
presente projeto, foi elaborada uma breve apresentação onde foram levantados os
principais critérios de desempenho.
3.4.1 Planejamento de Turmas
O processo de planejamento de turmas faz parte da função acadêmica do DEI e
é considerado uma das principais atividades do departamento. Planejar as turmas
Funções do DEI
Acadêmicas
Manutenção
Projetos de
Infraestru-tura
Gerenciais e
Administra-tivas
25
significa alocar os professores às disciplinas, definir salas (capacidade), dias e horários
para cada uma das disciplinas oferecidas em um determinado período.
Esta tarefa se torna complexa à medida que não se tem uma visibilidade clara
da demanda por cada disciplina. A demanda de pedidos de inscrição em disciplinas
possui uma natureza difícil de regular. Isso ocorre devido a um fenômeno ocorrido no
sistema provocado pelo fato de alunos se inscreverem em diversas disciplinas a fim de
aumentarem suas chances de conseguir o máximo de aceitação possível. Isso pode vir
a provocar uma lotação diferente da prevista pelo processo em questão.
Além disso, outro fator que contribui para a complexidade da previsão é o fato
das características das turmas (professores disponíveis e demanda por vagas) não
serem estáveis. Em cada período, existe uma necessidade diferente de alocação que,
por sua vez, é diferente das alocações executadas nos períodos anteriores. Isso pode
ocorrer por diversos motivos, tais como: professores apresentam restrições de horários
diferentes, alunos que estão regressando de intercâmbio, novos alunos realizando
intercâmbio na universidade, maior percentual de reprovação em um determinado
período – o que pode aumentar ou reduzir a demanda de vagas em uma determinada
disciplina, entre outros fatores.
O principal objetivo deste processo é realizar a alocação de recursos que
possibilite a oferta das disciplinas obrigatórias, restritas e eletivas para os alunos do DEI
. Vale destacar, entretanto, que este objetivo deve ser atingido com o máximo de
atendimento das necessidades dos docentes, coordenadores e alunos.
Considerando estes resultados esperados, o DEI deve conseguir realizar este
planejamento de forma mais eficaz e eficiente, no sentido de atender aos objetivos
especificados e com a menor alocação de homem-hora possível para realização destas
atividades, respectivamente, desonerando a chefia no processo, tornando o cargo mais
atrativo para próximas gestões.
Atualmente, a previsão de turmas é feita com base no histórico de turmas
oferecidas. Entretanto, devido à instabilidade do sistema ocasionado pelo
comportamento irregular da demanda e pelo dinamismo entre os agentes envolvidos,
tal método se mostra insuficiente. Conforme relatado pelo chefe de departamento,
faltam critérios que confiram robustez ao processo de previsão de turmas.
A tabela 1 apresenta os principais critérios de desempenho do processo de
previsão de turmas levantados por meio de entrevistas com o chefe do DEI, de forma a
servir como base para melhoria deste processo.
26
Função Critérios de Desempenho
Planejar as turmas do período alocando os recursos do departamento (salas e
professores)
Menor retenção de alunos (Longo Prazo)
Menor número de alunos sem vaga (Curto Prazo)
Maior satisfação dos professores
Tabela 1 - Critérios de desempenho do processo de planejamento de turmas
Fonte: Elaboração própria
Se o aluno não for reprovado em nenhuma disciplina e cursar todas as disciplinas
dentro do período especificado, é esperado que ele termine o curso de Engenharia de
Produção em cinco anos. No entanto, as reprovações acontecem, os alunos vão para
intercâmbio e, por isso, muitos deles acabam ficando mais tempo dentro da
universidade. Nesse caso, cabe ao departamento oferecer uma grade que permita que
o aluno, mesmo diante de uma reprovação ou outro motivo, consiga realizar um conjunto
de disciplinas que minimize o impacto deste atraso no seu tempo de atravessamento no
curso.
O planejamento de turmas deve beneficiar os alunos, em primeira instância, mas
também deve ser coerente com os interesses dos docentes, tanto de horário e número
de alunos. Por uma questão de limitação de salas, entretanto, não é possível que todos
os professores deem aula no seu horário preferido. Assim cabe à chefia encontra um
planejamento que busque concentrar os horários dos professores, em poucos dias e em
uma faixa de horário contínua.
27
4. MODELAGEM DOS PROCESSOS DE PLANEJAMENTO DE TURMAS
Nesta seção foi apresentada a modelagem do processo de planejamento de
turmas. Esta etapa é fundamental para que se possa tornar explícito o processo
estudado, possibilitando uma posterior identificação das necessidades de automação.
Para modelar os processos foi utilizado o software Bizagi Modeler, onde foi
possível construir o fluxograma de processos seguindo a notação BPMN.
4.1 O Processo de Planejamento de Turmas
O processo de planejamento de turmas tem como objetivo central determinar em
qual horário e sala de aula determinada disciplina será ministrada, além de promover a
alocação de um professor responsável. O processo se inicia alguns meses antes do
começo do período letivo. O responsável pela condução do processo é o chefe de
departamento, porém outros agentes – professores, coordenadores, alunos e
funcionários do DEI – também participam em determinados momentos. O processo
possui uma duração média de 1 mês e meio e, de acordo com o chefe do DEI, da forma
como é conduzido atualmente, ocasiona em si sobrecarga significativa.
Inicialmente, o chefe do DEI utiliza como base para construção do planejamento
de turmas de determinado semestre a versão final da previsão para o mesmo semestre
do ano anterior. Assim, por exemplo, caso o interesse seja realizar a previsão de turmas
para 2016.1, o chefe do DEI irá utilizar a base de dados de 2015.1. Isso se dá devido
ao fato de existirem matérias que são ofertadas de forma alternada entre semestres, ou
porque o quadro de professores disponíveis permanece relativamente o mesmo, salvo
algumas exceções, o que confere ao resultado anterior uma boa aproximação para a
construção da nova previsão. A versão inicial de previsão de turmas é construída com
o auxílio de planilhas, e o seu resultado é confrontado com a configuração de turmas do
semestre em curso para detecção de alterações realizadas que necessitam ser
validadas quanto à sua permanência junto aos professores e alteradas na base de
dados.
O chefe do DEI, então, reúne todas as demandas de professores e
coordenadores. Esse último grupo inclui, além do coordenador de Engenharia de
Produção, coordenadores de outros cursos, pois o DEI oferta disciplinas para outras
engenharias.
Coordenadores de outros cursos que desejam solicitar determinada quantidade
de vagas para seus alunos em turmas ofertadas pelo DEI enviam as solicitações por
meio de memorandos ou e-mails. O primeiro caso se dá mais frequentemente para
28
solicitações que compreendem um número pequeno de turmas. Já o segundo caso
ocorre com mais frequência quando envolve cursos que solicitam uma oferta maior de
disciplinas do DEI, como é o caso do curso de Engenharia de Petróleo, e assim o
processo de previsão se torna mais dinâmico e complexo.
Uma vez que a previsão é feita baseada nas duas previsões anteriores, é
provável que uma turma solicitada cuja natureza seja de oferta regular já esteja prevista,
sem gerar grandes problemas. Entretanto, caso o solicitante altere o horário da turma
ou aumente o número de vagas necessárias, irá requerer alterações mais significativas
no quadro de turmas, envolvendo disponibilidade de professores e salas de aula. Nesse
caso, se a disciplina requerida for obrigatória para o curso solicitante, a negociação se
estende até que seja obtida uma solução, podendo ser tomadas medidas pouco
recorrentes, como contratar um professor substituto, pedir ajuda a outros departamentos
ou solicitar que determinado professor fique sobrecarregado. Se a disciplina requerida
fizer parte do grupo de disciplinas condicionadas, não se torna necessário o transtorno
mencionado, uma vez que tais matérias fazem parte de um grupo maior que, inclusive,
podem ser ministradas em outros departamentos. A mesma lógica vale para pedidos de
novas turmas.
O coordenador de Engenharia de Produção é o responsável por negociar as
turmas de disciplinas ministradas para alunos de Engenharia de Produção que não são
de responsabilidade do DEI, como as matérias ofertadas pelo Instituto de Física (IF) e
Instituto de Matemática (IM), além de outros departamentos, por exemplo, e transmitir
oralmente ou por e-mail os resultados parciais das negociações para que a chefia do
DEI atualize a previsão. Tais negociações envolvem determinação de salas de aula e
tamanho de turmas.
Uma vez enviada por e-mail para os professores e coordenadores a primeira
versão da previsão de turmas realizada, os mesmos são requisitados pelo chefe do DEI
a verificar se os dados estão de acordo com suas demandas. À medida que alguns
professores confirmam e outros realizam pedidos de alteração, e o coordenador de
Engenharia de Produção realiza alterações nos horários de disciplinas que não são de
responsabilidade do DEI, novas versões da planilha de previsão são criadas e
encaminhadas até que se obtenha consenso geral. A figura 15 mostra a layout da
planilha usada no processo de planejamento de turmas.
29
Figura 15 – Planilha de planejamento de turmas
Fonte: DEI (2016)
30
Após a obtenção do consenso por todos os demandantes quanto à previsão de
turmas, o chefe do DEI divulga o planejamento final por e-mail para professores e
coordenadores, e encaminha o mesmo para funcionários do DEI, que são responsáveis
por lançar as turmas no Sistema Integrado de Gestão Acadêmica da UFRJ (SIGA) antes
do início oficial do período de inscrição. Além disso, o chefe do DEI disponibiliza nos
murais do departamento o planejamento de turma no formato de quadro de horários,
conforme visto na figura 16.
Figura 16 – Quadro de horários da Engenharia de Produção (1º período – 2016.1)
Fonte: DEI (2016)
Durante o período de inscrição, pode ser necessário alterar a capacidade de
determinadas turmas (aumentando ou diminuindo o número de vagas), seja devido a
uma demanda de inscrições não prevista ou alterações de última hora no quadro de
professores ou de salas de aula disponíveis. Sob essas condições, caso seja necessário
aumentar a capacidade da turma, o chefe do DEI inicialmente verifica se o projeto
pedagógico do professor alocado permite a expansão e se a sala designada comporta
a nova quantidade de alunos. Se a primeira condição for atendida e a segunda, não, é
possível ainda buscar outras salas de aula. Caso seja necessário diminuir a capacidade
da turma e já tenha uma quantidade de alunos inscritos superior à nova capacidade, é
31
necessário que o chefe do DEI notifique individualmente cada aluno em excesso,
pedindo que os mesmos retirem suas inscrições.
Atualmente, o processo de previsão de turmas atende às necessidades do
Departamento, porém demanda tempo por parte do chefe do DEI, comprometendo a
qualidade do serviço e abrindo oportunidades para melhoria. Existe uma ferramenta de
automação sendo elaborada pelo estagiário do Departamento com o intuito de
automatizar o planejamento de turmas. Por enquanto, tal ferramenta se baseia no
histórico dos períodos para gerar a grade horária, porém a mesma permite uma interface
mais intuitiva e dinâmica com o chefe do DEI ao apostar, principalmente, na
apresentação dos dados e informações necessárias à tomada de decisões. Cabe
ressaltar, entretanto, que a ferramenta em questão e suas características não serão
consideradas no projeto de automação deste projeto.
Em entrevista, o chefe do DEI estabeleceu as seguintes metas para o processo:
diminuir o tempo de execução; buscar a otimização da alocação de recursos (salas de
aula, professores e horários) no universo do DEI; tornar a previsão e turmas baseada
na demanda real de alunos, ao invés de no histórico de previsões. A figura 17 representa
um diagrama que resume alguns aspectos relacionados ao processo de previsão de
turmas, como evento de início e de fim, além dos inputs, outputs e condições previstas.
O processo modelado pode ser encontrado no apêndice A.
Figura 17 – Ambiente geral do processo de planejamento de turmas
Fonte: Elaboração própria
32
5. ANÁLISE DO PROCESSO
Após modelar o processo escolhido para aplicar a automação de processos,
tema central deste projeto, foram levantados os pontos de alavancagem do processo a
partir da identificação dos efeitos indesejáveis e de suas causas, para que, em um
segundo momento, fosse possível esclarecer as necessidades de automação no
processo de planejamento de turmas do DEI.
A análise foi dividida em três seções. Na primeira, foi realizada uma avaliação
geral do processo, com base nos critérios de desempenho estabelecidos no capítulo 3
e descritos na tabela 1. Na segunda seção, foram levantados os efeitos indesejáveis
(EI) que impedem que os processos atinjam um desempenho superior. Por fim, na
terceira seção, foram identificadas as causas dos “efeitos indesejáveis” a partir da
utilização da Árvore da Realidade Atual (ARA), desenvolvida por Goldratt. Na ARA, os
efeitos indesejáveis são desdobrados até que se identifique as causas raízes destes
problemas.
5.1 Avaliação Geral com Base nos Critérios de Desempenho
Como visto na caracterização do DEI, definiram-se três critérios que traduzem o
desempenho do processo:
Menor retenção de alunos – avalia o planejamento no longo prazo e se traduz
por meio do tempo de atravessamento médio dos alunos no curso.
Menor número de alunos sem vagas – avalia o planejamento no curto prazo e
se traduz por meio da razão entre oferta e demanda por turma.
Maior satisfação dos docentes – avalia o planejamento pela perspectiva do
docente. Este critério pode ser definido e padronizado no sentido de concentrar
os horários de aula dos docentes durante a semana, não permitindo, por
exemplo, que um mesmo professor dê uma aula às 07:00 e uma às 15:00 no
mesmo dia.
Estes critérios foram definidos a partir de entrevistas com o chefe do DEI, que
destacou estes três aspectos como importantes para entender se o processo está
atingindo o seu propósito. Como o departamento não controla estes critérios por meio
de nenhum indicador quantitativo e não houve tempo suficiente para coletar
informações, uma vez que o processo ocorre ao longo de todo semestre, foi inviabilizada
uma análise quantitativa destes critérios de desempenho.
A atual gestão do DEI está buscando alternativas para montar um planejamento
que atenda os interesses de alunos, coordenadores e docentes com maior efetividade.
33
A vontade de atingir este objetivo traz um ônus para a chefia que, manualmente, realiza
alterações no processo a cada solicitação que necessita ser atendida.
Com relação à satisfação dos docentes, é importante ressaltar que não é
possível agradar a todos com o número de salas disponíveis atualmente. Os horários
de sete às dez da manhã e de três às cinco da tarde (principalmente na sexta feita) são
os preteridos por boa parte dos docentes, de acordo com o chefe de departamento do
DEI. Como existe um número limitado de salas, algum professor poderá ser alocado
nestes horários. Dentro do possível, o chefe procura concentrar os horários dos
docentes durante a semana e durante o dia, de forma que o docente não tenha que dar
aulas todos os dias e evitando que o professor precise ficar na universidade o dia todo.
5.2 Efeitos Indesejáveis
A partir da modelagem do processo de planejamento de turmas e conversas com
alguns envolvidos no processo, levantou-se alguns efeitos indesejáveis que impedem
que o processo atinja um desempenho superior em termos dos critérios definidos na
tabela 1.
Os efeitos indesejáveis encontrados no processo foram listados abaixo com as
respectivas justificativa.
EI 1. Necessidade de ajustes na alocação de recursos durante o período de inscrição e
de alteração
Um dos principais efeitos que mostram que o processo não atingiu uma boa
eficácia é a necessidade de reajuste no planejamento durante o período de inscrição.
Quanto mais alterações de capacidade e ajustes de sala e professor o chefe precisa
realizar durante o período de inscrição e alteração, menor foi a assertividade de seu
planejamento.
Os principais erros que geram a necessidade de ajustes no planejamento
durante o período de inscrição em disciplinas e de alteração são os erros de cadastro
de turmas no SIGA e erros de previsão relacionados a dificuldade de atender a demanda
real por disciplinas.
De acordo com o chefe de departamento, em menos de uma semana após a
abertura do período de inscrições referente ao período 2016.2, já haviam sido realizadas
duas alterações no planejamento. Apesar de parecer pouco, realizar alterações quando
todo o planejamento já foi colocado no SIGA gera um trabalho ainda maior, como foi
demonstrado na modelagem do processo.
EI 2. A demanda supera as expectativas em algumas turmas e fica abaixo em outras
34
O DEI planeja um determinado número de vagas para cada turma. Em algumas
turmas, o número de inscrições supera muito a capacidade. Em contrapartida, algumas
turmas recebe um número de inscrições muito pequeno. Quando este tipo de situação
ocorre, gera-se um desconforto para o chefe do departamento, que deve buscar alguma
alternativa para equilibrar a demanda.
Este efeito também gera a necessidade de ajustes no planejamento durante o
período de inscrição, que pode acarretar em um maior número de atividades para a
chefia do DEI.
EI 3. Eventualmente as salas cadastradas no SIGA não estão corretas para algumas
turmas
Em alguns casos, existem turmas cadastradas com a sala errada no SIGA. Este
erro demanda um retrabalho por parte da chefia do DEI, que deve entrar no sistema e
corrigir o erro manualmente.
Erros desse tipo, se não percebidos a tempo, podem gerar confusão por parte
dos alunos.
EI 4. Eventualmente os professores cadastrados no SIGA não estão corretos para
algumas turmas
Análogo ao EI 3, em alguns casos, existem turmas cadastradas com o professor
errado no SIGA. Este erro demanda um retrabalho por parte da chefia do DEI, que deve
entrar no sistema e corrigir o erro manualmente.
Erros desse tipo, se não percebidos a tempo, podem gerar confusão por parte
dos alunos, comprometendo a efetividade do processo.
EI 5. Necessidade constante de reajuste do planejamento de turmas antes de ser
lançado no SIGA
Para o semestre de 2016.1, foram lançadas 5 versões do planejamento de
turmas, sendo cada uma delas fruto de alterações incorporadas ao longo do processo
pelo chefe do DEI. Cabe ressaltar que tais alterações são advindas de solicitações feitas
por professores do departamento, além de coordenadores de cursos para os quais o
DEI oferta disciplinas e outros departamentos e institutos que ofertam disciplinas para o
curso de Engenharia de Produção.
A constante necessidade de reajustes no planejamento de turmas, além de
ocasionar sobrecarga de trabalho para o chefe do DEI, aumenta o tempo de execução
do processo.
EI 6. Em alguns casos, ocorrem sobreposição de turmas de um mesmo período
No planejamento de turmas para o período 2016.2, foi observado que há a
possibilidade de haver sobreposição de turmas de um mesmo período, problema
35
considerado grave. A figura 18 apresenta o planejamento de turmas do segundo período
do curso de Engenharia de Produção para o segundo semestre de 2016. Nele pode ser
observado que existem quatro possíveis turmas de Física Experimental 2, cuja carga
horária é de duas horas semanais. Observa-se que se um aluno do segundo período de
Engenharia de Produção quiser realizar todas as disciplinas listadas nessa grade, ele
só terá uma opção de turma de Física Experimental 2, a lecionada às sextas das 15h
às 17h.
O problema reside no fato de que não há vagas suficientes nas turmas de Física
Experimental para uma turma completa de Engenharia de Produção do segundo
período. Assim, os alunos ou terão que realizar as disciplinas de Cálculo 2 ou Física 2
em outros cursos, liberando o horário de sexta para realizar Física Experimental em uma
turma na sexta de manhã, ou tentar se inscrever na turma de sexta das 15h às 17h,
correndo o risco de ficar sem a vaga.
Nesse caso, esta sobreposição não foi observada a tempo de realizar uma
alteração viável.
Figura 18 – Quadro de horários da Engenharia de Produção (2º período – 2016.2)
Fonte: DEI (2016)
5.3 Identificação das Causas
Para que se possa realizar uma avaliação das principais necessidades de
automação do processo estudado, é preciso encontrar as causas dos problemas (ou
36
efeitos indesejáveis) levantados. Para isso, como já mencionado, foi utilizado a Árvore
da Realidade Atual. Neto e Bornia (2001) sugerem uma abordagem para leitura de uma
Árvore da Realidade Atual, conforme ilustrado na figura 19.
Como pode ser observado, a lógica do diagrama pressupõe que as causas
estejam abaixo dos efeitos.
Figura 19 – Abordagem para leitura da ARA
Fonte: Neto e Bornia (2001)
Goldratt define dez passos para a construção de uma árvore da realidade atual,
conforme explicitado por Dettmer (1997):
1. Identifique a sua área de controle e sua esfera de influência;
2. Crie uma lista de efeitos indesejáveis;
3. Comece a árvore da realidade atual;
4. Conecte os dois primeiros efeitos indesejáveis;
5. Conecte outros efeitos indesejáveis;
6. Construa a cadeia de causa e efeito para baixo;
7. Redefina os efeitos indesejados;
8. Identifique causas raízes e o problema central;
9. Procure pelas ligações em forma de “V” (causa central) ou falta de ligações;
10. Decida quais causas raízes atacar.
Goldratt também define Categorias Legítimas de Reserva que ajudam a
identificar erros comuns ao se construir uma ARA. Os testes sugeridos apresentados
em Dettmer (1997) e aplicados na ARA do presente projeto são:
37
Existência da Entidade – Verifica se os problemas listados são realmente
problemas.
Existência da Causalidade – Verifica se a relação de causa e efeito
realmente existe entre duas entidades.
“Falta de Oxigênio” – Verificar se existem elementos que sabemos que
precisam estar presentes na árvore porém não estão representados.
Insuficiência de Causa – Verificar se não existem mais causas para um
determinado efeito.
Causas Adicionais – Verificar se não existe excesso de causas para um
mesmo efeito.
Reversão entre Causa e Efeito – Verificar se não houve algum engano na
relação entre causa e efeito de duas entidades.
Dessa forma, os testes foram aplicados para garantir confiabilidade à ARA
construída para estudar o processo de planejamento de turmas do DEI.
5.3.1 Árvore da Realidade Atual para o Processo de Planejamento de Turmas
A partir dos efeitos indesejáveis listados na seção 5.2 deste relatório, buscou-se
seguir o método de construção da ARA sugerido por Dettmer (1997). A árvore da
realidade atual construída teve como principal foco o processo de planejamento de
turmas, avaliando problemas que estão na esfera de influência do DEI.
Vale ressaltar que o objetivo da realização desta ARA é encontrar as causas
raízes que geram estes efeitos indesejáveis e impedem que o processo tenha um
desempenho superior. Em seguida, serão identificadas as necessidades de automação
para o processo que ataquem suas principais causas de problemas.
A árvore de realidade atual construída para a análise do processo em questão
pode ser encontrada no apêndice B.
Pode-se verificar como causas raízes dos efeitos indesejáveis listados:
1. Até a data de inscrição em disciplinas, não existe restrição à chegada de
solicitações, isto é, professores e coordenadores podem realizar solicitações de
alteração de horários ou vagas ao longo de todo o processo até a data de inscrição em
disciplinas.
2. A comunicação entre os departamentos acontece de forma insuficiente, isto
é, os outros departamentos que solicitam e oferecem turmas para o DEI, não procuram
entender o planejamento do DEI para tomar suas decisões.
3. Alguns docentes acabam não se preocupando com uma resposta rápida ao
planejamento de turmas.
38
4. O planejamento de turmas se inicia de forma tardia em alguns períodos.
5. As ferramentas utilizadas são limitadas em termos da avaliação das
combinações de turmas e apontamento dos erros.
6. Não se conhece a demanda real por turmas.
7. Os critérios de prioridade nas turmas não são claros para todos os alunos.
8. Alguns alunos não fazem um planejamento das disciplinas que irão puxar até
o fim do curso.
9. Os alunos que voltam de intercâmbio ou que vem de transferência não sabem
se terão dispensa das disciplinas que cursaram fora da UFRJ.
10. Toda a entrada de dados no SIGA é realizada manualmente, turma por
turma.
11. Cada departamento lança suas turmas no SIGA e o DEI não tem controle
sobre isso.
12. O SIGA permite duas ou mais turmas em uma mesma sala (ou com o mesmo
professor) em um mesmo horário.
13. Em algumas disciplinas, existem professores e horários que são preferidos
pelos alunos.
Vale destacar que não é pretensão deste projeto esgotar e solucionar todas
estas causas. A seleção das causas que serão compreendidas na solução de
automação forma listadas e justificadas na seção 6.2 deste relatório.
39
6. DEFINIÇÃO DAS NECESSIDADES DE AUTOMAÇÃO
A modelagem do processo de planejamento de turmas, considerado crítico para
o Departamento de Engenharia Industrial, permitiu tornar explícitas as atividades que
compõem este processo. Dessa maneira, foi possível levantar os efeitos indesejáveis
dos processos, sobretudo os que impactavam diretamente nos respectivos
desempenhos. A partir dos efeitos indesejáveis, chegou-se às causas, com o objetivo
de identificar onde a automação de processos seria melhor aplicada, gerando os
melhores resultados.
Assim, o capítulo 6 teve o objetivo de listar as principais necessidades de
automação no processo estudado, para que fosse possível focar no desdobramento de
uma solução que potencialize o desempenho do processo.
6.1 Atividades Automatizáveis – Processo de Previsão de Turmas
Para cada uma das atividades do processo de planejamento de turmas que são
realizadas pela chefia do DEI, foram avaliados os seguintes aspectos para determinação
da necessidade de automação: se a atividade é automatizável, qual o impacto da
automação desta atividade (quanto maior o impacto, melhor será o desempenho do
processo) e qual a complexidade da automação desta atividade.
Vale destacar que não foram consideradas automatizáveis as atividades que
dependem da disponibilização de informações de outros departamentos, bem como
atividades que dependem de alterações pontuais no SIGA, pois se tratam de atividades
corretivas e difíceis de padronizar.
Destaca-se ainda que as atividades automatizáveis em parte, são as que
dependem de algum tipo de validação não padronizável da chefia para prosseguir.
A tabela 2 apresenta a avaliação realizada para cada atividade realizada pela
chefia do DEI. As atividades foram numeradas para que fosse possível realizar uma
breve explicação da análise realizada para cada atividade.
40
Tabela 2 - Necessidades de Automação
Fonte: Elaboração própria
A atividade “reunir solicitações de professores e coordenadores” (1) pode ser
considerada automatizável uma vez que se trata de uma atividade meramente manual,
sem que haja a necessidade de tomar uma decisão não padronizável. O fato de
existirem três canais de comunicação (oral, via e-mail, via memorando) para a
realização das solicitações de alteração de horário e pedido de turmas, aumenta a
complexidade da automação. Padronizar a chegada destas solicitações pode ser uma
solução para viabilizar a automação.
É Automatizável? Impacto da Automação Complexidade da Automação Causas relacionadas
1Reúne solicitações de
professores e
coordenadores
Sim Alto Média 1, 2, 4
2 Monta quadro de horários Em parte Alto Média 5, 6, 7
3Envia nova proposta de
horários para professor /
coordenador
Sim Baixo Baixa 2
4 Divulga o planejamento Sim Baixo Baixa 3
5 Avalia deliberações Em parte Alto Média 2
6 Divulga resultado final Sim Baixo Baixa -
7Passa planilhas para
funcionáriosSim Baixo Baixa -
8 Lança turmas no SIGA Sim Alto Alta 11, 12
9Verifica se projeto
pedagógico do professor
comporta (o aumento)
Sim Médio Baixa 8, 9, 10, 14
10Verifica disponibilidade de
salasNão Alto - 8, 9, 10, 14
11Verifica se número de
inscritos é superior a nova
capacidade
Não Baixo - 8, 9, 10, 14
12Notifica excedentes e pede
que retirem inscriçãoNão Alto - 8, 9, 10, 14
13Ajusta capacidade da turma
no SIGANão Alto - 8, 9, 10, 14
Atividade
Processo: Planejamento de Turmas
Necessidades de Automação
41
Vale destacar que a chefia pouparia tempo se já recebesse, compilada, todas as
solicitações prévias antes de montar a primeira versão do planejamento. Por isso,
considera-se que o impacto desta automação seja alto.
A atividade “montar quadro de horários” (2), por sua vez, foi considerada
automatizável em partes. Isso porque é importante que o chefe de departamento avalie
aspectos pessoais em relação ao arranjo das turmas. Vale destacar, entretanto que esta
avaliação pode ser incluída na solução por meio de uma validação. O impacto desta
solução pode ser considerado alto uma vez que o chefe de departamento avalia as
possibilidades de alteração manualmente, despendendo um tempo relativamente alto,
justamente pela limitação da ferramenta e do método utilizado.
Vale ressaltar que o não conhecimento da demanda real por vagas dificulta uma
alocação de recursos mais efetiva. Foi preciso pensar em um método, incorporado à
automação para se chegar mais próximo da demanda real por turmas para que o
processo atinja o seu objetivo.
O “envio da nova proposta para docente” (3) pode ser considerado
automatizável. O e-mail, por exemplo, pode ser disparado a partir de um dado evento,
como uma confirmação da chefia. O impacto pode ser considerado baixo pois a chefia
não despende muito tempo realizando esta atividade. A automatização desta atividade,
garante, no entanto, que todos os docentes receberão a proposta de horário em tempo
hábil para avaliar e propor alterações.
A validação tardia de alguns docentes da proposta de horário acaba gerando
uma dificuldade para o processo. Se o docente demora muito para responder, pode
haver um retrabalho, pois o chefe de departamento terá que avaliar o planejamento
novamente.
A “divulgação do planejamento” (4) também foi considerada uma atividade
automatizável. Uma vez finalizada a primeira versão do planejamento, um e-mail pode
ser disparado para os interessados.
A “avaliação das deliberações recebidas de docentes e coordenadores” (5), pode
ser automatizada em partes. É preciso que a chefia realize uma avaliação pessoal dos
motivos pelo qual o docente ou coordenador precisa de um outro dia ou horário. A
automação pode compreender a atividade de avaliar se a solicitação pode ser atendida
em termos de recursos (se existe o horário ou sala solicitada pelo coordenador ou
docente).
Vale ressaltar que é importante, nesse caso, que o chefe de departamento possa
simular possibilidades com facilidade e agilidade. Não seria uma solução de automação,
porém aceleraria a parte da atividade que não pode ser automatizada.
42
A “divulgação do resultado final” (6) também pode ser automatizada seguindo a
mesma lógica das atividades 3 e 4. Assim que o chefe define que o planejamento está
finalizado, um e-mail pode ser disparado para os interessados.
A atividade “passar planilhas para funcionários” (7) também pode ser
automatizável. Inclusive, esta atividade pode ser incorporada à atividade 6. O
funcionário responsável por colocar a planejamento no mural pode receber o
planejamento por e-mail, imprimir e colocar no mural.
Considerou-se que “lançar turmas no SIGA” (8) é uma atividade automatizável,
porém com uma complexidade alta. Isso por que não se conhece a estrutura por trás do
SIGA. Mais uma vez, o objetivo desta automação é reduzir o número de atividades
manuais, evitando erros e colaborando para uma maior agilidade do processo.
A atividade “verificar o projeto pedagógico do professor” (9) pode ser
automatizada desde que haja um banco de dados com o projeto pedagógico de cada
docente. A automatização desta atividade pode reduzir o trabalho da chefia, que, neste
caso, obteria a informação automática dada a necessidade de alteração da capacidade
da turma.
A “verificação da disponibilidade de salas” (10) foi considerada uma atividade
não automatizável uma vez que o DEI utiliza salas fora do departamento. Para
automatizar seria necessário ter a informação das salas disponíveis em cada
departamento. O acesso a esta informação não depende exclusivamente do DEI. Se
houvesse uma base onde se registrasse a ocupação das salas em toda a Escola
Politécnica, esta atividade poderia ser parcialmente automatizada.
A atividade de “verificação do número de inscritos é superior à nova capacidade”
(11) foi considerada como não automatizável, uma vez que depende de acesso pontual
às informações do SIGA.
Foi considerado que a “notificação dos alunos que excedem a capacidade” (12)
não pode ser automatizada. Isso porque a comunicação deve ser feita por telefone. Esta
exigência é feita pois existe a necessidade que os alunos excedentes retirem sua
inscrição o mais rápido possível, caso haja uma mudança de capacidade. Assim, a
automação desta atividade poderia prejudicar a eficácia da atividade.
O “ajuste da capacidade no SIGA” (13) foi considerado como não automatizável,
uma vez que se trata de uma alteração pontual na base de dados do SIGA. Este tipo de
alteração não seria permitido pelo sistema a curto prazo.
43
6.2 Seleção do Foco da Automação
A partir das análises realizadas no capítulo 5 e da avaliação da possibilidade de
automação das atividades realizadas pela chefia do DEI no processo de planejamento
de turmas, já no capítulo 6, verificou-se que a automação do processo por inteiro é
tecnicamente inviável. Após a inserção das turmas no SIGA, não há forma de criar
rotinas padronizadas e automatizadas para gerar os ajustes de capacidade e professor
no SIGA.
Assim, definiu-se que a automação do processo de planejamento de turmas
compreenderá as atividades até a inserção das turmas no SIGA. Todas as alterações
posteriores ao início do período de inscrição terão que ser realizadas manualmente.
Cabe dizer que a automatização da atividade “inserir turmas no SIGA” hoje não
é possibilitada pelo sistema de gestão acadêmica da UFRJ. Entretanto, buscou-se
nesse projeto, oferecer alternativas para que se torne viável esta integração,
minimizando erros de entrada de dados, tais como troca de turmas e professores.
Vale ressaltar que nem todas as causas raízes listadas na seção 5.3.1 serão
solucionadas a partir da automação. As causas 6, 7, 9, 11, 12 e 13 não dependem
apenas de uma solução de automação. Entretanto, as seguintes causas merecem ser
analisadas para se pensar em uma alternativa que torne a solução de automação mais
robusta e eficaz: “não se conhece a demanda real por turmas” e “alguns alunos não
fazem um planejamento das disciplinas que irão puxar até o fim do curso”.
Assim, também será foco da solução final deste projeto, avaliar alternativas que
incluam no sistema automatizado o resultado de uma previsão do número de inscrições
em cada disciplina, baseando-se na necessidade real dos alunos.
44
7. PROJETO DE AUTOMAÇÃO
Este capítulo possui o objetivo de apresentar de forma detalhada a
implementação da metodologia definida na seção 2.3.4 para automação de processos
de negócio utilizando BPMS, aplicada ao processo de planejamento de turmas do DEI,
conforme delineado na seção 6.2.
O capítulo está dividido em sete seções: solução de automação, onde será
melhor explicada qual a solução de automação a ser projetada; modelagem do
processo, onde foi apresentada a remodelagem do processo de planejamento de turmas
com base na solução de automação adotada; modelagem de dados, que consiste no
mapeamento das informações necessárias para o funcionamento do sistema e na
definição dos relacionamentos entre os grupos de informações; criação de formulários,
onde foram sugeridas interfaces para cada atividade; definição das regras de negócio,
que consiste no detalhamento das condições e relações lógicas do fluxo de trabalho.
Além disso, apesar de não se realizar um aprofundamento técnico muito grande, definiu-
se os usuários e definiu-se as necessidades de integração com outros sistemas, para
que, caso haja o interesse da implantação do sistema BPMS para gerir o processo de
planejamento de turmas, se tenha orientações concretas e bem estruturadas de como
prosseguir.
7.1 Solução de Automação
A solução de automação proposta é a criação de um sistema que visa dar
suporte ao processo de planejamento de turmas ao integrar em um mesmo ambiente
os agentes e informações envolvidos no processo, além de automatizar total ou
parcialmente atividades que antes eram exclusivamente manuais, considerando as
limitações destacadas na seção 6.2. Este sistema foi intitulado de Sistema Integrado de
Planejamento de Turmas (SIPT).
Cabe destacar que a solução de automação em desenvolvimento pelo estagiário
do DEI se assemelha com o SIPT nas seguintes características: centralização das
informações e maior controle do processo pelo chefe de departamento.
Destaca-se ainda que a solução também passa pela especificação de um
software, externo ao sistema, que irá, por meio de um algoritmo de otimização, realizar
a melhor alocação de recurso de forma automática dado as restrições pré-
estabelecidas. Dessa forma a geração da primeira versão do planejamento de turmas
será automatizada e otimizada.
45
Vale destacar que a ideia é que alunos, docentes, coordenadores e funcionários
do DEI tenham acesso ao sistema, com um perfil que lhes permita executar as
atividades relacionadas ao processo de planejamento de turmas. A forma de acesso ao
sistema não será especificada neste trabalho, uma vez que demanda um conhecimento
de TI que extrapola o especificado para elaboração deste trabalho. Entretanto, é
sugerido que se busque uma integração com o website do departamento para que seja
possível centralizar ainda mais o acesso às informações no departamento.
A solução foi determinada baseada nas causas raízes especificadas também na
seção 6.2. De uma forma geral, buscou-se a conciliação dos interesses dos principais
stakeholders do processo – alunos, professores, coordenadores e chefe do DEI; o
aprimoramento do antigo fluxo de informações, centralizando-o em um mesmo
ambiente; a padronização das atividades e o estabelecimento de prazos para algumas
delas; a criação de uma funcionalidade que permite ao aluno realizar o seu
planejamento de turmas ao longo dos períodos que compõem o curso, ajudando-o a se
organizar para o tempo presente e futuro; entre outras.
Espera-se que a implantação do sistema traga diversos benefícios para o DEI,
dentre eles: o compartilhamento mais rápido de informações, maior controle do
processo por parte do chefe do DEI e menor margem de erro na previsão de demanda
por disciplinas.
Para a construção da solução, foi utilizado o software Bizagi Studio, conforme
descrito na seção 1.4. A metodologia adotada foi descrita na seção 2.3.4, considerando
as devidas adaptações necessárias.
7.2 Modelagem do processo
O processo de planejamento de turmas foi modelado em sua forma atual
conforme ilustrado no apêndice A e apresentado no capítulo quatro. Nesta seção, o
processo foi remodelado levando em consideração a inclusão da solução de automação
e outras soluções consideradas para atuar em algumas causas levantadas no capítulo
cinco. Vale destacar que o processo remodelado não compreende o processo por
inteiro. Como a automação da entrada das turmas no SIGA é inviável, bem como as
alterações posteriores no sistema, foi realizado um recorte para o processo remodelado
uma vez que após o recebimento da planilha final pelos funcionários do DEI, tudo
permanece o mesmo.
No apêndice C, pode ser encontrado o processo remodelado. A tabela 3, por sua
vez, apresenta as melhorias incorporadas ao novo modelo.
46
No processo remodelado, o aluno poderá atualizar seu planejamento de curso e
os professores e coordenadores suas solicitações por meio de uma interface, vinculada
preferencialmente ao website do DEI. Duas semanas antes da data estabelecida para
o início do processo de planejamento de turmas (por exemplo um mês após o período
de inscrição de turmas), os alunos, professores e coordenadores receberão um e-mail
recomendando que realizem a atualização do planejamento de turmas e as solicitações
no sistema. Chegada a data, o software externo vai coletar as informações contidas no
banco de dados do SIPT e gerar uma grade de turmas com base em algoritmos de
otimização. Uma lista de solicitações não atendidas tanto de docentes quanto de
coordenadores é enviada para o chefe de departamento que realizará uma avaliação
dessas solicitações (apoiado por uma interface com o sistema), negociará com cada
solicitante não atendido e fará as alterações necessárias manualmente pelo SIPT.
Finalizada a alteração no planejamento de turmas, a grade é divulgada para os
docentes e coordenadores a fim de que estes respondam se o planejamento os atendem
ou não. Serão cinco dias úteis (valor arbitrado) abertos a resposta. No terceiro dia, para
os professores e coordenadores receberão uma notificação os lembrando de dar alguma
resposta à chefia. O chefe de departamento avaliará as respostas e negociará com os
envolvidos nas alterações. A versão final (antes do período de inscrição) é, então,
enviada para todos os stakeholders do processo.
Destaca-se ainda que a versão final do planejamento de turmas deve poder ser
exportada em dois formatos. O primeiro em forma de grade horária para os cursos do
DEI, separadas por período, dia da semana e horário, incluindo disciplinas optativas das
ênfases do curso de Engenharia de Produção e disciplinas condicionadas. O segundo
no formato padrão para o processo de pedido de professores substitutos.
47
Tabela 3 - Melhorias incorporadas ao processo de planejamento de turmas
Fonte: Elaboração própria
Vale destacar que a ideia central por trás da solução de automação sugerida é
ter uma ferramenta que auxilie a gestão do processo no sentido de centralizar as
informações, controlar as regras de negócio e aproximar os envolvidos com o
departamento pata dar mais agilidade ao processo.
7.3 Modelagem de dados
Ao longo do processo, uma grande quantidade de informações é transmitida
entre os agentes. Nesta etapa, todas as informações requeridas pelo processo são
definidas e inter-relacionadas, de modo a criar um repositório de dados no Bizagi Studio.
Este repositório possibilita uma melhor gestão dos dados, evitando transferência
desnecessária de informação.
Para definição das entidades e dos respectivos atributos a serem relacionados
na modelagem de dados, levantou-se, para cada atividade do processo remodelado, as
informações envolvidas durante a sua realização, sem as quais o processo não atinge
seu objetivo.
A lista de informações necessárias para a execução de cada atividade pode ser
encontrada na tabela 4.
Processo no Estado Atual Processo Remodelado
As solicitações de professores e coordenadores são recebidas ao
longo de todo o processo, por meio de diferentes canais
Os professores e coordenadores realizarão as solicitações por meio
de um único canal (o SIPT), com uma interface apropriada
A primeira versão da grade de turmas será gerada por meio de um
software externo ao SIPT que levará em consideração os dias e
horários das turmas demandas (histórico), solicitações de
professores e coordenadores, restrições de horários de professores,
demanda por disciplinas por semestre, entre outras informações.
Os alunos poderão registrar seu planejamento de curso no SIPT,
centralizando as informações
As versões do planejamento são enviadas por e-mail pelo chefe de
departamentoO sistema realizará todos os envios de e-mail para os envolvidos
Não existe um prazo padronizado e preestabelecido para a
resposta dos professores e coordenadores ao planejamento
enviado após a negociação com os professores que não tiveram
solicitações atendidas
Após o recebimento da grade de turmas, os professores e
coordenadores terão 5 dias úteis para dar alguma resposta ao
departamento.
A primeira versão da grade de turmas é baseada apenas no
histórico e em solicitações anteriores
48
Tabela 4 - Conjunto de informações necessárias para a execução do processo
Fonte: Elaboração própria
Atividade Responsável Informações
Registro do Solicitante
Nome do solicitante
Cargo do solicitante
Departamento do solicitante
Curso da disciplina
Disciplina solicitada
Justificativa
Vagas solicitadas (se coordenador)
Dias da semana propostos
Horários propostos
Disciplinas a serem cursadas
Semestre
Demanda por disciplinas
Discplinas oferecidas
Dsiciplinas demandadas
Tipo da disciplina
Período da disciplina
Turno do período
Periodicidade da disciplina
Carga horária das disciplinas
Dias da disciplina demandada
Horários das diciplinas demandadas
Professores do DEI
Restrições de horário do professor
Solicitações de professores e coordenadores
Salas disponíveis
Situação da sala
Capacidade das salas
Horário disponível das salas
Nome do Docente / Coordenador solicitante
Situação dasolicitação (aprovada ou não)
Email do docente
Nome do Docente / Coordenador solicitante
Situação dasolicitação (aprovada ou não)
Grade de horários montada
Email do docente / coordenador
Nome do docente / coordenador
Alternativas de horário
Grade de horários montada
Turmas a serem alteradas
Novos horários
Grade de horário montada
Email do grupo de professores do DEI
Email dos coordenadores
Verifica se o planejamento atende suas necessidades Professor / Coordenador Grade de horário montada
Email da chefia do DEI
Departamento
Curso da disciplina
Disciplina solicitada
Vagas solicitadas (se coordenador)
Dias da semana propostos
Horários propostos
Avalia respostas Chefia do DEI Idem atividade 5
Negocia alternativas com docente / coordenador Chefia do DEI Idem atividade 6
Atualiza grade de horários no SIPT Chefia do DEI Idem atividade 7
Grade de horário final
Email dos professores
Email dos coordenadores
Email dos Alunos
Grade de horários montada
Acesso ao SIGA
Chefia do DEIDivulga resultado final
Lança turmas no SIGA
Professor / CoordenadorRegistra solicitação no SIPT
Chefia do DEIMonta quadro de horários
Atualiza planejamento do curso no SIPT Aluno
Encaminha lista de solicitações pendentes para chefia do DEI SIPT
Avalia solicitações pendentes Chefia do DEI
SIPT
Chefia do DEINegocia com docente / coordenador
Atualiza grade de horários no SIPT Chefia do DEI
Divulga o planejamento Chefia do DEI
Professor / CoordenadorEncaminha resposta para o chefe do DEI
49
Após o levantamento das informações necessárias para a execução de cada
atividade do processo, foi possível elaborar um modelo de dados relacional,
representado graficamente pelas entidades, atributos e relacionamentos. O
relacionamento entre as entidades do processo dá origem a um banco de dados interno
ao Bizagi Studio. Os dados foram conectados por meio de vínculos entre tabelas,
tornando viável a elaboração de formulários e especificação das regras de negócio no
próprio software.
A figura 20 apresenta a modelagem dos dados construída para o processo de
planejamento de turmas do DEI. Nela, cada caixa representa uma entidade, isto é, uma
tabela no banco de dados. No modelo representado abaixo, pode ser observado que
existem entidades ilustradas com diferentes cores, no caso, verde, azul e cinza. Esta
distinção é realizada pelo Bizagi, que reconhece quatro tipos diferentes tipos de
entidades, de acordo com o website Bizagi (2016):
Master (azul) – Nesse tipo de entidade o Bizagi armazena informações
diretamente ligadas ao processo.
Parâmetro (verde) – É a entidade que vai armazenar uma lista de valores pré-
definidos, que formarão as opções de valores para um determinado parâmetro
de outra entidade.
Stakeholder (roxo) – É a entidade que incorpora as classificações para o usuário
final do sistema. Vale destacar que na modelagem do presente projeto não foi
necessária a utilização desta entidade.
Entidades de Sistema (cinza) – É uma entidade interna ao Bizagi, não editável,
que pode se relacionar com uma entidade master definida por quem está
realizando a modelagem de dados.
A modelagem estabelecida para o processo de planejamento de turmas foi
melhor destrinchada na tabela 5, onde destacou-se as entidades, seu respectivo tipo e
uma breve descrição.
50
Figura 20 – Modelo de dados
Fonte: Elaboração própria
Destaca-se que mesmo se o departamento optar por não implantar o sistema de
workflow sugerido, a modelagem de dados fica como uma possível referência para a
criação de um sistema de apoio ao processo de planejamento de turmas.
51
Tabela 5 - Descrição das entidades
Fonte: Elaboração própria
Tipo Entidade Descrição
Semestre Armazena o nome dos semestres (Ex. 2017.1, 2017.2, 2018.1).
CondiçãoArmazena a condição da turma, isto é, se ela é uma disciplina oferecida ou
demandada pelo DEI.
Grupo de DisciplinasArmazena os valores possíveis para o grupo que a disicplina pertence
(obrigatória, optativa de escolha restrita etc).
DisciplinaArmazena os nomes das disciplinas e outras informações tais como carga
horária e número da discipliana.
Curso Armazena o nome do curso, sigla, coordenador e número do curso.
DepartamentoArmazena as informações dos departamentos, tais como nome, código e
chefe.
Sala Armazena as informações das salas.
UnidadeArmazena os nomes das unidades: Escola Politécnica, Instituto de
Matemática etc.
Bloco Armazena os nomes dos blocos.
VínculoArmazena os nomes dos vínculos de um professor com o seu departamento
(permanente, substituto, convidado etc).
Lotação InternaArmazena a área do professor dentro do departamento: Métodos
Quantitativos, Gerência da Produção etc.
Curso_DisciplinaArmazena as informações das disciplinas referentes a um determinado
curso.
Turmas Armazena todas as informações de uma turma.
Professor Armazena as informações do professor.
Aluno_PlanArmazena as informações do planejamento de turmas de disciplinas por
semestre do aluno.
Prof_Solic Armazena as informações das solicitações de professores e coordenadores.
Sistema WFUSER Armazena as informações do usuário do sistema.
Parâmetro
Master
52
7.4 Criação de formulários
Após a modelagem de dados, a próxima etapa sugerida pela metodologia
adotada para a automação neste projeto é a criação de formulários para as atividades
que demandam interações com o sistema. Estas interações podem ser de consulta,
entrada de dados e alteração.
As atividades do processo que receberam um formulário foram:
Registra solicitações no Sistema Integrado de Planejamento de Turmas (SIPT)
– Docente / Coordenador.
Atualiza planejamento do curso no SIPT – Aluno.
Avalia solicitações pendentes – Chefia do DEI.
Atualiza grade de horários no SIPT – Chefia do DEI.
Verifica se o planejamento atende suas necessidades – Docente / Coordenador.
Para cada uma destas atividades foram apresentados os formulários e seus
objetivos.
7.4.1 Registra solicitações no SIPT
Para o registro das solicitações de professores e coordenadores foi montado o
formulário da figura 21. Nele, o usuário, que será identificado como professor pelo
sistema, escolhe a disciplina, o dia sugerido, o horário sugerido, a justificativa da
solicitação e o número de vagas, somente no caso de uma solicitação de turma por um
coordenador de curso externo ao DEI.
O acesso a este formulário fica aberto durante todo o tempo, exceto no período
após o envio da primeira versão do planejamento e o término do período de alteração
de turmas.
53
Figura 21 – Formulário para registro das solicitações
Fonte: Elaboração própria
Vale destacar que o processo não engloba pedido de afastamento. Caso isto
ocorra, o chefe de departamento deve alterar o a condição do professor que irá se
ausentar na tabela de professores. O algoritmo que gerará a grade de horários,
externamente ao Sistema Integrado de Planejamento de Turmas considerará a
condição dos professores para definir as turmas.
7.4.2 Atualiza planejamento do curso no SIPT
Esta atividade acontece para que o DEI tenha uma estimativa da demanda por
disciplinas em cada período. O ideal é que todos os alunos preencham o planejamento
do próximo período antes da criação da primeira grade de horários. De acordo com o
fluxograma de processos remodelado o aluno teria acesso irrestrito a esta página. Cerca
de duas semanas antes do início da previsão de turmas, o sistema deve disparar um
aviso para os alunos atualizarem o planejamento.
É importante que os alunos possam planejar semestres posteriores ao próximo,
isto é, se estamos em 2016.2, o aluno poderá se planejar para 2017.1, 2017.2, 2018.1.
Dessa forma, mesmo que o aluno não atualize o planejamento em um determinado
período, o DEI terá uma previsão das disciplinas que ele irá se inscrever.
A figura 22 apresenta o formulário sugerido para atividade. Vale ressaltar que o
Bizagi Studio é limitado em termos da criação de interfaces. O ideal é que a interface
seja a mais interativa e visual possível, por exemplo com o auxílio do fluxograma do
curso.
54
Figura 22 – Formulário para planejamento do curso pelo aluno
Fonte: Elaboração própria
No formulário da figura 22, no campo “Disciplina”, o aluno pode pesquisar uma
disciplina para saber de qual período ela é em seu curso, a qual grupo de disciplinas ela
pertence, quantos créditos ela tem, quais são seus pré-requisitos, entre outras
informações conforme formulário da figura 23 que aparece ao se pesquisar uma
disciplina.
Figura 23 – Formulário para consulta de disciplina
Fonte: Elaboração própria
55
7.4.3 Avalia solicitações pendentes
A atividade de avaliação das solicitações pendentes deve ser realizada pelo
chefe de departamento. O algoritmo que irá criar a primeira versão da grade de horários
deverá dizer quais solicitações não foram atendidas. O chefe de departamento receberá
por e-mail esta lista e avaliará as solicitações.
O formulário desenvolvido para esta atividade foi elaborado para que o chefe de
departamento possa consultar os dados da solicitação do professor com o status de
solicitação não aceita. No formulário da figura 24, realiza-se a consulta por meio do
código SIAPE do docente. Na figura 25, por sua vez, verifica-se as informações da
solicitação buscada.
Figura 24 – Formulário para consultar docente
Fonte: Elaboração própria
56
Figura 25 – Formulário com a solicitação do docente consultado
Fonte: Elaboração própria
Vale destacar que o DEI está desenvolvendo uma ferramenta de apoio a tomada
de decisão, onde, visualmente, o chefe de departamento pode avaliar onde existe folga
de capacidade para alocar turmas. Esta ferramenta pode ser incorporada nesta
atividade. Como ainda está em fase de construção, não é possível dar mais detalhes
sobre o funcionamento desta ferramenta.
7.4.4 Atualiza grade de horários no SIPT
A atualização da grade se faz por meio do formulário da figura 26. Nele, o chefe
busca o curso da disciplina (se for uma disciplina oferecida para o curso de Engenharia
Mecânica, busca-se, Engenharia Mecânica) e é direcionado para o formulário da figura
27, onde altera manualmente na tabela na parte inferior da tela o horário ou dia da turma.
57
Figura 26 – Formulário busca do curso
Fonte: Elaboração própria
Figura 27 – Formulário para visualização e edição da grade do curso
Fonte: Elaboração própria
É importante ressaltar que o sistema deve ser capaz de informar se houver uma
colisão de turmas em um mesmo dia, horário e sala. A programação desta rotina não é
um dos objetivos do projeto uma vez que envolve um conhecimento mais aprofundado
da Structured Query Language (SQL).
58
7.4.5 Verifica se o planejamento atende suas necessidades
A atividade de verificação do planejamento é meramente consultiva. O docente
ou coordenador realiza o login no sistema e pesquisa o seu nome (que será preenchido
automaticamente pelo sistema). A figura 28 apresenta o formulário de pesquisa. A figura
29, por sua vez, apresenta o formulário com o resultado da pesquisa. Este formulário
mostra as turmas de cada docente, com informação de dia, horário e sala.
Figura 28 – Formulário para busca da grade do docente
Fonte: Elaboração própria
Figura 29 – Formulário para visualização das turmas do docente
Fonte: Elaboração própria
59
7.5 Definição das regras de negócio
Nesta seção foram definidas com mais clareza e detalhe as confirmações e
restrições que controlam e influenciam o comportamento do processo de planejamento
de turmas, bem como as condições e validações necessárias para a execução dos
processos.
As regras de negócio para o processo remodelado são:
1. O processo é iniciado 9 semanas antes do período de inscrição.
2. Após a comunicação do aviso do início do processo pelo sistema, os alunos,
coordenadores e professores terão duas semanas para atualizar o planejamento do
curso e realizar solicitações.
3. O sistema encaminha para o chefe a lista de solicitações pendentes se nem
todas as solicitações de professores e coordenadores forem atendidas e divulga o
planejamento caso contrário.
4. Se o chefe de departamento avaliar que é necessário realizar algum ajuste na
grade ele negocia alternativas com o docente / coordenador, caso contrário, divulga o
planejamento.
5. Coordenadores e docentes terão 5 dias úteis para responder se o
planejamento atende suas necessidades. No terceiro dia serão lembrados que precisam
responder.
6. Se o chefe de departamento avaliar que é necessário realizar algum ajuste na
grade ele negocia alternativas com o docente / coordenador, caso contrário, divulga o
planejamento.
Para facilitar a explicação, dividiu-se o processo. Na figura 30, pode ser
visualizado o primeiro conjunto de regras. Os alunos poderão realizar a atualização de
seus respectivos planejamentos de curso ao longo de todo o período, bem como os
professores também poderão realizar solicitações a qualquer momento antes da
geração da primeira grade de horários das turmas. Um e-mail é disparado para todos
os alunos, professores do DEI e coordenadores solicitando que realizem estas
atividades em até duas semanas. Se um professor não fizer nenhuma solicitação de dia
e horário por disciplina, na geração da primeira versão do planejamento, só serão
consideradas suas restrições de horários. Se um coordenador não fizer nenhuma
solicitação de turma para o DEI, será considerado, na primeira versão do planejamento,
o histórico de dias, horários e vagas para a disciplina que normalmente é oferecida para
este curso.
60
Figura 30 – Regras de negócio 1 e 2
Fonte: Elaboração própria
A figura 31 ilustra a parte do processo que é realizada após o prazo de duas
semanas depois do e-mail enviado pelo SIPT. O software externo ao sistema gera a
primeira versão da grade de horários e retorna as solicitações que não foram atendidas.
Se o software encontrar uma solução onde todas as solicitações forem atendidas, assim
como todas as restrições, o Sistema Integrado de Planejamento de Turmas enviará esta
versão para os docentes e coordenadores validarem. Caso contrário, um e-mail será
enviado para o chefe de departamento com as solicitações não atendidas.
61
Figura 31 – Regra de negócio 3
Fonte: Elaboração própria
A figura 32, por sua vez, representa a regra de negócio que decorre da lista de
solicitações não atendidas no primeiro planejamento. O chefe de departamento realizará
uma avaliação pessoal onde avaliará as justificativas das solicitações de professores e
coordenadores, bem como as possibilidades de alteração para chegar à conclusão da
necessidade de alteração da primeira versão do planejamento. Se não for necessário
alterar, o chefe indica para o sistema que a primeira versão do planejamento está
fechada. Se for necessário alterar, o chefe faz a alteração manualmente no
planejamento de turmas e indica para o sistema o fechamento da primeira versão do
planejamento de turmas. Se houver alguma colisão de turmas ao se alterar o
planejamento, o sistema deve avisar.
62
Figura 32 – Regra de negócio 4
Fonte: Elaboração própria
A figura 33 apresenta a parte do processo que explicita a sequência de
atividades após a divulgação da primeira versão do planejamento de turmas. Os
professores e coordenadores tem cinco dias úteis para responder a primeira versão do
planejamento. Após dois dias úteis, todos os professores receberão uma notificação por
e-mail, onde serão lembrados de responder o planejamento.
63
Figura 33 – Regra de negócio 5
Fonte: Elaboração própria
Por fim, a figura 34 ilustra a última regra de negócio aplicada ao processo. O
chefe de departamento avaliará as respostas e julgará se é necessário ou não realizar
alterações. As solicitações de alteração nessa fase surgirão, em sua maioria, de
professores que não cadastraram solicitações no início do processo ou não mantiveram
atualizadas suas restrições de horário no perfil do professor no sistema. Se o chefe
achar que a solicitação é necessária, ele poderá atualizar a grade de horários
manualmente e fechar o planejamento de turmas. Ressalta-se que o sistema deve
avisar o chefe caso haja alguma colisão de horários ou salas. Se o chefe achar que não
é necessário atualizar o planejamento, ele deve indicar para o sistema que o
planejamento está fechado.
Figura 34 – Regra de negócio 6
Fonte: Elaboração própria
64
Assim, caberá ao programador do sistema incorporar estes prazos, condições,
e validações ao sistema para que este possa rodar de acordo com as necessidades do
processo de planejamento de turmas.
7.6 Definição dos perfis de usuários
Nesta etapa do ciclo de automação utilizando BPMS, não será realizado um
aprofundamento sobre os níveis de acesso ao sistema. Apesar disso, sabe-se que esta
é uma etapa bastante importante da modelagem de um sistema.
De maneira geral é possível dizer que existem alguns participantes chave no
processo e que merecem um destaque nessa fase. A tabela 6 atribui a cada tipo de
participante o conjunto de tarefas que este deve poder executar em seu perfil no
sistema.
Tabela 6 - Atividades possibilitadas pelo SIPT por usuário
Fonte: Elaboração própria
Assim, pode-se implantar diferentes níveis de acesso para os diferentes tipos de
usuários do sistema. É importante que cada participante consiga executar as tarefas do
processo de planejamento de turmas para que o sistema consiga exercer sua principal
função.
Usuário Tarefas
Chefe do DEI
1. Consultar solicitações de coordenadores e docentes / 2. Editar a
grade de turmas / 3. Definir data limite para início do planejamento /
4. Indicar para o sistema o status do planejamento
Coordenadores1. Consultar a grade atual das turmas oferecidas pelo DEI a seu
curso / 2. Realizar solicitações de turmas e vagas
Docentes do DEI
1. Consultar a grade atual das turmas que leciona e a grade do curso
/ 2. Realizar solicitações de dias e horários para disciplina que
leciona
Alunos do DEI 1. Consultar grade do curso de Engenharia de Produção
Funcionários Administrativos1. Realizar consultas /2. Imprimir a grade de turmas dos cursos do
DEI
Responsável de TIAcesso irrestrito a todos os formulários e base de dados do sistema,
bem como suas integrações
65
7.7 Definição das integrações
De acordo com Bizagi (2016), o Bizagi Studio possui uma “poderosa camada de
integração que suporta as diferentes possibilidades de integração”, conforme ilustra a
figura 35.
Figura 35 – Camadas de integração do Bizagi Studio
Fonte: http://help.bizagi.com/bpmsuite/en/index.html?integrating.htm. Acesso em: set.2016
Existem duas integrações que são chaves e que merecem bastante atenção pela
pessoa da área de TI que for implantar o BPMS por completo ao processo de
planejamento de turmas. A primeira integração é com o website do DEI, que, apesar de
não ser obrigatória, é importante para que os envolvidos tenham uma opção única para
acessar diferentes informações relacionadas ao DEI, inclusive acessar o SIPT. A
segunda integração é com o software que irá gerar a primeira versão do planejamento
de turmas.
Vale destacar que nesta seção, também não foi realizado um aprofundamento
muito técnico com relação às integrações necessárias para a implantação do sistema.
66
Isso por que estudar linguagens de integração de sistemas, bem como os tipos de
sistemas destacados na figura 35 não é o foco do projeto.
No entanto, foi realizada especificação das informações necessárias para que o
algoritmo do software externo ao SIPT consiga gerar a grade de turmas. O diagrama da
figura 36 apresenta as informações necessárias para a geração da grade de turmas.
Figura 36 – Informações necessárias para geração da grade de turmas
Fonte: Elaboração própria
Dessa forma, o software de geração das turmas deve importar da base de dados
do sistema todas as informações listadas na figura 36 e devolver as turmas formadas,
com seus respectivos horários, dias da semana, professor, sala e capacidade.
67
8. ANÁLISE DOS RESULTADOS
O capítulo sete se ateve a descrição da solução de automação elaborada para
o processo de planejamento de turmas do Departamento de Engenharia Industrial da
UFRJ. Este projeto não contemplou a implantação do sistema BPMS sugerido uma vez
que demanda recursos e conhecimentos que extrapolam o escopo definido
previamente. Assim o foco foi dado a construção de um novo processo, sustentado por
um sistema integrado. Detalhou-se o funcionamento do novo processo e do sistema.
Utilizou-se o Bizagi Studio para definir todos os seus requisitos de funcionamento,
começando pela modelagem de dados, passando pelas interfaces com o usuário e
regras de negócio de uma maneira mais aprofundada. Definiu-se as atividades
essenciais para cada usuário e as integrações necessárias.
Ressalta-se que a automação do processo de planejamento de turmas se dá
pelo gerenciamento automático das regras de negócio, por meio das notificações, da
centralização das informações e da geração automática da primeira versão do
planejamento de turmas através de um software externo ao sistema, também
especificado neste projeto. É importante dizer que este processo não pode ser
automatizado totalmente uma vez que o chefe deve fazer uma avaliação prévia do
planejamento e ponderar certas solicitações.
A partir da implantação do processo sugerido, apoiado pelo sistema
caracterizado neste projeto, espera-se que alguns dos efeitos indesejados listados na
Árvore da Realidade Atual sejam extintos a partir da eliminação de algumas causas. A
tabela 7 relaciona algumas das causas destacadas na ARA com seu respectivo efeito
desdobrado, diretamente ou indiretamente, e com a solução dada neste trabalho.
Vale destacar, por fim, que a implantação do sistema gerará benefícios para os
diferentes participantes do processo. Espera-se que o chefe de departamento fique
menos sobrecarregado e que consiga ter acesso às informações do processo com maior
facilidade, agilidade e confiabilidade. Além disso, o sistema irá realizar as cobranças
relacionadas aos prazos. Os coordenadores poderão se comunicar com o DEI de uma
forma mais rápida, além de ter certeza de que suas demandas serão avaliadas. Os
docentes poderão estabelecer suas restrições de horário, bem como realizar
solicitações por meio de uma única interface. Por fim, os alunos poderão realizar seu
planejamento de turmas pela interface do sistema e poderão contar com um
planejamento que leve em consideração sua real demanda.
68
Tabela 7 - Relação entre as soluções, causas raízes e efeitos indesejáveis
Fonte: Elaboração própria
Assim, apesar de não podermos quantificar os resultados, uma vez que não foi
implantada a solução, qualitativamente falando, espera-se que o departamento dê um
salto em relação aso critérios de desempenho definidos. Espera-se que haja, no longo
prazo, uma menor retenção de alunos, já que haverá um planejamento mais otimizado,
um menor número de alunos sem vaga, pelo fato de estar levando em consideração a
demanda real de vagas por disciplina e uma maior satisfação dos professores do DEI.
Efeito indesejado Causa relacionada (diretamente ou indiretamente) Solução
Alguns docentes acabam não se preocupando com uma
resposta rápida
O sistema irá gerenciar os prazos e disparar
notificações por e-mail para que os docentes se
atentem aos prazos
O planejamento de turmas se inicia de forma tardia em
alguns períodos
O chefe definirá a data mais propícia para o
sistema iniciar o processo, que comunicará todos
os participantes
A comunicação entre os departamentos acontece de
forma insuficiente
Toda a comunicação necessária entre os
coordenadores dos cursos com o DEI deverá ser
realizada pelo SIPT e seus formulários
Até a data de inscrição em disciplinas, não existe restrição
à chegada de solicitações
Criação de uma janela temporal para realização
das solicitações, gerenciada pelo próprio SIPT
Não se conhece a demanda real por turmas
Alguns alunos não fazem um planejamento das disciplinas
que irão puxar até o fim do curso
O sistema apontará quando o chefe realizar uma
alteração que gere algum tipo de sobreposição
Necessidade constante de
reajuste do planejamento
de turmas antes de ser
lançado no SIGA
Necessidade de ajustes na
alocação de recursos
durante o período de
inscrição e de alteração
Espaço no SIPT para que os alunos possam
realizar o planejamento do curso, contribuindo
para que o DEI consiga mensurar a demanda real
por disciplina
Foi prescrita a utilização de um software para
gerar a primeira versão do planejamento de
turmas, levando em consideração todas as
informações necessárias
Em alguns casos, ocorrem
sobreposição de turmas de
um mesmo período
As ferramentas utilizadas são limitadas em termos de
avaliação das combinações de turmas e apontamento dos
erros
69
9. CONCLUSÃO
O processo de planejamento de turmas ofertadas pelo DEI vem sendo realizado
baseado em um padrão que, apesar de atender às necessidades do departamento,
ocasiona a constante necessidade de reajustes antes do lançamento de turmas no SIGA
e durante o período de inscrição em disciplinas, além de resultar, em alguns casos, na
sobreposição de turmas de um mesmo período. Isso causa, dentre outros efeitos,
atrasos na execução de atividades, sobrecarga ao chefe de departamento devido a
retrabalho e redução da efetividade no planejamento de turmas. Percebe-se, portanto,
que apesar de atender às necessidades do departamento, o processo de planejamento
de turmas possui espaços para melhorias e necessita ser revisto.
Por meio da ferramenta Árvore de Realidade Atual (ARA), buscou-se identificar
e entender as causas raízes que originavam os problemas relatados. Notou-se que os
efeitos indesejados observados eram, em grande parte, ocasionados devido à forma
como o processo era conduzido, desconsiderando fatores importantes como prazos,
comunicação efetiva entre departamentos e demanda real por disciplinas. Por meio da
análise das causas raízes identificadas, pôde-se realizar um estudo de viabilidade de
automação relacionado a cada atividade executada no processo.
Assim, o presente projeto teve a intenção de criar, com o auxílio de ferramenta
BPMS, um sistema que unificasse em um mesmo ambiente todos os agentes e
informações envolvidos, além de proporcionar um espaço onde o aluno pudesse realizar
o seu planejamento individual dos períodos atual e subsequentes.
Espera-se que, com a implementação do sistema no departamento, a gestão do
processo de planejamento de turmas seja aperfeiçoada, trazendo inúmeros benefícios.
Dentre eles, pode-se citar: melhor controle do processo por parte do chefe de
departamento, maior centralização das informações e conciliação de interesses dos
agentes envolvidos.
De modo a tornar a solução de automação viável, cabe ao DEI investir no
desenvolvimento do software de geração automática de grade horária especificado no
capítulo 7, configurar as regras de negócio estabelecidas na modelagem e níveis de
acesso de usuários no sistema sugerido, realizar as integrações necessárias com o
software supracitado e o website do departamento.
Além disso, como o DEI possui o interesse em automatizar o processo de
planejamento de turmas, as informações discutidas neste projeto podem servir de
insumo básico para a elaboração de outros projetos relacionados ao assunto, além de
possibilitar a continuidade da solução proposta ao executar o sistema aqui discutido.
70
Espera-se, também, que o presente projeto estimule trabalhos futuros no que tange ao
estudo da natureza e previsão da demanda real por disciplinas do departamento, visto
atualmente como um dos maiores desafios para a elaboração de um planejamento de
turmas assertivo.
71
10. REFERÊNCIAS BIBLIOGRÁFICAS
BALDAM, R. et al. Gerenciamento de processos de negócios: BPM – Business
Process Management. 2 ed. São Paulo: Editora Érica, 2007. 240 p.
BIZAGI, disponível em:
<http://help.bizagi.com/bpmsuite/en/index.html?modeling_data.htm>. Acesso em: 22
ago. 2016.
BPM CBOK. Guia para o gerenciamento de processos de negócio corpo comum de
conhecimento ABPMP BPM CBOK V3.0. São Paulo: ABPMP Brasil, 2013. 453 p.
BPM Para Todos - Uma Visão Geral Abrangente, Objetiva e Esclarecedora sobre
Gerenciamento de Processos de Negócio / Gart Capote de Britto. 1. ed. Rio de
Janeiro: Gart Capote, 2012.
CAPIOTTI, P. Benefícios da automação de processos. iProcess Soluções em
Tecnologia, 25 jun. 2012. Disponível em <blog.iprocess.com.br/2012/06/benefícios-da-
automacao-de-processos>. Acesso em: 18 jun. 2016.
CARRARA, A. R. Implantação de sistema BPMS para a gestão por processos: uma
análise crítica. 2011. 183 p. Dissertação (Mestrado em Engenharia de Produção) –
Escola Politécnica - USP, São Paulo, 2011.
CHANG, J. F. Business Process Management Systems: Strategy and Implementation.
Boca Raton: Auerbach Publications, 2006 apud CARRARA, A. R. Implantação de
sistema BPMS para a gestão por processos: uma análise crítica. 2011. 183 p.
Dissertação (Mestrado em Engenharia de Produção) – Escola Politécnica - USP, São
Paulo, 2011.
COSENZA, C. A. N. História do departamento, por Carlos Alberto Nunes Cosenza. 29
jul. 2016. Disponível em <http://www.ind.ufrj.br/site/hist%C3%B3ria-do-departamento,-
por-carlos-alberto-nunes-cosenza.html>. Acesso em: 18 jun. 2016.
CRUZ, T. BPM & BPMS: Business Process Manegement & Business Process
Manegement Systems. 2ª. ed. Rio de Janeiro: Brasport, 2010 apud SANTOS, D. S.
72
Automatização de processos de negócios utilizando BPM/BPMS. 2013. 114 p.
Monografia (Graduação em Ciência da Computação) – Universidade Estadual do
Sudoeste da Bahia, Bahia, 2013.
DAVENPORT, T. Natureza da reengenharia de processos. In:____. Reengenharia de
processos. Boston: Harvard Business School Press, 1993 apud PAIM, R. et al. Gestão
de processos: pensar, agir e aprender. 1 ed. Porto Alegre:
Bookman, 2009. 328 p.
DEI, 2016. Disponível em <www.ind.ufrj.br>. Acesso em: 10 jun. 2016.
DETTMER, H. W. Goldratt's Theory of Constraints: A Systems Approach to Continuous
Improvement. 1 ed. ASQ Quality Press, 1997. 378 p.
FELIX, H. L., CAGIDO, F. S. Análise do planejamento de ensino do departamento de
engenharia industrial. 2016. 137 p. Monografia (Graduação em Engenharia de
Produção) – Escola Politécnica – UFRJ, Rio de Janeiro, 2016.
HALL, C.; HARMON, P. The BPTrends 2006 report on business rules products.
BPTrens, May 2006. Disponível em: www.bptrends.com. Acesso em: maio 2006 apud
PAIM, R. et al. Gestão de processos: pensar, agir e aprender. 1 ed. Porto Alegre:
Bookman, 2009. 328 p.
JURIC, M.; PANT, K. Business process driven SOA using BPMN and BPEL. 1 ed.
Birmingham: Packt Publishing Ltd., 2008. 328 p.
LEITE, L. O.; REZENDE, D. A. Gestão coorporativa por processos na administração
pública municipal: estudo de caso na implantação de BPM no Instituto de Curitiba de
Informática. In: ENCONTRO DE ADMINISTRAÇÃO DA INFORMAÇÃO, 1., 2007,
Florianópolis. Anais... Florianópolis: ENADI, 2007 apud OLIVEIRA, A. et al. Avaliação
de ferramentas de Business Process Management (BPMS) pela ótica da gestão do
conhecimento. Perspectivas em ciência da informação, v.15, n.1, p. 132-153, jan./abr.
2010.
LINDSAY, A.; DOWNS, D.; LUNN, K. Business processes: attempts to find a definition.
Information and Software Technology, n.45, p. 1015-1019, 2003.
73
MALAMUT, G. Processos aplicados a sistemas integrados de gestão. 1º Seminário
Brasileiro de Gestão por Processos, Rio de Janeiro, Anais. Rio de Janeiro, p. 1-20,
2005.
MCCORMARK, K.; JOHNSON, W. Business process orientation: gaining the e-
business competitive advantage. Florida: CRC Press, 2001 apud PAIM, R. et al.
Gestão de processos: pensar, agir e aprender. 1 ed. Porto Alegre:
Bookman, 2009. 328 p.
MOHAPATRA, S. Business process automation. 1 ed. Delhi: PHI, 2009. 392 p.
NETO, A. R.; BORNIA, A. C. A utilização da ferramenta árvore da realidade atual
(ARA) para a identificação do problema raiz em uma instituição de ensino superior
(IES). Associação Brasileira de Engenharia de Produção – ABEPRO.
NETTO, C. A. Definindo gestão por processos: características, vantagens,
desvantagens. In: LAURINDO, F. J. B. (Coord.).; ROTONDARO, R. G. (Coord.).
Gestão integrada de processos e da tecnologia da informação. São Paulo: Atlas, 2006.
cap. 2. p. 14-37. ISBN 8522445079 apud CARRARA, A. R. Implantação de sistema
BPMS para a gestão por processos: uma análise crítica. 2011. 183 p. Dissertação
(Mestrado em Engenharia de Produção) – Escola Politécnica - USP, São Paulo, 2011.
OLIVEIRA, S. B. (Org.). Gestão por processos: fundamentos, técnicas e modelos de
implementação. Rio de Janeiro: Qualitymark, 2006. 310 p. ISBN 857303389 apud
CARRARA, A. R. Implantação de sistema BPMS para a gestão por processos: uma
análise crítica. 2011. 183 p. Dissertação (Mestrado em Engenharia de Produção) –
Escola Politécnica - USP, São Paulo, 2011.
OMG. Business Process Model and Notation (BPMN) V2.0. Object Management
Group, 2011. 538 p.
PAIM, R. et al. Gestão de processos: pensar, agir e aprender. 1 ed. Porto Alegre:
Bookman, 2009. 328 p.
74
SANTOS, D. S. Automatização de processos de negócios utilizando BPM/BPMS.
2013. 114 p. Monografia (Graduação em Ciência da Computação) – Universidade
Estadual do Sudoeste da Bahia, Bahia, 2013.
SCHEER, A. et al. Business process automation: ARIS in practice. 1 ed. Berlin:
Springer-Verlag, 2004. 183 p.
SMITH, H; FINGAR, P. Business process management: the third wave. 1 ed. Tampa:
Meghan-Kiffer Press, 2003. 292 p. ISBN 0929652347 apud CARRARA, A. R.
Implantação de sistema BPMS para a gestão por processos: uma análise crítica. 2011.
183 p. Dissertação (Mestrado em Engenharia de Produção) – Escola Politécnica -
USP, São Paulo, 2011.
VENKI, disponível em: <www.venki.com.br/blog/o-que-e-automacao-de-processos/>.
Acesso em: 10 jun. 2016.
75
APÊNDICE A – Processo de Planejamento de Turmas (AS IS)
PARTE 1
76
APÊNDICE A – Processo de Planejamento de Turmas (AS IS)
PARTE 2
77
APÊNDICE B – Árvore da Realidade Atual do Processo de Planejamento de Turmas
78
APÊNDICE C – Processo de Planejamento de Turmas (TO BE)