Como elaborar um RFP para TMS: a nossa experiência [+ 5 modelos gratuitos]

Respondemos a RFPs (Request for Proposal) para software de gestão de transportes todas as semanas. Alguns são um prazer de trabalhar. Outros são uma lição sobre o que não fazer.

Este artigo é o que eu construiria se estivesse a conduzir um processo de seleção de TMS do zero hoje. Baseia-se nos RFPs a que respondemos, nos padrões que se repetem entre empresas e setores, no que a maioria inclui e nos erros mais comuns que encontramos.

Se é um especialista em sourcing, grande parte disto parecerá familiar. Esperemos que pelo menos uma parte lhe poupe uma ronda de esclarecimentos desnecessária.

O que é um RFP para TMS?

Um RFP para TMS (Request for Proposal) é um documento estruturado que envia aos fornecedores de software de gestão de transportes. Descreve a sua operação logística e pede a cada um que proponha como o seu sistema a trataria, com base no mesmo conjunto de requisitos. O objetivo é a comparabilidade: as mesmas perguntas, o mesmo formato, o mesmo contexto — para que o que chega de volta possa ser colocado lado a lado em vez de ser lido como cinco argumentos de venda separados.

Nem sempre é necessário. Um RFP justifica-se quando a decisão é complexa ou quando terá de a justificar internamente perante outras pessoas. Se a sua operação logística for simples, uma demonstração do produto e uma conversa com alguns fornecedores são suficientes.

Precisa mesmo de lançar um concurso de transporte com RFP?

Errar neste ponto é o erro mais caro de todo o processo de seleção de TMS. Decida isto antes de qualquer outra coisa.

A questão é a complexidade da sua logística, não a dimensão da empresa.

Lance um concurso de transporte estruturado com RFP se expede a partir de vários locais, utiliza múltiplos modos de transporte e precisa que o sistema se integre com o seu ERP. É nesse caso que precisa de todos os fornecedores alinhados lado a lado, para que nada importante passe despercebido. As transportadoras ligam-se de formas muito diferentes. Uma chama-lhe "nativo", a seguinte encaminha-o discretamente por terceiros. Num processo pouco rigoroso, só se apercebe disso depois de assinar. Demasiado tarde.

Dispense o RFP formal se opera num único local com um punhado de transportadoras e já sabe o que precisa. Porquê? Porque assim que lança um RFP, coloca-se automaticamente no escalão de preços enterprise. Duas ou três boas demonstrações com perguntas certeiras conseguem-lhe frequentemente um sistema melhor, mais barato e mais rápido. Diga a esses dois ou três fornecedores o que expede e o que quer resolver, e peça-lhes que lho mostrem no sistema em produção. Fica a saber em menos de uma hora. E se expede principalmente encomendas em vez de paletes ou carga, pode nem precisar de um TMS completo — o software de envio multi-transportador é uma categoria diferente e mais ligeira, criada precisamente para isso.

Por isso, seja honesto sobre qual das opções prefere antes de começar. Lançar um RFP desnecessário é a forma mais lenta e dispendiosa de comprar um TMS.

Lançar um RFP desnecessário é a forma mais lenta e dispendiosa de comprar um TMS.

Mais um aviso se optar pelo RFP completo. Um processo carregado de linguagem de governação, frameworks metodológicas e exigências de preço fixo demora semanas a responder, e os fornecedores que conseguem absorver essa sobrecarga tendem a ser os grandes e estabelecidos. Por isso, se uma plataforma mais ágil e moderna seria na verdade a melhor opção para si, um processo excessivamente burocrático pode filtrá-la silenciosamente antes de alguma vez ver uma demonstração.

O objetivo é encontrar a solução certa para si. Desenhe o processo em torno disso, não em torno de gerir o próprio processo.

O processo de RFP para TMS em 9 etapas

A seleção de um TMS não tem de ser complicada. Mas precisa de uma sequência clara. Salte etapas e pagará por isso mais tarde — normalmente durante a implementação, quando pressupostos que deveriam ter sido clarificados cedo se tornam surpresas dispendiosas.

Bem conduzido, o processo todo demora entre 8 e 12 semanas. Menos para um âmbito simples, e raramente precisa de mais.

Eis a sequência que funciona:

1. Análise de mercado. Antes de escrever um único requisito, dedique tempo a perceber o que existe. O mercado de TMS evoluiu muito nos últimos cinco anos: existem boas plataformas enterprise, boas plataformas para o mercado médio e soluções SaaS de software de gestão de transportes genuinamente capazes que não existiam há cinco anos. Construa uma lista longa de 5 a 8 fornecedores de TMS que valha a pena abordar.
2. NDA. Envie-o cedo. Vai partilhar dados operacionais como volumes, nomes de transportadoras e detalhes de sistemas internos — um NDA assinado antes de o RFP ser enviado é prática padrão que protege ambas as partes.
3. RFI (opcional). Um breve Request for Information faz sentido se a sua lista longa for ampla e quiser filtrar antes de investir num processo de RFP completo. Limite-o a uma página: contexto da empresa, capacidades principais, intervalo de preços aproximado. O suficiente para fazer uma pré-seleção sem pedir aos fornecedores que escrevam dissertações.
4. RFP. O documento central. Fornece a cada fornecedor o que precisa para propor com precisão. Mais sobre isto no próximo capítulo.
5. Janela de perguntas e respostas. Inclua sempre uma. Os fornecedores terão dúvidas, e as respostas melhoram frequentemente todas as propostas que recebe. Conduza-a por escrito e partilhe todas as perguntas e respostas com todos os fornecedores em simultâneo. Mantém o processo limpo e comparável.
6. Pré-seleção e apresentações. Pontue as propostas escritas e convide 2 a 3 fornecedores a apresentar. A apresentação deve incluir uma demonstração ao vivo do sistema com base nos seus casos de uso reais, não uma demonstração genérica. Se um fornecedor não consegue mostrar o seu cenário no sistema, essa é uma informação útil.
7. Segunda ronda (se necessário). Para uma decisão complexa, uma sessão mais aprofundada focada em lacunas específicas — segurança, integração, condições comerciais — vale o tempo. Não a agende a menos que tenha questões reais por resolver.
8. Decisão e contrato. Alinhe internamente antes de negociar. Saiba quais são os seus requisitos inegociáveis, os compromissos aceitáveis e os pontos de rutura.
9. Onboarding. O processo não termina na assinatura. Os melhores resultados de RFP têm um plano de onboarding acordado antes de o contrato ser assinado.

Calendário de RFP para TMS que pode copiar

Duração aproximada por âmbito:

• Único local sem complexidade: 6 a 8 semanas (pode não precisar de um RFP completo).
• Múltiplos locais + integração com ERP: 8 a 12 semanas.
• Global, multi-entidade, integração complexa: 12 a 20 semanas, provavelmente com duas rondas de apresentações.

Descarregar o modelo de calendário de RFP (.docx)

O que incluir no documento de RFP para TMS

O documento de RFP é a sua ferramenta mais importante em todo este processo. Um bom documento de RFP faz grande parte do trabalho de avaliação por si — por isso, mantenha-o focado. Um RFP conciso de 10 páginas supera um de 30 que tenta cobrir tudo.

1. Carta de apresentação e objetivo

Uma página. Quem é, o que procura, porquê agora. Seja factual. Os fornecedores não precisam de uma declaração de visão — precisam apenas de compreender o seu problema operacional.

2. Calendário

Um cronograma claro com datas reais: emissão do RFP, prazo de perguntas e respostas, submissão, janela de apresentações, decisão. Os fornecedores planeiam o seu esforço de resposta com base nisto. Calendários vagos geram propostas igualmente vagas.

3. Contexto da empresa e operacional

É aqui que a maioria dos RFPs falha, e é a diferença entre propostas comparáveis e uma ronda de esclarecimentos. Não se limite a descrever o seu negócio — descreva a sua operação logística. Quantos locais. Quantas entidades jurídicas. Que modos de transporte (encomendas, LTL, FTL, aéreo, marítimo, ferroviário). Que regiões. Volumes aproximados. Sistemas atuais. O que é "bom" também varia por setor — os requisitos para fabricantes de eletrónica, maquinaria, produtos químicos ou impressão e embalagem não são os mesmos. Este é o contexto de que os fornecedores precisam para dimensionar a sua proposta com precisão. Se não fornecer detalhes suficientes aqui, passará duas semanas a responder a perguntas de esclarecimento que poderiam ter sido completamente evitadas. Este tema tem a sua própria secção mais abaixo, no próximo capítulo.

4. Requisitos funcionais

Uma tabela com o que o sistema precisa de fazer, priorizada por importância: obrigatório / importante / desejável (Excel é suficiente). Peça aos fornecedores que respondam a cada requisito com o seu nível de cobertura: a) nativo, b) de terceiros, c) por personalização, ou d) não suportado. É isto que torna as propostas comparáveis. Mais sobre como construir esta lista mais adiante.

5. Critérios de avaliação

Diga aos fornecedores como vai tomar a decisão: funcionalidade, preço, abordagem de implementação, referências, segurança, equipa. Partilhe a ponderação se estiver disposto a fazê-lo. Quanto mais transparente for, melhores serão as propostas.

6. Modelo de preços

Peça uma discriminação completa: subscrição, implementação, taxas por transação, suporte e qualquer outro custo. Peça uma fatura de exemplo se possível. As estruturas de preços variam muito entre fornecedores, e os custos ocultos têm o hábito de aparecer tarde. Tente descobri-los cedo.

7. Formato de resposta

Diga aos fornecedores exatamente como quer a proposta estruturada e, se fornecer modelos, exija a sua utilização. Propostas comparáveis poupam-lhe dias durante a avaliação, e o formato está inteiramente sob o seu controlo.

Descarregue o modelo de documento de RFP para começar com a estrutura completa acima:

Descarregar o modelo de documento de RFP (.docx)

A informação operacional que a maioria dos RFPs para TMS omite — e por que é a mais importante

Este é o capítulo que gostaria que todos os autores de RFPs para TMS lessem primeiro.

Respondemos a muitos concursos de transporte. Quase todas as propostas que escrevemos precisam de uma ronda de esclarecimentos — e raramente porque os requisitos eram pouco claros. É porque o contexto operacional não estava lá: volumes, estrutura de locais, panorama de transportadoras, sistemas atuais.

Os RFPs que exigiram uma ronda completa de esclarecimentos têm quase sempre uma coisa em comum:

Já vimos empresas passarem semanas a elaborar critérios de avaliação e listas de requisitos, para depois enviarem um RFP que não menciona quantos envios processam por mês.

Sem isso, os fornecedores fazem suposições. E quando fazem suposições, as propostas chegam genéricas, os preços não são definitivos e não há nada sólido para comparar.

Por exemplo, um fabricante global com 10 armazéns e SAP precisa de uma proposta completamente diferente da de um distribuidor com um único local que gere a logística em folhas de cálculo. Se um fornecedor não consegue perceber qual dos dois é, cobre-se com ambiguidades — e acaba com propostas que não se comprometem com nada.

A solução leva uma tarde. Responda a estas dez perguntas no RFP antes de o enviar.

1. Organização e âmbito. Quantas entidades jurídicas e locais estão incluídos? A implementação é paralela ou faseada? Com que independência operam os locais — contratos de transportadoras separados, equipas separadas?
2. Volumes de envios. Número de envios mensais e diários por local, médio e em pico. Sazonalidade. Divisão entre entrada e saída.
3. Distribuição por modo de transporte. Que percentagem é de encomendas, LTL, FTL, aéreo, marítimo? Que modos estão a crescer? Quais são os mais críticos operacionalmente?
4. Panorama de transportadoras. Quantas transportadoras por local e por modo? Partilhadas entre locais ou geridas localmente? Existem transportadoras estratégicas que devem ser prioritárias, ou transportadoras indicadas por clientes que não pode alterar?
5. Geografia e rotas comerciais. Que regiões estão incluídas? Que rotas são mais importantes: domésticas, transfronteiriças, intercontinentais? Portos ou hubs logísticos principais?
6. Situação atual. Como são planeados, reservados e rastreados os envios hoje? No ERP, em folhas de cálculo, nos portais das transportadoras, por e-mail? Quais são os principais pontos de dor no processo atual?
7. Configuração financeira. Quem paga o transporte — uma entidade ou várias? Existem números de conta de terceiros ou de clientes? Como é que o custo de frete é registado e validado hoje?
8. Modelo de negócio. B2B, B2C? Se for misto, qual a proporção. Os requisitos operacionais e de sistema diferem de forma bastante significativa.
9. Panorama de integrações. Que sistemas precisam de se ligar ao TMS: ERP, WMS, CRM? Existem integrações de transportadoras já existentes a manter? Qual o nível de automação necessário desde o primeiro dia?
10. Calendário e condicionantes. Existe uma data-alvo para entrada em produção? Existem marcos internos — fecho do ano fiscal, época de pico, migrações de sistemas — que afetam o calendário?

Nada disto é difícil de escrever. Mas muda tudo no que diz respeito ao que recebe de volta.

Descarregue a lista de verificação de informação operacional para transformar estas dez perguntas numa tabela de preenchimento que insere diretamente no seu RFP:

Descarregar a lista de verificação de informação operacional (.docx)

Como escrever os requisitos funcionais para um TMS

Os requisitos funcionais são o coração do RFP. Acerte neles e obtém uma imagem clara e comparável do que cada fornecedor consegue e não consegue fazer. Erre-os e pode passar semanas a descodificar respostas que dizem todas "sim".

O objetivo não é a lista mais longa. É a mais honesta.

Priorize sem contemplações: obrigatório, importante, desejável

Nem tudo o que quer tem a mesma importância. Use três categorias e mantenha-as:

1. Obrigatório (O): inegociável. Um fornecedor que não o consiga satisfazer fica de fora, independentemente do resto.
2. Importante (I): relevante, mas consegue viver com uma solução alternativa ou uma promessa de roadmap a curto prazo.
3. Desejável (D): bom de saber, mas fica atrás de tudo o que está acima.

A maioria das listas tem demasiados requisitos obrigatórios. Se tudo é crítico, nada é. Seja honesto sobre o que genuinamente impediria o sistema de funcionar para si, e marque apenas esses como obrigatórios.

Peça aos fornecedores que classifiquem a cobertura funcional: nativo / de terceiros / por personalização

Para cada requisito, faça-os responder com uma destas opções:

Esta coluna é onde as propostas ganham ou perdem a sua confiança. Um fornecedor que responde com honestidade e escreve não suportado onde é verdade mostra-lhe como se comportará como parceiro. Um fornecedor que responde nativo a tudo também lhe está a dizer algo importante.

Seja específico na pergunta

"O sistema suporta preços de transportadoras?" vai dar-lhe um inútil "sim". "O sistema consegue calcular o preço de frete para todas as transportadoras, incluindo as que não têm API de preços, e mostrá-los lado a lado por envio?" dá-lhe algo que pode realmente avaliar.

Onde termina o ERP e onde começa o TMS?

Uma das fontes de confusão mais comuns nas avaliações de software de gestão de transportes é onde o TMS termina e o ERP começa.

Processos financeiros como codificação contabilística, custo de desembarque e auditoria de frete são frequentemente tratados do lado do ERP, com o TMS a alimentar os dados para o ERP. Isso é normal e muitas vezes a configuração certa. Mas tem de ser explicitado. Quando um fornecedor responde "tratado via integração com ERP" num dos seus requisitos obrigatórios, aprofunde exatamente o que isso significa para a sua implementação — e quem o desenvolve.

Especifique o objetivo, não a solução técnica

Descreva o que precisa de alcançar, não como o sistema deve tecnicamente alcançá-lo. Requisitos demasiado prescritivos eliminam boas soluções por razões erradas. Deixe aos fornecedores espaço para lhe mostrar uma forma melhor do que aquela que tinha em mente — porque às vezes têm uma.

Uma lista honesta e priorizada de 30 requisitos dir-lhe-á mais do que uma folha de cálculo de 150 linhas onde tudo é crítico e todos os fornecedores assinalaram todas as caixas.

Um conjunto inicial de requisitos de TMS para adaptar

A maioria dos compradores de primeira viagem quer um ponto de partida para a lista, por isso aqui está um conjunto de exemplo com base na nossa experiência, já categorizado, que pode adaptar à sua operação. A lista completa está disponível para descarregar na folha de pontuação abaixo — isto é suficiente para perceber a estrutura.

Descarregue a folha de pontuação de requisitos funcionais, já construída com prioridades e uma coluna de cobertura por fornecedor:

Descarregar a folha de pontuação de requisitos funcionais (.docx)

Como comparar o custo de um TMS (e construir um modelo a três anos)

"Quanto custa um software de gestão de transportes?" é a pergunta que os compradores mais querem ver respondida e que os fornecedores adoram evitar. Mas a taxa de subscrição raramente é o seu custo final. Para uma empresa de média dimensão com múltiplos locais, a implementação e a integração podem até representar mais do total a três anos do que a mensalidade — e é precisamente essa a rubrica sobre a qual os fornecedores são mais vagos. Por isso, a competência aqui está em estruturar a pergunta de forma a que as respostas sejam comparáveis e o custo real seja visível.

Como orientação aproximada, um TMS cloud para o mercado médio tende a custar de algumas centenas a alguns milhares de euros por mês, enquanto os sistemas enterprise tradicionais vão de dezenas de milhares a mais de um milhão por ano, com implementações que podem atingir seis ou sete dígitos. É um intervalo muito amplo — razão pela qual um modelo comparável importa mais do que qualquer número isolado. Para ter uma ideia do que os fornecedores de TMS realmente cobram, consulte a nossa análise dos principais fornecedores de TMS.

Componentes de preço de um TMS

Quase todas as cotações de TMS são alguma combinação destes elementos:

Construa um modelo de custo a três anos antes de comparar

Um fornecedor de TMS que parece barato na subscrição pode acabar por ser o mais caro quando se somam a implementação, as taxas por transação e o onboarding de transportadoras. Passe todos os fornecedores pelo mesmo modelo:

Custo a 3 anos = implementação + (subscrição anual × 3) + (taxa por envio × volume anual × 3) + suporte + integrações de transportadoras e extras esperados.

Use os seus volumes reais, não um exemplo arrumado do fornecedor. Essa tabela tende a reordenar a lista de pré-selecionados.

Analise os diferentes componentes de preço, não apenas a taxa base

Alguns fornecedores praticam preços baixos na subscrição e recuperam nas taxas por transação ou por transportadora. Isso não é automaticamente mau, mas muda quem é mais barato à medida que cresce. Se o seu volume está a aumentar, um modelo por envio pode ultrapassar um modelo fixo rapidamente. Peça uma fatura de exemplo e os termos de subscrição para comparar o que vai realmente pagar, não uma taxa de tabela.

Uma pergunta que vale a pena colocar a todos os fornecedores: as novas integrações de transportadoras estão incluídas ou são faturadas de cada vez? Algumas plataformas de TMS cobram 5.000 a 10.000 € por nova integração de transportadora e demoram meses, enquanto outras desenvolvem novas integrações sem custo adicional. Para uma empresa de média dimensão que vai adicionando transportadoras ao longo dos anos, essa única resposta pode mover o total a três anos mais do que a linha de subscrição alguma vez fará.

Como avaliar propostas de TMS para além do preço

As propostas chegaram. Todas parecem razoáveis, a maioria diz sim aos seus requisitos e os preços estão numa faixa semelhante. E agora?

É neste ponto que as equipas recaem silenciosamente sobre o preço, porque tudo o resto parece mais difícil de comparar. Não o faça. Eis o que realmente as distingue.

1. Conectividade com transportadoras.

Num TMS, a conectividade com transportadoras é a base de tudo. Como é que o fornecedor se liga efetivamente às transportadoras — através de integrações diretas por API/EDI, agregadores de terceiros, ou de forma nenhuma (ordens por e-mail + PDF independentemente das suas capacidades tecnológicas)? O que acontece quando precisa de uma transportadora que ainda não suportam, quanto tempo demora e qual o custo?

Um fornecedor com conectividade direta e profunda com transportadoras é um animal diferente de um que encaminha tudo por uma camada intermédia. A diferença sente-se na fiabilidade das reservas, na qualidade do rastreamento e em saber se consegue adicionar uma transportadora sem abrir uma nova negociação comercial de cada vez.

2. Harmonização do nível de serviço das transportadoras — este ponto importa mais do que a maioria das pessoas percebe.

As transportadoras não são iguais nas suas capacidades digitais. Algumas têm APIs sofisticadas que cobrem preços em tempo real, previsão de ETA, validação de moradas, geração de etiquetas e eventos de rastreamento detalhados. Outras enviam-lhe uma confirmação de reserva por e-mail e a conversa termina aí. A maioria das redes de transportadoras tem ambos os tipos em simultâneo.

Isso torna-se o seu problema no momento em que liga o seu ERP ou WMS ao TMS. Se a sua integração espera um conjunto completo de dados de cada transportadora — confirmação de reserva, link de rastreamento, etiqueta, estimativa de custo — mas algumas transportadoras não o conseguem fornecer, obtém exceções, processos manuais e lacunas nos seus dados. Uma transportadora fraca quebra a consistência de todo o fluxo de trabalho.

Existem duas formas diferentes de os fornecedores de software de gestão de transportes lidar com isto, e vale a pena decidir qual prefere antes de ler uma única proposta:

• Um TMS mais simples passa o que cada transportadora fornece, e será o seu problema lidar com as lacunas no ERP ou em trabalho manual. Integração mais simples, mais exceções para tratar da sua parte.
• Um TMS que normaliza os dados e preenche as lacunas por si próprio: calcula o custo de frete a partir da sua tabela de preços carregada quando não há API de preços; estima o prazo de entrega quando não há ETA fornecido pela transportadora; gera etiquetas de envio quando a transportadora não o consegue fazer; quando não têm rastreamento, permite que as transportadoras introduzam marcos de rastreamento manualmente, e mais. O software preenche as lacunas nas capacidades técnicas das suas transportadoras, e o seu ERP vê uma estrutura consistente.

Ao avaliar propostas, pergunte diretamente aos fornecedores: como lidam com transportadoras com capacidades digitais limitadas? A resposta diz-lhe muito sobre a maturidade real da plataforma.

3. Honestidade sobre a integração.

Preste muita atenção à forma como os fornecedores descrevem o âmbito da integração (quem faz o quê). Uma proposta que diz claramente "o desenvolvimento do lado do ERP é da sua responsabilidade, aqui está o que fornecemos e como o suportamos" é mais fiável do que uma que sugere "integração perfeita" sem explicar qual das partes trata de qual integração — você ou eles. As surpresas de integração são uma das razões mais comuns pelas quais os projetos de TMS ultrapassam o tempo e o orçamento.

4. Abordagem de implementação.

Uma abordagem faseada — validação operacional manual primeiro e automação depois — é geralmente de menor risco do que um lançamento em big bang. Permite confirmar que o sistema funciona para os seus fluxos de trabalho reais antes de apoiar toda a operação nele. Da nossa perspetiva, os fornecedores que propõem isto sem serem solicitados já passaram normalmente por um arranque complicado. Os que apresentam automação total desde o primeiro dia muitas vezes não.

5. Referências

Peça referências de empresas com operações semelhantes, não apenas de dimensão ou número de colaboradores semelhantes. Uma referência de um distribuidor com um único local não é particularmente útil se estiver a gerir uma operação de fabrico multi-local com integração SAP. E faça as perguntas diretas: "Como correu o onboarding das transportadoras?" "Como decorreu o processo de integração?" "O que aconteceu quando algo não funcionou como esperado?"

6. A própria proposta.

A forma como um fornecedor de TMS responde ao seu RFP é uma antevisão de como se comportará como seu parceiro. Respondeu às suas perguntas diretamente, ou envolveu tudo em qualificações? Assinalou as lacunas com honestidade, ou afirmou cobertura total em todos os requisitos? Demonstrou que compreendeu a sua operação, ou enviou uma versão ligeiramente modificada do seu deck padrão?

Uma proposta que admite não suportado em dois pontos e explica porquê vale mais do que uma que diz sim a tudo. Vai descobrir a verdade de qualquer forma. É melhor descobri-la durante a avaliação do que na entrada em produção.

Descarregue a matriz de avaliação de fornecedores para pontuar os fornecedores com critérios ponderados:

Descarregar a matriz de avaliação de fornecedores (.docx)

A ronda de apresentações dos fornecedores de TMS

As propostas escritas dizem-lhe o que um fornecedor afirma. As apresentações dizem-lhe se consegue comprová-lo.

A esta altura deve ter uma lista curta de 2 a 3 fornecedores. O objetivo da ronda de apresentações é colocar a proposta sob pressão real e ver se o sistema funciona com os seus cenários concretos.

Peça uma demonstração ao vivo, não uma apresentação ensaiada

Uma apresentação ensaiada é uma sequência preparada que mostra o sistema no seu melhor. Uma demonstração ao vivo é você a dizer "mostre-me como trataria este envio, a partir do nosso armazém nos Países Baixos, com a nossa transportadora, à nossa tarifa acordada" — e observar o que realmente acontece.

Prepare 2 a 3 cenários reais da sua operação antes da reunião: uma reserva de saída padrão, um envio que precisa de uma cotação spot e algo mais complicado — como um envio atrasado ou uma transportadora que não fornece rastreamento. Quando um fornecedor continua a desviar-se para a apresentação polida em vez de executar o seu cenário, essa é a sua resposta.

Confronte as lacunas

Todas as propostas de TMS as têm. Vá diretamente às partes onde um fornecedor respondeu parcialmente ou onde tem dúvidas, e fique aí. Não deixe que regressem a algo que funciona na perfeição. Como funciona exatamente isto? Quem faz o quê? O que acontece quando não funciona como esperado?

Traga as pessoas certas para a sala

Do lado do fornecedor de TMS, as pessoas que apresentam devem ser as que vão realmente trabalhar na sua implementação — não apenas a equipa de vendas. Peça isso explicitamente. Do seu lado, traga alguém de TI (se a integração estiver em âmbito) e pelo menos uma pessoa que vai usar o sistema todos os dias. Fazem perguntas diferentes das de procurement, e quer ambos os conjuntos de perguntas feitos.

Segunda ronda, apenas se necessário

Para uma decisão complexa, uma segunda sessão focada em tópicos específicos vale o tempo. Exemplos de tópicos a cobrir:

• Segurança e proteção de dados — solicite um relatório de pentest ou documentação de segurança se a sua equipa de TI ou de segurança da informação o exigir
• Arquitetura de integração — uma sessão técnica entre a sua equipa de TI e a do fornecedor
• Condições comerciais — percorra o contrato, o SOW e os pressupostos linha a linha antes de entrar em negociações formais

Não a agende apenas para repetir a primeira reunião com mais pessoas na sala. Ou resolve questões abertas específicas, ou não deve acontecer.

Confirme os compromissos por escrito

Qualquer compromisso assumido por um fornecedor na sala que não conste da proposta escrita tem de ser confirmado por escrito antes de avançar. Os compromissos verbais não sobrevivem às negociações contratuais. Se um fornecedor de TMS disser "sim, conseguimos fazer isso" sobre algo importante, envie um e-mail no mesmo dia e peça-lhe que confirme.

Contrato e SOW (Statement of Work) de TMS: o que verificar antes de assinar

Escolheu o seu fornecedor. A maioria das equipas "respira de alívio" neste momento. Recomendo que não o faça, porque é aqui que os detalhes que toda a gente ignorou durante a avaliação se tornam silenciosamente o seu problema.

Alinhe internamente antes de negociar

Saiba quais são os seus requisitos inegociáveis, os compromissos aceitáveis e os pontos de rutura antes de a conversa começar. Alterar requisitos a meio da negociação custa tempo, desgasta a confiança e ocasionalmente faz-lhe perder o fornecedor de TMS que realmente queria. Resolva isso internamente primeiro e só depois negoceie.

Perceba o que está a comprar: SaaS, não uma licença

As plataformas de TMS modernas são subscrições SaaS, não licenças de software. Está a subscrever um serviço que o fornecedor aloja, mantém e atualiza — não a comprar um sistema definitivamente. Isso muda o que o contrato tem de cobrir: termos de subscrição, rescisão, propriedade e direitos de exportação de dados, compromissos de disponibilidade, tempos de resposta do suporte. Os modelos de procurement padrão não foram escritos para este modelo, por isso certifique-se de que o seu está atualizado.

O SOW importa tanto quanto o contrato

O Statement of Work especifica o que é entregue, por quem e quando: configuração da conta, onboarding de transportadoras, suporte à integração, formação e os critérios de aceitação que indicam que a implementação está efetivamente concluída. Se não estiver no SOW, não está incluído, independentemente do que foi dito numa reunião ou num e-mail. Leia a secção de pressupostos com especial atenção. É aí que o âmbito é definido condicionalmente. Se a sua lista de transportadoras for maior do que o declarado, ou se o seu ERP precisar de um formato de integração não padrão, a secção de pressupostos decide se isso é uma conversa rápida ou um pedido de alteração com custo.

Seja explícito sobre o que está fora do âmbito

Desenvolvimento personalizado, formação presencial, migração de dados, trabalho de integração nos seus sistemas, alterações do lado das transportadoras. Estes itens são geralmente faturados separadamente. Colocá-los em papel antes de assinar elimina a fonte mais comum — e mais evitável — de fricção na implementação: duas partes que cada uma assumiu que algo diferente estava incluído.

Acorde o plano de onboarding antes de assinar

Não depois. Priorização de transportadoras, calendário de configuração, marcos de integração, critérios de entrada em produção — resolva tudo enquanto ainda tem poder negocial. Um fornecedor que não consegue apresentar um plano de onboarding claro na fase contratual está a dizer-lhe algo que vai querer saber antes de se comprometer.

Após a assinatura: implementação e onboarding do TMS

A maior parte do risco real vive após a assinatura. Três fatores decidem como corre.

1. Migração de dados

Contratos de transportadoras, tabelas de preços, livros de endereços, envios históricos. Decida cedo o que precisa de migrar, o que é limpo primeiro e quem é responsável pelo trabalho. Dados de origem desorganizados são a razão mais comum pela qual a data de entrada em produção vai sendo adiada. Limpe-os antes de migrar, não durante a migração.

2. Sequência de onboarding de transportadoras

Não liga todas as transportadoras no primeiro dia. Priorize por volume e criticidade, coloque as principais em produção e valide-as, e depois expanda a partir daí. É precisamente aqui que a abordagem faseada sobre a qual perguntou durante a avaliação demonstra o seu valor.

3. Adoção pelos utilizadores

As pessoas que fazem reservas de envios todos os dias têm de querer usar o novo sistema. Envolva pelo menos uma delas desde a fase de RFP, forme-as adequadamente durante o período de hypercare (onboarding) e certifique-se de que o fluxo de trabalho diário é genuinamente mais rápido do que o que faziam antes. Uma implementação tecnicamente impecável que a equipa simplesmente não usa continua a ser uma implementação falhada.

10 erros comuns nos RFPs para TMS

Os padrões que vemos com mais frequência, todos num só lugar:

• Sem contexto operacional. O maior de todos. Nenhum volume, nenhuma estrutura de locais, nenhum panorama de transportadoras fornecido aos fornecedores. Uma ronda de esclarecimentos e preços genéricos são garantidos.
• Tudo é obrigatório. Quando todos os requisitos são críticos, a coluna de prioridades não serve de nada e não consegue distinguir um requisito inegociável de um desejável.
• Calendário vago. Sem datas, os fornecedores não conseguem estimar o seu esforço — e as propostas chegam igualmente vagas.
• Especificar demasiado o como. Prescrever a implementação técnica em vez do resultado operacional elimina boas soluções por razões erradas.
• Ignorar a fronteira ERP/TMS. Assumir que o TMS trata de processos financeiros que na realidade pertencem ao ERP, e só perceber isso a meio da implementação.
• Decidir pelo preço. Escolher com base na taxa de subscrição sem um modelo a três anos, ou sem ponderar a conectividade com transportadoras e a honestidade sobre a integração.
• Uma apresentação ensaiada em vez de uma demonstração ao vivo. Assistir à sequência polida do fornecedor em vez de fazer o sistema testar os seus cenários reais.
• Referências que não correspondem à sua operação. Olhar para os logótipos impressionantes, quando essas empresas podem ter operações logísticas que não se parecem nada com a sua. Peça referências semelhantes a si e pergunte-lhes como correu o onboarding e a integração.
• Deixar o onboarding para depois da assinatura. O plano que negoceia com poder negocial supera sempre o que negoceia sem ele.
• Um processo demasiado pesado para o fornecedor certo. A sobrecarga burocrática pode filtrar as plataformas modernas que melhor o serviriam.

Modelos gratuitos de RFP para TMS

Construímos cinco modelos com base nos RFPs a que respondemos, para que não tenha de começar de uma página em branco:

1. Modelo de documento de RFP. A estrutura completa deste guia.
2. Folha de pontuação de requisitos funcionais. Priorizada, com uma coluna de cobertura por fornecedor.
3. Lista de verificação de informação operacional. As dez perguntas numa tabela de preenchimento.
4. Matriz de avaliação de fornecedores. Pontuação ponderada entre fornecedores.
5. Modelo de calendário de RFP. Atividades, datas e responsáveis.

Descarregue o pacote completo — todos os cinco, gratuitos, sem necessidade de e-mail. Aproveite o que for útil e ignore o resto:

Descarregar o pacote completo de modelos de RFP para TMS (.zip)

A Cargoson é um software de gestão de transportes utilizado por fabricantes e grossistas de média dimensão em toda a Europa e América do Norte. Respondemos a RFPs como aquele que está prestes a escrever regularmente — por isso, se preferir discutir os seus requisitos antes de começar a escrever, temos todo o gosto em ajudá-lo a pensar no assunto, sem qualquer compromisso.

Marque aqui uma consulta gratuita de 30 minutos

Conduza bem o processo e valerá cada hora investida.