A eterna questão de comprar ou construir seu software (James Monaghan)

Parabéns. Você tem um problema, um projeto, um orçamento e um prazo. Em vez de atirar em pessoas, o software é a solução, mas agora você precisa decidir entre construir ou comprar, essa é a questão. Ou é? Não tenho mais tanta certeza de que seja uma decisão clara.
Build use para se referir à contratação de programadores internos para codificar qualquer sistema que seja necessário e buy refere-se aos produtos prontos para uso que podem ser adquiridos e executados. Isso fazia sentido quando falávamos sobre sistemas de contabilidade, sistemas de negociação, CRM, relatórios,
Empréstimos, cobranças, CLM, etc. Agora vivemos em um ambiente de baixo código, onde construir algo não requer experiência em codificação. Pode ser arrastar e soltar. Junte isso à compra de soluções prontas para uso que acabam sendo tão personalizadas que você pode querer
bem, construí-lo. Então, onde isso nos deixa para tomar a decisão de construir ou comprar? Vejamos o que realmente precisamos.

Nenhum sistema moderno pode mais contar com um único ponto de entrada. As expectativas do cliente determinam que vários canais são necessários. Pessoalmente, por telefone direto ou call center, e-mail, mídia social, SMS, web, celular, tablet – tanto habilitado para celular quanto nativo
aplicativos, todos com a necessidade de serem intercambiáveis ​​sem perder conteúdo ou contexto. Um cliente que começa na filial/loja ou pessoalmente, mas precisa sair para um compromisso, deseja poder continuar de onde parou quando fizer login on-line mais tarde naquele dia. Ou
se começarem online, mas ficarem frustrados e pedirem ajuda, não vão querer ter que iniciar o processo desde o início. Isto também se aplica às partes interessadas internas. A cadeia de informações dentro de uma organização precisa ser tão flexível quanto o cliente enfrenta.
opções. 

Então, o que vem a seguir para nossas entradas de dados iniciais em qualquer lugar? Bem, há uma razão pela qual precisamos desses dados em primeiro lugar. Quer um novo cliente queira trabalhar com a organização, um cliente existente queira um novo produto ou serviço, ou mesmo apenas dúvidas e reclamações do dia a dia
ou pedidos de informação. Tudo isso deve iniciar processos definidos, mas flexíveis, para concluir a solicitação da maneira mais eficiente e fácil possível. O processo é geralmente definido e normalmente a equipe é treinada para seguir uma sequência de tarefas para concluí-lo com prazos predeterminados.
ações baseadas em determinadas entradas de dados. 

Nem os clientes finais nem os usuários do sistema devem ter que redigitar as informações em qualquer lugar se elas já tiverem sido capturadas em algum lugar. Na verdade, se as informações estiverem disponíveis em qualquer lugar da organização ou de fontes terceirizadas, como provedores de dados, agências de crédito,
fornecedores de rastreio, etc., deve estar acessível durante todo o processo a todos os utilizadores que dele necessitem. O processo é definido, mas os pontos de contato devem ser intercambiáveis ​​e os dados coletados devem ser integrados sempre que possível e estruturados sempre que possível.
Menus suspensos, valores de pesquisa, campos de data e valores de texto livre controlados para garantir a captura antecipada do máximo de qualidade de dados. Isso permite muito mais automação em todo o processo e menos tratamento de exceções.

Agora que os dados estão em processo de captura ou atualização ativa, a inteligência artificial pode ser aplicada. A equipe não precisa saber todos os detalhes e até mesmo os membros mais novos podem trabalhar em casos mais complexos porque o sistema usa regras codificadas por políticas
lógica para tomar decisões automaticamente que a equipe anteriormente precisava ter amplo treinamento e experiência para lidar. Chega de erros e ao mesmo tempo permite supervisão e até mesmo verificações de controle de qualidade ou filas de exceções para intervenção manual, se necessário.

Tudo isto requer uma abordagem sistemática. A velha ideia de uma pasta manilla que fica na gaveta dos funcionários para sua carteira de clientes está ultrapassada e cria um risco desnecessário. Clientes sendo processados ​​isoladamente podem ser limitantes e redundantes
ao mesmo tempo. Se um cliente corporativo tem diretores que trabalham com vários outros clientes, por que cada avaliação individual ignoraria o panorama geral? Você também revisará o mesmo diretor várias vezes em todos os relacionamentos ou poderia
fazer isso uma vez e reutilizar essas informações em toda a organização?

Eles nem precisam ter partes relacionadas em comum para que o benefício seja aparente. Setores semelhantes, clientes semelhantes, e se os fornecedores/fornecedores de seus clientes também forem clientes? Isso nos leva a como você precisa processar as informações
e por que as organizações precisam olhar para toda a empresa ao considerar o software atualmente. Se você encarar um problema isoladamente e tratá-lo como tal, estabelecendo orçamentos e emitindo RFPs para cada componente de CRM, Fincrime, Client Outreach, você acabará
com o gasto de mais recursos tentando integrar tudo do que qualquer economia potencial inicialmente esperada. Agora aplique isso para cada região ou linha de negócios que possa receber orçamentos e supervisão separados e você terá 8 versões
do mesmo software que precisa ser integrado a si mesmo devido à grande customização por área, eliminando quaisquer economias de escala que poderiam alcançar.

Uma pasta numa gaveta que precisa ser revisada anualmente ou não, com a equipe precisando ser treinada sobre o que fazer e quando fazer. A revisão completa (ou nova integração/produto/serviço adicional/etc) pode ser dividida em partes compostas que podem ou
não pode ser tratado por outras pessoas/equipes. O sistema pode então determinar quando uma tarefa é concluída ou quando dados suficientes são capturados para serem enviados à próxima pessoa para entrada. Todos estes são estruturados como casos e subcasos internos. Desta forma cada elemento
o caso pode ter seu próprio prazo, caminho de escalonamento, responsável e aprovadores. Em vez de uma tarefa grande que um membro da equipe precisa ter experiência suficiente para saber como concluí-la e a quem recorrer para obter vários elementos, o sistema agora atribui o trabalho
e garante sua conclusão oportuna em toda a empresa com o máximo de tarefas automatizadas possível para liberar os tomadores de decisão para se concentrarem no que é importante.

Tudo isso é muito bom do ponto de vista empresarial. O trabalho é conhecido e o que precisa ser feito. Mas quando estamos tentando decidir se devemos comprar ou construir o software nós mesmos, como isso influencia as coisas? Bem, vamos supor que existam múltiplas fontes
de dados em vários sistemas. Espera-se que qualquer sistema moderno seja orientado por API e tenha recursos de pouco ou nenhum código. Uma suposição razoável para software mais rápido e flexível. Tudo hoje em dia precisa ser tratado como uma espécie de microsserviço para evitar
os monólitos de software de estilo antigo. O software deve ser instalado e usado porque é o melhor disponível e preparado para o futuro para se adaptar às mudanças conforme necessário. Muitas ofertas são arraigadas e mantidas apenas porque são muito difíceis e demoradas
para substituir. A maior parte disso ocorre porque as regras são codificadas, provavelmente entrelaçadas com os próprios dados, os dados não são apenas integrados, mas replicados várias vezes para cada peça separada de software na cadeia de informações e se você tentar substituir uma peça, o
todo o sistema pode quebrar. Muito do antigo processo de pensamento, se não estiver quebrado, não conserte. O que é realmente necessário é que todos esses componentes sejam microsserviços, coletando os dados necessários, aplicando regras automatizadas ou entradas/revisões do usuário e
passando-o para o próximo microsserviço. Os dados não devem ser armazenados em mais de um local. Pode ser federado, mas não replicado fora dos backups. Seus sistemas CRM, Onboarding, KYC, Client Outreach, etc. devem acessar apenas os dados de que precisam e não
ser repositórios de dados, a menos que você tenha escolhido um. Replicar os mesmos dados em vários locais e as regras que os regem é um exercício de futilidade, pois cada sistema extra adicionado multiplicará as complexidades envolvidas.

Isto nos leva à consideração final. Quer você tenha uma única fonte de verdade/Golden Copy ou vários registros e sistemas redundantes e concorrentes que possam atualizá-los, você ainda se encontrará em outra camada de requisitos com base na linha de
negócio, jurisdição, tipos de clientes e produtos/serviços. Um indivíduo é tratado de forma diferente de uma empresa ou trust e difere de acordo com as linhas de negócios do consumidor/varejo, comercial ou corporativa quanto aos requisitos e adequação. No mais básico dos exemplos, se
temos 10 tipos de clientes (individual – solteiro, casado, etc, empresa privada, empresa pública, trust, caridade, etc) e você pode atuar em 10 regiões, podendo oferecer 10 tipos de produtos/serviços, já estamos em potencialmente mais de 1000 regras que poderiam
ser aplicado. Não seria muito mais fácil definir regras para uma região, para uma linha de negócios, para um tipo de cliente e produtos ou serviços e deixar que o sistema resolva os requisitos? Removendo duplicatas e reutilizando pontos de dados que estavam anteriormente
oferecido. Este é o benefício de abstrair o processo e as regras da camada de dados. 

Portanto, agora, quando consideramos a velha questão de comprar ou construir software, sabemos que precisamos de orquestração omnicanal, automação de processos sempre que possível, lógica de regras flexível, gerenciamento de casos para supervisão e auditabilidade, baixo código e orientado por API, uma abordagem abstrata
camada de dados e um mecanismo de regras inteligente que pode herdar de diferentes camadas lógicas. O mercado de tecnologia está cheio de inovadores que satisfazem com prazer todos os problemas de nicho que podem ser pensados, mas em que ponto deixa de fazer sentido ter “pronto para uso”?
produtos que precisam ser personalizados e integrados entre si, em vez de construí-los você mesmo. Plataformas de baixo código podem permitir que você tenha 80% de seus requisitos disponíveis e você só precisa configurar esse delta de 20%. O melhor dos dois mundos é um baixo
plataforma de código para a qual outros também criaram componentes reutilizáveis, para que você possa obter os produtos "prontos para uso" como aceleradores para o seu negócio, ao mesmo tempo que permite que sua equipe ou terceiros certificados criem o restante dos requisitos específicos
para sua organização. Comprar ou construir? Realmente deveria ser ambos.