O ERP de pouco código domina a complexidade

ERP

Pouco código

Simplifique projetos complexos de design de móveis

Oportunidade

A Joly Design é uma empresa familiar com uma história de 50 anos. A empresa projeta móveis para várias marcas em todo o mundo, ostentando um banco de dados exclusivo com mais de 70.000 designs. É provável que você já tenha se sentado em uma de suas criações. Seu modelo de negócios é bastante específico: eles não produzem móveis, mas recebem royalties de seus designs. Todo o processo, desde os esboços iniciais até os relatórios de vendas reais, leva meses e era suportado por um sistema de software local de 20 anos. Um arquiteto autônomo, amigo da família, manteve esse sistema durante a última década. No entanto, depois de receber uma oferta de uma startup, ele não pôde mais gerenciar o software. Isso representou riscos significativos para a Joly Design, pois as operações e os dados históricos de 70.000 modelos estavam em risco. Eles precisavam agir rapidamente para enfrentar esses desafios.

Solução

A Joly Design é uma pequena empresa que não podia pagar por um software personalizado tradicional, nem encontrar soluções SaaS prontas para uso que se adequassem aos seus processos comerciais exclusivos. Por isso, decidimos usar o Retool e o Supabase para reconstruir e migrar seu aplicativo de negócios interno legado para uma pilha de tecnologia moderna que prioriza a nuvem. Conseguimos propor um orçamento fixo de apenas 80.000 euros para redesenhar, reconstruir e migrar todos os dados. Esse orçamento cobre o suporte para o fluxo de trabalho de design de modelos, um portal do cliente, trocas, importações de relatórios de royalties, faturamento, contabilidade e gerenciamento de usuários.

Como projetamos a migração de um aplicativo de negócios legado?

A migração de um sistema ERP legado sempre se baseia mais ou menos nas mesmas etapas.

Passamos por todas as jornadas do usuário com os usuários finais do software existente.
Faça anotações de cada tela do aplicativo: quais são os campos, quais são as ações, qual é o fluxo.
Começamos a projetar o novo modelo de dados no Supabase (o que define um modelo? Quais campos para um cliente? Qual fluxo de trabalho para royalties? Qual o formato de uma fatura, etc...).
A próxima etapa é projetar fluxos de usuário e maquetes de alto nível das principais telas de interação. Olga, nossa proprietária de produto, prefere usar quadros Miro, que são mais fáceis de entender para clientes não técnicos como a Joly Design. Eles podem ver o fluxo, as telas, fazer perguntas e comentários diretamente no quadro Miro.

Você pode se perguntar por que não começamos a projetar diretamente em Retool, com iterações curtas, como fizemos em outros projetos de migração de aplicativos legados.

Bem, pareceu-nos que precisávamos de mais tempo para projetar completamente todo o processo e o fluxo de trabalho antes de começar a usar as telas dos aplicativos. Os principais motivos foram que os clientes não técnicos precisam de mais tempo para aceitar a complexidade de seus próprios processos, que eles estão acostumados a executar, mas têm mais dificuldades para sintetizar e criar seu próprio modelo mental. Geralmente, acrescentamos essa primeira etapa de design em projetos muito complexos ou com clientes muito pouco técnicos.

Parte do quadro Miro com todas as jornadas de usuário da Joly Design EPR

Como foi essa migração do software legado para Pouco Código?

Muito bem! Rapidamente projetamos telas para gerenciar modelos. Lidar com imagens de alta resolução foi um desafio, pois o Retool não é realmente feito para artistas, portanto, foram necessários alguns ajustes. A integração da API da Fidealis também foi uma tarefa e tanto. Ela é crucial para o depósito de patentes, em que cada modelo projetado pela Joly Design deve ser depositado e registrado com carimbo de data/hora por esse provedor de serviços terceirizado. Também tivemos algumas idas e vindas na tentativa de criar uma maneira simples e segura de apresentar modelos projetados aos clientes. Anteriormente, as páginas em PDF eram criadas manualmente com os modelos projetados e enviadas por correio para o cliente. Isso foi concluído com a criação de páginas do portal do cliente, nas quais eles agora podem selecionar modelos como em um site de comércio eletrônico, adicionar comentários e remover modelos de que não gostam. Uma maneira incrível de comunicação entre designers e clientes.

Gerenciamento de modelos de portal do cliente

A importação de arquivos de royalties também foi uma tarefa bastante complicada, pois tivemos que lidar com vários formatos diferentes. Acabamos criando um middleware que transformava esses formatos em um único formato pivô, que era então importado para o Supabase.

Ah, a propósito, esquecemos de falar sobre o motivo pelo qual preferimos o Supabase ao Xano para este projeto. O motivo é que, quando temos muitos relatórios financeiros, as consultas SQL diretas são muito mais eficientes do que escrever toneladas de diferentes pontos de extremidade complexos com o Xano. Podemos escrever consultas SQL complexas com muitas variáveis e gerar praticamente qualquer tipo de relatório com poucas consultas. Portanto, nossa regra é simples: se tivermos muitos JOINs e consultas complexas com várias tabelas, provavelmente será melhor usar o Supabase. Por outro lado, se tivermos uma lógica de negócios complexa com processamento algorítmico de dados, o Xano é muito melhor.

Por fim, a migração também foi um desafio, pois precisávamos extrair dados de um servidor Windows 2000 local com 20 anos de idade, com acesso apenas ao TeamViewer. Ninguém nunca havia usado o Windows 2000 em nossa equipe. Ops, tivemos que aprender com lágrimas como os produtos da Microsoft podem ser horríveis :)

No final, depois que treinamos todos na Joly Design, eles se tornaram usuários satisfeitos do novo e poderoso software. Mas o mais importante é que salvamos seus 70.000 modelos e oferecemos a eles uma maneira de continuar projetando móveis para seus traseiros nos próximos 50 anos.

‍