Un responsabile operativo richiede un diverso workflow di rilascio degli ordini. La soluzione proposta è un’estensione personalizzata, ma la richiesta di approvazione non chiarisce se l’ERP esistente possa soddisfare il requisito tramite configurazione, se sia il processo stesso a dover cambiare o chi manterrà l’estensione dopo il rilascio.
Approva il requisito di business prima di approvare il metodo di implementazione. La personalizzazione non è di per sé né uno spreco né una scelta strategica. Autorizzala quando un’esigenza operativa documentata giustifica gli impegni continuativi relativi a responsabilità, interfacce, test e supporto. In caso contrario, adotta il processo standard, configura le funzionalità disponibili o valuta un’applicazione esterna.
Questa decisione riguarda una singola richiesta di modifica. Se invece l’analisi rivela che la piattaforma non può soddisfare requisiti aziendali fondamentali, usa il più ampio modello decisionale per migliorare o sostituire l’ERP prima di considerare una successione di estensioni come la risposta.
Stabilisci cosa il processo standard non riesce a ottenere
Apri la richiesta con un risultato da raggiungere, non con il disegno di una schermata. «Replicare la vecchia schermata di approvazione» prescrive una soluzione. «Impedire il rilascio finché il responsabile operativo competente non ha accettato il requisito di gestione specifico del cliente» definisce un controllo di business che potrebbe essere soddisfatto da soluzioni diverse.
In un webinar sulla sovranità digitale dell’ERP, i relatori di SoftEngine respingono le critiche indiscriminate alla personalizzazione, sostenendo che i processi complessi possano richiedere adattamenti specifici. Mettono però in discussione anche la riproduzione automatica dei workflow esistenti: prima occorre stabilire se un processo sia ancora necessario, poi se le funzionalità standard possano supportarlo.
Per chi approva una modifica, l’implicazione è richiedere una dimostrazione dell’alternativa standard proposta. Chiedi al consulente funzionale e al responsabile di processo di eseguire il caso operativo reale, comprese le eccezioni. Una risposta convincente identifica con precisione il controllo o il risultato mancante. «Gli utenti preferiscono il vecchio metodo» non è una prova equivalente, anche se un problema di usabilità dimostrato, che impedisce un’esecuzione affidabile, merita attenzione.
Documenta perché il requisito è importante: un obbligo contrattuale, un vincolo operativo, un controllo necessario o una capacità di servizio commercialmente rilevante. Non tutte le modifiche giustificate devono differenziare l’azienda. Se il processo standard consente di ottenere il risultato, approva l’adeguamento del processo e la preparazione degli utenti anziché ricostruire comportamenti familiari. Se non ci riesce, documenta la lacuna con sufficiente precisione da orientare la successiva decisione progettuale.
Confronta le opzioni di implementazione sullo stesso requisito
Usa lo stesso scenario di accettazione per ogni opzione. Altrimenti, una dimostrazione della configurazione potrebbe essere valutata rispetto all’intero workflow, mentre un prototipo personalizzato viene accettato dopo aver mostrato soltanto la sua funzionalità più interessante. Considera le opzioni seguenti come alternative da approfondire, non come una graduatoria universale.
| Opzione | Quando considerarla | Evidenze da richiedere |
|---|---|---|
| Adottare il processo standard | Il risultato può essere ottenuto cambiando il modo di lavorare delle persone. | Una dimostrazione realistica del workflow e l’accettazione delle differenze da parte del responsabile di processo. |
| Configurare le funzionalità disponibili | Impostazioni, regole o funzionalità di workflow esistenti sembrano soddisfare il requisito. | Il disegno della configurazione, i suoi limiti e le condizioni di supporto del prodotto applicabili. |
| Integrare un’applicazione esterna | Un’applicazione separata merita di essere valutata per la capacità richiesta. | Accesso alle interfacce, responsabilità sulle transazioni, gestione delle eccezioni e condizioni commerciali continuative. |
| Autorizzare uno sviluppo personalizzato | Rimane una lacuna rilevante e l’estensione proposta dispone di un piano accettabile per il suo ciclo di vita. | Un progetto dal perimetro definito, un meccanismo di estensione supportato, un responsabile della manutenzione e test di regressione. |
Rendi esplicita la terminologia nella proposta. La spiegazione di Oracle ERP-ACE descrive la configurazione come l’uso di funzionalità standard per controllare il comportamento dell’applicazione e la definisce «sempre sicura rispetto agli aggiornamenti». Considerala una caratterizzazione di Oracle, non una garanzia contrattuale per la tua installazione né una prova che un’integrazione riceva la stessa protezione. Chiedi quale prodotto, release, modello di distribuzione e meccanismo utilizzi effettivamente la modifica proposta.
La discussione sulla trasformazione aziendale propone un argomento architetturale più deciso: evitare di accumulare debito tecnico nelle aree che non differenziano l’azienda e scegliere con attenzione dove collocare gli elementi distintivi. Il confronto sul clean core usa SAP come esempio e privilegia un approccio basato sulle applicazioni rispetto all’aggiunta di codice personalizzato. Ai fini dell’approvazione, usa questa opinione per mettere in discussione gli sviluppi non necessari, non per presumere che le regole sulle estensioni siano identiche in tutti i prodotti ERP.
Un’applicazione esterna dovrebbe essere sottoposta allo stesso esame di un’estensione interna. Chiedi perché la sua capacità giustifichi l’interfaccia aggiuntiva, le responsabilità operative e la dipendenza commerciale. Al contrario, non respingere un’estensione personalizzata dal perimetro definito soltanto perché esiste un’altra applicazione. Confronta progetti completi rispetto allo stesso risultato.
Compila la scheda di approvazione della modifica
La scheda seguente è uno strumento decisionale editoriale, non uno standard architetturale convalidato dalle fonti. Allegala alla richiesta di modifica e assegna una persona responsabile a ogni punto irrisolto. L’approvazione dovrebbe descrivere sia l’implementazione sia le responsabilità continuative che vengono accettate.
| Domanda per l’approvazione | Evidenze da allegare | Motivo per sospendere l’approvazione |
|---|---|---|
| Quale risultato non è ottenibile con il processo standard? | Requisito di business, scenario non soddisfatto dal processo standard e conseguenza della mancata risoluzione della lacuna. | La motivazione descrive soltanto una schermata preferita o un’abitudine consolidata. |
| Perché questa opzione di implementazione? | Confronto tra modifica del processo, configurazione, integrazione e sviluppo personalizzato. | Le alternative sono state scartate senza verificare il requisito. |
| Chi è responsabile dell’estensione? | Responsabile di business, manutentore tecnico, accesso al repository e diritti d’uso e modifica concordati. | La responsabilità si limita a sapere chi chiamare. |
| Di quali interfacce e dati ha bisogno? | Inventario delle interfacce, diritti di accesso, autorizzazioni, confini delle transazioni ed eventuali costi applicabili. | «Esiste un’API» sostituisce la verifica delle operazioni richieste. |
| Come verranno testati gli aggiornamenti? | Scenari di regressione, ambiente di test, responsabilità di rilascio e procedura di ripristino. | I test si fermano all’installazione o alla consegna del messaggio. |
| Quali attività continuative devono essere finanziate? | Attività di manutenzione, responsabilità di supporto, impegno per i test e voci commerciali ricorrenti pertinenti. | La stima copre soltanto lo sviluppo. |
| Cosa succede se cambiano il fornitore o la roadmap? | Materiali da consegnare per il passaggio di consegne, alternative di supporto, clausole di uscita e approccio alla dismissione o sostituzione. | Il piano dipende da una funzionalità futura non garantita o da conoscenze del fornitore non accessibili. |
Separa la responsabilità di business dalla manutenzione tecnica. Il responsabile di processo dovrebbe accettare ciò che la modifica realizza e decidere se rimane necessaria. Il responsabile tecnico dovrebbe rispondere dell’implementazione, delle dipendenze e del supporto. Chi si occupa di acquisti o della revisione legale dovrebbe confermare i diritti pertinenti, anziché dedurli dal possesso di un repository di codice.
Se la responsabilità è assegnata a un partner di implementazione, verifica chi eseguirà il lavoro e come avverranno i passaggi di consegne. Questa verifica della capacità di esecuzione rientra nella valutazione del partner di implementazione; la richiesta di modifica dovrebbe registrare le responsabilità concordate, senza ripetere l’esercizio di selezione del fornitore.
Approva manutenzione e accettazione, non soltanto lo sviluppo
Prima di accettare una stima dei costi del ciclo di vita, chiedi un piano di manutenzione dell’estensione ERP articolato in attività e ruoli responsabili. Includi l’analisi delle modifiche rilevanti al prodotto, la manutenzione e l’esecuzione dei test, la risoluzione dei difetti, il rilascio e il supporto operativo. Aggiungi i costi di hosting, interfacce o applicazioni quando il progetto proposto li richiede. Chiedi le ipotesi alla base della stima, anziché applicare una percentuale di manutenzione priva di riscontri.
Scenario di valutazione ipotetico: un’applicazione esterna verifica una condizione per il rilascio di un ordine e restituisce un’approvazione all’ERP. Il trasferimento riuscito di un messaggio non è una prova sufficiente per l’accettazione. Chiedi al team di dimostrare che l’ordine corretto cambi stato, che un’approvazione non autorizzata venga rifiutata e che il personale operativo possa ricostruire quanto accaduto.
Verifica poi gli errori e il ripristino: l’applicazione esterna approva, ma l’ERP rifiuta l’aggiornamento; una risposta arriva in ritardo; un’approvazione viene inviata nuovamente; oppure l’azienda annulla l’ordine prima del completamento. Richiedi che il progetto specifichi chi rileva ogni eccezione, chi riconcilia lo stato del processo aziendale e chi autorizza il ripristino. Questi sono test di accettazione proposti, non affermazioni sul comportamento di un prodotto specifico.
Per gli aggiornamenti, chiedi quali test debbano essere ripetuti e chi decida se la modifica rimanga idonea all’uso. «Compatibile con gli aggiornamenti» è una risposta debole senza la politica di prodotto applicabile e un piano di test per il workflow. Limita o rinvia l’approvazione se il team non riesce a chiarire il meccanismo supportato, gli obblighi legati agli aggiornamenti o la responsabilità degli interventi correttivi.
Verifica le dipendenze prima di autorizzare la modifica
Nella discussione sulla trasformazione incentrata su SAP, un partecipante invita i clienti a insistere per ottenere le API necessarie, compreso l’accesso per lavorare con altri fornitori. L’implicazione utile per la singola modifica è precisa: verifica l’accesso alle operazioni e ai dati richiesti dal progetto prima di approvare un’integrazione. Non equiparare una dichiarazione generale di accesso alla piattaforma al diritto di utilizzare ogni interfaccia necessaria.
Simula un’interruzione delle condizioni previste per l’estensione proposta. Chiedi cosa accadrebbe se il manutentore non fosse più disponibile, un’interfaccia necessaria cambiasse, le condizioni commerciali diventassero inaccettabili o una funzionalità fosse rimossa dalla roadmap. Richiedi al team di distinguere ciò che l’organizzazione può gestire, modificare, sostituire o dismettere da ciò che rimane dipendente da un’altra parte.
Per un’estensione personalizzata, richiedi un repository ispezionabile, istruzioni di build e rilascio, documentazione delle dipendenze, materiali di test e conferma dei diritti pertinenti. Per un’applicazione esterna, esamina l’esportazione dei dati, le condizioni d’uso delle interfacce, la documentazione della configurazione e l’assistenza all’uscita. Sono disposizioni da negoziare e verificare, non diritti da dare per acquisiti.
Prima di approvare la prossima modifica, compila la scheda con il responsabile di processo e il manutentore tecnico, poi raccogli le evidenze mancanti che potrebbero cambiare la scelta di implementazione. Approva l’opzione il cui valore di business giustifica gli obblighi espliciti che comporta, non semplicemente quella con la dimostrazione più convincente.
Se hai bisogno di supporto funzionale o tecnico per valutare quel requisito, confrontati con gli specialisti ERP di Digiventi sulle attività di configurazione, integrazione o sviluppo che stai considerando.
