01 · La premessa
Se un processo richiede tre fogli Excel e cinque email per essere completato, non è un processo. È un sintomo.
L'automazione dei processi non è un tema di RPA bolt-on. È un tema di software engineering che incontra il dominio operativo del cliente. Mappiamo i flussi reali — quelli scritti nelle email, non nei processi documentati — e li riscriviamo come sistemi software propri.
L'approccio è quello degli Extreme Contracts: per ogni step automatizzato esiste un input ben tipizzato, un output verificabile, un side-effect dichiarato. Niente comportamenti emergenti, niente sorprese a fine mese.
E applichiamo Test-Driven Development dal giorno zero: ogni step ha test che girano in CI prima del merge. Un workflow che muore alle 3 del mattino senza un alert e senza un test è un workflow che non esiste.
04 · Il contratto
Precondizioni, postcondizioni, invarianti.
Ogni engagement ha precondizioni esplicite, postcondizioni misurabili e invarianti che non violiamo. Sai cosa serve all'inizio, cosa esce alla fine, e cosa non negoziamo nel mezzo.
Precondizioni / cosa serve da te
- Sponsorship operativo: chi gestisce oggi il processo è disponibile a parlare con noi.
- Accesso ai sistemi di origine (CRM, ERP, etc.) o agli ambienti di staging.
- Definition of done chiara: cosa misura il successo? Ore salvate? Errori ridotti? Tempo di processo?
- Permessi e governance: chi può cambiare cosa, e chi deve approvare i deploy.
Postcondizioni / cosa garantiamo
- Workflow in produzione, con SLA misurato sui run reali (non sui test).
- Riduzione misurabile del lavoro manuale — KPI concordato all'inizio.
- Codice e runtime nel repository del cliente; nessun lock-in su nostre piattaforme.
- Team interno in grado di aggiungere step e fixare bug entro la prima settimana post-handover.