Não há nenhuma fase de construção que o cliente aguarde sem fazer nada. Cada sessão de trabalho segue o mesmo ciclo, no próprio ambiente do cliente, em telas reais com os dados de amostra do cliente: mostrar a linha do Fit Ledger, configurá-la ao vivo e sem código, o cliente realiza a alteração, verificar com dados de amostra, registrar e marcar a linha como concluída.
Se o cliente não estiver na sessão, a sessão não ocorre. O usuário-chave deve estar no comando até a tela T-14; se o TRANXACT ainda estiver usando o teclado na tela T-13, mencione isso na reunião diária como um risco de adoção.
Sete dias, estrutura antes das transações (padrão proposto)
| Dia T | Foco | Configurado |
|---|---|---|
| T-17 | Estrutura | Entidades, plano de contas, calendário fiscal, dimensões |
| T-16 | Dinheiro e conformidade | Moedas e câmbio, códigos fiscais, numeração de documentos, bancos |
| T-15 | Pessoas e acesso | Funções e permissões, grupos SSO, hierarquia de aprovação |
| T-14 | Dados mestres | Clientes, fornecedores, itens, funcionários — o ASK cria em massa a partir de extrações. |
| T-13 | Fluxos e regras | Fluxos de aprovação, lançamento, correspondência e regras de precificação |
| T-12 | Especificações do módulo | Pipeline de CRM, custos da cadeia de suprimentos, elementos de remuneração de RH, alternância de módulos |
| T-11 | Integrações e filas | Clientes de API, endpoints bancários/fiscais/de folha de pagamento, filas por função |
Mantenha a ordem mesmo quando a estrutura do Fit Ledger for diferente: estruturar primeiro significa que o mapeamento de migração pode começar na transação T-15, e o mapeamento do Razão Geral, do qual tudo o mais depende, existe antes dos dados mestres.
ASK faz o trabalho pesado
Crie em massa 2.400 clientes a partir de um extrato com condições de pagamento por segmento; elabore uma regra de lançamento para frete dividido pelo centro de custo do armazém de recebimento; gere um assistente de contas a pagar que possa inserir, mas não aprovar, faturas acima de 10.000; liste todos os fluxos de aprovação sem um aprovador alternativo. O ASK faz isso com as mesmas permissões e registro de auditoria de um clique humano, e o usuário-chave revisa cada resultado antes que a linha seja marcada.
Solicitações que soam como código
| "Precisamos de..." | A configuração que responde a isso |
|---|---|
| Nosso processo de aprovação exclusivo | Um fluxo de aprovação em várias etapas com regras de valor, entidade e dimensão. |
| Um layout de fatura personalizado | Um modelo de documento com campos, logotipo e idioma por entidade. |
| Um campo que não existe | Um campo personalizado sem código, utilizável em relatórios e regras. |
| Nosso relatório legado exatamente como está. | O criador de relatórios ou o painel de controle — questione o layout; muitas vezes "desnecessário". |
| Uma interface para o banco ou MES | Um cliente de API com uma função definida; troca de arquivos quando necessário. |
| Alertas quando X acontece | Uma regra de fila de ações que leva em consideração a função |
Integrações em tempo real (padrão proposto)
Lista e proprietários até T-18; clientes de API e endpoints de teste de parceiros até T-13; testes de integração até T-10 (folha de pagamento T-9, BI T-6; SSO até T-17, porque o ensaio precisa disso); teste de ponta a ponta na simulação em T-3; mudança para produção em T-0.
Um parceiro que não consegue fornecer um endpoint de teste até o T-13 migra essa integração para o T-Plus com uma etapa intermediária manual — um upload manual de arquivo bancário, um upload no portal pela área financeira e a execução da folha de pagamento no sistema legado com importação de lançamento contábil. O SSO não possui etapa intermediária: ele é necessário para o teste.
O banco de Calderwood disponibiliza seu endpoint de teste dentro do prazo; o ambiente de testes (sandbox) do portal tributário ainda não foi liberado no T-13. A integração tributária se torna uma linha T-Plus, e o departamento financeiro carrega as faturas eletrônicas no portal manualmente durante as primeiras semanas — tudo ensaiado no T-1, como todas as outras etapas.
Experimente Na transação T-12, um usuário-chave solicita que a tela de fatura do fornecedor exiba um campo que o sistema antigo possuía. Isso é código?
Não — trata-se de um campo personalizado sem código no formulário, utilizável em relatórios e regras. Ele recebe uma linha no Razão de Ajuste, é configurado na sessão com o usuário principal responsável, verificado com dados de amostra, registrado na Planilha de Configuração e submetido a uma verificação de configuração no Plano de Teste.