Você sabe o que é design etnográfico?

Você sabe o que é design etnográfico?

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.

Mais informações em: http://repositorio.ipea.gov.br/bitstream/11058/9388/1/Design%20etnogr%C3%A1fico.pdf

Design etnográfico aplicada em diferentes fases do ciclo de políticas públicas
Design etnográfico aplicada em diferentes fases do ciclo de políticas públicas

Neste post veja os conceito de BPMS e os novos conceitos de iBPMS conforme o Cbok 4.0

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.

Utilizando paralelo com BPMN 2.0

A OMG é a mantenedora da notação BPMN.

No link https://www.omg.org/spec/BPMN/2.0/PDF/ pode-se baixar toda a norma da notação.

Na página 36/37 temos:

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.

‹Nenhuma atividade do processo ainda está ativa.

COMO CONTRATAR SERVIÇOS DE MELHORIA DE PROCESSOS?

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.