envolvimento do usuÁrio em projetos de melhoria bpm€¦ · a abordagem de gerenciamento de...
TRANSCRIPT
UNIVERSIDADE DE SÃO PAULO
ESCOLA DE ENGENHARIA DE SÃO CARLOS
DEPARTAMENTO DE ENGENHARIA DE PRODUÇÃO
ISABELA CRISTINA SIMÕES ZACHARIAS
ENVOLVIMENTO DO USUÁRIO EM PROJETOS DE MELHORIA BPM
SÃO CARLOS
2018
2
UNIVERSIDADE DE SÃO PAULO
ESCOLA DE ENGENHARIA DE SÃO CARLOS
DEPARTAMENTO DE ENGENHARIA DE PRODUÇÃO
ENVOLVIMENTO DO USUÁRIO EM PROJETOS DE MELHORIA BPM
Trabalho de Conclusão de Curso
apresentado à Escola de Engenharia de
São Carlos da Universidade de São
Paulo para obtenção do título de
Bacharel em Engenharia de Produção
Mecânica.
Discente: Isabela Cristina Simões
Zacharias
Orientadora: Profª. Drª. Janaina M H
Costa
SÃO CARLOS
2018
3
4
Agradecimentos
À minha família, pelo apoio e alegria de sempre.
Aos meus amigos do CAASO ao longo de toda a graduação, pelas dicas e risadas.
Aos colegas do NUMA, pelos valiosos ensinamentos e orientações, em especial a
professora Janaina, Carina e Sânia pela paciência e dedicação desde os tempos de iniciação
cientifica.
Aos colegas do SAPRA LANDAUER, sem vocês este trabalho não seria possível.
Obrigada pelo apoio, atenção, paciência e ensinamentos, especialmente Dra. Yvone, Paulo, Dra.
Maria de Fátima, Júlio, Paula, Rosangela, Roger, Eurides, Silvandira, Angélica e toda equipe do
Faturamento: Cacilda, Alessandra, Rita, Jackeline, Nathalia, Rose e Brielly.
5
Resumo
As organizações buscam aperfeiçoar seus processos por meio de projetos de melhoria. A
abordagem Business Process Management (BPM) defende que estes projetos de melhoria
devem estar associados aos objetivos estratégicos da organização e que o foco destes projetos
deve ser nos processos de negócio. Durante o desenvolvimento de um projeto, o ciclo BPM
propõe que os processos sejam analisados e modelados, e as ações planejadas, executadas e
verificadas, de forma iterativa. Os atores do processo (usuários) são indicados no
desenvolvimento do projeto de melhoria como fonte de informações e possuem um papel
decisivo na incorporação da mudança dentro da cultura organizacional. Apesar de esses usuários
exercerem um papel importante no projeto, não está descrito a forma e em que momento do
desenvolvimento da melhoria estes usuários devem ser envolvidos nos modelos BPM. O
objetivo deste trabalho é avaliar o envolvimento do usuário em projetos de melhoria BPM a
partir de um estudo de caso realizado em uma empresa de serviços. Com isso, foi possível
determinar que os usuários podem ser envolvidos no ciclo de melhoria BPM através de
ferramentas de UCD, e este envolvimento pode ser feito durante todo o desenvolvimento o que
serve como estímulo para a incorporação da melhoria e retorna uma solução focada aos
usuários. O envolvimento dos usuários no momento certo foi comprovado ser vantajoso
conforme prega a abordagem User centered-design (UCD), este envolvimento permite que o
desenvolvimento seja mais fluido, iterativo e retorne uma solução com mais valor e focado ao
que o usuário precisa. A proposta de integração das abordagens pode ser replicada em outras
organizações em projetos de melhoria de variadas complexidades.
Palavras-chave: Business Process Managment, BPM, User centered-design, UCD, projeto de
melhoria, envolvimento do usuário
6
Lista de Figuras
Figura 1- Ciclo PDCA _______________________________________________________________________________________ 15 Figura 2 - Modelo de van der Aalst ________________________________________________________________________ 15 Figura 3 - Modelo de zur Muehlen e Ho ____________________________________________________________________ 16 Figura 4 - Modelo de Hallerbach, Bauer & Reichert ______________________________________________________ 16 Figura 5 - Modelo de Houy, Fettke & Loss _________________________________________________________________ 17 Figura 6 - Modelo ABPMP __________________________________________________________________________________ 18 Figura 7 - Modelo Baldam, Valle & Rozenfeld _____________________________________________________________ 19 Figura 8 - Modelo Costa ____________________________________________________________________________________ 20 Figura 9- Descrição das atividades ________________________________________________________________________ 25 Figura 10 - Processo Geral _________________________________________________________________________________ 32 Figura 11 - Processos do Faturamento ____________________________________________________________________ 33 Figura 12 - Processo tirar do especial _____________________________________________________________________ 38 Figura 13 - Mapa da Empatia ______________________________________________________________________________ 39 Figura 14 - User Stories ____________________________________________________________________________________ 41 Figura 15 - Relação necessidades identificadas com requisitos __________________________________________ 42 Figura 16 - Tela do software _______________________________________________________________________________ 44 Figura 17 - Tela com os princípios de solução_____________________________________________________________ 46 Figura 18 - Inclusão das ferramentas de UCD no ciclo BPM ______________________________________________ 50 Figura 19 - Proposta de inclusão de ferramentas UCD de acordo com seu objetivo ao ciclo BPM ______ 51
7
Lista de Tabelas
Tabela 1 - Processo de formulação dos projetos __________________________________________________________ 34 Tabela 2 - Relação requisitos e princípios de solução _____________________________________________________ 47 Tabela 3 - Relação processo novo e mudança _____________________________________________________________ 47 Tabela 4 - Avaliação tópicos de usabilidade _______________________________________________________________ 48
8
Lista de Siglas
ABPMP – Association of Business Process Management Professionals
BPM – Business Process Management
BPMN – Business Process Modeling Notation
IBM - International Business Machines
PDCA – Plan, Do, Check, Act
UCD – User centered-design
9
Sumário
1 Introdução _________________________________________________________________________________ 11
1.1 Contextualização ________________________________________________________________________ 11
1.2 Objetivo __________________________________________________________________________________ 12
2 Revisão da literatura ____________________________________________________________________ 13
2.1 Business Process Management (BPM) ______________________________________________ 13 2.1.1 Definição ________________________________________________________________________________________ 13 2.1.2 Ciclos BPM ______________________________________________________________________________________ 14
2.1.1.1 Modelo de van der Aalst (2004) ___________________________________________________________ 15 2.1.1.2 Modelo de zur Muehlen e Ho (2006) _____________________________________________________ 15 2.1.1.3 Modelo de Hallerbach, Bauer e Reichert (2008) ________________________________________ 16 2.1.1.4 Modelo de Houy, Fettke e Loss (2010) ___________________________________________________ 17 2.1.1.4 Modelo ABPMP (2013) ____________________________________________________________________ 17 2.1.1.5 Modelo Baldam, Valle e Rozenfeld (2014) _______________________________________________ 18
2.2 Metodologia BPM Costa (2006) _______________________________________________________ 19
2.3 User centered-design (UCD) __________________________________________________________ 20
2.3.1 Definições _______________________________________________________________________________________ 20 2.3.2 Ferramentas de UCD ___________________________________________________________________________ 21
2.3.2.1 Mapa de empatia___________________________________________________________________________ 21 2.3.2.2 User Stories _________________________________________________________________________________ 22 2.3.2.3 Prototipagem _______________________________________________________________________________ 22 2.3.2.4 Teste de usabilidade _______________________________________________________________________ 22
2.4 Síntese da revisão da literatura ______________________________________________________ 23
3 Metodologia _______________________________________________________________________________ 24
3.1 Descrição das Atividades ______________________________________________________________ 24 3.1.1 Estágio 1 - Fundamentação Teórica ___________________________________________________________ 24 3.1.2 Estágio 2 – Estudo de Caso _____________________________________________________________________ 26 3.1.3 Estágio 3 – Análise dos Dados _________________________________________________________________ 28
4. Resultados ________________________________________________________________________________ 30
4.1 Descrição da empresa __________________________________________________________________ 30
4.2 Descrição da aplicação da metodologia BPM _______________________________________ 30 4.2.1 Etapa 1 __________________________________________________________________________________________ 30
4.2.1.1 Definir a Mudança _______________________________________________________________________ 30 4.2.1.2 Diagnóstico _______________________________________________________________________________ 31 4.2.1.3 Definir Portfólio de projetos ___________________________________________________________ 34
4.2.2 Etapa 2 __________________________________________________________________________________________ 34 4.2.2.1 Planejar a Mudança _____________________________________________________________________ 34 4.2.2.2 Analisar a Situação Atual _______________________________________________________________ 35 4.2.2.3 Projetar a Situação Futura _____________________________________________________________ 39 4.2.2.4 Implementar a Mudança ________________________________________________________________ 42 4.2.2.5 Validar a Mudança _______________________________________________________________________ 45
4.3 Avaliação do processo de melhoria e das ferramentas ___________________________ 49
4.4 Discussão do envolvimento do usuário _____________________________________________ 50
10
5. Considerações finais ____________________________________________________________________ 53
6. Referências _______________________________________________________________________________ 54
7. Apêndices _________________________________________________________________________________ 57
Apêndice A – Protocolo Diagnóstico _____________________________________________________ 57
Apêndice B – Protocolo Análise da Situação Atual _____________________________________ 58
Apêndice C – Protocolo Validação Usabilidade _________________________________________ 59
Apêndice D – Protocolo Discussão e Resultados _______________________________________ 60
11
1 Introdução
1.1 Contextualização
Para atender os objetivos estratégicos delimitados pela organização, é necessário
alcançar a máxima eficiência e eficácia dos processos. A eficiência dos processos está
relacionada ao conceito de produtividade, à forma com a qual os recursos – materiais ou
humanos - são empregados, enquanto a eficácia aborda a satisfação relacionada ao resultado
entregue (Carpinetti, 2006).
A abordagem de Gerenciamento de Processos de Negócio (BPM - Business Process
Management) associa a compreensão do processo (Smart, Maddern, & Maull, 2009) à estratégia
da organização (Hung, 2006), à medida que vincula a estratégia organizacional com os
processos de negócio da empresa. Processos de negócio podem ser compreendidos como o
esforço que entrega algo de valor ao cliente ou possui uma função gerencial ou de apoio para
outros processos (ABPMP, 2013). O gerenciamento intencional de tais processos de negócio
desenvolve práticas que levam a processos considerados mais eficazes e eficientes e,
consequentemente, que atendem os resultados pretendidos (ABPMP, 2013).
As empresas incorporam, cada vez mais, o BPM em sua cultura, e isto é refletido no
material encontrado na literatura acerca da temática (ABPMP, 2013). Baldam, Valle &
Rozenfeld (2014) citam onze modelos de referência para o ciclo de Gerenciamento de Processos
de Negócios propostos por pesquisadores em um período de aproximadamente dez anos.
Entretanto, apesar das evidências apresentadas que o BPM auxilia a empresa a manter
sua vantagem competitiva (Hung, 2006) e ajuda a identificar quais são os processos-chave a fim
de melhorá-los (Trkman, 2010), ainda existem dificuldades para a sua adequada implementação.
Para obtenção de resultados satisfatórios, o entendimento e diagnóstico do processo precisam
ocorrer de forma holística, isto é, compreender o processo em si e a forma como este processo
interage na organização, além da forma que é influenciado por aspectos como ambiente,
contexto, cultura, envolvimento, restrições e capacidades (Segatto, Pádua, & Martinelli, 2013).
Além disso, é necessário que os atores do processo institucionalizem a mudança na forma de
conceitos, práticas e padrões, ou seja, transformem a mudança efetivamente em rotina (Schein,
2002).
Os novos conceitos e rotinas são desenvolvidos e estabilizados nas organizações por
meio de projetos (Shenhar, Dvir, Levy, & Maltz, 2002), e é assim que as iniciativas de BPM
acontecem nas organizações. Em um projeto de melhoria a partir do ciclo BPM, as pessoas são
os agentes de mudança e são os próprios atores do processo de melhoria. Na área de
desenvolvimento de produtos, os usuários são subdivididos de acordo com Abras, Maloney-
Krichmar e Preece (2004) em: usuários primários, secundários e terciários. Os usuários
primários são aqueles que efetivamente utilizam o produto; os secundários são aqueles que
ocasionalmente detêm a interação com o produto, e os terciários são os afetados pelo uso do
produto. Logo, as pessoas envolvidas em uma melhoria podem ser consideradas como usuário,
uma vez que interagem e modificam o processo. Isso demonstra a importância do emprego da
teoria do envolvimento do usuário em projetos de BPM.
No contexto das teorias de envolvimento do usuário, se destaca a abordagem UCD
(User-Centered Design) que aborda o envolvimento do usuário para um entendimento claro de
suas necessidades e requisitos (Vredenburg, Mao, Smith, & Carey, 2002). Com a utilização da
12
abordagem UCD, as chances de se desenvolver algo que tenha real valor e/ou identificar
possíveis problemas aumenta de forma considerável (Gulliksen et al., 2003).
A principal vantagem do emprego da abordagem UCD é conseguir compreender o
usuário em esferas variadas: psicológica, organizacional, social e alinhada com os seus
propósitos (Abras, Krichmar, & Preece, 2004). Em projetos de melhoria de processo esta
compreensão permite o desenvolvimento e aprimoramento de processos de forma mais
adequada e de fácil compreensão, o que resulta em processos que possam ser melhores
executados. Os usuários finais são as pessoas que cotidianamente executam uma determinada
função no processo, e também constituem especialistas em seus trabalhos e conseguem ter uma
visão completa e detalhada do que poderia ser melhorado e/ou alterado (Gulliksen & Göransson,
2001).
A literatura de BPM ressalta que o foco deve ser no(s) processo(s) que traz (em) valor
ao consumidor (Trkman, Mertens, Viaene, & Gemmel, 2015), ou seja, com ênfase em
atividades de impacto na satisfação do cliente (Hung, 2006). Entretanto, a literatura apresenta
uma lacuna em como envolver o usuário do processo em um projeto de melhoria de processo
utilizando a abordagem BPM, não há referências que demonstram como o usuário deve ser
envolvido, nem o seu papel em outras etapas do ciclo BPM.
Na abordagem UCD existem diversos métodos, técnicas, práticas e abordagens que
podem ser aplicadas de modo que os usuários de um processo possam ser envolvidos e
considerados no projeto de melhoria. Para isto, é preciso definir em que momento este(s)
usuário(s) deve(m) ser envolvido(s) ao longo do ciclo de melhoria de BPM e com qual
finalidade.
1.2 Objetivo
A questão de estudo fundamental deste trabalho foca em avaliar o envolvimento dos
usuários por meio da integração de ferramentas de UCD em projetos de melhoria BPM com o
intuito de alcançar resultados mais pertinentes aos usuários do processo.
O objetivo é apresentar um estudo de caso de um projeto de melhoria realizado a partir das
abordagens BPM e UCD em uma empresa de serviços. Os objetivos específicos são, portanto:
o Identificar como as ferramentas de UCD podem ser incorporadas no ciclo BPM;
o Identificar quais os desafios do envolvimento dos usuários no processo de
desenvolvimento da melhoria;
o Identificar quais os desafios do envolvimento dos usuários para melhorar a
institucionalização da melhoria.
13
2 Revisão da literatura
Como parte da estratégia das organizações para se assegurarem ativamente e
competitivamente no mercado, há uma busca pelo aperfeiçoamento dos processos realizados nas
empresas (Carpinetti, 2016). A abordagem BPM explicita que os objetivos estratégicos podem
ser atingidos por meio de melhoria contínua dos processos chaves da organização (ABPMP,
2013). Sendo assim, dentro das organizações são executados projetos voltados à melhoria de
processos, sendo que tais processos são denominados por processos de negócio (Shenhar, Dvir,
Levy, & Maltz, 2002; Baldam, Valle, & Rozenfeld, 2014). Processos de negócio correspondem
a um trabalho que entrega valor ao cliente (ABPMP, 2013).
Paralelamente, no campo de estudo de projeto e desenvolvimento de produtos e serviços
são reconhecidos a importância e os benefícios do envolvimento do usuário nas diversas fases
(Abras et al., 2004; Gulliksen et al., 2003; Rippon, 2006). A abordagem UCD explicita que este
envolvimento proporciona produtos e serviços com maior valor para o usuário. Este
envolvimento nas fases de desenvolvimento pode ser feito por intermédio de diversos métodos e
ferramentas, de acordo com o que é necessário para a execução de uma fase determinada
(Campese, Scatolin, Esposto, & Costa, 2015).
Assim, durante a execução de projetos de melhoria de processo, conseguir dar à solução
um viés a partir da perspectiva dos usuários envolvidos resulta, além de bons resultados, uma
melhoria focada que consegue de fato suprir necessidades, limitações e dificuldades alvos da
melhoria.
2.1 Business Process Management (BPM)
2.1.1 Definição
O conceito de BPM se relaciona aos processos e a forma como estes permeiam as
organizações (Maddern, Smart, Maull, & Childe, 2014; Smart et al., 2009). Todas as
organizações executam suas atividades por meio de processos (Armistead, Pritchard, & Machin,
1999), ou seja, os processos são os meios pelos quais as organizações atingem seus objetivos, é
por meio deles que as necessidades dos clientes são atendidas (Smart et al., 2009). Os processos
são a associação de atividades e tarefas feita tanto por homens quanto por máquinas com o
intuito de satisfazer um objetivo (ABPMP, 2013).
Para a realização dos processos, isto é, para gerar valor e retornar algo às partes
interessadas, é necessária uma infraestrutura organizacional e participação de pessoas dentro de
uma organização. A este conjunto damos o nome de negócio (ABMPM, 2013; Baldam, Valle,
& Rozenfeld, 2014). Logo, processos de negócios corresponde a forma lógica de organizar
tarefas de forma a entregar valor aos consumidores, alcançar objetivos estratégicos e apoiar ou
gerenciar outros processos (ABPMP, 2013; Trkman, 2010).
A abordagem BPM, portanto, se concentra em processos de negócio (ABPMP, 2013;
Antonucci & Goeke, 2011; Zairi, 1997) com o intuito de melhorá-los de forma contínua
(Antonucci & Goeke, 2011) e alcançar resultados relativos a estratégia da organização (Baldam,
Valle, & Rozenfeld, 2014; ABMPM, 2013; Trkman, 2010) no atendimento das necessidades
dos clientes (ABPMP, 2013).
O surgimento do BPM ocorreu devido a uma evolução de conceito das pesquisas
realizadas no campo da administração e engenharia. Não se trata de uma abordagem criada de
forma isolada, mas sim de um processo de evolução de teorias, ferramentas e concepções
14
desenvolvidas, estudadas e dessiminadas ao longo do tempo (Antonucci & Goeke, 2011;
Baldam, Valle, & Rozenfeld, 2014; Maddern et al., 2014). As técnicas mais contemporâneas,
como CRM (Customer Relationship Management), ERP (Enterprise Resource Planning), Seis
Sigmas e Gestão da Cadeia de Suprimentos, utilizam como base a gestão de processos (Baldam,
Valle, & Rozenfeld, 2014; Smart et al., 2009).
O conceiro de processo como fator organizacional importante teve início com Taylor no
início do século XIX com a busca pelo aumento da produtividade por meio das tarefas
organizadas em linhas de produção (processo), na busca pelo aperfoiçamento da qualidade com
a filosofia japonesa e técnicas de eficiência pautadas em melhoria contínua e orientadas a
processo, e, por fim, na introdução dos computadores e softwares para modelos de processos na
gestão conhecida como Reengenharia (Baldam, Valle, & Rozenfeld, 2014; Maddern et al.,
2014). O BPM surge, então, como gerenciamento para otimizar os processos por meio de
melhoria contínua e participação dos trabalhadores de forma integrada (Baldam, Valle, &
Rozenfeld, 2014).
A maior crença do BPM reside em defender que objetivos organizacionais podem ser
atingidos por gerenciamento de negócio (ABPMP, 2013). Isto ocorre por meio de uma mudança
que precisa ser associada a uma mudança cultural (Zairi, 1997), pois para atingir os objetivos
desejados, mais do que entender os processos, é necessário considerar na análise as forças,
fraquezas, o ambiente, a cultura organizacional, as restrições e capacidades (Segatto et al.,
2013), e compreender a forma como se relacionam interna e externamente (Hung, 2006).
A abordagem BPM busca entender os processos em sua totalidade, bem como suas
barreiras e inter-relações (Smart et al., 2009). Por isso prega uma visão por processos em
oposição a uma visão departamental (mais tradicional) em que cada departamento estabelece
seus próprios objetivos, o que por vezes podem ser antagônicos ou conflituosos (Segatto et al.,
2013). Já na visão por processo, busca-se a compreensão do trabalho em si com relação as
atividades que agregam valor (Hung, 2006), dando uma perspectiva holística de planejamento e
gerenciamento (Antonucci & Goeke, 2011; Maddern et al., 2014; Segatto et al., 2013).
2.1.2 Ciclos BPM
Os ciclos de BPM são estruturas de referência com o intuito de organizar um conjunto
de atividades consideradas fundamentais, de forma contínua para garantir o alinhamento
constante com os objetivos da organização (ABPMP, 2013; Baldam, Valle, & Rozenfeld, 2014).
Porém, para implementar o BPM não é necessário seguir todas as fases sequencialmente, mas
sim adequar as necessidades e maturidade da organização (Baldam, Valle, & Rozenfeld, 2014),
uma vez que pode ser aplicada a organizações de carater público ou privado de qualquer porte
(ABPMP, 2013).
A literatura possui diversos ciclos BPM descritos. Estes ciclos são, a partir de uma
visão mais ampla, caracterizados principalmente por planejamento, análise, modelo ou desenho,
implementação e controle ou monitoramento (ABPMP, 2013; Baldam, Valle, & Rozenfeld,
2014). Esta configuração tem forte correlação com o Ciclo PDCA de Deming (ABPMP, 2013)
apresentado na Figura 1.
15
Figura 1- Ciclo PDCA
Fonte: ABPMP (2013)
De acordo com ABPMP (2013), de forma simplificada, o ciclo BPM é composto pelas
fases Planejar (Plan), Fazer (Do), Verificar (Check) e Agir (Act). A fase Planejar corresponde a
uma compreensão do escopo do projeto e a garantia do alinhamento estratégico. A fase Fazer é
a implementação do projeto em si, já a fase Verificar estabelece um parâmetro de comparação
entre o esperado e o real para o projeto. Por fim, a fase Agir institui a mudança no contexto
organizacional e se preocupa em garantir a continuidade da melhoria contínua.
2.1.1.1 Modelo de van der Aalst (2004)
O modelo de van der Aalst (2004) é focado em processos direcionados para software
(Figura 2).
Figura 2 - Modelo de van der Aalst
Fonte: van der Aaslt (2004)
O modelo estabelece quatro fases: design do processo, configuração do processo,
aprovação do processo e diagnóstico (van der Aalst, 2004). Na fase de design é feita a
construção do modelo “as-is” ou “to-be” de acordo com a necessidade do projeto objetivando
uma maior compreensão do processo (Morais, Kazan, Pádua, & Costa, 2014).
Na fase de configuração, os processos são implementados pela configuração de um
sistema de informação. A fase de aprovação é feita a partir de um sistema configurado em que o
processo é executado e por fim, no diagnóstico é feita uma análise do processo para identificar
problemas e/ou aspectos que podem ser melhorados (Morais et al., 2014; van der Aalst, 2004).
2.1.1.2 Modelo de zur Muehlen e Ho (2006)
O modelo de zur Muehlen e Ho (2006) apresentado na Figura 3 é focado na automação
dos processos de negócio e inclui atividades de TI (Morais et al., 2014). A premissa deste ciclo
é o alinhamento, isto é, por meio de um alinhamento geral dos processos individuais e da
estratégia da organização é possível melhorar o desempenho tanto quantitativamente quanto
qualitativamente (zur Muehlen & Ho, 2006).
16
O ciclo BPM proposto por zur Muehlen e Ho se inicia com o estabelecimento das metas
organizacionais e de processos e de uma análise dos fatores que limitam os processos de
negócio (zur Muehlen & Ho, 2006). Entretanto, tal fase é uma etapa inicial fora do ciclo que
direciona uma ou mais iniciativas (Morais et al., 2014). Feita esta análise organizacional, tem
início a fase de design do processo em que os processos-alvo do ciclo são analisados, e para isto
usa-se o mapeamento de processo e analisam-se quais fatores afetam ou influenciam o processo.
Estes fatores podem ser de caráter interno ou externo (zur Muehlen & Ho, 2006).
Em seguida, os processos são implementados, ou seja, são executados de forma
operacional ou automatizada e é feita a aprovação do que foi institucionalizado. Como forma de
manutenção da melhoria é feito um monitoramento real, este monitoramento conjuntamente
com avaliações de outros resultados são os subsídios para novas melhorias (zur Muehlen & Ho,
2006).
Figura 3 - Modelo de zur Muehlen e Ho
Fonte: zur Muehlen e Ho (2006)
2.1.1.3 Modelo de Hallerbach, Bauer e Reichert (2008)
O modelo de Hallerbach, Bauer e Reichert (2008) (Figura 4) é um modelo simplificado
e restrito, pois não considera de maneira forma uma visão estratégica nem um alinhamento com
os objetivos estratégicos (Morais et al., 2014).
Figura 4 - Modelo de Hallerbach, Bauer & Reichert
Fonte: Hallerbach, Bauer & Reichert (2008)
17
O modelo é composto por três fases: modelagem, em que o desenho do processo é feito
considerando as variantes na análise; seleção: em que a configuração das variantes é escolhida;
execução: a variante do processo é executada junto a um monitoramento em tempo real. Tais
fases são ligadas por uma interação de otimização onde as melhores práticas são escolhidas
(Hallerbach, Bauer, & Reichert, 2008).
2.1.1.4 Modelo de Houy, Fettke e Loss (2010)
O modelo de Houy, Fettke e Loss foi construído a partir de pesquisa e associação de
alguns ciclos BPM presentes na literatura (Figura 5), E corresponde, portanto, a um ciclo
especificado com base em conceitos (Morais et al., 2014).
Figura 5 - Modelo de Houy, Fettke & Loss
Fonte: Houy, Fettke e Loss (2010)
O ciclo se inicia com o desenvolvimento da estratégia voltado ao BPM, definição e
modelagem dos processos relevantes a estratégia traçada, sem seguida é feita a implementação
dos processos na organização com posterior execução de tais processos. Os processos são
monitorados e controlados em busca da melhoria dos processos alinhado a estratégia e
otimização (Houy, Fettke, & Loos, 2010).
2.1.1.4 Modelo ABPMP (2013)
O modelo ABPMP (2013) se apresenta com seis conceitos e a ideia ininterrupta de
trabalho em busca da melhoria da contínua (Baldam, Valle, & Rozenfeld; 2014).
18
Figura 6 - Modelo ABPMP
Fonte: ABPMP (2013)
O modelo apresentado na Figura 6 se inicia com um planejamento relativo à estratégia
da organização e às metas que querem ser alcançadas. Em seguida é realizada uma análise com
o propósito de entender o processo de forma mais ampla, e tal processo deve estar
correlacionada com a estratégia identificada. A fase de desenho tem muita importância, pois é a
partir dele que as discussões seguintes são realizadas incluindo restrições e avaliações de
impacto. O processo é então implementado efetivamente na organização e passa por um
controle e monitoramento a fim de garantir a conformidade com o que foi especificado e
levantar hipóteses do que pode ser feito como melhoria. O refinamento é a continuidade do ciclo
relativo a melhorias (Baldam, Valle, & Rozenfeld, 2014).
2.1.1.5 Modelo Baldam, Valle e Rozenfeld (2014)
O modelo proposto por Baldam, Valle e Rozenfeld (2014) foi o resultado do estudo de
onze ciclos BPM diferentes presentes na literatura, a proposta foi feita a partir da relação com as
fases apresentadas nos modelos (Baldam, Valle, & Rozenfeld, 2014).
O modelo agrupa as fases em quatro categorias (Figura 7). A primeira é a fase Planejar
o BPM, onde as condições para aplicação do ciclo e execução da melhoria ocorrem, nesta fase
faz-se uma análise da estratégia e do contexto da organização, classifica e prioriza os processos,
identifica recursos necessários para o projeto e forma a equipe o que realizará. Na fase Analisar,
modelar e otimizar processos são feitas discussões em torno do projeto atual (“as-is”) de forma
a formular uma proposta futura (“to-be”) analisando e otimizando o processo (Baldam, Valle, &
Rozenfeld, 2014).
Na fase Implementar processos, o projeto é executado e para isso é necessário fazer
ajustes ao processo atual, conduzir testes, treinar e apoiar a equipe executora com o intuito de
fazer uma gestão da mudança. A última fase, Monitorar o desempenho de processos, se
preocupa em controlar o processo de forma a levantar informações relevantes a serem utilizadas
como realimentação para as fases anteriormente descritas. Para isso pode ser incorporada a
utilização de indicadores de desempenho (Baldam, Valle, & Rozenfeld, 2014).
19
Figura 7 - Modelo Baldam, Valle & Rozenfeld
Fonte: Baldam, Valle e Rozenfeld (2014)
A partir do que foi apresentado nos ciclos descritos é observado que os usuários são
envolvidos em projetos BPM, afinal eles são pessoas que conduzem estes projetos (equipes) e
são pessoas que executam e/ou interagem com os processos diariamente dentro das
organizações. Apesar de ficar implícito que é necessário o envolvimento dos usuários para
conduzir o ciclo tanto nas fases de análise, quanto nas fases de implementação e controle, não
há menção na literatura de como o usuário pode ser envolvido, isto é, não há menções de
ferramentas que cumprem este papel do envolvimento. Assim, com base no que foi discutido
surge a seguinte questão que norteará este trabalho: “Como envolver os usuários em projetos
BPM?”.
2.2 Metodologia BPM Costa (2006)
O modelo BPM escolhido para ser aplicado no projeto de melhoria foi o modelo de
gestão da mudança apresentado por Costa (2006), na Figura 8. Este ciclo é composto por duas
etapas. Uma inicial, em que a partir da necessidade de mudança é realizada uma análise geral da
organização de acordo com os objetivos estratégicos para o levantamento de possíveis projetos
de melhoria. A segunda etapa corresponde as fases para a execução de um projeto de melhoria
especifico (Costa, 2006).
Definido o(s) projeto(s) de melhoria que serão executados, segundo o ciclo de Costa
(2006), inicia-se a segunda etapa na aplicação do clico BPM com as seguintes fases: Planejar a
Mudança, Analisar a Situação Atual, Projetar a Situação Futura, Implementar a Mudança e
Validar a Mudança.
20
Figura 8 - Modelo Costa
Fonte: Adaptado Costa (2006)
Na fase Planejar a Mudança é determinado os objetivos do projeto, quais os resultados
esperados, bem como são planejadas as ações que devem ser realizadas para o bom andamento
do projeto. A fase Analisar a Situação Atual consiste em um diagnóstico com um maior
detalhamento tanto de requisitos quantitativos quanto qualitativos.
Os dados qualitativos são importantes à medida que permitem que o ponto de vista do
usuário seja considerado no desenvolvimento (Chen & Chou, 2013), pois o desenvolvedor
mesmo que execute inúmeras análises, não conseguirá entender o processo com tanta
propriedade como as pessoas que o executam diariamente (Rudd & Isensee, 1991).
A fase Projetar Situação Futura consiste em projetar a solução, projeto “to-be”. A fase
Implementar a Mudança, é onde a mudança é institucionalizada e os treinamentos requeridos
são realizados. Por último, a fase Validar a Mudança corresponde a uma análise crítica, tal
análise é feita no fim do processo para comprovar se os objetivos foram atingidos de forma
satisfatória (Costa, 2006).
2.3 User centered-design (UCD)
2.3.1 Definições
O termo User centered-design (UCD) surgiu pela primeira vez na década de 80 nas
pesquisas de Donald Norman (Abras et al., 2004). A partir de estudos que envolviam a
engenharia cognitiva, Norman (1986) percebeu que para desenvolver softwares melhores era
preciso entender como os usuários executavam as tarefas. Ou seja, entender as tarefas dos
usuários de forma mais aprofundada, bem como a forma que estes usuários interagiam e
executavam tais tarefas, eram premissas essenciais para que a partir das necessidades fosse
desenvolvido algo considerado “utilizável” (Norman, 1986).
21
Neste contexto, surge a abordagem UCD que em um sentido mais amplo pode ser
compreendida como a prática de envolver o usuário por meio de várias ferramentas de modo a
possibilitar um entendimento claro, tanto do usuário quanto de seus requisitos (Abras et al.,
2004; Vredenburg et al., 2002). Ao se envolver o usuário nas fases de desenvolvimento as
chances de se produzir algo que tenha valor ao usuário e/ou que se consiga identificar um
problema para uma possível medida corretora aumenta substancialmente (Gulliksen et al.,
2003).
A maior vantagem da utilização de uma abordagem centrada no usuário é conseguir
compreender o usuário dentro de uma gama de fatores, como: fatores psicológicos,
organizacionais, sociais e ergonômicos, isto assegura que a solução desenvolvida esteja alinhada
como o proposito inicial (Abras et al., 2004), pois possibilita uma fonte constantes de feedback,
uma vez que os usuários são as pessoas mais adequadas para testar e avaliar protótipos de
soluções a serem utilizadas posteriormente por eles (Gulliksen & Göransson, 2001).
Como a abordagem prega que os usuários sejam envolvidos desde as fases iniciais do
projeto, os desenvolvedores entram em contato com os usuários e desde o começo conseguem
traçar um objetivo relativo ao que o usuário espera e deseja do produto e/ou serviço, estas ideias
e sugestões são usadas como subsídios para as fases posteriores do desenvolvimento (Abras et
al., 2004). Desta forma, os benefícios ao se usar a abordagem UCD são sumariamente: a
alavancagem competitiva proveniente de produtos mais atrativos e aumento da satisfação do
consumidor com alta possibilidade de fidelização (Rippon, 2006).
O desenvolvimento focado no usuário possui forte correlação com usabilidade1, já que
para se alcançar as metas de usabilidades recorrem-se às ferramentas de UCD (Gulliksen &
Göransson, 2001). Dentro do universo de desenvolvimento de softwares, este tema ganhou
notoriedade (Gulliksen et al., 2003), e a usabilidade pode ser então compreendida como uma
série de técnicas utilizadas para melhorar a facilidade do sistema (Rippon, 2006).
2.3.2 Ferramentas de UCD
De acordo com a classificação proposta Campese et al (2015) com relação as
ferramentas de UCD presentes na literatura, há três classificações: identificação do usuário,
identificação dos requisitos do usuário e validação do conceito com o usuário. As ferramentas
de identificação do usuário auxiliam a equipe de desenvolvimento a identificar e compreender
usuários considerados potenciais; as ferramentas de identificação dos requisitos permitem que
as necessidades sejam levantadas e transformadas em requisitos, e as ferramentas de validação
direcionam os testes com os usuários (Campese et al., 2015).
2.3.2.1 Mapa de empatia
De acordo com a classificação de Campese et al (2015), o mapa da empatia se enquadra
como uma ferramenta que auxilia na identificação dos requisitos do usuário. Trata-se de uma
ferramenta que busca eliminar suposições e encontrar fatos relacionados às necessidades,
desejos, anseios e comportamentos dos usuários (Campese & Costa, 2017).
O objetivo da aplicação desta ferramenta é trazer informações e observações que a
simples aplicação de um questionário não pode absorver (Chen & Chou, 2013). É pautada no
1 Usabilidade: para a informática possui relação com a facilidade que um equipamento ou produto pode
ser usado (Dicionário Online de Português – Dicio)
22
design empático2 (Chen & Chou, 2013) e considera os problemas em seis dimensões: fala,
pensa, faz, sente, dores e ganhos. Tem o propósito de considerar fatores cognitivos, emocionais
e contextuais (Campese & Costa, 2017; Chen & Chou, 2013).
2.3.2.2 User Stories
Segundo o estudo realizado por Campese et al (2015), a ferramenta User Stories é
classificada como identificadora de requisitos dos usuários. Esta ferramenta permite captar as
intenções dos usuários dentro de seu contexto (Alexander & Maiden, 2004), permitindo assim
que necessidades, desejos e expectativas sejam entendidas e traduzidas em requisitos (Campese
et al., 2015).
Com base nas definições encontradas na literatura é possível definir a ferramenta User
Stories como uma breve descrição, por meio de narrativas (Alexander & Maiden, 2004), que a
partir da perspectiva do usuário (Cohn, 2004) demonstra uma funcionalidade que o sistema deve
atender (Rees, 2002). Esta funcionalidade envolve aspectos além de características técnicas,
contemplando aspectos diversos que retornam valor ao usuário (Oglio, 2006).
Esta ferramenta permite que exista uma linguagem comum entre desenvolvedores e
usuários, que geralmente tendem a ter diferentes pontos de vista acerca dos requisitos do
projeto, o que implica em uma solução afastada do ideal (Leffingwell & Behrens, 2010). É feita
por iterações o que permite feedbacks constantes a serem incrementados no projeto (Alexander
& Maiden, 2004). A ferramenta User Stories é amplamente utilizada no desenvolvimento de
softwares (Oglio, 2006).
2.3.2.3 Prototipagem
Como parte do processo de desenvolvimento, inúmeras vezes faz-se necessário testar de
forma representativa as tarefas envolvidas em um contexto, e isto pode ser realizado por meio
de protótipos (Hall, 2001). O protótipo como ferramenta no desenvolvimento é pautado na
iteratividade (Rudd & Isensee, 1991) em que é desenvolvida uma interface com o usuário, esta
interface é prototipada, é conduzido um teste de usabilidade (seção 2.3.2.4 Teste de usabilidade)
e os resultados são analisados. Quando necessário volta-se ao começo do ciclo para incluir
modificações (Bogers & Horst, 2014).
O protótipo é uma ferramenta de validação de conceitos3 (Campese et al., 2015) em que
a troca de informações acaba se tornando mais rápida, o que implica em um processo de
desenvolvimento mais fluido e contínuo (Bogers & Horst, 2014). A escolha do protótipo
depende do objetivo da utilização dele, isto é, de quais informações de deseja extrair e/ou
observar, isto depende de alguns fatores como: características do produto em desenvolvimento,
estágio do desenvolvimento e recursos disponíveis (Hall, 2001).
2.3.2.4 Teste de usabilidade
Dentro de um desenvolvimento UCD é necessário que sejam feitas análises de forma a
adicionar certas melhorias identificadas nas fases subsequentes ou retrabalhar as fases
anteriores. Estas análises são conduzidas em sua maioria por meio de testes (Bogers & Horst,
2014; Hall, 2001; Rudd & Isensee, 1991). Estes testes são dentro da abordagem UCD, testes de
2 A palavra empático faz referência à empatia. De acordo com o Dicionário Online de Português – Dicio,
empático é aquele que se coloca no lugar do outro, de forma a pensar e agir como o outro faria em uma
dada situação. 3 Conceito em projeto e desenvolvimento de produto se refere a um conjunto de princípios de solução que
geram e/ou transmitem uma ideia.
23
usabilidade em que usuários reais são envolvidos com tarefas reais permitindo que os
desenvolvedores obtenham dados relevantes dentro do contexto de uso. Tais dados são
utilizados em análises e discussões dentro de um processo que se propõe a implementar, avaliar
e agir (Abras et al., 2004; Rippon, 2006).
Para Campese et al (2015), o teste de usabilidade se enquadra como uma ferramenta
para a validação dos conceitos, entretanto para a execução do teste é necessário aliá-lo a outras
ferramentas, isto é, trata-se de uma ferramenta complementar de análise. O teste de usabilidade
é comumente usado com protótipos (Campese et al., 2015). Em um ciclo iterativo, a fase de
testar possui um papel primordial (Gulliksen & Göransson, 2001), pois consegue fornecer o que
é necessário para completar o ciclo descrito pela abordagem UCD (Abras et al., 2004). Assim,
dentro das organizações o teste de usabilidade é uma das ferramentas de UCD mais utilizada
(Rippon, 2006).
2.4 Síntese da revisão da literatura
O BPM é uma evolução das práticas e teorias de gestão estudadas e aperfeiçoadas ao
longo do tempo. Dentro das organizações pode trazer melhorias consideráveis ao associar os
objetivos estratégicos aos processos de negócio, isto é, ao facilitar o entendimento de como os
procedimentos da organização impactam diretamente no que a organização deseja alcançar. Por
ser algo em constante mudança e influencia de diversos fatores internos e/ou externos, o BPM
se apoia na melhoria contínua onde mudanças são feitas de forma constante e progressiva.
A literatura possui uma vasta discussão acerca de como os ciclos devem ser geridos e
cultivados dentro das organizações. Apesar de demonstrar que os usuários devem ser
considerados como fonte de informações e recursos transformadores, não estabelece a forma e
em quais momentos estes usuários devem ser envolvidos.
O envolvimento dos usuários no momento certo, obtendo os dados relevantes para o
estágio atual de desenvolvimento contribui consideravelmente para uma solução mais focada,
que apresente valor ao usuário em um desenvolvimento mais rápido e fluido. A abordagem
UCD prega o envolvimento do usuário já em fases iniciais de desenvolvimento a fim de
estabelecer um desdobramento orientado. Para isto, há diversas ferramentas disponíveis com
objetivos de recolhimento de informações específicas que se enquadram melhor em cada uma
das fases de desenvolvimento.
Nas organizações, práticas e ferramentas de envolvimento de usuários do
desenvolvimento são conhecidas principalmente no desenvolvimento de produtos,
especialmente de softwares. Entretanto, tais ferramentas podem a partir de uma customização e
adequação ao propósito do projeto, ser aplicadas com sucesso em projetos de outra natureza,
como projetos de melhoria de processos.
24
3 Metodologia
O foco deste trabalho é avaliar como o envolvimento dos usuários contribui para uma
melhor aplicação do ciclo BPM, para isto foi empregado duas teorias distintas: BPM e UCD.
Para discutir e validar os benefícios de uma aplicação conjunta escolheu-se como procedimento
de pesquisa o estudo de caso. O estudo de caso gera valor à pesquisa ao explorar, construir,
testar, refinar e estender a aplicação de teorias (Voss, Tsikriktsis, & Frohlich, 2002).
O estudo de caso é unidade básica de análise de uma pesquisa de caso(s), pode ser
usada para testar uma hipótese previamente formulada sobre um construto4 (Voss et al., 2002).
As hipóteses a serem testadas e discutidas neste trabalho estão descritas abaixo:
Hipótese 1: As ferramentas utilizadas foram adequadas ao projeto da melhoria.
Hipótese 2: Os usuários se sentiram envolvidos no projetos.
Hipótese 3: Os usuários terão menos resistência a mudança.
O estudo de caso tem como recurso fundamental as entrevistas estruturadas por meio de
um protocolo, entretanto outras fontes de dados surgem como forma de complementar a análise,
são elas: observações, conversas informais, pesquisas aplicadas na organização, análise de
documentos e arquivos, entre outros (Voss et al., 2002).
O procedimento estudo de caso é indicado para testar a aplicação conjunta de teorias
por permitir estabelecer uma relação de causa e efeito. Quando o estudo de caso é aplicado em
uma organização, é necessário estabelecer a relação entre processos e sistemas e analisar
quantos respondentes são necessários, considerando aspectos como conhecimento e domínio
sobre o assunto da investigação e necessidade de mais de um ponto de vista sobre o mesmo
tema. (Voss et al., 2002).
O presente trabalho expõe um estudo de caso único. A principal vantagem associada a um
caso singular é permitir que fosse feito um estudo mais aprofundado, em contrapartida a
principal limitação reside na representatividade e nas generalizações provenientes da conclusão
(Voss et al., 2002).
3.1 Descrição das Atividades
As atividades foram divididas em três estágios: Fundamentação Teórica, Estudo de Caso
e Análise dos dados, conforme Figura 9.
3.1.1 Estágio 1 - Fundamentação Teórica
No Estágio 1 foi realizada a atividade A1.1- Estudo da fundamentação teórica que
corresponde ao capítulo 2 Revisão da literatura. Esta atividade foi subdividida em duas
atividades referentes à fundamentação teórica das duas abordagens usadas no presente trabalho.
A atividade A1.1.1 fez a seleção dos métodos de BPM presente na seções 2.1 Business Process
Management (BPM) e 2.2 Metodologia BPM Costa (2006). Já a atividade A1.1.2 fez a seleção
dos métodos de UCD presente na seção 2.3 User centered-design (UCD).
4 Construto, segundo o Dicionário Online de Português, é um modelo mental que estabelece uma relação
entre uma teoria e uma observação idealizada, isto é, ideias construídas com base em elementos
conceituais.
25
Para a realização da revisão da literatura foram usados trabalhos encontrados nas bases
de dados eletrônicas Web of Science, Google Scholar e na Biblioteca Digital de Teses e
Dissertações da USP. Estes trabalhos foram encontrados a partir de buscas iterativas das
palavras-chaves “BPM”, “Business Process Management”, “UCD”, “User centered-design”,
nos títulos, resumos e/ou palavras-chaves dos artigos.
Figura 9- Descrição das atividades
Fonte: a autora
Para este trabalho foi selecionada a metodologia BPM de Costa apresentada em 2.2
Metodologia BPM Costa (2006), por ser um ciclo mais detalhado e aplicável em diferentes
granularidades, uma vez que parte de uma análise inicial vinculada a estratégia para definir um
portfólio de projetos. No processo de melhoria, é interessante perceber que para alcançar a
26
melhoria pretendida, muitas vezes é necessária mais de uma iniciativa de mudança, porém tais
iniciativas estão vinculadas a recursos e disponibilidades da organização. O ciclo escolhido
permite que as iniciativas sejam priorizadas e permite que seja trabalhado, com base nelas, um
planejamento de longo prazo.
De acordo com as fases apresentas no ciclo BPM de Costa (Planejar a Mudança,
Analisar a Situação Atual, Projetar Situação Futura, Implementar a Mudança e Validar a
Mudança), em cada objetivo delimitado foi traçado o que era preciso para o desenvolvimento e
entrega de cada uma das fases. Na Análise da Situação Atual, para organizar os elementos
qualitativos obtidos por meio de entrevistas, observações e/ou conversas informais, foi
empregada a ferramenta de UCD - Mapa de Empatia-.
A fase de Projetar a Situação Futura exige a partir da fase anterior (análise da situação
atual) reverter os resultados da análise em requisitos a serem desenvolvidos, para isto optou-se
por uma ferramenta UCD caracterizada por auxiliar a identificar requisitos Por se tratar de um
projeto de melhoria de software foi escolhida a ferramenta User Stories, que se enquadra na
classificação pretendida, além de ser uma ferramenta amplamente utilizada no universo de
software para este fim.
Na fase de Implementar a Mudança, seguiu-se os preceitos de UCD, ou seja, foi
realizado um desenvolvimento iterativo que constantemente se renovava com base nas opiniões
recebidas. Normalmente, estas opiniões dos usuários são obtidas mais facilmente por meio de
uma interação com protótipos alinhada a um teste de usabilidade, portanto, foi escolhido aplicar
tais ferramentas (protótipo e teste de usabilidade) conjuntamente a fim de se obter respostas
rápidas relativas ao incremento dos requisitos junto aos usuários do processo.
3.1.2 Estágio 2 – Estudo de Caso
O estudo de caso foi guiado pelo método BPM selecionado que é apresentado na seção
2.2 Metodologia BPM Costa (2006) e pela inclusão de ferramentas descritas na seção 2.3 User
centered-design (UCD) de acordo com cada uma das etapas descritas na metodologia escolhida.
Este estágio foi subdividido em 14 atividades, e algumas destas atividades foram agrupadas de
acordo com cada uma das fases do ciclo BPM descrito, estas atividades serão descritas
separadamente.
A atividade A2.1 – Reconhecimento geral do contexto da empresa constituiu de uma
explanação inicial da empresa em que o estudo de caso foi realizado. O resultado dessa
atividade é apresentado na seção 4.1 Descrição da empresa, foram identificadas características
como o tipo de serviço executado e como o funcionamento geral ocorre. As atividades A2.2,
A2.3 e A2.4 correspondem às fases presentes na etapa 1 do ciclo proposto por Costa (2006). A
atividade A2.2 foi executada segundo um protocolo de entrevistas desenvolvido segundo as
diretrizes de Echeveste, Amaral, & Rozenfeld (2007), este protocolo encontra-se no Apêndice A
– Protocolo Diagnóstico.
A atividade A2.2 – Diagnóstico da situação atual se propôs a partir de entrevistas e
observações iniciais, entender o processo geral da empresa e do processo alvo da mudança.
Assim, com base nos procedimentos de entrevista e observações foi realizada a modelagem do
processo escolhido. O propósito de se utilizar a modelagem é descrever o fluxo de trabalho
(Cimino et al., 2017), para isso foi escolhida a notação BPMN (Business Process Modeling
Notation) que é comumente usada para capturar os processos de negócio (Dijkman, Dumas, van
27
Dongen, Kaarik, & Mending, 2011; Dijkman, Dumas, & Ouyang, 2008) por possuir uma fácil
compreensão (Cimino et al., 2017).
Com base neste diagnóstico inicial e nos objetivos estratégicos da empresa em direção a
melhoria do processo alvo da mudança foram identificados os principais problemas e
dificuldade e com isso, elencou-se as oportunidades que poderiam ser trabalhadas, A2.3 –
Identificação das oportunidades de melhoria, cujo resultado é apresentado na subseção 4.2.1.2
Diagnóstico.
Estas oportunidades resultaram em um portfólio de projetos alinhados com a estratégia
da organização. Para a escolha do projeto a ser executado primeiro (e descrito neste trabalho) foi
priorizado o projeto que apresentava um ganho maior associado, isto é, com base nas
informações obtidas foi escolhido o projeto que atuava no maior gargalo do processo por meio
da atividade A2.4 - Priorização e seleção do projeto apresentada na subseção 4.2.1.3 Definir
Portfólio de projetos. Assim, os projetos foram priorizados de acordo com o seu impacto no
fluxo do processo, principalmente no que se referia aos gargalos identificados.
As atividades de 2.5 a 2.13 correspondem a etapa 2 do ciclo proposto por Costa (2006)
(vide Figura 8) no qual o projeto da mudança é efetivamente executado. A atividade A2.5 –
Definição do projeto corresponde a delimitar o desenvolvimento do projeto em relação aos
objetivos, ações planejadas e as entregas do projeto, e se encontra na subseção 4.2.2.1 Planejar a
Mudança. Para o planejamento do projeto foram considerados: o patrocinador do projeto, o
objetivo pretendido, as entregas, os riscos e algumas ações de execução e mitigação de riscos.
Em seguida vem a fase de Analisar Situação Atual em que foram realizadas três
atividades A2.6, A2.7 e A2.8 presentes na subseção 4.2.2.2 Analisar a Situação Atual. Para o
diagnóstico da situação atual realizada de forma mais aprofundada para o projeto específico a
ser executado, foi realizado primeiramente uma modelagem do processo A2.6 – Modelagem do
processo com base na notação BPMN, tal modelagem serviu de base para as etapas posteriores,
isto foi realizado por meio de entrevistas e observações diretas, as entrevistas foram feitas com
base no roteiro desenvolvido segundo as diretrizes de Echeveste et al. (2007) presente no
Apêndice B – Protocolo Análise da Situação Atual.
Com o intuito de realizar um estudo mais amplo foi conduzida uma análise quantitativa
na base de dados da empresa de forma comparativa para buscar semelhanças e padrões de
ocorrências nos registros relativos ao processo alvo da mudança, esta análise corresponde á
atividade A2.7 – Análise do registro da emissão das notas, em que os registros foram analisados
e classificados individualmente Para sumarizar as necessidades e impressões expressas nas
entrevistas e observações, foi realizado A2.8 – Aplicar o mapa de empatia (vide subseção
2.3.2.1 Mapa de empatia), a fim de organizar as informações e transmiti-las nas etapas
seguintes, esta ferramenta foi para uso da autora. O template usado está descrito no Guia de
Envolvimento do Usuário no desenvolvimento de produtos eletromédicos de Campese & Costa
(2017).
Em seguida, ocorreu a fase descrita na subseção 4.2.2.3 Projetar a Situação Futura.
Como a solução dependia diretamente de trabalhos de um funcionário fora do processo alvo da
melhoria, foi necessário transmitir as informações acumuladas nas fases anteriores. Para isto,
optou-se por apresentar a este funcionário o processo geral e o processo-alvo descritos por meio
da modelagem, bem como as análises conduzidas e as necessidades identificadas junto as
funcionárias. Para isto, optou-se por fazer um evento a fim de debater estes dados e transformar
28
as informações em requisitos a serem desenvolvidos, neste evento foi aplicada a ferramenta
User Stories- A2.9 – Aplicar User Stories (vide subseção 2.3.2.2 User Stories)-.
Para a realização deste evento exigiu-se um preparo inicial. Inicialmente, a autora
consolidou as informações em frases escritas de acordo com as observações e entrevistas
realizadas, de acordo com a instrução da ferramenta presente na literatura. Com o uso da
ferramenta foi possível delimitar os requisitos a serem desenvolvidos.
A subseção 4.2.2.4 Implementar a Mudança descreveu como a solução foi
institucionalizada. Primeiramente, foi feito um acompanhamento da autora junto ao
desenvolvedor do software para discutir ideias e conceitos baseados nas informações obtidas,
relativo à atividade A2.10 – Acompanhar desenvolvimento do software, até a obtenção de uma
versão inicial.
A partir da versão inicial, a fase de Implementar a Mudança foi realizada de forma
gradual e contínua para cada um dos requisitos estipulados: foi construída uma tela com
características de protótipos (vide subseção 2.3.2.3 Prototipagem) com o intuito de executar um
ciclo: A2.11 – Testar usabilidade das versões (vide subseção 2.3.2.4 Teste de usabilidade),
executar A2.12 – Alterar software e A2.13 – Acompanhar o uso do software para cada um dos
requisitos. Nesta fase, a participação da autora foi fundamental para conduzir os testes junto aos
usuários e retornar os resultados, necessidades, problemas e sugestões ao desenvolvedor do
software para posterior alteração, este procedimento foi feito iterativamente até se obter uma
solução final com todos os requisitos.
A atividade A3.2.14 – Avaliar solução se encontra na subseção (4.2.2.5 Validar a
Mudança) e corresponde a última fase do ciclo BPM de Costa (2006), Validar a Mudança. Esta
fase corresponde a uma análise crítica para contrapor esperado com realizado, e para isto foram
executas as atividades a seguir.
A atividade A2.14.1 – Relacionar solução com requisitos estabeleceu a relação entre os
requisitos listados na fase Projetar a Situação Futura e o que foi apresentado como solução
afinal, a fim de contrapor metas estabelecidas com critérios desenvolvidos. A atividade A2.14.2
– Analisar as tarefas estabeleceu as mudanças de procedimentos no fluxo de execução do
processo alvo da mudança para avaliar aspectos gerais do fluxo e necessidades específicas
descritas para o processo. Por fim, foram realizadas entrevistas para verificar a usabilidade
obtidas A2.14.3, o protocolo presente no Apêndice C – Protocolo Validação Usabilidade foi
elaborado com base no questionário IBM de Lewis (1993). A partir destas entrevistas foi
realizada uma análise para inferir sobre a usabilidade da solução desenvolvida com base nas
impressões das funcionárias
3.1.3 Estágio 3 – Análise dos Dados
O Estágio 3 foi subdivido em três atividades A3.1, A3.2 e A3.3. Para discutir os
objetivos do trabalho com base nos resultados obtidos no estudo de caso, foram realizadas as
atividades A3.1 – Avaliar aplicação do projeto e A3.2 – Avaliação da inclusão das ferramentas,
descritas na seção 4.4 Discussão do envolvimento do usuário. A fim de guiar a discussão foram
realizadas entrevistas com as pessoas envolvidas no projeto a fim de inquirir sobre as vantagens
de BPM descritas em ABPMP (2013), o desempenho geral do projeto e a utilização das
ferramentas, estas entrevistas encontram-se no Apêndice D – Protocolo Discussão e Resultados.
Por fim, foi realizada a atividade A3.3 – Discutir o envolvimento dos usuários para
discussão dos objetivos iniciais do trabalho e da pergunta de pesquisa: como os usuários podem
29
ser envolvidos em projetos BPM foram elencados alguns fatores e apresentada uma proposição
de contribuição teórica, esta discussão encontra-se na seção 4.4 Discussão do envolvimento do
usuário.
30
4. Resultados
Esta seção se propõe a apresentar a aplicação da metodologia descrita de um ciclo BPM
conjuntamente com ferramentas de UCD. Inicialmente, é apresentada a descrição da empesa,
em seguida são descritos os resultados das fases do ciclo BPM e das ferramentas que foram
utilizadas em cada fase. Finalmente, é feita uma avaliação da aplicação do projeto de acordo
com as premissas iniciais e a avaliação da inclusão das ferramentas de UCD no ciclo BPM, e
quais os benefícios e desvantagens percebidos.
4.1 Descrição da empresa
A empresa escolhida para participar do estudo de caso deste trabalho é o SAPRA
(Serviço de Assessoria e Proteção Radiológica). Esta empresa é uma prestadora de serviço de
monitoração externa individual em profissionais expostos a doses de radiação. Estes
profissionais atuam na medicina, indústria e na área de diagnósticos.
A fundação da empresa foi em 1979 com um vinculo forte com o Instituto de Física e
Química de São Carlos da Universidade de São Paulo (USP). No início, a empresa atuava na
conscientização da importância da dosimetria5 individual externa. A partir de 1996, com as
normas estabelecidas a nível nacional que regularizaram a obrigatoriedade da monitoração em
indivíduos ocupacionalmente expostos à radiação, a empresa inicia a prestação de serviços em
todo o território nacional. Em 1998 realiza uma parceria junto à maior empresa de dosimetria
dos Estados Unidos, a Landauer, passando então a se chamar SAPRA Landauer. Atualmente o
SAPRA Landauer é o maior laboratório de dosimetria em operação no país.
Os valores do SAPRA são oferecer serviços de qualidade, com confiabilidade e
conformidade. Para isto, além dos processos envolvidos na empresa com o foco principal em
determinar as doses, há outros processos de cunho mais administrativos que viabilizam a
operação como um todo, principalmente no que se refere ao cadastro e controle das doses do
usuário exigidas por órgãos reguladores nacionais. Outros processos, como vendas, atendimento
ao cliente e financeiro operacionalizam as atividades realizadas. Entre os processos
apresentados destaca-se o processo de Faturamento que corresponde a um processo chave para o
funcionamento saudável da organização, uma vez que por meio deste setor acontece o retorno
de todo trabalho e esforço empregado.
Um dos papeis da Alta Direção é acompanhar os resultados dos processos e contrastar o
que é entregue e o que era esperado de acordo com a estratégia da organização. Ao perceber que
a equipe de Faturamento encontrava dificuldades para executar suas atividades de forma
eficiente e eficaz, sinalizou a necessidade de uma melhoria do processo objetivando diminuir os
erros e o custo deste processo.
4.2 Descrição da aplicação da metodologia BPM
A seguir está descrito cada uma das fases do ciclo BPM escolhido (vide seção 2.2
Metodologia BPM Costa (2006)) nas duas etapas distintas.
4.2.1 Etapa 1
4.2.1.1 Definir a Mudança
Motivada pela necessidade da mudança, a Alta Direção deu inicio a esta fase por meio
de uma reunião que contava com a participação da autora e da orientadora do trabalho a fim de
expor esta motivação e explicar o intuito do projeto.
5 Dosimetria é o nome dado ao processo das práticas necessárias para que se conheça a dose de radiação
recebida por trabalhadores ocupacionalmente expostos em conformidade com a norma de radioproteção
CNEN NN – 3.01. Fonte: Instituto de Radioproteção e Dosimetria – IRD <
http://www.ird.gov.br/index.php/dosimetria>.
31
O projeto de mudança foi realizado no processo de Faturamento, que remete a um
importante e estratégico processo para a empresa. A motivação foi originada pela diferença
entre o que era esperado e o que era entregue pelo processo de Faturamento, relativo à critérios
de contabilidade gerencial da organização. A Alta Direção já havia feito iniciativas pontuais
deslocando funcionários de outros setores para auxiliar a equipe na execução de suas atividades,
entretanto constatou-se que havia um problema de processo na forma como as atividades eram
executadas e as ferramentas empregadas.
4.2.1.2 Diagnóstico
A primeira parte do diagnóstico foi uma compreensão de como o processo geral da
empresa flui em sua estrutura organizacional (Figura 10) este processo foi mapeado por meio da
modelagem em linguagem BPMN. A empresa possui oito atividades principais diretamente com
o processo de emissão do relatório, e são elas: Vendas, Cadastro, Faturamento, Produção,
Envio, Recebimento, Leitura e Físicas Responsáveis. Além desses setores, há o setor de
Atendimento ao Cliente e Sistemas que permeiam todos os outros setores, e são atividades de
apoio ao processo principal.
O processo se iniciava em Vendas com o contato inicial com o cliente e preenchimento
do contrato e outras fichas, seguia para o Cadastro tanto para incluir as informações no banco de
dados quanto para Cadastro nos órgãos nacionais reguladores. Do Cadastro seguia dois fluxos
distintos: para o Faturamento para agendamento e emissão das notas fiscais conforme acerto
contratual e Montagem para montar os monitores a serem utilizados na monitoração das doses
por parte do cliente. Após serem montados, estes monitores são encaminhados para o setor de
Envio para serem encaminhados ao cliente.
Após o período de utilização, estes monitores retornam ao SAPRA. Como forma de
rastreamento e controle, passam pelo processo de Recebimento para que esta movimentação
esteja presente no banco de dados, são então encaminhados para a Desmontagem para
procedimentos de preparo para a leitura. No processo de Leitura, os monitores são lidos e é
emitido um relatório, e este relatório é encaminhado para as físicas responsáveis que realizaram
os procedimentos necessários para aprovação e constatação das doses recebidas. Este relatório é
encaminhado para o cliente na remessa de monitores no mês seguinte.
A seguir ao diagnóstico do processo geral, também por meio de modelagem iniciou-se
um diagnóstico de forma a compreender os processos de faturamento executados, definido
como processo alvo da mudança (Figura 11). O processo de Faturamento foi escolhido por
apresentar papel decisivo na manutenção financeira saudável da organização. Este diagnóstico
tinha o objetivo de compreender e identificar gargalos e processos, para isto foram feitas
entrevistas conforme o protocolo (descrito no Apêndice A – Protocolo Diagnóstico) com as
funcionárias que executam as atividades deste processo de forma a desenhar o processo, agregar
informações e pedir sugestões.
32
Figura 10 - Processo Geral
Fonte: a autora
Há três processos principais no setor Faturamento (Figura 11): agendar as notas fiscais,
tirar notas do especial e emitir as notas. Todo o serviço prestado pela empresa é acompanhado
da emissão de uma nota fiscal de serviço eletrônica junto a prefeitura municipal. De acordo com
a organização do processo existente e a formulação do sistema interno para a emissão destas
notas fiscais é necessário um agendamento prévio neste sistema interno.
Estas notas fiscais a serem emitidas são divididas em duas categorias: casos especiais e
casos não especiais. Os casos não especiais são referentes às notas que podem ser emitidas sem
que haja uma avaliação crítica e/ou atividade(s) necessária(s) antes da emissão da nota; já notas
consideradas especiais exigem uma avaliação das funcionárias relativo ao valor cobrado e/ou
exigem alguma documentação. Esta documentação pode ser uma autorização de emissão
fornecida pelo cliente, normalmente exigida pelos órgãos públicos e/ou uma documentação
especial da empresa prestadora a ser enviada junto à nota gerada como forma de comprovação
do serviço prestado.
33
Figura 11 - Processos do Faturamento
Fonte: a autora
34
A emissão das notas é realizada por meio de um programa que envia lotes de notas para
serem geradas junto a prefeitura, de acordo com as normas do município de São Carlos.
Posteriormente a emissão, as notas geradas são gravadas no banco de dados da empresa e
encaminha-se um boleto bancário relativo ao serviço prestado (nota fiscal) através do e-mail
para o cliente. Diariamente, as funcionárias realizam o atendimento ao cliente relativo as
atividades do processo de Faturamento.
Todas as funcionárias eram capacitadas para executar todas as atividades, porém não
havia uma formalização das responsabilidades deixando a critério delas organizar e gerir as
atividades no dia. O maior problema encontrado foi a limitação do sistema interno programado
na linguagem Clipper. Esta linguagem possui diversas limitações por ser uma linguagem de
programação antiga.
Os processos de agendar e retirar as notas do especial eram realizados neste sistema
interno. As limitações se davam principalmente pela exigência de passar por todas as etapas
para finalizar a operação e o desenvolvimento de atividades complementares manuais que o
sistema não conseguia realizar, tais atividades extras e exigências levavam, consequentemente,
ao principal gargalo do processo. Assim, a maior necessidade encontrada foi: a adequação do
sistema interno ao processo desempenhado de forma simplificada para que não comprometesse
a eficiência e eficácia.
4.2.1.3 Definir Portfólio de projetos
Com base no diagnóstico foi possível estabelecer as necessidades e a partir destas
formular o portfólio dos projetos presentes na Tabela 1.
Tabela 1 - Processo de formulação dos projetos
Problema Necessidade Projetos
Falta de formalização das
responsabilidades
Estabelecer papeis e
responsabilidades
1 - Reorganização das atividades
Sistema com muitas
limitações
Adequação do sistema ao
processo
2 - Melhoria do sistema interno
para agendamento de notas
3 - Melhoria do sistema interno
para tirar notas do especial Muitas atividades
manuais
Inclusão de atividades no
sistema
Os projetos elencados foram: 1) a reorganização das atividades com o intuito de tornar o
projeto mais fluido, 2) melhoria no sistema interno para o agendamento das notas e 3) melhoria
no sistema interno para inclusão das atividades do processo de tirar as notas do especial.
Os três projetos de melhoria foram executados em momentos distintos. O primeiro
projeto priorizado e executado foi o projeto 3 focado na melhoria operacional do sistema interno
para tirar as notas do especial. Esta priorização foi dada por este ser o principal gargalo dos
processos apresentados, que impactava diretamente em toda a operação do processo geral de
Faturamento. Logo, a Etapa 2 descreve o projeto de mudança 3. Portanto, mesmo que outros
projetos de melhoria tenham sido elencados, o foco da mudança apresentado neste trabalho é o
projeto 3.
4.2.2 Etapa 2
4.2.2.1 Planejar a Mudança
A partir da definição do projeto 3 como projeto de mudança a ser executado, iniciou-se
seu planejamento. Primeiramente, foi definido que o patrocinador do projeto seria a própria
35
proprietária da empresa por acompanhar o desempenho do processo em relação aos objetivos
estratégicos contábeis da organização.
O objetivo principal definido para este projeto de mudança foi o aumento da eficiência
no que se refere a agilidade das atividades e a eficácia no que tange a acuracidade da execução,
ambos pautando a melhora na dinâmica de trabalho e minimização dos erros. A partir da
declaração do escopo do projeto foram listadas as entregas programadas:
o Estudo detalhado das observações especiais: analisar as informações presentes no banco
de dados da empresa de forma a agrupar e buscar similaridade entre as ocorrências;
o Descrição dos requisitos do sistema futuro: estabelecer de forma clara as necessidades
transformadas em requisitos como entrada para o desenvolvimento da solução;
o Formulação de um piloto: para que testar e validar cada um dos requisitos estabelecidos
junto as funcionárias do setor alvo da melhoria;
o Treinamento: conforme a inserção de novos requisitos era necessário um treinamento
das funcionárias com a ferramenta para execução e testes dos procedimentos e tarefas
da maneira correta.
A equipe formada para a execução deste projeto contava com: a autora e a orientadora
deste trabalho, um membro da Alta Direção, o responsável pelo fechamento financeiro da
empresa, um funcionário de Sistemas, e as três funcionárias do processo de Faturamento.
Com relação aos riscos, elencou-se que a disponibilidade e comprometimento dos
colaboradores em desempenhar as atividades propostas eram os aspectos mais latentes. As ações
tomadas para mitigar tais riscos foram: conscientização da importância do projeto a ser
realizado com relação aos resultados e objetivos pretendidos e estabelecimento da participação
de cada membro da equipe conforme demanda e andamento do projeto com o intuito de não
impactar negativamente nas outras atividades desempenhadas pelos colaboradores.
Como forma de incentivo e parte do desenvolvimento do projeto, após o
desenvolvimento de um dos requisitos, este era testado junto aos colaboradores, tanto para
efeito de melhoria rápida quanto para demonstrar como mudança traria resultados benéficos a
todas as partes envolvidas. Além disso, foi definido que a autora acompanharia o
desenvolvimento de melhoria junto as funcionárias, desta forma, a autora permaneceu no
ambiente de trabalho do processo de Faturamento durante todo o projeto.
4.2.2.2 Analisar a Situação Atual
Fundamentado no diagnóstico inicial, a análise da situação atual se preocupou
primordialmente em mapear o processo de tirar as notas do especial e sua interação com o
sistema (modelo “as-is”), além das atividades necessárias para a execução correta do
procedimento.
Para o mapeamento do processo foram feitas entrevistas com as funcionárias do setor e
outros funcionários que possuem contato direto com o trabalho desenvolvido pelo processo de
Faturamento e/ou são influenciados por ele – o responsável pelo fechamento financeiro e a
gestora da empresa (Apêndice B – Protocolo Análise da Situação Atual).
Além disso, foram feitas observações através do acompanhamento direto da autora
dentro do ambiente de trabalho das funcionárias, com relação às atividades executadas. Este
acompanhamento direto foi proporcionado pelo fato que a autora trabalhava junto às
36
funcionárias no mesmo ambiente, isto serviu para fortalecer o comprometimento com o projeto,
desenvolver a empatia e a confiança necessárias e levantar diversos aspectos por meio de
observações e relatos da relação funcionárias-processo-sistema que não seriam obtidos por meio
de aplicação de questionários. Tanto as entrevistas quanto as observações se preocuparam em
avaliar as entradas, atividades desempenhadas, recursos necessários, saídas e aspectos mais
sensíveis como dificuldade, sequenciamento e habilidade. Com relação a dinâmica de trabalho,
a funcionária designada para a função de tirar as notas do especial, diariamente emitia uma
listagem que continha os dados relevantes à emissão da nota: preço unitário, quantidade de
monitores enviados, valor total (preço vezes quantidade) e a descrição da observação especial
que explicitava as análises e/ou procedimentos que precisavam ser feitos. Esta descrição era
alimentada no banco de dados no momento do agendamento da nota.
Para entender o funcionamento do campo de observação especial e buscar agrupá-lo de
acordo com similaridades ou padrões de ocorrências com o propósito de encontrar necessidades
e traçar requisitos desejáveis para o bom andamento das atividades, foi feita uma análise extensa
do banco de dados de notas agendadas de modo a classificá-las. As principais observações desta
análise são:
o A emissão de notas possuía dois picos: o primeiro dia útil do mês (aproximadamente
60% das notas agendadas) e próximo ao dia 16 (aproximadamente 30% das notas
agendadas) – o restante era dividido nos outros dias. Estes picos acompanham o
funcionamento da empresa que possui duas remessas de envio de monitores para o
cliente: dia primeiro (a ser usada do primeiro ao ultimo dia do mês) e dia 16 (a ser usada
do dia 16 do mês até o dia 15 do mês subsequente);
o As notas consideradas especiais correspondem a aproximadamente 50% do total e se
distribuem de acordo com o padrão da emissão;
o A partir da análise feita no campo de observação especial estabeleceu-se que as
categorias mais recorrentes eram: quantidade e solicitados (as notas solicitadas eram
referentes a contratos que solicitavam o serviço conforme demanda normalmente este
tipo de contrato é reservado às escolas profissionalizantes, uma vez que há períodos que
estas instituições não precisam da realização do serviço) e exigência de documentação;
o A categoria por quantidade e solicitados correspondem às notas que precisam de uma
verificação associado a quantidade enviada de monitores ao cliente no mês de
referência. O faturamento a ser executado corresponde a quantidade exata enviada em
um dado período, o mesmo ocorre para os clientes solicitados, entretanto este envio de
remessa está sujeita a uma solicitação por parte do cliente.
o As observações que exigiam documentação eram de dois tipos: documentos necessários
da empresa prestadora a serem encaminhados junto a nota fiscal para confirmação da
prestação do serviço e documentos fornecidos pelos clientes relativos a autorização da
emissão da nota. Normalmente os clientes que emitem esta autorização são órgãos
públicos.
o Constavam anotações relativas a valores de acréscimo ou decréscimo no valor total de
acordo com negociação feita com o cliente ou outros serviços (como segunda via de
relatório) e informações de correção de impostos a ser deduzido corretamente da nota a
ser emitida.
Os problemas e as limitações encontradas foram:
o Para iniciar o procedimento de tirar as notas do especial era emitida uma listagem com
o resumo do agendamento e a descrição do especial, e esta listagem apresentava uma
37
difícil visualização dos dados e gerava um gasto excessivo de material para a
impressão;
o No resumo do agendamento presente na listagem eram informados a quantidade
enviada e o valor total, entretanto no sistema era necessário digitar ambos os campos
para a correta emissão da nota. O mesmo acontecia para acréscimo e decréscimos, que o
sistema não computava este valor no valor total. Assim funcionárias realizavam a
operação matemática em um ambiente separado e incluíam o valor total no sistema;
o O sistema calculava os impostos de acordo com a porcentagem estipulada, porém caso
fosse necessário alguma modificação como não cobrar um determinado imposto, por
exemplo, era necessário apagar o valor do sistema;
o O envio de documentos para o cliente era feito em um e-mail separado após a emissão
da nota. Assim o cliente recebia um e-mail enviado pela prefeitura e outro com os
documentos solicitados.
O processo descrito encontra-se modelado na Figura 12.
Além disso, as funcionárias executavam uma atividade paralela de verificação. Ao final
do mês, era conferido nas agendas de notas classificadas como solicitadas ou quantidade, se
tinha ocorrido algum envio durante o mês de referência que não foi contemplado na nota
anterior, se este envio ocorria após a data de emissão da nota ainda para aquele mês de
referência. Caso fosse verificado tal envio, era incluída a informação no campo de observações
especiais da próxima nota com a quantidade a ser cobrada a mais. As funcionárias
denominavam este processo como “fora do período”.
Os principais erros ocorriam por duplicidade ou erro de valores o que acarretava em
necessidade de cancelamento da nota. A causa desses erros era principalmente a inserção de
números calculados à parte do sistema.
Para uma análise completa da situação, as necessidades e impressões obtidas pelas
entrevistas e observações foram sumarizadas em um Mapa de empatia com o intuito de registrá-
las, organizá-las e transmiti-las às etapas seguintes. Este mapa apresentado na Figura 13 foi
usado para lembrar e transmitir as informações relativas às observações, entrevistas e relatos do
contato diário da autora com as funcionárias de aspectos qualitativos referente a experiência e a
sensação das funcionárias com o processo alvo, tais informações foram usadas posteriormente
para criar empatia no restante da equipe durante o desenvolvimento do projeto.
38
Figura 12 - Processo tirar do especial
Fonte: a autora
39
Figura 13 - Mapa da Empatia
Fonte: a autora
De acordo com as atividades executadas, pela presença da autora junto as funcionárias
na sala de trabalho foi possível perceber que a maior dificuldade das funcionárias do
Faturamento era que elas não se sentiam confiantes para executar seu trabalho com acuracidade
dada a complexidade das informações.
Por se tratar de um trabalho no campo financeiro, as funcionárias sentiam a pressão de
executar o trabalho assertivamente, isto era expresso pelos relatos feitos nas entrevistas, a
conferência de grande parte do trabalho executado e das observações diretas realizadas. Não
havia componentes à prova de erro no sistema, o que delegava à elas toda a responsabilidade da
acuracidade da execução, isto é exemplificado pelo fato de que as funcionárias inseriam os
valores nos campos delimitados, não havia uma computação automática.
Ademais, as funcionárias apontaram sugestões iniciais de ideias que simplificariam
substancialmente suas atividades como conter as informações necessárias para não terem que
realizar diversas consultas no sistema em outros módulos. A principal contribuição deste mapa
foram relativa as Dores de limitação do sistema, inserção manual de informações e grande
quantidade de tarefas extras manuais; estas Dores são o ponto chave do Diagnóstico na
integração das duas abordagens, pois este é o direcionamento que o envolvimento do usuário
transmite ao projeto de melhoria BPM.
4.2.2.3 Projetar a Situação Futura
A partir do diagnóstico mais detalhado realizado na fase anterior, foi iniciada a etapa de
projeção do sistema futuro (“to-be”). Para isto foi envolvido de forma mais atuante o
funcionário de Sistemas responsável pelo desenvolvimento do novo sistema interno em
40
linguagem Delphi, uma linguagem mais nova. A participação da autora foi essencial para
transmitir o diagnóstico realizado e as necessidades e sugestões feitas pelas funcionárias do
setor de Faturamento.
Para transmitir todas as necessidades de forma a transformá-las em requisitos foi
empregada a ferramenta User Stories. Primeiramente foi feita uma transcrição das stories para
cada um dos atores principais do processo entrevistado: funcionárias do setor descritas como
operadores do sistema, responsável pelo fechamento financeiro e gestora. A autora incluiu suas
stories por entender que detinha informações, observações e ideias oriundas de suas impressões
(muitas inclusive presentes no mapa de empatia). Na aplicação da ferramenta a autora se
denominou como analista de sistema. As stories são apresentadas na Figura 14 numeradas de
acordo com o usuário descrito.
Para as funcionárias do Faturamento (operadoras do sistema) as stories descreviam as
necessidades e dores relatadas, ponto de partida do desenvolvimento da melhoria focado no
envolvimento destas funcionárias. As necessidades são relacionadas à disponibilidade das
informações, há fatores de soma, subtração e correção que poderiam ser feitos automaticamente
pelo sistema e mecanismos de controle de outras atividades executadas como a emissão de
documentos.
Para o gestor e o responsável pelo fechamento financeiro, a necessidade alinhada ao
objetivo estratégico da organização é a redução de erros para evitar o cancelamento das notas
fiscais. Por fim, as impressões obtidas deste contato direto e das observações foram expressas
como necessidades identificadas pela autora de melhoria no sistema e usabilidade.
Para a apresentação do diagnóstico da situação atual foi realizado um evento com o
funcionário de Sistemas, a autora e a orientadora deste trabalho. A primeira parte foi uma
apresentação do processo detalhado pela modelagem, cujo desenho serviu como plano de fundo
para as discussões que ocorreram. Conforme as stories eram apresentadas, era feito um debate
acerca da importância de tal necessidade e como as informações envolvidas estavam
armazenadas nos diferentes bancos de dados. As Stories estão presentes na Figura 14.
A partir das necessidades provenientes das funcionárias, gestora, responsável pelo
fechamento e da autora foram discutidas e formalizadas ideias a serem implementadas como
requisito. Ressalta-se a integração das abordagens BPM e UCD nesta fase, pois a partir das
necessidades identificadas com o envolvimento dos usuários foi feito o direcionamento dos
requisitos a serem implementados no projeto de melhoria BPM.
41
Figura 14 - User Stories
IDU
suárioStory
1.0O
perador do sistema
Como operador do sistem
a quero que o sistema m
e forneça subsídios necessários para facilitar meu trabalho
1.1O
perador do sistema
Como operador do sistem
a quero que as informações essenciais do m
eu cliente tenham fácil acesso a fim
de agilizar a operação
1.2O
perador do sistema
Como operador do sistem
a quero ser informado do que precisa ser cobrado "fora do período" para não conferir todas as instituições
1.3O
perador do sistema
Como operador de sistem
a quero que o sistema com
pute automaticam
ente acréscimo ou decréscim
o de valor para evitar erros
1.4O
perador do sistema
Como operador do sistem
a quero que o sistema calcule de form
a automátiva o valor total de acordo com
a quantidade porque isso evita erros de valores
1.5O
perador do sistema
Como operador do sistem
a quero que as quantidades não apareçam duplicadas para a em
issão correta
1.6O
perador do sistema
Como operador do sistem
a quero que a forma de consultar as inform
ações necessárias seja facilitada para evitar erros
1.7O
perador do sistema
Como operador do sistem
a quero o sistema m
e ajude a gerenciar os documentos a fim
de que as NFs saiam
corretamente
1.8O
perador do sistema
Como operador do sistem
a quero que as notas com condições especiais só saiam
com a devida autorização para evitar erros
2.0G
estorCom
o gestor quero reduzir os erros para melhor funcionam
ento da empresa
2.1G
estorCom
o gestor quero reduzir o cancelamento de N
Fs por informações erradas um
a vez que isto gera custo à empresa
2.2G
estorCom
o gestor quero um controle e eficiência m
aior na emissão dos especiais para evitar erros
3.0Responsável pelo fecham
entoCom
o responsável pelo fechamento financeiro quero reduzir os erros e reagendam
entos a fim de garantir um
correto fechamento financeiro
3.1Responsável pelo fecham
entoCom
o responsável pelo fechamento financeiro quero m
inimizar o reagendam
ento de NFs para correto fecham
ento financeiro
3.2Responsável pelo fecham
entoCom
o responsável pelo fechamento financeiro quero que o im
posto seja deduzido corretamente para a correta relação no final do m
ês
4.0A
nalista de sistema
Como analista de sistem
a quero melhorar o sistem
a para facilitar o trabalho das funcionárias
4.1A
nalista de sistema
Como analista de sistem
a quero que o sistema inform
e na tela a quantidade e o total a ser cobrado a fim de agilizar o processo
4.2A
nalista de sistema
Como analista de sistem
a quero que tenha um cam
po para acréscimo e decréscim
o para evitar correções
4.3A
nalista de sistema
Como analista de sistem
a quero agrupar documentos para enviar a fim
de simplificar o envio de docum
entos
4.4A
nalista de sistema
Como analista de sistem
a quero que os documentos sejam
enviados automaticam
ente para agilizar o processo
5.0A
nalista de sistema
Como analista de sistem
a quero melhorar a usabilidade do sistem
a para facilitar a interação e melhorar a eficiência
5.1A
nalista de sistema
Como analista de sistem
a quero que a disposição da tela seja de forma a facilitar o uso
5.2A
nalista de sistema
Como analista de sistem
a quero que os campos sejam
dispostos de forma a deixar o processo m
ais intuitivo
42
Na evolução das ideias (Figura 15) foi considerado o que era necessário para
desempenhar tal necessidade e o que isto exigiria de alteração no sistema, por exemplo, para
evitar erros que era uma necessidade principal para a gestora e o responsável pelo fechamento
financeiro foi pensado que as informações precisariam estar disponíveis e centralizadas para a
correta análise crítica. Para que as informações estivessem centralizadas foi formulada a ideia de
agrupar as funcionalidades em uma única tela de edição com botões para cada uma das
operações específicas realizadas apresentadas na modelagem da Figura 12.
Alguns requisitos atendiam mais de uma necessidade expressa por diferentes usuários,
esta gestão geral dos requisitos e de como conseguiriam atender diferentes dores e expectativas
foi possibilidade pelo uso da ferramenta User Stories.
Figura 15 - Relação necessidades identificadas com requisitos
Fonte: a autora
4.2.2.4 Implementar a Mudança
A mudança para o processo “to-be” foi realizada de forma gradual como planejado para
que os colaboradores pudessem desempenhar os testes de usabilidade necessários de maneira a
não impactar em suas atividades diárias. Nesta fase, a participação da autora foi essencial para
conduzir as informações de um processo ao outro relativo à realização e aos resultados dos
testes.
Por se tratar da emissão de um documento fiscal gerado junto a prefeitura municipal,
era necessário que a nota fosse emitida e conferida logo em seguida, pois caso fosse identificada
a necessidade de cancelamento, este pudesse ser feito dentro do tempo hábil de 24 horas após a
emissão. Para estes testes, foram escolhidos dias diferentes do pico de emissão de notas, com o
propósito de facilitar esta verificação.
43
Os testes de usabilidade foram conduzidos por meio de um piloto (protótipo) que
constituía de uma tela (Figura 16) em que os requisitos foram desenvolvidos separadamente.
Cada requisito foi desenvolvido e testado individualmente, no sentido de menor para maior grau
de complexidade. Isto foi feito como forma de garantir que as etapas desenvolvidas
anteriormente estivessem em plenas condições de funcionamento e agregavam em operações
disponíveis para desenvolver soluções de requisitos ditos mais complexos.
As funcionárias relatavam as dificuldades, validavam as operações e sugeriam
alterações após cada teste realizado. Estas considerações retornavam ao setor de Sistemas que
fazia as alterações necessárias e retornava para um novo teste, constituindo assim um ciclo
iterativo de desenvolvimento contínuo da melhoria.
44
Figura 16 - Tela do software
Fonte: a autora
45
4.2.2.5 Validar a Mudança
Para a fase de validação do projeto de melhoria tendo em vista os objetivos traçados de
aumento da eficiência e eficácia por meio de agilidade das tarefas e acuracidade da execução
foram feitas três análises: uma análise geral da solução contrapondo os requisitos com o que foi
desenvolvido, uma análise das tarefas para verificar como a mudança impactou na forma de
fazer, e uma análise de usabilidade feita por meio de uma entrevista par avaliar o software em
si.
A) Análise da Solução
De acordo com a tela desenvolvida (Figura 16) para o processo de tirar as notas do
especial, foram feitas as seguintes operações: de acordo com o dia selecionado (1), que
corresponde à data agendada ou atualizada caso a nota ainda não tenha sido emitida, é mostrado
todas as notas a serem emitidas nesta data (2). O resumo das notas a serem emitidas (2) possui:
código do cliente, nome da instituição, motivo (descrição do campo especial), data de emissão,
número da parcela, vencimento da parcela de acordo com o agendamento, quantidade agendada,
valor líquido e valor dos impostos.
Ao selecionar uma das notas, de forma automática, aparece o que está descrito no corpo
da nota (3), as notas fiscais anteriores emitidas de forma resumida com permissão para o acesso
(em PFD da nota) (4), além de outras informações agendadas como: o valor unitário,
quantidade, valor total, valor dos impostos e valor líquido. De acordo com o que é necessário
alinhado à descrição do campo observação especial, utiliza-se os campos (5) para adicionar
documentos a serem enviados no mesmo e-mail que a nota fiscal. É possível visualizar os
envios para o código selecionado e determinar qual a quantidade a ser cobrada (6), somar ou
subtrair valores (7) e alterar o valor dos impostos (8). Qualquer alteração feita que impacte na
mudança do valor líquido final é calculada automaticamente pelo programa (9).
A atividade denominada de fora do período se tornou uma análise, em que a partir das
informações disponíveis e agrupadas na tela, como resumo dos envios para a instituição (data e
quantidade) e acesso as notas fiscais anteriores, é possível decidir se houve envio fora do
período, se é necessário realizar a cobrança na nota fiscal atual e no momento executar todos os
procedimentos para que esta nota seja emitida corretamente. Na Tabela 2 está associado os
requisitos gerados no item 4.2.2.3 Projetar a Situação Futura e parte da solução desenvolvida
expressa na Figura 17.
46
Figura 17 - Tela com os princípios de solução
Fonte: a autora
47
Tabela 2 - Relação requisitos e princípios de solução
Requisito Solução
Presença de informações essenciais 2,3 e 4
Operações matemáticas automáticas 9
Mostrar relação de envio 6
Somar ou subtrair valores 7
Valor alterado conforme alteração da quantidade 6
Fácil visualização da correção de impostos 8
Controle dos documentos enviados 5
Alterar apenas o que for necessário 5, 6, 7 e 8
Autorização para prosseguir 10
B) Análise das tarefas
Com a institucionalização do software específico para o processo de tirar as notas do
especial, as atividades ficaram interligadas ao sistema. Entretanto, uma das preocupações foi
fornecer os subsídios necessários para que as funcionárias pudessem realizar suas análises
críticas com eficiência e eficácia. O maior ganho encontra-se no suporte e simplicidade desta
análise e a facilidade em alterar apenas o essencial para que esta nota saia corretamente, em
oposição ao sistema antigo que exigia passar por todas as etapas para finalizar o processo. A
Tabela 3 estabelece esta relação.
Tabela 3 - Relação processo novo e mudança
Processo Antigo Mudança
Imprimir listagem Resumo na tela
Buscar a nota no sistema Selecionar a nota desejada
Digitar quantidade e valores Selecionar envios para o período
Somar ou subtrair valores e incluir valor
total Digitar o valor a ser somado ou subtraído
Enviar email separado com os
documentos solicitados
Selecionar os documentos na emissão da nota, a
serem enviados posteriormente no mesmo e-mail da
nota fiscal
Conferir o que foi enviado com o que foi
cobrado nota a nota
Analisar os envios de acordo com o resumo dos
envios e as notas anteriores
Corrigir o valor dos impostos Selecionar a operação que deseja realizar relativa
aos impostos
Percorrer todas as etapas para salvar a
edição
Selecionar e alterar apenas o que é necessário para
aquela nota
O processo antigo exigia que se imprimisse uma listagem e a partir desta listagem se
localizassem as notas a serem feitas as modificações no processo de tirá-las do especial. As
modificações precisavam ser feitas de forma manual, muitas vezes somando ou subtraindo os
valores em um ambiente separado. Com a mudança de sistema, há um resumo da tela de todas
as notas especiais e para acessá-las basta clicar, eliminando a listagem e procura pela nota
específica. Além disso, acréscimo ou decréscimo de valores passou a ser feitos de forma
automática.
Todas as notas ainda são gravadas no banco de dados da empresa, e no processo
anterior era enviado um e-mail com o boleto relativo à nota; com a mudança, a empresa passou
a enviar o boleto e a nota (juntos) como garantia de envio ao cliente. Nos casos que a nota
exigia documentação, esta documentação era anexada no processo de tirar a nota do especial e
48
encaminhada no mesmo e-mail, reunindo assim todos os documentos pertinentes àquela nota em
um único e-mail.
A atividade do fora do período se tornou uma atividade de análise a ser realizada no
sistema e apenas o que exige alteração é modificado pelas funcionárias. Desta forma, o processo
se condensou em atividades executadas no sistema, muitas das quais são computadas
automaticamente, o que contribui significantemente para evitar erros e agilizar o processo como
um todo.
C) Análise da Usabilidade
Após o desenvolvimento final da solução foi realizada uma avalição da usabilidade
por meio de entrevistas relativas a oito tópicos relacionados: facilidade de uso, eficiência,
eficácia, conforto, correção de erros, disponibilidade das informações, aplicação das
informações e satisfação. A avaliação encontra-se na Tabela 4.
Tabela 4 - Avaliação tópicos de usabilidade
Tópicos de Análise Avaliação
Facilidade de uso
Eficiência
Eficácia
Conforto
Mensagens de erro
Disponibilidade das informações
Aplicação das informações
Satisfação
Com relação a facilidade de uso, as funcionárias relataram que consideram o sistema
fácil de usar. Entretanto, é necessário um conhecimento prévio do assunto e treinamento
adequado. Isto é influenciado pelo fato de que se trata da emissão de um documento fiscal
regido por normas e regras estabelecidas, sendo, portanto, necessário um conhecimento de como
e o que pode/deve ser feito. Comparativamente ao sistema antigo, as funcionárias informaram
que a facilidade aumentou significativamente.
O tópico de eficiência foi medido com relação a agilidade das tarefas. Contrastando
com o sistema anterior, a agilidade das tarefas aumentou. Porém, as funcionárias relataram que
o sistema exige uma análise crítica por parte delas, e esta análise ainda consome um tempo
considerável. Tal análise crítica é necessária para a correta emissão da nota, e foi melhorada
com base nas informações disponíveis. Para o tópico da eficácia, as funcionárias estabeleceram
uma relação positiva, pois com o novo sistema é possível encontrar todas as funções necessárias
para desempenhar suas atividades assertivamente.
As funcionárias do faturamento descreveram que se sentem confortáveis em utilizar o
sistema com base na organização da tela, inclusive gostam de executar as atividades no sistema.
Com relação a mensagens de erros, as funcionárias relataram que precisam recorrer ao auxilio
do funcionário do processo de Sistemas para corrigir os erros relacionados ao software, erros
relativos ao processo podem ser corrigidos por outros meios no sistema e muitos dos erros no
processo de tirar do especial são contidos pelo sistema, como por exemplo, cálculo do valor
final.
49
As funcionárias expuseram que é fácil encontrar e analisar as informações presentes no
sistema e que tal informação as ajuda a completar corretamente o trabalho desempenhado. Por
fim, em uma avaliação geral as funcionárias se sentem satisfeitas com a mudança e com o
sistema em si. Logo, com relação a usabilidade e aplicabilidade, a solução foi considerada
satisfatória.
4.3 Avaliação do processo de melhoria e das ferramentas
O processo de melhoria descrito no estudo de caso deste trabalho apresentou uma
integração entre as ferramentas de UCD e a abordagem BPM. Com relação a hipótese 1 relativa
a adequação das ferramentas ao projeto, a ferramenta Mapa da Empatia serviu como mecanismo
de organização para critérios qualitativos obtidos por meio das entrevistas, mas principalmente
por meio da observação da autora em relação as atividades desempenhadas. Esta empatia serviu
junto com a modelagem do processo (característica presente nos ciclos BPM) como plano de
fundo para todas as fases desenvolvidas bem como as ferramentas empregadas.
A ferramenta User Stories utilizada entre a autora, a orientadora e o funcionário de
Sistemas foi essencial para a condução da solução de acordo com os requisitos levantados a
partir das necessidades identificadas, isto é, tal ferramenta foi adequada para transmitir as
necessidades e direcionar a solução final posterior. Os testes de usabilidade aliados ao protótipo
(tela) foram essenciais para que as funcionárias pudessem entender o processo de forma mais
ampla e identificar critérios a serem melhorados e/ou mudados.
O papel das ferramentas de UCD em envolver os usuários dentro das fases do ciclo
BPM foi satisfatório, à medida que o envolvimento levou a ideias e conceitos que sem as
ferramentas não seria possível e o ciclo BPM coordenou o envolvimento para que a melhoria
fosse desenvolvida e institucionalizada adequadamente.
Com relação a hipótese 2 sobre a percepção dos usuários acerca do envolvimento, as
funcionárias relataram que se sentiram envolvidas durante o projeto, ou seja, acreditam que suas
opiniões foram ouvidas e transformadas em melhorias desde o inicio do desenvolvimento do
projeto. A Alta Direção avaliou que este envolvimento foi essencial para a melhoria
desempenhada e o funcionário de sistemas acredita que sem esta participação efetiva o sistema
não teria as características finais apresentadas, nem seria focado ao que as funcionárias
precisavam.
No envolvimento dos usuários, destaca-se a importância da intermediação da autora que
fez uso das ferramentas de UCD para possibilitar o envolvimento integrado ao ciclo BPM de
melhoria. A autora desempenhou papel principal para conduzir as análises e discussões e na
realização dos testes e entregas do projeto.
O envolvimento no ciclo BPM a partir das ferramentas UCD permitiu que as
funcionárias tivessem uma maior compreensão do processo, conseguissem estabelecer papeis e
responsabilidades com clareza e apresentasse ferramentas apropriadas ao trabalho (solução
final). Estes benefícios apoiados pelo desenvolvimento gradual do projeto, acompanhamento
diário da autora junto as funcionárias para instrução e treinamento adequado colaborou para que
a hipótese 3 relativa a menor resistência a mudança fosse considerada satisfatória.
Como toda a mudança, a incorporação da mudança na rotina do processo foi difícil
inicialmente, mas com o acompanhamento próximo, a percepção do envolvimento ativo por
meio das ferramentas e do retorno das sugestões em melhorias conduziu a assimilação do
50
projeto como algo a contribuir na melhora das atividades e isto tornou esta incorporação mais
fluida e natural.
4.4 Discussão do envolvimento do usuário
O ciclo do projeto de melhoria conjuntamente com as ferramentas proposto pode ser
replicado em diferentes empresas e negócios e é um importante recurso para conduzir melhorias
em processos. Este ciclo pode ser aplicado em projetos de baixa ou alta complexidade.
Para o estudo de caso, optou-se pela utilização das seguintes ferramentas de UCD:
Mapa da Empatia, User Stories, Protótipo e Teste de Usabilidade incorporadas no ciclo BPM
conforme Figura 18. O Mapa de Empatia foi escolhido por permitir organizar e relacionar
aspectos qualitativos de diferentes vertentes, mais explicita como relatos e mais subjetivas como
observações de comportamentos. A ferramenta User Stories foi eleita por ser amplamente
utilizada para a funcionalidade de transmitir necessidades em requisitos no desenvolvimento de
softwares, alvo do projeto descrito no estudo de caso. Por fim, as ferramentas protótipo e teste
de usabilidade foram utilizados por permitem um retorno rápido e direcionado no
desenvolvimento iterativo. As ferramentas foram escolhidas de forma a conciliar o que era
esperado ser desenvolvido em cada uma das fases do ciclo BPM.
Figura 18 - Inclusão das ferramentas de UCD no ciclo BPM
Fonte: Adaptado de Costa (2006)
51
A literatura de UCD apresenta diversas ferramentas com diferentes objetivos e
aplicações. A escolha entre as opções pode variar de acordo com alguns fatores como:
conhecimento prévio, disponibilidade de recursos e pessoas da organização, entre outros. A
Figura 19 estabelece uma sugestão de inclusão de ferramentas, de acordo com a sua
classificação, com base no ciclo selecionado. A inclusão de ferramentas pautadas no
envolvimento do usuário se dá por cumprir a lacuna presente na literatura em apontar como o
usuário, parte essencial no desenvolvimento de um projeto de melhoria, deve ser envolvido para
contribuir e apoiar o desenvolvimento em execução.
Figura 19 - Proposta de inclusão de ferramentas UCD de acordo com seu objetivo ao ciclo BPM
Fonte: Adaptado de Costa (2006)
Nesta proposta as ferramentas são integradas ao ciclo BPM durante a Etapa 2, por
entender que a etapa anterior (Etapa 1) corresponde a uma análise direcionada aos objetivos,
enquanto a Etapa 2 concretiza a mudança. Dependendo da complexidade do projeto e das
pessoas envolvidas, na fase Planejar a mudança pode ser necessário a utilização de ferramentas
de gerenciamento de projetos (que não foram abordadas neste trabalho), a utilização destas
ferramentas pode ser assunto de pesquisas futuras.
A fase Analisar a Situação Atual é a fase em que o envolvimento dos usuários
estabelece uma importante contribuição, pois se desde o início as necessidades, limitações e
sugestões dos usuários são ouvidas, a solução final tende a ser mais focada e dar mais valor a
estes usuários. Nesta fase, para envolver os usuários é preciso primeiro conhecê-los, para isso há
ferramentas disponíveis na literatura que se baseiam em identificar os usuários. Estes usuários
52
muitos vezes, são os atores do processo, mas é necessário que seja feita uma análise para
entender como outros usuários de outros processos influenciam o processo de negócio alvo.
Em seguida, incluir na análise da situação atual as necessidades, anseios e problemas do
usuário corrobora fortemente para um desenvolvimento com características da abordagem UCD,
pois utiliza estas informações para nortear as fases seguintes, quando corretamente transmitida.
A possibilidade de entrar em contato com os usuários permite que a equipe de desenvolvimento
da mudança crie empatia e tenha uma maior compreensão do processo.
Para a fase Projetar a Situação Futura sugere-se a utilização de ferramentas que
auxiliem na elicitação de requisitos, como forma de auxiliar na formulação do modelo “to be”.
As ferramentas com esta dimensão, normalmente precisam de uma entrada, na grande maioria
dos casos se utiliza entrevistas e observações, logo uma análise bem feita que contemple todos
os pontos importantes é essencial para o bom desempenho desta fase.
As fases Implementar a Mudança e Validar a Mudança recomenda-se o uso de
ferramentas de validação. Seguindo os preceitos de UCD, nestas fases é interessante utilizar
ferramentas que consigam validar ao mesmo tempo em que testem e assim, conseguem gerar
novas ideias, necessidades, conceitos e sugestões que podem ser incorporados ao
desenvolvimento, tornando-o mais iterativo e rápido.
A escolha das ferramentas está atrelada a necessidade do projeto. No presente trabalho,
optou-se pela utilização de algumas que foram julgadas mais pertinentes, porém é interessante
notar que a equipe é livre para fazer as escolhas que julgar necessário. Na Figura 19 há uma
sugestão do tipo de ferramenta ideal para cada fase.
53
5. Considerações finais
O presente trabalho apresentou a integração entre as abordagens BPM e UCD, de forma
geral o envolvimento do usuário em um ciclo BPM contribui para resultados mais pertinentes
por desde o inicio do desenvolvimento direcionar a solução ao que o usuário realmente precisa
e/ou considera valoroso.
Para a fase inicial, de análise da situação e levantamento das informações, recomenda-
se o uso de ferramentas que permitam uma identificação clara dos usuários (atores do processo e
outras pertinentes a análise) envolvidos e ferramentas que auxiliem a identificar as necessidades
destes usuários. Com isso, espera-se um desenvolvimento desde o começo focado no real
problema e necessidade das pessoas envolvidas e o recolhimento de informações importantes a
serem usadas nas fases seguintes.
Para a fase de projeção da situação futura, recomenda-se o uso de ferramentas que
permitam trabalhar as necessidades encontradas e analisadas em requisitos da solução. Ao se
considerar dados provenientes de usuários para construir a solução, aumentam-se muito as
chances de se desenvolver algo que corresponda uma melhoria real. Por outro lado, isto exige
um conhecimento e recursos empregados para ser feito com excelência.
Nas fases de implementação e validação, sugere-se o uso de ferramentas que consigam
testar e validar e durante este processo, recolher informações que possam ser usadas para
incrementar a solução. A solução final desenvolvida fica mais robusta, à medida que novos
conceitos são incrementados com base em análises conduzidas com princípios de solução. Estas
ferramentas exigem recursos tanto humanos para testar e analisar os testes, quanto um
desprendimento organizacional para garantir meios adequados para conduzir estes testes.
Ao final do desenvolvimento da melhoria com a participação dos usuários, a
incorporação da mudança é feita de forma mais natural e fluida na organização, por apresentar
algo que se originou das sugestões, opiniões e necessidades dos usuários e por ser feito um
trabalho em conjunto de forma gradual em cada uma das fases do ciclo de melhoria.
A integração destas duas abordagens (BPM e UCD) contribui desenvolver projetos de
melhoria de forma mais completa e que retorne real valor às partes interessadas. Esta integração
pode ser replicada em outras empresas e em projetos de diferentes segmentos.
O caso apresentado neste trabalho possui a limitação de ser um caso em único em uma
pequena empresa. Contudo, isto não afeta o resultado encontrado que pode ser generalizado e
aplicado em diversas organizações. Isto corresponde aos próximos passos do estudo, aplicação
desta proposta tanto em empresas de ramos diferentes quanto com a utilização de diferentes
ferramentas de UCD e o e estudo de como as ferramentas de Gerenciamento de Projetos podem
ser incorporadas em projetos de melhorias BPM de diferentes complexidades.
54
6. Referências ABPMP. (2013). Guia para o Gerenciamento de Processos de Negócio - Corpo Comum de
Conhecimento (BPM CBOK).
Abras, C., Krichmar, D. M., & Preece, J. (2004). User-Centered Design. In Encyclopedia of Human-
Computer Interaction (pp. 1–14).
Alexander, I. A. N., & Maiden, N. (2004). Scenarios, stories, use cases. (I. A. N. Alexander & N.
Maiden, Eds.). England: John Wiley &Sons Ltd.
Antonucci, Y. L., & Goeke, R. J. (2011). Identification of appropriate responsibilities and positions for
business process management success: Seeking a valid and reliable framework. Business Process
Management, 17(1), 127–146. http://doi.org/10.1108/14637151111105616
Armistead, C., Pritchard, J., & Machin, S. (1999). Strategic Business Process Management for
Organisational Effectiveness. Long Range Planning, 32(1), 96–106.
Baldam, R., Valle, R., & Rozenfeld, H. (2014). Gerenciamento de processos de negócios - BPM: uma
referência para implantação prática. 1 edição. Rio de Janeiro: Elsevier.
Bogers, M., & Horst, W. (2014). Collaborative Prototyping : Cross-Fertilization of Knowledge in
Prototype-Driven Problem Solving *. Product Development & Management Association, 31(4),
744–764. http://doi.org/10.1111/jpim.12121
Campese, C., & Costa, J. M. H. da. (2017). Métodos: Mapa de Empatia. In Envolvimento do Usuário no
Desenvolvimento de Produtos Eletromédicos (pp. 13–18).
Campese, C., Scatolin, J. L., Esposto, R. F. S., & Costa, J. M. H. da. (2015). ESTUDO DOS MÉTODOS
DE UCD. In 10o Congresso Brasileiro de Gestão da Inovação e Desenvolvimentos de Produtos (pp.
1–12). Itajubá - MG.
Carpinetti, L. C. R. (2016). Gestão da Qualidade: conceitos e técnicas. São Paulo: Atlas.
Chen, K., & Chou, W. (2013). Emotional Experience and Interactive Design in the Workplace. In
Springer-Verlag Berlin Heidelberg (pp. 446–454).
Cimino, M. G. C. A., Palumbo, F., Vaglini, G., Ferro, E., Celandroni, N., La, D., … Workflow, Á.
(2017). Evaluating the impact of smart technologies on harbor’s logistics via BPMN modeling and
simulation. Information Technology and Management, 18(3), 223–239.
http://doi.org/10.1007/s10799-016-0266-4
Cohn, M. (2004). User Stories Applied: For Agile Software Development. Addison Wesley.
Costa, J. M. H. da. (2006). Proposta de uma Metodologia de Gestão de Mudanças: aplicação em uma
empresa desenvolvedora de software.
Dijkman, R., Dumas, M., van Dongen, B., Kaarik, R., & Mending, J. (2011). Similarity of Business
Process Models : Metrics and Evaluation. Informations Systems, 36(2), 498–516.
Dijkman, Dumas, & Ouyang. (2008). Semantics and analysis of business process models in BPMN.
Information and Software Technology, 50(12), 1281–1294.
http://doi.org/10.1016/j.infsof.2008.02.006
Echeveste, M., Amaral, C. S. T., & Rozenfeld, H. (2007). A support tool for the selection of statistical
techniques for industrial product development and improvement processes. In Complex Systems
Concurrent Engineering: Collaboration, Technology Innovation and Sustainability (pp. 247–255).
http://doi.org/10.1007/978-1-84628-976-7
Gulliksen, J., & Göransson, B. (2001). Reenginering the System Development Process for User Centred
Design.
55
Gulliksen, J., Göransson, B., Boivie, I., Blomkvist, S., Persson, J., & Cajander, Å. (2003). Key Principles
for User-Centred Systems Design.
Hall, R. R. (2001). Prototyping for usability of new technology. Human-Computer Studies, 1(55), 485–
501. http://doi.org/10.1006/ijhc.2001.0478
Hallerbach, A., Bauer, T., & Reichert, M. (2008). Managing process variants in the process life cycle. In
Proceedings of the 10th International Conference on Enterprise Information Systems (Vol. 2, pp.
154–161). Retrieved from http://www.scopus.com/inward/record.url?eid=2-s2.0-
55849084721&partnerID=40&md5=05d56a703ca0fe2bd33e2f1507cbdb82
Houy, C., Fettke, P., & Loos, P. (2010). Empirical research in business process management – analysis of
an emerging field of research. Business Process Management Journal, 16(4), 619–661.
http://doi.org/10.1108/14637151011065946
Hung, R. Y. (2006). Business Process Management as Competitive Advantage : a Review and Empirical
Study. Total Quality Management, 17(1), 21–40. http://doi.org/10.1080/14783360500249836
Leffingwell, B. D., & Behrens, P. (2010). By Dean Leffingwell with Pete Behrens, 1–16.
Lewis, J. R. (1993). IBM Computer Usability Satisfaction Questionnaires : Psychometric Evaluation and
Instructions for Use. International Journal of Human-Computer Interaction, 7(1), 57–78.
http://doi.org/10.1080/10447319509526110
Maddern, H., Smart, P. A., Maull, R. S., & Childe, S. (2014). End-to-end process management:
implications for theory and practice. Production Planning & Control, 25(16), 1303–1321.
http://doi.org/10.1080/09537287.2013.832821
Morais, R. M. de, Kazan, S., Pádua, S. I. D., & Costa, A. L. (2014). An analysis of BPM lifecycles: from
a literature review to a framework proposal. Business Process Management Journal, 20(3), 412–
432. http://doi.org/10.1108/BPMJ-03-2013-0035
Norman, D. A. (1986). Cognitive Engineering. In D. A. Norman & S. W. Draper (Eds.), User-Centered
System Design: New Perspectives on Human-Computer Interaction (pp. 32–61). Hillsdale, NJ:
Lawrence Earlbaum Associates.
Oglio, P. D. (2006). Uma Ferramenta para Gerenciamento de Requisitos em Projetos Baseados em
Extreme Programming. UNIVERSIDADE DO VALE DO RIO DOS SINOS.
Rees, M. J. (2002). A Feasible User Story Tool for Agile Software Development? In Proceedings of the
Ninth Asia-Pacific Software Enginerring Conference (APSEC’02) (pp. 0–8).
Rippon, S. (2006). Usability , user-centered design ( UCD ) and FOSS. In OSDC (pp. 1–11).
Rudd, J., & Isensee, S. (1991). Twenty-two Tips for a Happier , Healthier Prototype. Proceedings of the
Human Factors Society, 328–331.
Schein, E. H. (2002). Models and Tools for Stability and Change in Human Systems. Reflections, 4(2),
34–46.
Segatto, M., Pádua, S. I. D. de, & Martinelli, D. P. (2013). Business process management : a systemic
approach ? Business Process Management, 19(4), 698–714. http://doi.org/10.1108/BPMJ-Jun-2012-
0064
Shenhar, A. J., Dvir, D., Levy, O., & Maltz, A. C. (2002). Project Success : A Multidimensional Strategic
Concept. Long Range Planning, 34(2001), 699–725.
Smart, P. A., Maddern, H., & Maull, R. S. (2009). Understanding Business Process Management :
Implications for Theory and Practice. British Journal of Management, 20, 491–507.
http://doi.org/10.1111/j.1467-8551.2008.00594.x
Trkman, P. (2010). The critical success factors of business process management. International Journal of
Management, 30, 125–134. http://doi.org/10.1016/j.ijinfomgt.2009.07.003
56
Trkman, P., Mertens, W., Viaene, S., & Gemmel, P. (2015). From business process management to
customer process management Article information : Business Process Management, 21(22), 250–
266. http://doi.org/10.1108/BPMJ-02-2014-0010
van der Aalst, W. M. P. (2004). Business Process Management: A personal view. Business Process
Management Journal, 10(2), 248–253.
Voss, C., Tsikriktsis, N., & Frohlich, M. (2002). Case research in operations management. International
Journal of Operations & Production Management, 22(2), 195–219.
http://doi.org/10.1108/01443570210414329
Vredenburg, K., Mao, J.-Y., Smith, P. W., & Carey, T. (2002). A Survey of User-Centered Design
Practice. Design Methods, 4(1), 471–478.
Zairi, M. (1997). Business process management : a boundaryless approach to modern competitiveness.
Business Process Management, 3(1), 64–80.
zur Muehlen, M., & Ho, D. T.-Y. (2006). Risk Management in the BPM Lifecycle. In C. Bussler et al.
(Eds.): BPM 2005 Workshops, LNCS 3812, (pp. 454–466). http://doi.org/10.1007/11678564_42
57
7. Apêndices
Apêndice A – Protocolo Diagnóstico
Pe
rgun
ta da P
esq
uisa
Ob
jetivo
Me
tasV
ariáveis
Valo
res assu
mid
os p
elas variavé
isR
esp
on
de
nte
sQ
ue
stõe
s
Co
mo
é o
trabalh
o q
ue
voce
exe
cuta?
O q
ue
este
trabalh
o e
xige?
É um
trabalh
o q
ue
de
man
da m
uito
tem
po
? Po
r qu
ê?
O q
ue
você
acha q
ue
mais d
ificulta o
seu
trabalh
o?
O q
ue
você
con
side
ra ser m
ais imp
ortan
te n
o se
u trab
alho
?
Qu
al (is) o(s) p
roce
sso(s) vo
cê e
xecu
ta?
Co
mo
é a su
a rotin
a?
Qu
ais info
rmaçõ
es vo
cê p
recisa? D
e o
nd
e ve
m e
stas info
rmaçõ
es?
De
form
a geral, o
qu
e vo
cê ach
a mais d
ifícil?
Qu
ais são as tare
fas qu
e vo
cê faz?
Co
mo
você
as exe
cuta?
Do
qu
e vo
cê d
ep
en
de
para e
xecu
tá-las?
O q
ue
dificu
lta a exe
cução
das tare
fas?
O q
ue
facilita a exe
cução
das tare
fas?
Qu
al é o
resu
ltado
final d
o p
roce
sso? C
om
o p
recisa se
r?
Qu
al seu
maio
r me
do
ou
rece
iro ao
exe
cutar e
ste trab
alho
?
O q
ue
você
esp
era atin
gir com
este
trabalh
o?
Pe
nsan
do
nas se
nsaçõ
es, ap
ós fin
alizar o trab
alho
. O q
ue
você
citaria?
Na su
a op
inião
, o q
ue
mais im
pacta o
seu
trabalh
o?
De
form
a geral, o
qu
e vo
cê m
ud
aria?
Na su
a op
inião
, o q
ue
é m
ais urge
nte
na e
xecu
ção d
este
trabalh
o e
ne
cessita d
e u
ma ate
nção
esp
ecial?
De
form
a geral, co
mo
o Fatu
rame
nto
imp
acta no
seu
trabalh
o?
Caso
estas in
form
açõe
s ven
ham
inco
mp
letas o
u e
rradas, o
qu
e
isso o
casion
a no
seu
trabalh
o?
Qu
ais info
rmaçõ
es vo
cê p
recisa p
ara exe
cutar su
as atividad
es q
ue
vem
do
Faturam
en
to?
Co
mo
o an
dam
en
to d
o Fatu
rame
nto
imp
acta as ou
tras atividad
es
da e
mp
resa?
De
acord
o co
m as su
as resp
on
sabilid
ade
s, o q
ue
você
esp
era e
m
relação
a exe
cução
do
trabalh
o n
o Fatu
rame
nto
?
Co
m u
ma visão
mais am
pla, q
ual o
ob
jetivo
qu
e vo
cê traçaria p
ara
o se
tor d
e Fatu
rame
nto
?
Na su
a op
inião
, o q
ue
pre
cisa ser m
ud
ado
? O q
ue
é m
ais urge
nte
?
Fun
cion
árias
Faturam
en
to
Ide
ntificar o
s
pro
cesso
s
De
scritiva qu
alitativa
(pe
rgun
tas e re
spo
stas
com
o u
suário
)
Texto
com
os tó
pico
s de
critério
s
relacio
nad
os ao
pro
cesso
Fun
cion
árias
Faturam
en
to
Ente
nd
er o
trabalh
o
do
seto
r
De
scritiva qu
alitativa
(pe
rgun
tas e re
spo
stas
com
o u
suário
)
Texto
com
os tó
pico
s de
critério
s
relacio
nad
os ao
trabalh
o
Texto
com
os tó
pico
s de
critério
s
relacio
nad
os ao
seq
ue
nciam
en
to
do
pro
cesso
Fun
cion
árias
Faturam
en
to
Qu
ais são o
s fatore
s
relacio
nad
os a
pe
rcep
ção e
exp
eriê
ncia
do
usu
ário co
m re
lação
ao p
roce
sso?
Ide
ntificar
ne
cessid
ade
s,
de
sejo
s e
com
po
rtame
nto
s
do
s usu
ários
Ide
ntificar
imp
ressõ
es e
suge
stõe
s
De
scritiva qu
alitativa
(pe
rgun
tas e re
spo
stas
com
o u
suário
)
Texto
com
os tó
pico
s de
critério
s
relacio
nad
os a im
pre
ssõe
s e
suge
stõe
s
Fun
cion
árias
Faturam
en
to
Qu
ais são o
s fatore
s
relacio
nad
os ao
de
sem
pe
nh
o e
de
sen
volvim
en
to d
os
pro
cesso
s?
Ide
ntificar o
s
pro
cesso
s para
map
eá-lo
s
Ide
ntificar
seq
ue
nciam
en
to d
os
pro
cesso
s
De
scritiva qu
alitativa
(pe
rgun
tas e re
spo
stas
com
o u
suário
)
Ide
ntificar
exp
ectativas e
de
sejo
s
De
scritiva qu
alitativa
(pe
rgun
tas e re
spo
stas
com
o u
suário
)
Texto
com
os tó
pico
s de
critério
s
relacio
nad
os a e
xpe
ctativas e
de
sejo
s
Fun
cion
árias
Faturam
en
to
Texto
com
os tó
pico
s
relacio
nad
os a co
mo
o p
roce
sso
inte
rfere
em
ou
tras atividad
es
Texto
com
os tó
pico
s
relacio
nad
os a co
mo
o p
roce
sso
inte
rfere
em
ou
tras atividad
es
Ge
stora e
Re
spo
nsáve
l
Fech
ame
nto
Finan
ceiro
Ge
stora e
Re
spo
nsáve
l
Fech
ame
nto
Finan
ceiro
O q
ue
o p
roce
sso
inte
rfere
com
relação
aos o
utro
s pro
cesso
s
qu
e o
corre
m n
a
organ
ização?
Ide
ntificar co
mo
ou
tros stake
ho
lde
rs
en
volvid
os se
relacio
nam
com
o
pro
cesso
Ide
ntificar co
mo
o
pro
cesso
inte
rfere
nas ativid
ade
s da
em
pre
sa
Ide
ntificar co
mo
o
pro
cesso
inte
rfere
no
trabalh
o d
e
ou
tros stake
ho
lde
rs
Ide
ntificar q
ual a
relação
com
ou
tras
atividad
es
De
scritiva qu
alitativa
(pe
rgun
tas e re
spo
stas
com
o u
suário
)
De
scritiva qu
alitativa
(pe
rgun
tas e re
spo
stas
com
o u
suário
)
58
Apêndice B – Protocolo Análise da Situação Atual
Pe
rgun
ta da P
esq
uisa
Ob
jetivo
Me
tasV
ariáveis
Valo
res assu
mid
os p
elas variavé
isR
esp
on
de
nte
sQ
ue
stõe
s
Qu
and
o vo
cê e
xecu
ta o p
roce
sso d
e tirar d
o e
spe
cial?
Qu
al a freq
uê
ncia?
Qu
em
é re
spo
nsáve
l? Co
mo
é d
ividid
o o
trabalh
o?
Qu
ais info
rmaçõ
es vo
cê p
recisa p
ara exe
cutar e
ste p
roce
sso?
As in
form
açõe
s de
pe
nd
em
de
ou
tros se
tore
s?
On
de
estas in
form
açõe
s estão
disp
on
íveis?
É fácil visualizá-las o
u e
nco
ntrá-las?
Qu
ais as atividad
es vo
cê e
xecu
ta?
Qu
al o p
asso a p
asso d
a exe
cução
?
Qu
al a inte
ração co
m o
sistem
a?
O q
ue
você
tem
disp
on
ível n
o siste
ma?
O q
ue
você
pre
cisa pro
curar e
m o
utro
s amb
ien
tes d
o siste
ma?
O q
ue
você
pre
cisa alterar n
o siste
ma?
Co
mo
você
realiza e
stas alteraçõ
es?
O q
ue
dificu
lta as suas ativid
ade
s?
O q
ue
você
gostaria q
ue
o siste
ma te
mo
strasse?
O q
ue
voce
gostaria q
ue
o siste
ma te
avisasse?
Na e
xecu
ção d
as atividad
es, o
qu
e vo
cê gan
haria te
mp
o?
O q
ue
voce
inclu
iria no
sistem
a?
O q
ue
você
mu
daria d
o p
roce
sso?
Qu
ais são o
s fatore
s
relacio
nad
os ao
de
sem
pe
nh
o e
de
sen
volvim
en
to d
o
pro
cesso
: tirar no
tas do
esp
ecial?
Ente
nd
er a ro
tina
Ide
ntificar
info
rmaçõ
es
ne
cessárias
Fun
cion
árias
Faturam
en
to
Fun
cion
árias
Faturam
en
toId
en
tificar
aspe
ctos d
o
pro
cesso
Ide
ntificar p
asso a
passo
do
pro
cesso
e in
teração
com
o
sistem
a
De
scritiva qu
alitativa
(pe
rgun
tas e re
spo
stas
com
o u
suário
)
Texto
com
os tó
pico
s de
critério
s relacio
nad
os ao
pro
cesso
De
scritiva qu
alitativa
(pe
rgun
tas e re
spo
stas
com
o u
suário
)
De
scritiva qu
alitativa
(pe
rgun
tas e re
spo
stas
com
o u
suário
)
Texto
com
os tó
pico
s de
critério
s relacio
nad
os a ro
tina
Texto
com
os tó
pico
s de
critério
s relacio
nad
os as
info
rmaçõ
es
Fun
cion
árias
Faturam
en
to
Fun
cion
árias
Faturam
en
to
Ide
ntificar
ne
cessid
ade
s e
de
sejo
s
De
scritiva qu
alitativa
(pe
rgun
tas e re
spo
stas
com
o u
suário
)
Texto
com
os tó
pico
s de
critério
s relacio
nad
os as
ne
cessid
ade
s e d
ese
jos
Fun
cion
árias
Faturam
en
to
Qu
ais são o
s fatore
s
relacio
nad
os a
pe
rcep
ção e
exp
eriê
ncia
do
usu
ário co
m re
lação
ao p
roce
sso?
Ide
ntificar
ne
cessid
adad
es
e su
gestõ
es
Ide
ntificar
imp
ressõ
es e
suge
stõe
s
De
scritiva qu
alitativa
(pe
rgun
tas e re
spo
stas
com
o u
suário
)
Texto
com
os tó
pico
s de
critério
s relacio
nad
os as
suge
stõe
s e im
pre
ssõe
s
59
Apêndice C – Protocolo Validação Usabilidade
Pe
rgun
ta da P
esq
uisa
Ob
jetivo
Me
tasV
ariáveis
Valo
res assu
mid
os p
elas variavé
isR
esp
on
de
nte
sQ
ue
stõe
s
Dad
o o
s seu
s con
he
cime
nto
s, o siste
ma é
con
side
rado
fácil de
usar?
Na su
a op
inião
, algué
m q
ue
não
po
ssui u
m co
nh
ecim
en
to tão
apro
fun
dad
o
con
sidararia sim
ple
s utilizar o
sistem
a?
No
geral, vo
cê e
stá satisfeito
com
a facilidad
e d
o p
roce
sso d
e tirar as n
otas d
o
esp
ecial?
Vo
cê co
nse
gue
com
ple
tar seu
trabalh
o d
e fo
rma ráp
ida u
sand
o e
ste siste
ma?
Vo
cê co
nse
gue
com
ple
tar seu
trabalh
o e
ficien
tem
en
te (faze
r o q
ue
tem
qu
e se
r
feito
) usan
do
este
sistem
a?
Vo
cê ach
a qu
e co
m e
ste siste
ma, vo
cê se
torn
ou
mais p
rod
utivo
?
No
geral, vo
cê e
stá satisfeito
com
o to
tal de
tem
po
ne
cessário
para co
mp
letar o
pro
cesso
?
Vo
cê co
nse
gue
com
ple
tar seu
trabalh
o e
fetivam
en
te (faze
r certo
as coisas ce
rtas com
qu
alidad
e) u
tilizand
o e
ste siste
ma?
O siste
ma te
m to
das as fu
nçõ
es q
ue
você
pre
cisa?
Vo
cê se
sen
te co
nfo
rtável u
sand
o e
ste siste
ma?
Vo
cê co
nsid
era a te
la agradáve
l?
Vo
cê go
sta de
usar a te
la do
sistem
a?
Para vo
cê, a o
rganização
na te
la é clara?
O siste
ma m
ostra m
en
sagen
s de
erro
, qu
e p
erm
item
con
sertar o
pro
ble
ma
facilme
nte
?
Qu
and
o vo
cê co
me
te u
m e
rro n
o siste
ma, é
rápid
o e
fácil con
sertá-lo
?
Na su
a op
inião
, a info
rmação
forn
ecid
a no
sistem
a é clara?
Vo
cê co
nsid
era fácil e
nco
ntrar as in
form
açõe
s qu
e p
recisa?
Vo
cê co
nsid
era d
e fácil co
mp
ree
nsão
, as info
rmaçõ
es fo
rne
cidas p
elo
sistem
a?
Na su
a op
inião
, a info
rmação
qu
e é
forn
ecid
a te aju
da a co
mp
letar se
u trab
alho
?
No
geral, vo
cê e
stá satisfeito
com
a info
rmação
de
sup
orte
forn
ecid
a para co
mp
letar
o p
roce
sso?
No
geral, vo
cê se
sen
te satisfe
ito co
m o
sistem
a?
Faça com
en
tário ge
rais sob
re o
sistem
a.
Fun
cion
árias
Faturam
en
to
Fun
cion
árias
Faturam
en
to
Fun
cion
árias
Faturam
en
to
Fun
cion
árias
Faturam
en
to
Fun
cion
árias
Faturam
en
to
Fun
cion
árias
Faturam
en
to
Fun
cion
árias
Faturam
en
to
Fun
cion
árias
Faturam
en
to
De
scritiva qu
alitativa
(pe
rgun
tas e re
spo
stas
com
o u
suário
)
De
scritiva qu
alitativa
(pe
rgun
tas e re
spo
stas
com
o u
suário
)
De
scritiva qu
alitativa
(pe
rgun
tas e re
spo
stas
com
o u
suário
)
Texto
com
os tó
pico
s de
critério
s
relacio
nad
os a facilid
ade
de
usar
Texto
com
os tó
pico
s de
critério
s
relacio
nad
os a e
ficiên
cia
Texto
com
os tó
pico
s de
critério
s
relacio
nad
os a e
ficácia
Texto
com
os tó
pico
s de
critério
s
relacio
nad
os a co
nfo
rto
Texto
com
os tó
pico
s de
critério
s
relacio
nad
os a co
rreção
de
erro
s
Texto
com
os tó
pico
s de
critério
s
relacio
nad
os a d
ispo
nib
ilidad
e d
e
info
rmaçõ
es
Texto
com
os tó
pico
s de
critério
s
relacio
nad
os a ap
licação d
as
info
rmaçõ
es
Texto
com
os tó
pico
s de
critério
s
relacio
nad
os a satisfação
De
scritiva qu
alitativa
(pe
rgun
tas e re
spo
stas
com
o u
suário
)
De
scritiva qu
alitativa
(pe
rgun
tas e re
spo
stas
com
o u
suário
)
De
scritiva qu
alitativa
(pe
rgun
tas e re
spo
stas
com
o u
suário
)
De
scritiva qu
alitativa
(pe
rgun
tas e re
spo
stas
com
o u
suário
)
De
scritiva qu
alitativa
(pe
rgun
tas e re
spo
stas
com
o u
suário
)
An
alisar a facilidad
e
de
usar
An
alisar a eficiê
cia
An
alisar a eficácia
An
alisar o co
nfo
rto
An
alisar a corre
ção
de
erro
s
An
alisar a
disp
on
ibilid
ade
das
info
rmaçõ
es
An
alisar a aplicação
das in
form
açõe
s
An
alisar a satisfação
Me
dir a
usab
ilidad
e
Qu
al a usab
ilidad
e d
a
solu
ção
de
sen
volvid
a?
60
Apêndice D – Protocolo Discussão e Resultados
Pe
rgun
ta da P
esq
uisa
Ob
jetivo
Me
tasV
ariáveis
Valo
res assu
mid
os p
elas variavé
isR
esp
on
de
nte
sQ
ue
stõe
s
Co
m a m
ud
ança fo
i po
ssível e
nte
nd
er m
elh
or co
mo
fun
cion
a o p
roce
sso
geral d
e e
missão
de
no
tas esp
eciais?
Co
m a m
ud
ança fo
i po
ssível e
stabe
lece
r os p
ape
is e re
spo
nsab
ilidad
es
com
mais clare
za?
Vo
cê co
nsid
era q
ue
esta m
ud
ança p
erm
itiu a in
trod
ução
de
ferram
en
tas
apro
priad
as ao trab
alho
? Po
r qu
ê?
De
acord
o co
m o
de
sen
volvim
en
to d
o n
ovo
sistem
a, você
con
side
ra qu
e
o p
roce
sso fo
i otim
izado
?
Vo
cê co
nsid
era se
gun
do
o q
ue
foi d
ese
nvo
lvido
, qu
e lim
itaçõe
s do
pro
cesso
foram
sup
erad
as? Po
r qu
ê?
Ge
rên
ciaV
ocê
con
side
ra qu
e a m
ud
ança re
alizada fo
i de
acord
o co
m o
s ob
jtivos
estraté
gicos p
ara o p
roce
sso d
e fatu
rame
nto
?
Vo
cê se
sen
tiu e
nvo
lvida n
o p
roce
sso d
e d
ese
nvo
lvime
nto
do
no
vo
sistem
a?
Vo
cê co
nsid
era q
ue
sua o
pin
ião fo
i ou
vida e
reve
rtida e
m m
elh
orias n
o
sistem
a?
Vo
cê co
nsid
ea q
ue
a solu
ção fin
al sup
riu as n
ece
ssidad
es in
iciais do
pro
cesso
qu
e vo
cê tin
ha?
Vo
cê co
nsid
era q
ue
o p
roce
sso fo
i feito
de
man
eira cíclica, o
u se
ja, o
qu
e fo
i de
sen
volvid
o, fo
i testad
o e
sua o
pin
ião so
bre
a mu
dan
ça foi
con
side
rada?
Vo
cê co
nsid
era q
ue
a particip
ação d
as fun
cion
árias do
Faturam
en
to fo
i
imp
ortan
te?
Vo
cê co
nsid
era q
ue
foram
con
side
radas as re
laçãos co
m o
utro
s
pro
cesso
s para d
ese
nvo
lver a m
elh
oria?
Na su
a op
inião
, sem
o e
nvo
lvime
nto
das fu
ncio
nárias d
o Fatu
rame
nto
seria p
ossíve
l de
sen
volve
r a solu
ção co
mo
está ago
ra?
Vo
cê co
nsid
era q
ue
o d
ese
nvo
lvime
nto
foi m
ais focad
o n
o q
ue
as
fun
cion
árias pre
cisavam?
Ge
rên
cia
De
form
a geral, vo
cê co
nsid
era q
ue
ho
uve
um
a me
lho
ra no
pro
cesso
?
Po
r qu
ê?
Qu
ais os b
en
efício
s de
BP
M alcan
çado
s com
o
pro
jeto
?
Fun
cion
ário Siste
mas
Fun
cion
ário Siste
mas e
Ge
rên
cia
Fun
cion
árias
Faturam
en
to
Texto
com
os tó
pico
s de
critério
s
relacio
nad
os ao
en
volvim
en
to d
os
usu
ários e
as con
seq
uê
ncias d
o
en
volvim
en
to
De
scritiva
qu
alitativa
(pe
rgun
tas e
resp
ostas co
m o
usu
ário)
Ide
ntificar
en
volvim
en
to e
con
seq
uê
ncias
Ide
ntificar co
mo
foi o
en
volvim
en
to
do
s usu
ários e
o
resu
ltado
de
ste
en
volvim
en
to
Co
mo
foi o
de
sem
pe
nh
o e
m
relação
ao
de
sen
volvim
en
to d
o
pro
jeto
?
Fun
cion
árias
Faturam
en
to
Fun
cion
ário Siste
mas e
Ge
rên
cia
Texto
com
os tó
pico
s de
critério
s
relacio
nad
os ao
s be
ne
fícios
De
scritiva
qu
alitativa
(pe
rgun
tas e
resp
ostas co
m o
usu
ário)
Ide
ntificar
be
ne
fícios p
ara
atore
s do
pro
cesso
Ide
ntificar se
os
ob
ejtivo
s de
BP
M
foram
atingid
os