Ir para o conteúdo

Ponto de vista · Leitura 6 min

Digitalizar os processos de terreno: do papel à aplicação móvel.

O núcleo de gestão está no SAP ou no Odoo, o CRM no Salesforce. E, no entanto, a realidade da empresa continua a escrever-se em cadernos, em fichas fotocopiadas e em grupos de WhatsApp: rotas comerciais, leituras de contadores, receções em armazém, visitas a obras, inquéritos junto de beneficiários. Este fosso entre o terreno e o sistema colmata-se com uma aplicação bem pensada, uma integração séria e equipas envolvidas desde o primeiro dia.

Ponto de vista das nossas equipas de aplicações & digital em Dakar · tomada de posição, experiência de terreno e recomendações

Pergunte a uma direção onde nasce o seu dado mais importante. A resposta raramente é «no ERP». Nasce no agente que visita uma loja de bairro, na obra onde se receciona o cimento, no armazém onde se contam as paletes, na agência rural que abre uma conta ou entrega um apoio, no inquiridor que recenseia agregados familiares. O que o sistema regista a seguir é uma cópia, reintroduzida mais tarde, por outra pessoa, com atraso e com erros. Digitalizar o terreno é fazer nascer o dado certo, uma só vez, no sítio onde ele se produz.

Porque é que o papel e o WhatsApp persistem

Seria fácil ver nisso um atraso. É antes uma resposta racional a restrições reais. O papel nunca fica sem rede. Não pede conta, nem palavra-passe, nem formação. O WhatsApp já está instalado, a fotografia parte num gesto e o responsável vê-a de imediato. Perante isto, muitas aplicações de empresa falharam por razões previsíveis: exigiam uma ligação permanente, reproduziam um formulário de escritório num ecrã pequeno, acrescentavam trabalho ao agente sem lhe devolver nada, e falavam uma língua que não era a sua.

O papel e o WhatsApp têm, no entanto, um custo que se acaba sempre por pagar. O dado chega atrasado, incompleto, impossível de reconciliar com o cliente ou com a encomenda no sistema. As fotografias perdem-se em conversas. Os stocks do sistema nunca correspondem aos stocks reais. Os doadores e os auditores pedem provas que ninguém consegue encontrar. E o conhecimento do terreno fica na memória dos agentes, que partem com ele.

O que uma aplicação de terreno tem de saber fazer

Uma aplicação de terreno não é um ERP em ponto pequeno. É uma ferramenta concebida para um contexto preciso: um telemóvel muitas vezes de gama de entrada, uma mão disponível, uma rede incerta, um utilizador com pressa. Daí decorrem cinco exigências.

  • Funcionar sem ligação. A primeira condição, e a que mais se sacrifica. O agente tem de poder introduzir e consultar os seus clientes, as suas rotas, os seus stocks, sem rede, durante um dia inteiro se for preciso. A aplicação é local primeiro, ligada depois.
  • Sincronizar de forma limpa. Quando a rede volta, os dados partem e regressam sem intervenção, pela ordem certa, sem duplicados, com regras claras quando duas pessoas alteraram a mesma coisa. A sincronização é o verdadeiro núcleo técnico do projeto: há que a conceber, e não sofrê-la.
  • Capturar a fotografia e a posição. Uma fotografia com data, hora e localização vale mais do que um formulário longo: prova de entrega, estado de um contador, avanço de uma obra, presença de um ponto de venda. A posição ajuda também a organizar as rotas e a verificar, sem vigiar, que a visita teve lugar.
  • Manter-se simples. Poucos ecrãs, botões grandes, listas já preenchidas em vez de campos para escrever, valores por defeito inteligentes. Cada campo acrescentado tem de se justificar por um uso real a jusante. Se ninguém lê o dado, não se pede.
  • Falar as línguas do terreno. Francês, wolof ou outra língua nacional consoante as equipas, com pictogramas e, quando é necessário, mensagens áudio. Uma aplicação que o agente compreende sem traduzir é uma aplicação que ele usa.

Ligar o terreno ao núcleo de gestão e ao CRM

Uma aplicação de terreno isolada limita-se a deslocar o problema: em vez de se reintroduzir a partir de um caderno, reintroduz-se a partir de uma base à parte. O valor nasce da integração. Do lado do núcleo de gestão, a receção em armazém atualiza o stock no SAP ou no Odoo; a encomenda registada em rota torna-se uma encomenda de venda; a ficha de obra alimenta o acompanhamento do projeto. Do lado da relação com o cliente, a visita, a reclamação ou a leitura de um ponto de venda enriquecem a ficha no Salesforce, para que a sede e o terreno olhem para o mesmo cliente.

Alguns princípios enquadram esta integração. Os referenciais permanecem no sistema mestre: a lista dos clientes, dos artigos, dos locais vem do ERP ou do CRM, e a aplicação não os recria. As trocas passam por APIs documentadas, com uma gestão explícita dos erros e das retomas. E decide-se, logo no enquadramento, o que sobe em tempo real e o que pode esperar pela sincronização seguinte. É o terreno da nossa oferta aplicações à medida, do ecrã móvel até à integração com o SAP, o Odoo e o Salesforce.

Uma aplicação de terreno bem sucedida reconhece-se por um sinal: os agentes abrem-na porque lhes presta um serviço, e não porque lho pediram.

A gestão da mudança com as equipas de terreno

É aqui que se joga a maior parte dos fracassos, e quase nunca são técnicos. As equipas de terreno já viram passar ferramentas impostas pela sede e depois abandonadas. Sabem que a aplicação tanto pode servir para as controlar como para as ajudar. Não se convencem com uma nota de serviço.

O que funciona, pela nossa experiência: associar alguns agentes desde a conceção, e não apenas na aceitação; devolver-lhes algo logo na primeira versão, uma rota já preparada, um histórico de cliente à mão, o fim de um relatório para refazer à noite; designar elos no terreno, colegas que formam os colegas na sua língua; aceitar um período em que o papel e a aplicação coexistem; e corrigir depressa a partir do retorno de cada semana. As chefias intermédias contam tanto como os agentes: se o chefe de agência ou o diretor de obra continuar a pedir a ficha em papel, a aplicação está morta.

Segurança e dados pessoais

Um telemóvel que circula no terreno transporta dados sensíveis: identidades de clientes ou de beneficiários, contactos, posições, fotografias, por vezes montantes. Pode ser perdido, roubado, emprestado. A aplicação deve, por isso, cifrar o que armazena localmente, abrir-se com uma autenticação adaptada aos usos, guardar no aparelho apenas o que serve para o dia, e poder ser apagada à distância. Os direitos seguem o papel e o perímetro: um agente vê a sua zona, não o país.

A partir do momento em que a aplicação recolhe dados sobre pessoas, entra no âmbito da lei n.º 2008-12. O tratamento declara-se junto da CDP, as pessoas são informadas da finalidade, a recolha limita-se ao que serve essa finalidade, o prazo de conservação é definido. Numa recolha de dados de beneficiários, estas regras contam ainda mais, porque as pessoas em causa são frequentemente vulneráveis. Tudo isto se concebe no enquadramento, e não depois da entrada em produção. A nossa oferta segurança e riscos de TI intervém já nesta etapa.

Um método por iterações, com um piloto

Não acreditamos na grande implementação de uma aplicação concebida em gabinete. Escolhe-se um processo e uma zona: uma equipa de rota, um armazém, uma agência. Observa-se o trabalho real, no local, antes de desenhar o mais pequeno ecrã. Constrói-se uma primeira versão limitada ao estritamente necessário, a funcionar sem ligação desde o início, ligada ao sistema em pelo menos um fluxo. Coloca-se nas mãos dos agentes-piloto em poucas semanas, e corrige-se ao ritmo deles. Mede-se o que conta para o negócio: prazo entre a visita e o dado no sistema, proporção de registos completos, stocks concordantes, tempo devolvido aos agentes. Depois estende-se, zona a zona, levando os elos formados durante o piloto.

Esta maneira de fazer é coerente com aquilo que somos: uma empresa de consultoria de Dakar, cujas equipas podem ir ao terreno, testar com os agentes na sua língua e voltar na semana seguinte. Conceber uma aplicação de terreno para a sub-região a partir da sub-região é a condição para que ela tenha em conta as redes, os telemóveis, as línguas e os hábitos reais. O dado que daí sai alimenta depois o reporting, tema da nossa oferta Data & Analytics, e por vezes os primeiros casos de uso de IA e automação, com a leitura dos documentos fotografados à cabeça.

As nossas recomendações

  1. Partir de um processo, não de uma aplicação. Que gesto de terreno produz o dado de que a empresa mais precisa? É por ele que se começa.
  2. Exigir o funcionamento sem ligação e a sincronização logo no enquadramento. São os dois pontos que não se recuperam a posteriori.
  3. Decidir cedo a integração. Que referenciais vêm do SAP, do Odoo ou do Salesforce, que fluxos sobem, a que ritmo.
  4. Conceber com os agentes e com as chefias de terreno. Devolver-lhes tempo logo na primeira versão.
  5. Tratar a segurança e a lei n.º 2008-12 como exigências do produto. Cifragem, direitos, declaração junto da CDP, informação das pessoas.
  6. Pilotar, medir, estender. Uma zona, algumas semanas, indicadores de negócio, depois a implementação por vagas.

Do papel à aplicação móvel, o caminho não é, antes de mais, tecnológico. Consiste em respeitar o trabalho de terreno tal como ele é, em lhe dar uma ferramenta que o sirva, e em ligar finalmente aquilo que a empresa faz àquilo que regista.

Um processo, uma zona, um piloto

Que processo de terreno quer tirar do papel?

Descreva-nos uma rota, um armazém, uma obra ou uma recolha. Um especialista AGILICIS diz-lhe o que uma aplicação de terreno mudaria aí, como ligá-la ao seu ERP ou ao seu CRM, e por que piloto começar.

Vamos conversar