Dois fornecedores podem apresentar propostas para ligar o mesmo CRM, sistema de encomendas e programa de contabilidade e, ainda assim, estar a descrever trabalhos muito diferentes. Um pode enviar apenas novas encomendas. O outro pode também relacionar clientes, devolver o estado contabilístico, tratar alterações posteriores e incluir registos antigos.
Para comparar propostas, descreva o que deve acontecer a uma encomenda concreta e quem verifica o resultado. O número de aplicações mostra onde ocorre o trabalho. As regras entre elas mostram o que é preciso construir.
Acompanhe uma encomenda ao longo da ligação
Imagine uma empresa grossista fictícia. A equipa comercial guarda os contactos dos clientes no CRM, os colaboradores aceitam encomendas num sistema próprio e a equipa financeira usa um programa de contabilidade separado. A empresa quer que uma encomenda aceite crie um documento em rascunho para análise da equipa financeira.
Considere a encomenda ORD-204. O cliente tem o identificador C-81 no CRM e a conta A-347 na contabilidade. Alguém tem de confirmar que os dois identificadores dizem respeito ao mesmo cliente. Comparar apenas o nome da empresa deixa a decisão por resolver quando o nome muda ou quando dois registos são parecidos.
Decida depois qual o sistema responsável por cada dado. O CRM pode fornecer o nome do contacto, enquanto a contabilidade fornece os dados de faturação aprovados. O sistema de encomendas pode ser a referência para as quantidades aceites e os preços acordados. Estas são regras propostas para o exemplo; cada empresa tem de acordar as suas.
«Aceite» também precisa de uma definição. A aceitação de uma encomenda pela equipa comercial não significa, por si só, que a equipa financeira aprovou o documento resultante. A documentação da Microsoft sobre o Dynamics 365 Sales ilustra esta distinção com fases separadas para propostas, encomendas e faturas. É o fluxo de um produto específico. A ligação precisa de regras adequadas ao software e ao negócio em causa.
Os mesmos três sistemas, âmbitos diferentes
Os três âmbitos seguintes são possíveis para a empresa fictícia. Cada um acrescenta trabalho de definição, implementação e verificação, desde que os produtos usados suportem as ações necessárias.
Apenas novas encomendas
Depois de a equipa aceitar uma nova encomenda, envie os campos acordados e os identificadores de cliente existentes à contabilidade para criar um rascunho. A equipa financeira analisa-o aí. As correções posteriores continuam a ser manuais e ficam atribuídas a uma equipa identificada.
Alterações e retorno acordados
Defina também que alterações posteriores à encomenda podem ser transferidas, o que acontece depois de a equipa financeira analisar o documento e que estado contabilístico regressa ao sistema de encomendas. Atribua a uma pessoa as alterações por resolver.
Inclusão de registos existentes
Acrescente um período selecionado de encomendas antigas e os registos de clientes relacionados. Relacione os identificadores, resolva os problemas de dados acordados e verifique o conjunto importado antes de começarem as transferências contínuas.
O âmbito mais pequeno pode chegar. O trabalho manual deve ficar visível na proposta para que o comprador possa decidir se essa solução lhe serve. Os âmbitos maiores exigem uma descrição explícita dos percursos e das decisões adicionais.
Prepare um mapa da ligação que possa ser orçamentado
Comece pelo percurso entre encomendas e contabilidade e registe o que o inicia: «Uma encomenda passa a aceite no sistema de encomendas». Anote o identificador da encomenda e a correspondência entre identificadores de cliente. Liste os campos transferidos e, quando relevante, como são interpretadas quantidades, descontos, moeda e estado. Acorde qualquer tratamento contabilístico com as pessoas responsáveis.
Especifique a ação no destino: criar um rascunho, atualizar um rascunho que ainda possa ser alterado ou enviar o caso à equipa financeira. Indique quem o pode aprovar. Defina o prazo esperado e quando os colaboradores devem investigar uma transferência pendente. «Regularmente» dá ao fornecedor menos informação do que um prazo acordado para a necessidade do negócio.
Descreva separadamente cada percurso de retorno. A contabilidade devolver o identificador de um documento é uma ação. Devolver o estado de um pagamento é outra. Nenhuma implica que todos os dados do cliente ou todos os documentos possam ser alterados nos dois sistemas.
A orientação da Microsoft sobre a tradução entre sistemas explica por que razão diferentes significados dos dados exigem tratamento deliberado, incluindo manutenção e monitorização. Descreve um padrão de arquitetura, não uma obrigação para todas as ligações. Para a proposta, o ponto prático é identificar esse trabalho de tradução em vez de presumir que campos com nomes semelhantes significam a mesma coisa.
Uma descrição útil do percurso de ORD-204 pode dizer: criar um rascunho para esta encomenda aceite com a correspondência de cliente acordada; devolver o identificador contabilístico; mostrar os casos pendentes à pessoa que coordena a equipa financeira. A proposta também tem de definir como são tratadas notificações repetidas e resultados incertos. É um requisito a acordar e verificar, não uma promessa de que cada entrega acontece exatamente uma vez.
Acorde como a equipa vai verificar o resultado
Para cada percurso, registe o que conta como concluído. O envio de uma mensagem, por si só, não mostra se o rascunho esperado existe com o cliente e os totais corretos. Acorde como comparar os registos de origem e destino, detetar resultados em falta ou divergentes e encontrar os identificadores necessários para investigar.
Indique a primeira pessoa ou equipa que recebe uma ocorrência, a informação a que tem acesso e quem pode corrigir o registo de origem ou autorizar outra tentativa. Inclua exemplos como um cliente desconhecido, um campo rejeitado e uma correção que chega após a análise. Decida quais os casos tratados manualmente.
Assim, o mapa da ligação torna-se utilizável: evento inicial, dados de referência, identificadores, direção, significado dos campos, ação no destino, prazo, verificação da conclusão e responsável pelas ocorrências. Acrescente quem fornece contas de teste e confirma que o resultado é aceitável.
Delimite os dados históricos
«Incluir encomendas antigas» levanta mais perguntas do que responde. Escolha os tipos de registo e o período, decida que registos de clientes relacionados são necessários e atribua a responsabilidade de os relacionar e corrigir. Indique o que será verificado depois da importação.
Separe esse trabalho pontual das transferências contínuas. Acorde onde termina o conjunto histórico e começa o processamento corrente, incluindo como são consideradas as alterações durante a transição. Caso contrário, dois fornecedores podem prever quantidades diferentes de preparação e verificação, embora ambos escrevam «importação de dados» na proposta.
Compare os pressupostos e o trabalho contínuo
Peça a cada fornecedor uma proposta para o mesmo mapa da ligação. Solicite que indique o que confirmou sobre as versões dos produtos, operações permitidas, permissões, limites das interfaces e termos dos conectores, e o que ainda precisa de verificar. A existência de uma API ou do logótipo de um conector não confirma que a sua conta possa executar a ação necessária.
Quando falta acesso ou uma regra continua por decidir, pergunte como essa incerteza será resolvida e de que modo afeta a proposta. A orientação do Governo britânico sobre contratação ágil aborda o efeito da informação incompleta nas decisões comerciais da contratação pública. Para esta comparação, a lição útil é tornar os pressupostos claros antes de considerar dois compromissos equivalentes.
Separe a configuração e os testes iniciais das subscrições recorrentes de software ou conectores. Identifique depois o trabalho de operação e manutenção acordado: cuidar das credenciais, verificar transferências pendentes, adaptar a correspondência entre dados e tratar alterações de compatibilidade. Pergunte o que está incluído, quem o faz e como se acordam alterações futuras. Uma linha de subscrição, por si só, não esclarece essas responsabilidades.
Termine a comparação seguindo ORD-204 em cada proposta. Consegue perceber o que chega, quando chega, o que acontece se o processo não for concluído e quem assume o caso? Cada diferença é uma decisão sobre o âmbito a discutir antes de comparar os valores.
Se quiser falar com a LINK-V sobre uma ligação definida, o nosso serviço de integração de API é um ponto de partida adequado. Traga os percursos e as questões em aberto. O âmbito e o trabalho de acompanhamento são acordados para cada projeto.
Perguntas sobre propostas de integração
Um conector existente define todo o âmbito da integração?
Pode cobrir parte da transferência. Verifique a versão do produto, as permissões e as operações suportadas e acorde, para os seus percursos, o significado dos campos, as aprovações, as alterações posteriores e o tratamento de ocorrências.
Porque é que os dados históricos alteram a proposta?
Os registos antigos podem exigir correspondência entre identificadores, correção de dados, registos relacionados e verificação. Defina os tipos de registo e o período, quem os prepara e onde a importação passa a dar lugar às transferências contínuas.
Quem deve manter a ligação depois do lançamento?
Indique na proposta quem cuida das credenciais, verifica transferências pendentes, altera a correspondência entre dados e trata questões de compatibilidade. Separe esse trabalho acordado das subscrições e defina como são organizados o suporte e as alterações futuras.
