Implantação de ERP: o checklist que eu queria ter tido antes
A lista que eu montei depois de tropeçar em cada item dela: ambiente, banco, configuração e validação com gente de verdade antes do primeiro dia útil.
A minha primeira implantação de ERP entrou no ar numa segunda-feira e eu passei o dia inteiro apagando incêndio. Nada do que aconteceu era imprevisível. Faltou extensão no servidor, faltou um script de banco que ninguém tinha aplicado e faltou testar o envio de e-mail com uma pessoa de verdade. Todos os problemas cabiam numa lista de uma página, e essa lista só passou a existir depois que eu vivi o dia ruim.
Este texto é essa lista, organizada na ordem em que as coisas travam. Não é uma receita universal, e sim o roteiro que eu sigo hoje para não repetir o mesmo dia.
Ambiente: o que precisa estar de pé antes de tudo
O ERP principal roda com PHP 8.1 recomendado no ambiente atual, com um conjunto de extensões que precisa estar presente. Falta de extensão gera erro que parece bug de aplicação e consome horas de investigação errada, então conferir isso primeiro economiza a parte mais frustrante do processo.
- PHP 8.1 recomendado no ambiente atual do ERP principal.
- Extensões intl, mbstring, curl, json, xml e mysqlnd.
- As extensões pdo_pgsql e pgsql apenas quando o ambiente usar conectores PostgreSQL ou acesso relacionado ao FluxHub.
- MySQL ou MariaDB acessível.
- Servidor web apontando para a pasta pública da aplicação.
- Permissão de escrita na pasta de arquivos graváveis.
- Arquivo de ambiente configurado com as variáveis do ERP.
php -v
php -m | grep -E 'intl|mbstring|curl|json|xml|mysqlnd'Rodar essas duas linhas no servidor antes de qualquer configuração é o menor investimento de tempo com o maior retorno de toda a implantação. Eu não fiz isso na primeira vez e descobri a extensão faltando quando a equipe já estava esperando.
A loja tem um requisito próprio que pega muita gente
A loja pública é uma aplicação independente e tem runtime documentado em PHP 7.4 para a base que ela usa. A documentação registra de forma explícita que PHP 8.1 não deve ser adotado nessa aplicação sem upgrade e testes, porque já foram registrados erros de página não encontrada quando deprecations do framework quebraram o envio de cabeçalhos. É o tipo de detalhe que ninguém adivinha e que derruba uma abertura inteira.
Se a sua implantação inclui vitrine e delivery, alinhe esse ponto com quem cuida da loja virtual e delivery antes de padronizar versão de PHP no servidor. Padronizar parece organização e, nesse caso específico, é risco.
Banco: scripts manuais e a armadilha do arquivo presente
Alguns recursos dependem de scripts manuais de banco, aplicados de forma controlada. O modelo novo de perfis de acesso é um deles, e enquanto a estrutura não estiver aplicada o código mantém degradação controlada para o modelo legado. Isso é bom, porque nada quebra, e é perigoso, porque tudo parece normal.
A mesma lógica vale para integrações: a existência de controller, rota ou driver não comprova credencial ativa nem homologação externa. Cada ponto precisa ser verificado onde vai rodar. Como o desenho de permissões vira registro efetivo está em catálogo de permissões e materialização.
Ordem de configuração numa implantação de ERP
- Ambiente conferidoVersão de PHP, extensões, banco acessível, servidor apontando para o lugar certo e permissão de escrita.
- Scripts de banco aplicados e confirmadosConfirmados, não presumidos. Peça a confirmação a quem aplicou, no ambiente que vai receber a equipe.
- Cadastro da empresa completoSem campo deixado para depois, porque campo em branco reaparece em documento na frente do cliente.
- E-mail funcionando e testadoCom envio real. Este item já me custou uma segunda-feira inteira e não custa mais.
- Perfis desenhados antes das pessoasPerfil pronto transforma cadastro de usuário em tarefa de minutos e evita o improviso que vira Acesso Total.
- Usuários criados no contexto certoEmpresa correta e perfil do cargo. Conferir isso antes de salvar evita acesso órfão.
- Piloto com gente de verdadeUma rotina completa executada por quem vai usar, incluindo as etapas de fechamento.
A validação que ninguém quer fazer e que resolve tudo
O piloto é o item que sempre tenta ser cortado por falta de tempo, e é o único que encontra o que a lista não previu. Coloque uma pessoa por perfil executando o trabalho real por um dia, com os dados reais, antes da abertura. No começo a gente pulava essa etapa achando que os testes de configuração bastavam. Não bastam: eles provam que a tela abre, não que o trabalho acontece.
| Etapa | O que ela prova | O que ela não prova |
|---|---|---|
| Conferência de ambiente | Que a aplicação sobe | Que os recursos que dependem de script funcionam |
| Aplicação dos scripts | Que a estrutura existe | Que os perfis foram desenhados |
| Configuração das telas | Que o painel está montado | Que a equipe consegue trabalhar |
| Piloto com usuário real | Que a rotina acontece do início ao fim | Que o volume do dia normal será suportado |
Checklist final antes do primeiro dia útil
- Versão de PHP e extensões conferidas no servidor que vai rodar.
- Banco acessível e scripts manuais confirmados por quem os aplicou.
- Cadastro da empresa completo e identidade visual aplicada.
- Envio de e-mail testado com uma redefinição de senha real.
- Perfis desenhados, com um usuário real de cada um testado.
- Ninguém operacional com Acesso Total no dia da abertura.
- Alguém de plantão no primeiro dia, com hora combinada para revisar o que apareceu.
Antes de expor o ambiente para um público amplo, passe também por a revisão de segurança antes de produção, que trata dos limites que a documentação assume abertamente. E revise a ordem dos ajustes em configurações da conta e da empresa, que é onde a maior parte das pendências de última hora costuma aparecer.