Convite para webinar: Superando os Desafios do Primeiro Projeto de Automação

O sucesso do primeiro projeto de automação de processos de uma organização depende de inúmeros fatores, que vão desde a escolha adequada do processo a ser automatizado até o impacto que o redesenho tecnológico do processo e a receptividade das área envolvidas no uso da nova tecnologia.

Com 18 anos de experiência em automação de processos, a iProcess irá neste webinar compartilhar os principais desafios e lições aprendidas para superar as dificuldades da primeira automação de processos de uma organização.

Participe, o evento é gratuito e será transmitido online ao vivo pela internet!


Apresentado por:
Eduardo Britto, Diretor de Consultoria da iProcess

Data:
12 de dezembro de 2017
Horário: 12h (BRT)

 

Vagas limitadas. Inscreva-se já:

Especial BPM Day Porto Alegre 2017

A iProcess foi novamente a organizadora do BPM Day de Porto Alegre, evento realizado pela ABPMP Brasil (Association of Business Process Management Professional), que aconteceu dia 21 de novembro e contou com mais de 650 inscritos.

Esta foi a 98a edição deste que é o maior e um dos mais importantes eventos de compartilhamento de experiências em Gestão por Processos de Negócio. o BPM Day é um evento com dimensão nacional com agenda em diversas cidades do país e tem como objetivo possibilitar a aproximação de profissionais das diversas áreas relacionadas a BPM com a apresentação casos aplicados em empresas.

Os cases apresentados têm como objetivo compartilhar como a disciplina de gestão por processos tem sido aplicada em organizações de diferentes portes e segmentos de negócio, os desafios enfrentados e os resultados obtidos.

Aqui estão as apresentações realizadas pelos profissionais que fizeram esta importante contribuição durante o BPM Day Porto Alegre 2017:

ABPMP: Abertura do BPM Day Porto Alegre 2017
Por: Kelly Sganderla, CBPP (Gestora Regional ABPMP no RS)

Case Lojas Renner: Processos no Varejo
Por: Cristine Schweig (Gerente do EGPP – Escritório de Gestão de Projetos e Processos)
e Alexandre Reichert (Especialista em processos do EGPP) da Lojas Renner
Material indisponível para distribuição (não autorizado).

Case PROCERGS: A Gestão do Conhecimento e da Inovação na PROCERGS – Práticas colaborativas para a transformação
Por: José Ignácio Jaeger Neto (Gerente de Projetos – CIC da PROCERGS)
e Luciana Hahn Menezes – Planejamento e Gestão do Conhecimento na CIC da PROCERGS)

Case SPC Brasil: Transformando o Escritório de Processos em Busca da Inovação
Por: Felipe Oliveira (Gestor do Escritório de Processos do SPC Brasil)

Case Universidade Tecnologica de Equador: Escritório 3P’s – o caminho da excelência na gestão da Universidade Tecnológica do Equador – UTI
Por: Fernando Estrada – Consultor Metodológico em Gestão e Estratégia

Case CMPC: De zero a dez mil processos – os seis primeiros meses com processos automatizados na CMPC
Por: Leonardo Costi (Analista de Processos da CMPC Celulose Riograndense)

Case Grupo A: Excelência em Projetos e Processos
Por: Renato Veisman – Diretor do Grupo A

Case WEG: Otimização e Automação de Processos na WEG
Por: Marcos Luis Kretzchmer (Analista de Otimização e Automação de Processos na Weg Equipamentos Elétricos)

Confira também algumas fotos do evento:

Problemas comuns na modelagem de processos em BPMN II – Uso de eventos de mensagens para comunicação dentro do processo

Continuando a série de artigos que falam de erros, problemas e inconsistências básicas de modelagem (veja artigo já publicado aqui), vamos falar hoje de outra situação bem comum, que é a utilização de eventos de mensagem para comunicação entre papéis/raias dentro de um mesmo processo.

Vamos imaginar um processo ponta a ponta de uma organização, como por exemplo um processo de compras, onde em determinado trecho temos uma comunicação entre dois papéis ou áreas diferentes que atuam neste processo, no caso uma comunicação para o solicitante da compra de que a mercadoria foi recebida. Se olharmos apenas uma definição genérica do evento do tipo message, temos que um evento deste tipo trata de “uma comunicação entre 2 participantes do processo”.

Partindo deste pressuposto inicial, alguém poderia imaginar uma modelagem como esta:

Perceba que foram utilizados dois eventos do tipo message, um de envio (throw) na raia de Compras e outro de recebimento (catch) na raia do Solicitante.

Qual o problema desta abordagem? Basta nos aprofundarmos um pouco mais na especificação oficial de BPMN (link), para encontramos o seguinte trecho na seção “10.4.1 Concepts“:

“Messages are triggers, which are generated OUTSIDE of the Pool they are published in. They typically describe B2B communication between different Processes in different Pools.”

Em tradução literal: mensagens são gatilhos gerados fora da pool onde estão publicados, descrevendo tipicamente a comunicação B2B entre diferentes processos em diferentes pools.

Assim, o evento do tipo message só deve ser usado para comunicação com participantes EXTERNOS ao processo, não devendo ser utilizado para comunicar com um participante que já faz parte (ou seja, já é uma raia) do processo.

Partindo deste novo conhecimento adquirido, como ficaria então o processo descrito acima? Para isto, precisaríamos saber um pouco mais sobre de que forma é feita a comunicação entre a área de compras e o solicitante. Supondo, por exemplo, que a comunicação fosse realizada como um email disparado automaticamente pelo sistema (ou pelo processo automatizado), poderíamos ter então este desenho:

Neste caso, em vez do par de eventos do tipo message de envio e recebimento, teríamos apenas uma service task indicando o envio de email de forma automática. Perceba que o recebimento de email pelo solicitante não é uma atividade que envolva trabalho (consumo de recurso) de fato. Assim, receber um email é uma situação passiva e consequência direta do envio do email, portanto não é necessário uma tarefa para receber o email na raia do solicitante.

Processos, Pessoas e Transformação Digital

O que será que acontece quando colocamos, numa mesma mesa, um especialista em Processos, outro em Internet das coisas e um terceiro em coach pessoal e profissional?

Como o avanço da tecnologia irá impactar a vida das pessoas? Como processos e tecnologias podem se integrar? Como “coisas”, processos e pessoas trabalharão juntas? Como ficam as pessoas diante de um cenário de profunda de transformação?

Estes entre outros assuntos são discutidos  no programa de rádio #Inovação, conduzido Debora Vilella, que entrevista Eduardo Britto, Diretor da iProcess e especialista em Gestão por Processos; Giovanni Comunello, CEO da iTinvent e especialista em Internet das Coisas (IOT) e Ana Paula Thiesen, Diretora da Insight Desenvolvimento e  Master Coach Pessoal & Profissional.

E se você deseja se preparar para liderar a transformação digital na sua organização, conheça o curso de TRANSFORMAÇÃO DIGITAL ORIENTADA A PROCESSOS,

um programa de treinamento à distância criado para formar os profissionais que conduzirão as organizações para transformar os seus processos com o uso da tecnologia, aliando inovação a eficiência.

Inscreva-se na lista de contatos da iProcess para receber notícias sobre cursos, treinamentos, novas publicações no blog e datas dos próximos webinares! Basta preencher o formulário de contato no site da iProcess: http://www.iprocess.com.br/contato

 

Problemas comuns na modelagem de processos em BPMN – I – Atividades de transferência do processo

Vamos iniciar hoje uma série de artigos que pretendemos publicar ao longo dos próximos meses, falando especificamente de erros, problemas e inconsistências básicas de modelagem, comuns de ocorrer quando começamos a modelar processos e ainda não conhecemos muito bem a notação BPMN.

Pra começar, vamos falar de uma questão muito frequente, que se refere ao encaminhamento de um papel do processo para outro. Vamos imaginar um processo de Viagens, que foi descrito pela área de negócio da seguinte forma:

  1. Um colaborador solicita a viagem
  2. Solicitação de viagem é encaminhada (atenção especial ao uso desta palavra) para uma área interna chamada “Administrativo”, que tem a responsabilidade de pesquisar e mandar cotações da viagem para o solicitante
  3. Cotações são então encaminhadas de volta para o Solicitante avaliar
  4. Se a cotação for aprovada, processo é direcionado novamente para setor Administrativo comprar os tickets, do contrário processo é direcionado de volta para o setor Administrativo refazer as cotações

Agora veja como o modelador decidiu, inicialmente, representar este processo:

Note que no caso da primeira transferência do processo, do papel “Solicitante” para o papel “Administrativo”, foram criadas 2 atividades:

  • Uma atividade na raia do “Solicitante”, chamada “Encaminhar Viagem para Cotação para Administrativo”
  • Uma atividade na raia do “Administrativo”, chamada “Receber Viagem para Cotação do Solicitante”

O mesmo comportamento foi modelado posteriormente, na transferência do papel “Administrativo” para o papel “Solicitante”, com as atividades “Encaminhar Cotações para Solicitante” e “Receber Cotações do Administrativo”, respectivamente.

Este trecho do processo não está errado do ponto de vista da notação BPMN. Mas o que temos aqui, no entanto, são atividades que na prática não precisariam existir. O modelador optou por explicitar a passagem de bastão de um papel a outro através de atividades de transferência do processo, mas isso não é necessário: em BPMN, o próprio fluxo de sequencia já tem o papel de representar/realizar esta transferência de responsabilidade dentro do processo. Neste caso, como ficaria o desenho do processo ajustado? Veja a seguir:
Perceba que com esta mudança, deixamos o processo mais simples e limpo, ao mesmo tempo mantemos o comportamento esperado.

O conceito de utilizar apenas fluxos de sequência para representar a transferência de atividades dentro do processo costuma se aplicar mesmo que exista, de fato, um encaminhamento físico sendo realizado. Por exemplo, este processo de viagens poderia ser realizado em papel, implicando que o solicitante tivesse que levar fisicamente a solicitação impressa e assinada para o setor Administrativo. Mas mesmo neste caso não seria necessário modelar as atividades de transferência. Caso fosse necessário ressaltar este aspecto de encaminhamento físico de algo, poderiam ser utilizados outros recursos para representar, como adicionar uma anotação ao processo ou documentar esta característica do processo nos procedimentos das atividades.

Um cenário em que poderia ser necessária uma atividade para encaminhar ou receber o processo seria num caso em que as atividades são reconhecidamente manuais, realizadas no plano físico, e que possuem procedimentos adicionais, como protocolar a chamada do documento esperado, carimbar, etc. Por exemplo, num processo logístico poderíamos ter uma atividade da área de “Recebimento” chamada “Enviar material para Estoque”, onde “Estoque” é uma área da organização:

Note que, em linhas gerais, continuamos falando do mesmo exemplo citado no Processo de Viagens: a passagem de bastão de uma área para outra. Se o ato de encaminhamento físico do material de um lugar para outro envolve procedimentos adicionais e tem um tempo de execução relevante (vamos imaginar neste caso uma grande planta industrial, em que seria necessário percorrer a distância entre um setor para outro), ou seja, a atividade consome efetivamente recursos, então neste caso faria mais sentido criar uma atividade de transferência.

Fique ligado para outros artigos desta série no futuro! ;-)

Do processo analógico ao digital: como as novas tecnologias digitais impactarão os processos da sua organização

Neste webinar, Eduardo Britto, Diretor de Consultoria da iProcess, mostra como as empresas podem vencer seus desafios culturais ou organizacionais para transformar os seus processos analógicos em experiências digitais para os seus clientes.

Aqui você assiste ao vídeo gravado do evento apresentado em parceria com a Oracle, ao vivo pela internet para centenas de profissionais, no dia 10/10/2017.



Confira abaixo as respostas para perguntas enviadas por nossos participantes durante o evento:

Pergunta: Qual é a solução de BPMS demonstrada? Oracle BPM?
Resposta: O Oracle BPM é a solução on premise para automação de processos da Oracle, mas neste webinar demonstramos o processo automatizado com o produto Oracle PCS (Oracle Process Cloud Services), que é uma solução que roda totalmente em um ambiente de nuvem.

Pergunta: A ferramenta apresentada é personalizada ou seria uma plataforma da oracle para automatização de processos?
Resposta: O Oracle PCS é uma plataforma de desenvolvimento de processos; a partir dela é possível automatizar todo tipo de processo, como um processo de sinistro (demonstrado no vídeo) até um processo de compras, ou então um processo de viagens, ou de recrutamento e seleção… É tudo uma questão de você planejar como usar a plataforma para buscar a melhoria e a transformação dos seus processos.

Pergunta: Gostaria de saber como vocês fazem a abordagem das empresas para prestação de serviços? como a empresa deve proceder para iniciar a conversa sobre o mesmo?
Resposta: Diríamos que o mais importante é avaliarmos como seriam os nossos processos. Certamente um processo analógico (não digital) tem um grande potencial de ganho com a automação. Então o primeiro ponto é olhar e refletir como agora trabalhar com esses processos em uma visão digital. E a base para isso deve ser a experiencia o seu cliente. Você deve chamar o que dizemos em BPM de “outside in” – olhar na experiência do cliente no contato com seu processo e avaliar como pode torná-la mais inovadora e fácil para seu cliente e a partir daí pensar na automação. Evidentemente, a partir daqui precisará pensar em conjuntos de integrações e em como automatizar ao máximo o que for possível em seu processo.

Pergunta: Como elaborar uma mudança do ERP em Cliente Servidor para ERP na Nuvem?
Resposta: Podemos fazer um gancho aqui com o tema da primeira pergunta, podemos integrar os processos com ERP tanto on premise como na nuvem; e entendemos que em breve praticamente todos os sistemas estarão na nuvem, o que reduz bastante os custos de manter uma infraestrutura própria só para manter as informações. Mas ainda no cenário atual, grande parte dos ERPs já possuem serviços para integração e utilização pelos processos automatizados.

Pergunta: Estou envolvido em um processo de automação de uma empresa de terceirização de serviços, e gostaria de saber se existe algum pattern para auxiliar na automação deste processo. Mesmo considerando a complexidade de cada domínio.
Resposta: Podemos dizer que existem duas situações – processos já prontos e experiências de boas práticas de diversas organizações. Na iProcess já trabalhamos em centenas de processos nestes 17 anos. Nesses projetos, muitas vezes esses processos se repetiram, e foram discutidos, e identificamos o que era bom e o que não era bom e como poderiam gerar ganhos. Hoje elaboramos um pacote de 40 processos que vão de processos administrativos como processos voltados para áreas de negócio específicos, como esteira de crédito, ou processos jurídicos de avaliação de contratos, que podem servir como um ponto de partida para construir uma visão customizada com base na experiência da iProcess e que possibilitam entregar ganhos muito mais ágeis para cada cliente.

  • Inscreva-se na lista de contatos da iProcess para receber notícias sobre cursos, treinamentos, novas publicações no blog e datas dos próximos webinares!
    Basta preencher o formulário de contato no site da iProcess:
    http://www.iprocess.com.br/contato

Seja o profissional que vai liderar a Transformação Digital nos negócios da sua empresa

A equipe da iProcess orgulhosamente apresenta o curso de
TRANSFORMAÇÃO DIGITAL ORIENTADA A PROCESSOS,
um programa de treinamento à distância criado para formar os profissionais que conduzirão as organizações para transformar os seus processos com o uso da tecnologia, aliando inovação a eficiência.

Participe desta experiência que alia a teoria à prática, com dezenas vídeo aulas, artigos e cases alinhados com demonstrações de ferramentas e exercícios práticos de modelagem e automação em soluções de diferentes fornecedores, formando conhecimento através de uma vivência que facilitará o desenvolvimento da transformação digital na sua organização.

  • Conheça os conceitos da transformação digital, as tecnologias que viabilizam esta transformação e os benefícios da sua aplicação.
  • Entenda como as plataformas de processos podem se integrar aos sistemas de informação da organização.
  • Aprenda como fazer esta transformação, estudando e aplicando técnicas e ferramentas de redesenho tecnológico, que multiplicam a eficiência dos processos com o uso da tecnologia.
  • Compreenda os principais problemas e desafios e prepare-se para a jornada da transformação digital, analisando como as áreas de negócio podem liderar este movimento.
  • Saiba como aplicar uma metodologia ágil de transformação que traga ganhos rápidos, crescentes e constantes.

Conheça mais, inscreva-se e participe!

Quero me inscrever agora

A parceria entre os processos automatizados e os sistemas já existentes em uma organização

Podemos dizer, a partir da experiência da equipe iProcess em automação de processos, que os processos automatizados e os sistemas informatizados das organizações não competem entre si, eles formam uma parceria, se complementam. Dizemos isto porque são nos sistemas já existentes nas organizações que os processos obtém as informações necessárias para a execução dos fluxos de trabalho, utilizando-se para isto de uma camada de integração. Daí o motivo de acreditarmos que ambos se complementam.

Os sistemas já existentes, que também chamamos de legado, não são descontinuados ao serem integrados ao processo automatizado. O processo será responsável pela conexão entre estes sistemas e os usuários do processo. Através do BPMS (Business Process Management Suite ou System), uma organização automatiza processos para aumentar seu nível de controle e monitoramento na execução dos processos. Assim, um BPMS atua como orquestrador da execução dos processos entre pessoas e sistemas, definindo o fluxo do trabalho e da informação entre estes participantes.

Desta forma, os sistemas se preocupam com o cadastro, atualização e consulta das informações armazenadas em base de dados e os processos com a sua distribuição, tendo o foco na sequência de etapas, prazos, distribuição das atividades, integridade do processo e em fornecer o melhor ambiente possível para que as atividades sejam executadas. Em alguns casos, se faz necessário o armazenamento das informações ao longo do processo, mas são informações específicas para o contexto das instâncias do processo, que servem para controle de estado do fluxo e logs de atividades, por exemplo.

Quando se automatiza um processo, na etapa de levantamento das informações, é que verificamos como a parceria entre os sistemas já existentes na empresa e o processo utilizando BPMS se dará. Algumas das informações levantadas nesta etapa são:

  • Informações consumidas e informações geradas pelo processo, isto é, quais as informações que deverão ser recebidas pelo processo oriundas de sistemas e quais as informações que eventualmente deverão ser enviadas para gravação em sistemas existentes da organização, como, por exemplo, ERP, sistemas contábeis ou cadastros corporativos.
  • Pontos de integração, isto é, em quais atividades do processo deverão ser obtidas/geradas informações que alimentam os sistemas legados.
  • Como que o processo e os sistemas legados conversarão entre si, que normalmente ocorre através da camada de integração, utilizando serviços especialmente construídos para isto.

A implementação de BPMS nas organizações não deve ser orientada a substituir total ou parcialmente os sistemas atuais esperando-se que passe eventualmente a ser o repositório central das informações da organização. O BPMS não é a fonte principal das informações que estão sendo manipuladas, mas atua principalmente como integrador delas, buscando e enviando informações para outros sistemas durante a execução dos processos.

A iProcess disponibiliza em sua plataforma EAD mais informações sobre este assunto, através do Curso TDP – Transformação Digital Orientada a Processos.

Convite para webinar: Do processo analógico ao digital

A iProcess apresenta, em parceria com a Oracle, o webinar:
Do processo analógico ao digital:
Saiba como as novas tecnologias digitais impactarão
os processos da sua organização.

 Com o uso cada vez mais presente em nosso dia-a-dia de tecnologias como Mobile, Internet das Coisas (IoT), computação na nuvem e redes sociais, a digitalização dos processos tornou-se uma exigência do mercado consumidor, que busca formas mais fáceis de interagir com as organizações.

A oferta de soluções cada vez mais amigáveis e próximas ao negócio, oferecidas em ambiente cloud, está tornando a transformação dos processos para o mundo digital cada vez mais acessível a organizações de todo porte.

Neste webinar, Eduardo Britto, Diretor de Consultoria da iProcess, mostrará como as empresas podem vencer seus desafios culturais ou organizacionais para transformar os seus processos analógicos em experiências digitais para os seus clientes.

Participe, o evento é gratuito e será transmitido online ao vivo pela internet!


Apresentado por:
Eduardo Britto, Diretor de Consultoria da iProcess

Data:
10 de outubro de 2017
Horário: 10h (BRT)

Vagas limitadas. Inscreva-se já:

Em que nível devo modelar meu processo?

Uma das principais atividades na transformação de um processo é a sua modelagem. Seja no princípio do projeto, para representar a sua situação atual (AS IS), a criação de modelos para simulação ou comparação de variações, a definição da sua visão de futuro (TO BE) ou o fluxo a ser implementado para automação, a modelagem é importante na representação do processo que está sendo detalhado ou melhorado.

A representação visual do modelo utilizando uma notação gráfica como BPMN é um dos seus aspectos chave da modelagem. O nível de detalhe das atividades no diagrama de processos, entretanto, é frequentemente tema de debate entre os profissionais de Processos.

A notação BPMN, apesar de poderosa e de ter uma gramática bem definida quanto ao uso dos seus elementos, não estabelece qual seria o nível ideal de modelagem do processo. Ela define formalmente que “uma atividade representa um trabalho”. Mas devemos ir por uma abordagem mais alto nível do significado de trabalho (o “trabalho” é aquilo feito por uma área inteira?) ou mais baixo nível (o “trabalho” é cada ação realizada por alguém para atender ao resultado objetivo do processo?).

Não há uma regra para isso, e na verdade cada tipo de modelo pode requerer um nível de detalhe diferente no mapeamento do processo, de acordo com o propósito para que serve aquele modelo.

Por exemplo, em uma reunião no qual estamos buscando um entendimento amplo sobre o processo, com uma visão ponta a ponta em que possamos identificar suas principais etapas, um nível alto seria o mais apropriado.
Mas e quando vamos mapear um processo que será usado como material de treinamento, num manual de processos ou para descrever o trabalho de uma determinada etapa?

Existem alguns critérios que podem ser interessantes de serem questionados pela equipe ao definir o nível de modelagem do processo que estamos criando.

Como oportunidade de reflexão, um de nossos leitores contribuiu recentemente com dois exemplos de processos. Vamos tomar por base então o seguinte exemplo:

1) Nesse fluxo, podemos perceber que o mapeamento está em nível de procedimento, não de trabalho. O trabalho seria, por exemplo, “Avaliar baixa”, que envolve esta sequência de procedimentos: Consultar arrecadações, selecionar arrecadação, …, até confirmar baixa manual. Embora exista uma sequência entre eles, pode ser uma sequência flexível, em que a ordem dos itens pode eventualmente mudar na operação da pessoa no sistema. Esse nível de detalhe é bem comum de ver em processos modelados por profissionais de TI. Cuidado para não confundir o fluxo de trabalho com o fluxo de interação com sistema. Para esse segundo, devemos utilizar UML (Diagrama de sequência ou diagrama de atividades ou até mesmo passos de um Caso de Uso).

2) Pensando no por quê modelamos processos no nível de operação, geralmente fazemos isso para entender o processo e ter um parâmetro para avaliar o seu desempenho, certo? Assim, normalmente as tarefas são utilizadas para determinar o trabalho do processo, onde podemos medir o tempo e custo da sua realização. Neste sentido, será que realmente interessaria para a organização mensurar detalhadamente quanto tempo leva para executar cada um desses passos? Ou é mais importante entender quanto tempo, dentro da dinâmica do processo, um profissional leva para realizar a análise e a baixa, de uma forma consolidada?

3) Geralmente quando mapeamos nesse baixo nível, fica mais difícil representar as exceções. Por exemplo, no caso em que qualquer um desses passos seja possível o ator voltar atrás em alguma ação. Nesse fluxo, teríamos que desenhar também todas as possibilidades de voltar e refazer algum passo. Ou seja, após ele selecionar o ingresso, ele terá que selecionar uma parcela. Mas se ao selecionar a parcela ele se der conta que escolheu o lançamento errado, ele poderia voltar pra selecionar outro lançamento?

4) Um outro fator a considerar é a manutenibilidade do processo. Queremos dizer com isso que qualquer mínima alteração nas ferramentas podem fazer com que você tenha que criar uma nova versão do seu diagrama de processo, tornando a manutenibilidade da documentação mais custosa e também dando mais chance para ela se tornar rapidamente obsoleta.
Se você tem uma tarefa “Avaliar baixa” e nela descreve os procedimentos, e a sua organização mudar do sistema XPTO para o sistema MEGAXPTO, o trabalho feito pela organização continuará sendo o mesmo, que é avaliar a baixa. O processo não mudou, o que mudou foi a ferramenta. Assim, no nível de mapeamento do trabalho, a manutenção fica mais fácil porque não precisará mudar o fluxo, apenas atualizar o procedimento (passos realizados naquela atividade, que podem ser descritivos complementares ao desenho do fluxo).

Se o plano for automatizar o processo, esses critérios podem ser ainda mais relevantes, porque o motor de processos é muito literal na interpretação do modelo. Confira uma outra reflexão semelhante que já fizemos sobre o assunto aqui no Blog da iProcess no artigo: Estudo de Caso: Automatizar o processo (ou não)? Eis a questão!