Design é uma abordagem que combina métodos e ferramentas de diversas áreas com o objetivo de gerar ou transformar um serviço ou produto.
A etnografia, por sua vez, é uma metodologia de pesquisa desenvolvida pela antropologia que auxilia o pesquisador a imergir numa sociedade para entendê-la profundamente em sua cultura, comportamentos e relações sociais.
O design etnográfico é uma metodologia de pesquisa qualitativa utilizada em processos de design que pode ser aplicada em diferentes fases do ciclo de políticas públicas. Por meio de um conjunto de técnicas, promove-se uma imersão em uma determinada realidade a ser transformada, buscando-se uma ampliação do conhecimento e identificação de oportunidades de inovação.
Antes desse diálogo entre a etnografia e o design, as pesquisas de projetos de design levantavam as possibilidades de usabilidade de um produto ou serviço tendo como base a psicologia. Outra forma era a pesquisa de mercado, na qual pessoas eram entrevistadas e expressavam seus gostos, percepções e hábitos. A etnografia passou a ser efetivamente incorporada ao design quando se percebeu que o contexto também era capaz de influenciar usos e que o que era pensado poderia não ser igual ao que efetivamente se praticava.
A aplicação da etnografia em projetos de design, também conhecida como design etnográfico, difere da aplicação da etnografia em projetos acadêmicos. Para esta, a motivação é o desenvolvimento de teorias com validade científica, já para aquela, espera-se identificar, com alguma profundidade contextual e limitação de tempo e escopo, o que, no cotidiano das pessoas, representa uma oportunidade de inovação. Assim, o design etnográfico é uma apropriação, feita pelo design, da abordagem etnográfica, adaptando-a aos seus processos de imersão e as suas concepções. A utilização do design etnográfico no setor público vem possibilitando avanços na compreensão de questões relacionadas à vivência do cidadão em serviços, a fim de identificar erros e oportunidades para melhorias incrementais ou disruptivas nas políticas públicas num tempo relativamente curto.
Neste post veja os conceito de BPMS e os novos conceitos de iBPMS conforme o Cbok 4.0. O Cbok 4.0 Traz a definição de BPMS – Businnes Process Management Suite como “Um conjunto de ferramentas automatizadas que permite à Organização ser modelada, mostrando fluxos, a utilização de regas, a utilização de dados e muito mais. Um BPMS fornece um conjunto integrado de softwares que define a arquitetura da aplicação e as necessidades tecnológicas de infraestrutura para o funcionamento e execução das aplicações que funcionam no âmbito do ambiente técnicos BPMS.
O ambiente operacional do BPMS responde ao desejo dos utilizadores corporativos de ver e gerir o seu trabalho, a medida que este avança na atividade organizacional.” Um BPMS apoia a modelagem de processos, seus desenhos, seu desenvolvimento e a execução gerida de trabalhos e aplicação. A informação de desenhos e regras do BPMS é utilizada para gerar automaticamente aplicações que são utilizadas na solução. Esta automatização permite uma mudança muito rápida, com controle sobre a forma com a mudança é aplicada.
O Cbok 4.0 trouxe o um novo conceito os iBPMS – Intelligent Businnes Process Mannagement Suites que foi traduzido oficialmente no Brasil para Conjunto Inteligente de Gestão dor Processos de Negócio. Os iBPMS são aplicações de negócio dinâmicas que se podem adaptar rapidamente as necessidades de negócio em mudança, à pressão competitiva e as oportunidades de mercado, ajudando as organizações a planejar e automatizar os seus complexos processo de negócio por meio da construção de um ambiente tecnológico dinâmico baseado no trabalho de conhecimento de valor.
No Cbok 4.0 você pode achar a descrição das capacidades que um iBPMS deve ter. Estas capacidades são, dentre outras, Analítica avançada, Inteligência Artificial, BPM Móvel (Permite processamento mais rápido de trabalhos remotos e em campo) , BPM Social (integração com redes sociais) , BPM baseado na nuvem, mineração de processos, Automatização Robótica de Processos (RPA), Análise preditiva, Internet das Coisas (IoT), Blockchaing(contratos inteligentes) e Gestão Dinâmica de Casos. Desta forma O iBPMS traz mais capacidades do que as previstas anteriormente para os BPMS tradicionais.
BPMN uses the term “fork” to refer to the dividing of a path into two or more parallel paths (also known as an AND-Split). It is a place in the Process where activities can be
performed concurrently, rather than sequentially. There are two options:
• Multiple Outgoing Sequence Flows can be used (see figure top-right). This represents “uncontrolled” flow is the preferred method for most situations.
• A Parallel Gateway can be used (see figure bottom-right). This will be used rarely, usually in combination with other Gateways.
O BPMN usa o termo “bifurcação” para se referir à divisão de um caminho em dois ou mais caminhos paralelos (também conhecido como Split AND). É um lugar no processo em que as atividades podem ser executadas simultaneamente, em vez de sequencialmente. Existem duas opções:
• Podem ser usados vários fluxos de sequência de saída (veja a figura no canto superior direito). Isso representa que o fluxo “não controlado” é o método preferido para a maioria das situações.
• Um gateway paralelo pode ser usado (veja a figura no canto inferior direito). Isso será usado raramente, geralmente em combinação com outros Gateways.
BPMN uses the term “join” to refer to the combining of two or more parallel paths into one path (also known as an AND-Join or synchronization). A Parallel Gateway is used to show the joining of multiple Sequence Flows.
O BPMN usa o termo “junção” para se referir à combinação de dois ou mais caminhos paralelos em um caminho (também conhecido como junção AND ou sincronização). Um gateway paralelo é usado para mostrar a junção de vários fluxos de sequência.
Na página 293/294 temos:
10.5.4 Parallel Gateway
A Parallel Gateway is used to synchronize (combine) parallel flows and to create parallel flows.
The Parallel Gateway MUST use a marker that is in the shape of a plus sign and is placed within the Gateway
diamond (see Figure 10.110) to distinguish it from other Gateways.
10.5.4 Gateway paralelo
Um Gateway Paralelo é usado para sincronizar (combinar) fluxos paralelos e criar fluxos paralelos.
O Gateway Paralelo DEVE usar um marcador na forma de um sinal de adição e colocado dentro do Gateway
diamante (veja a Figura 10.110) para distingui-lo de outros Gateways.
Figure 10.110 – An example using an Parallel Gateway Parallel Gateways are used for synchronizing parallel flow (see Figure 10.111)
Figura 10.110 – Um exemplo usando um Parallel Gateway Parallel Gateways é usado para sincronizar o fluxo paralelo (consulte a Figura 10.111)
Figure 10.111 – An example of a synchronizing Parallel Gateway A Parallel Gateway creates parallel paths without checking any conditions; each outgoing Sequence Flow receives a token upon execution of this Gateway. For incoming flows, the Parallel Gateway will wait for all incoming flows before triggering the flow through its outgoing Sequence Flows.execution of this Gateway. For incoming flows, the Parallel Gateway will wait for all incoming flows before triggering the flow through its outgoing Sequence Flows.
The Parallel Gateway element inherits the attributes and model associations of Gateway (see Table 8.46), but adds no additional attributes or model associations.
Figura 10.111 – Um exemplo de gateway paralelo sincronizado Um gateway paralelo cria caminhos paralelos sem verificar nenhuma condição; cada fluxo de sequência de saída recebe um token na execução deste gateway. Para fluxos de entrada, o Parallel Gateway aguardará todos os fluxos de entrada antes de acionar o fluxo através da execução de fluxos de sequência de saída deste Gateway. Para fluxos de entrada, o Parallel Gateway aguardará todos os fluxos de entrada antes de acionar o fluxo através de seus fluxos de sequência de saída.
O elemento Parallel Gateway herda os atributos e as associações de modelos do Gateway (consulte a Tabela 8.46), mas não adiciona atributos ou associações de modelos adicionais.
Conforme a página 362 ele pode ser fechado com um Gateway Complexo quando usado em colaboração com outro processos conforme imagem abaixo.
Na página 426 temos:
A Process instance is completed, if and only if the following three conditions hold: If the instance was created through an instantiating Parallel Gateway, then all subsequent Events (of that Gateway) MUST have occurred. There is no token remaining within the Process instance. No Activity of the Process is still active.
‹Uma instância do Processo é concluída, se e somente se as três condições a seguir forem válidas:
‹Se a instância foi criada através de um Parallel Gateway instanciador, todos os Eventos subsequentes (desse
Gateway) DEVE ter ocorrido.
‹Não há nenhum token restante na instância do Processo.
Sempre que se vai contratar trabalhos para mapeamento de melhoria de processos, fica a dúvida de como contratar e controlar. O primeiro passo para dirimir estas dúvidas é entender como é o seu cenário, e o quanto conhece do que quer mapear. Quando se vai terceirizar os serviços de mapeamento e melhoria de processos, a melhor opção é a contratação de serviços específicos. Mas como mensurar e valorar estes serviços? Deve-se deixar claro o que se vai pedir e construir um catálogo de serviços com valores que servirá com um “menu” para a contratante escolher o que vai ser usado em cada caso. Segue abaixo alguns exemplos de análise de cenários e sugestões de formas de contratação.
Cenário 1: O escopo
de atuação é definido previamente. É conhecido a quantidade de processos que
deverá ser mapeada, tem-se uma ideia de sua complexidade e o numero de árias
envolvidas. Neste caso, usando a metodologia da própria área, estima-se o
escopo e o esforço necessário para o levantamento. Este esforço é convertido em
porcentagem ou números absolutos para se ter uma base para facilitar a
conversão em Unidades de Serviço/Trabalho UST. Neste cenário, não importa o
quanto tempo a contratada vai demorar para levantar um processo, ela será paga
por processo levantado. As UST neste cenário tem uma valorização maior mas tem
poucas em quantidade. Este cenário geralmente é encontrado em contratantes que tem
um grau de maturidade em processos elevado e a contratante vem como uma mão extra.
Exemplo de catálogos de serviço:
Mapeamento de processo (diagramação As Is) 1 UST
(por processo)
Diagnóstico
3 UST (por processo)
Proposição de melhorias (To Be do processo) 2
UST (por processo)
Detalhamento para automação de processo 3 UST
(por processo)
Acompanhamento da implementação 1UST (por
processo)
Neste exemplo, um processo do As
Is, realizando todos os serviços até seu acompanhamento seria gasto um total de
10 UST por processo. Como o número de processos a serem mapeados é conhecido,
basta multiplicar este número e você terá o número total de UST para se ter os
processos mapeados conforme escopo já definido. Se pretende levantar 30 processos, seria
necessário contratar 300 USTs.
Em outro exemplo, em uma determinada
análise, foi levantado que seria necessário trabalhar em diferentes fases em 3
processos. Multiplicando pelo serviço necessário em cada processo estimou-se
ser necessário 20 UST, conforme exemplo abaixo.
Exemplo de Ordem de Serviço:
Mapear As Is e Diagnosticar o processo XPTO. Total
4 UST.
Realizar Mapeamento, Diagnóstico, proposição de
melhoria para o processo ABC. Total 6 UST.
Realizar Mapeamento, Diagnóstico, proposição de
melhoria, detalhamento para automação e acompanhar a implementação para o
processo XYZ. Total 10 UST.
Esta OS de exemplo teria um total de XPTO 4, ABC 6 XYZ 10 dando um total de 20 UST.
Cenário 2: O escopo
de atuação é conhecido, mas não se tem
uma ideia da complexidade dos processos e o esforço necessário. Neste cenário,
o melhor é trabalhar com um catálogo parecido com o do cenário 1, mas aplicando
fatores de complexidade para corrigir distorções.
Exemplo de catálogo:
Mapeamento de processo (diagramação As Is) 1 UST (por processo)
Diagnóstico
3 UST (por processo)
Proposição de melhorias (To Be do processo) 2
UST (por processo)
Detalhamento para automação de processo 3 UST
(por processo)
Acompanhamento da implementação 1 (por processo)
Exemplos de alguns fatores Multiplicadores
Complexidade do processo
Fator
Áreas envolvidas
Fator
Automação de processo
Fator
Baixa
1
1 a 3
1
Não tem
1
Média
2
3 a 6
2
Tem, mas
sem integrações com sistemas legados
2
Alta
3
6 a 10
3
Tem com integrações
com sistemas legados.
3
Foi levantado que seria
necessário trabalhar em diferentes fases em 3 processos. Multiplicando pelo
serviço necessário em cada processo estimou-se conforme exemplo abaixo.
Exemplo de Ordem de Serviço:
Mapear As Is e Diagnosticar o processo XPTO.
Total 4 UST.
Realizar Mapeamento, Diagnóstico, proposição de
melhoria para o processo ABC. Total 6 UST.
Realizar Mapeamento, Diagnóstico, proposição de
melhoria, detalhamento para automação e acompanhar a implementação para o
processo XYZ. Total 10 UST.
Após análise o processo XPTO é de
baixa complexidade, envolve 3 áreas e não tem automação. Recebeu um fator
multiplicador 1 totalizando 4 UST.
Após análise o processo ABC é de
baixa complexidade, envolve 6 áreas e não tem automação (1 x 3 x 1) recebeu um
fator multiplicador de 3 (3×6) totalizando 18 UST.
Após análise, o processo XYZ foi identificado
com de alta complexidade, 6 áreas envolvidas e tem automação de processos e
envolve integração com sistemas legados, (3x3x3) tendo o mais alto fator
multiplicador de 27… totalizando 270 USTs.
Total de UST da ordem de serviço
seria 292 USTs.
Neste cenário para se ter uma estimativa de gastos de UST, deve-se levantar minimamente a lista dos processos que se deseja mapear, aplicar os fatores multiplicadores e somar todas as USTs necessárias para aqueles processos.
Cenário 3: O escopo
de atuação é desconhecido assim como o esforço necessário para se levantar o
processo. A complexidade do levantamento dos processos também é desconhecida
pela equipe. Neste cenário, divide-se os trabalhos em micro entregas para que
seja mensuráveis e a cada Ordem de Serviço – OS, deve-se fazer um estudo
preliminar para estimar seu tamanho e o que será necessário para a entrega do
processo mapeado.
O Catálogo de serviço, deve
conter a menor unidade de serviço possível e as evidências de cada entrega
claras como por exemplo:
Workshop estruturado para levantamentos iniciais
do processo (definição dos limites do processo, envolvidos, escopo de atuação e
o que mais for necessário para elaboração do termo de abertura do projeto) 1
UST entrega TAP e ata de reunião.
Workshop estruturado para levantamento da
situação atual do processo (1 UST por Workshop estruturado realizado). Entrega:
diagrama do processo desenhado e descrito, Ata de reunião.
Workshop estruturado levantamento e elaboração
de diagnóstico de processo (2 UST por Workshop
estruturado realizado). Entrega: diagnóstico da situação atual do processo, Ata
de reunião.
Workshop estruturado Levantamento das
proposições de melhoria do processo (To be) (1 UST por Workshop estruturado
realizado). Entrega: diagrama do processo desenhado e descrito, Ata de reunião.
Workshop estruturado para detalhamento do
processo para automação (1 UST por Workshop estruturado realizado). Entrega: requisitos
do processo com base no To Be e Ata de
reunião.
Acompanhamento da implementação do processo. 1
UST por acompanhamento. Entrega ata de reunião.
Neste cenário, usando o catálogo
acima, abriu-se um OS para mapeamento do processo XPTO.
1 UST gasta para levantamentos
inicias do processo
Após a entrega do TAP,
entendeu-se que seriam necessários 5 encontros para levantamento da situação
atual do processo, 3 encontros para elaboração do diagnóstico, 2 encontros para
elaborar o To Be, 4 para detalhamento do processo e 4 para acompanhamento.
Com base nestas informações,
abre-se a próxima OS que teria o TAP como detalhamento e uma previsão de gasto
de UST de 21 UST. Este número pode variar para mais ou para menos no decorrer
do projeto dependendo do andamento dos levantamentos.
Neste cenário, como não se tem o
total de processos que serão levantados, pode-se fazer uma estimativa baseado no
tamanho da equipe que se pretende alocar para realização dos trabalhos e os
esforços que tal equipe teria a capacidade de executar. Em uma equipe de 3
profissionais, levando em consideração que o mês tem em média 21 dias úteis, uma
jornada de trabalho de 8 horas diárias, teríamos 21 x 8 = 168 horas, 168 x 3 profissionais
= 504 horas mês. A estimativa de horas no ano seria 6048. Para a conversão em
UST, deve-se mensurar quantas horas seriam gastas para a execução de um
Workshop estruturado. A título de exemplo vamos considerar que o profissional
gastaria 2 horas com preparações e produções pré e pós reunião e 2 horas com os
encontros em si, totalizando, em média, 4 horas de esforço com cada Workshop.
Neste exemplos teríamos uma estimativa anual de UST para alocação dos 3 profissionais de 1512 UST ano.
Nos cenários 1 e 2, deve-se deixar
claro os levantamentos realizados para a contratada poder estimar o valor de
forma correta da UST. Quanto mais informações forem fornecidas, mais preciso
será o valor que o mercado dará para a UST. Os perfis dos profissionais, com os
conhecimentos, habilidades e atitudes mínimas necessárias para atuação são muito
importantes. A vantagem destes cenário é ter com clareza o que se quer de
entrega e a gestão do contratos será menos onerosa para um fiscal, pois as
entregas serão maiores e em menor quantidade por mês. Por outro lado, o valor
da UST será maior em grande parte pelo risco assumido pela contratada, pois a
mesma ganhará um valor fixo por processo independente do tempo gasto para o seu
mapeamento o que pode gerar prejuízos para a contratada caso o projeto não seja
gerenciado de forma adequada. Geralmente a gestão do projeto fica no âmbito da
contratada.
No cenário 3, deve-se deixar
claro o quantitativo de profissionais desejados assim como os perfis almejados
para que se possa ter um valor correto de UST em uma possível tomada de preço
no mercado. Deve-se também ter claras as entregas de cada micro serviço assim
como os critérios de aceite dos mesmos. Neste cenário não se tem riscos para a
contratada, mas sim para a contratante. O valor da UST tende a ser bem menor.
Este tipo de cenário exige uma participação muito mais ativa por parte da
contratante. Geralmente a gestão do projeto fica no âmbito da contratante, para
que a mesma possa gerir os custos das OS e não extrapolar o que se é previsto
mensalmente como entrega, exaurindo o contrato antes do esperado. Este tipo de
cenário, por mais que seja mais simples realizar a sua contratação, por não
necessitar de estudo preliminares por parte da contratante, tendem a onerar
mais tempo de fiscais no decorrer de sua execução devido ao número elevado de
entregas que devem ser avaliadas.
Todos os cenários tem suas vantagens
e desvantagens. Deve-se escolher o melhor para a realidade da contratante e de
sua capacidade de detalhar o que quer de entrega.
