0 4 min
Simon Collier
- 28 de setembro de 2021
- 04
leitura mínima
Simon Collier (SuisseTechPartners): Seu sistema pode fazer isso?
Há algumas semanas, entrei para a SuisseTechPartners (STP) para dirigir os negócios da empresa na Ásia. Recebi muitos comentários gentis e votos de felicidades de amigos e ex-colegas - uma experiência muito humilde. Mas uma pergunta comum que me fizeram, levando em conta meus quase 40 anos no setor, foi: "O que o atraiu para uma Fintech como a STP"?
Então, tenho refletido sobre isso. Ao longo de minha carreira, comprei e/ou implementei muitos sistemas de gestão de investimentos ou de serviços financeiros em nome de meus empregadores ou clientes; alguns se mostraram excelentes opções para casos de uso específicos ou restritos, enquanto outros foram francamente um desastre (e você sabe quem você é). No caso dos "desastres", quase sempre houve um descompasso entre as expectativas do cliente estabelecidas durante o processo de vendas e a realidade funcional do sistema quando ele estava sendo implementado. De acordo com minha experiência, o esforço despendido na construção de uma RFP "precisa e precisa", juntamente com uma abordagem de "teste e verificação", é um importante indicador do resultado final. É claro que sempre há situações em que uma decisão de compra é tomada devido à reciprocidade ou a algum outro critério não relacionado ao desempenho funcional do sistema proposto, mas essas decisões quase nunca funcionam bem para as pessoas que precisam implementar e operar esse sistema!
A título de ilustração, há alguns anos, iniciei uma pesquisa de RFP para uma plataforma de contabilidade de investimentos com ênfase específica nesses requisitos essenciais, além da funcionalidade básica usual desses sistemas:
- Nativo da nuvem, com pegada local zero e instalação/treinamento remoto; agnóstico em relação ao provedor de nuvem.
- Nenhum processo de "fim de dia" que afetaria/limitaria o acesso de leitura/gravação de transações de um cliente 24 horas por dia, 7 dias por semana.
- Capacidade de criptografia, incluindo registros baseados em lotes e interfaces que suportam as casas decimais máximas exigidas para ativos digitais.
- Unicode/multilíngue em toda parte, especialmente para idiomas baseados em caracteres de logogramas (por exemplo, Kanji, chinês).
- Recurso abrangente e personalizável de dados/relatórios disponível por meio de um portal on-line.
Enviei uma RFP para uma dúzia de empresas no total, a maioria delas de renome, com os critérios de aprovação específicos mencionados acima. Pouco tempo depois, comecei a perceber como essa "solicitação" específica seria difícil. Ao final da primeira rodada de respostas/análises, cinco empresas haviam se retirado, principalmente por não serem capazes de atender a todos ou a uma combinação desses três requisitos principais:
(i) O sistema não era "nativo da nuvem"/não tinha pegada local zero.
(ii) O sistema não conseguia lidar com os requisitos de criptografia e algumas outras classes de ativos alternativos.
(iii) O sistema não conseguia lidar com Unicode/multilíngue de ponta a ponta, desde dados estáticos até relatórios.
"Enviei uma RFP muito específica para uma dúzia de empresas - uma mistura de fornecedores que vendem plataformas de contabilidade de investimentos. Cinco se recusaram imediatamente a responder devido a 'lacunas funcionais'."
Em uma inspeção minuciosa, outras três empresas não conseguiram atender plenamente a um ou mais requisitos básicos, e várias outras tiveram dificuldades em fornecer uma verdadeira base multimoeda; afinal, nem todo mundo quer dólares americanos como moeda base... A simples pergunta: "Seu sistema pode fazer isso?" tornou-se uma continuação de: "Seu sistema pode realmente fazer isso? Por favor, me mostre". Sejamos claros: manter o Ethereum em uma avaliação de portfólio como um "Ativo Mantido em Outro Lugar" claramente não preenche os requisitos, apesar dos melhores esforços da equipe de vendas.
Após a primeira rodada de eliminações, fiquei com duas empresas na lista de pré-selecionados, e uma delas era a STP. Infelizmente, a pandemia de Covid chegou e esse projeto específico foi adiado por motivos comerciais, mas a STP me impressionou com sua tecnologia moderna, bem como com sua integridade e comprometimento, além de sua clareza quando uma função específica não estava imediatamente disponível ou estava em desenvolvimento.
Embora uma RFI/RFP abrangente seja sempre um ótimo ponto de partida, ela precisa ser redigida com obstáculos de pré-qualificação muito específicos, o que, francamente, poupará muito tempo de todos os participantes. Depois disso, uma etapa abrangente de "Teste e verificação" é fundamental. Tendo recebido muitas RFPs de centenas de páginas, posso dizer que gostaria que essas solicitações fossem explícitas ao detalhar os requisitos mínimos aceitáveis. As RFPs que permitem respostas como "Totalmente/Parcialmente/Não disponível" apenas prolongam a agonia dos fornecedores de tecnologia e serviços que, de outra forma, poderiam ser rapidamente eliminados. Parece-me que a maioria das boas equipes de vendas consegue obter uma resposta de "Parcialmente" para praticamente qualquer coisa...
De modo geral, a lição que aprendi com esse exercício - assim como em muitas incursões anteriores no mundo das RFPs - foi que, embora os atraentes folhetos e sites prometam muito, a realidade é que ainda existem enormes diferenças na funcionalidade e no custo de propriedade, embora cada fornecedor pareça afirmar que oferece tudo o que sua empresa pode precisar.
Portanto, agradeço a todos por seus votos de sucesso e espero que isso explique o que me atraiu a trabalhar com uma empresa como a Suisse Tech Partners. Lembrem-se de fazer suas RFPs "afiadas e pontiagudas" com critérios claros de aprovação/reprovação para seus "itens obrigatórios", seguidos por um processo abrangente de "teste e verificação". A pergunta: "O seu sistema pode fazer isso?" precisa ser baseada em uma pesquisa de RFP precisa e abrangente com critérios claros de obstáculos. No mínimo, isso pouparia muitas árvores...
