La fattibilità dipende dall'ERP effettivamente installato, dai dati necessari e dalle operazioni consentite. API, esportazioni e altre modalità autorizzate sono possibilità da verificare, non connettori Digital Employee già garantiti. Finance e IT devono concordare fonti, permessi, test e gestione degli errori prima di collegare il processo.
Verificare un processo, non soltanto il nome dell'ERP
Dire «usiamo questo ERP» non basta a definire un'integrazione. Servono versione, modalità di installazione, personalizzazioni, società coinvolte e operazione richiesta. Leggere uno scadenzario e modificare una registrazione contabile sono incarichi diversi, anche quando riguardano lo stesso sistema.
Partite dal risultato desiderato: quale informazione deve arrivare a quale persona, con quale frequenza? Poi risalite alle fonti necessarie. Per il perimetro del servizio, la pagina Digital Employee per amministrazione e finanza presenta attività da valutare sui sistemi reali. Le modalità tecniche qui descritte sono possibilità generali da verificare, non un catalogo di connettori disponibili.
Quali modalità di accesso si possono valutare
API e interfacce documentate
Un'API è un'interfaccia attraverso cui un programma può richiedere dati o operazioni previste dal sistema. La sua esistenza non dimostra che esponga tutti i campi necessari o consenta l'azione desiderata. Per esempio, Microsoft documenta API REST per Business Central e distingue l'abilitazione online da quella per installazioni locali. È una caratteristica documentata di quel prodotto, non una dichiarazione di compatibilità del nostro servizio. Fonte: documentazione Microsoft delle API v2.0.
Esportazioni concordate
Un file prodotto dall'ERP può essere una fonte da valutare quando la frequenza di aggiornamento è adatta al lavoro. Concordate formato, campi, identificativi, periodo e responsabile della consegna. Un elenco esportato ieri non può essere presentato come stato aggiornato a oggi. Se l'esportazione non contiene una colonna necessaria, il processo deve segnalarlo o essere ridisegnato.
Operazioni tramite interfaccia
Un accesso tramite interfaccia applicativa è un'altra possibilità generale, se autorizzata e tecnicamente sostenibile. Prima di considerarlo, verificate condizioni d'uso, autenticazione, schermate e gestione delle interruzioni. Un cambiamento di schermata o una sessione scaduta sono casi da includere nella valutazione. Non promettete continuità sulla base di una sola esecuzione riuscita.
La checklist comune a Finance e IT
Questa è una checklist pratica di fattibilità, da completare con il responsabile del sistema e del processo. Una risposta «da verificare» identifica lavoro da fare; non equivale a un'approvazione tecnica.
Scorri la tabella in orizzontale per leggere tutte le colonne.
| Area | Informazione da raccogliere | Evidenza utile |
|---|---|---|
| Sistema e versione | Prodotto, versione, installazione e personalizzazioni coinvolte. | Inventario confermato dal referente IT. |
| Fonti e società | Archivi, tabelle o documenti necessari e confini tra entità. | Mappa delle fonti e del proprietario di ciascun dato. |
| API o esportazioni | Campi, operazioni, formati e frequenze effettivamente disponibili. | Documentazione applicabile e campione autorizzato. |
| Permessi | Identità usata, dati accessibili, operazioni ammesse e revoca. | Matrice di accesso approvata e prova dei divieti. |
| Ambiente di test | Dove provare casi ordinari, eccezioni e interruzioni. | Ambiente isolato o dati di prova adeguati al perimetro. |
| Lettura o scrittura | Quali azioni sono informative e quali cambiano il sistema. | Elenco esplicito delle operazioni consentite. |
| Qualità dei dati | Identificativi, duplicati, campi mancanti, valute e date. | Campioni con casi validi, incompleti e ambigui. |
| Gestione errori | Come fermare, assegnare, riprendere e verificare un caso. | Esito osservabile di prove di errore. |
| Manutenzione | Chi segue versioni, credenziali e cambi di formato. | Responsabile e procedura di verifica dei cambiamenti. |
| Accettazione | Quando Finance e IT considerano valido il risultato. | Criteri concordati, evidenze e responsabili della decisione. |
Permessi: rendere verificabile anche ciò che è vietato
Non è sufficiente dimostrare che un collegamento legge un documento: verificate anche che non acceda a società o dati fuori incarico. Definite come si identifica l'integrazione, chi ne autorizza l'accesso e chi può revocarlo. Non usate credenziali personali condivise come scorciatoia da dare per scontata.
Le opzioni dipendono dal prodotto. Per esempio, Microsoft descrive per Business Central un'autenticazione tra servizi basata sull'identità di un'applicazione, con registrazione e autorizzazioni da configurare; raccomanda di assegnare i soli permessi necessari. Fonte: autenticazione tra servizi di Business Central. Il principio operativo da verificare sul vostro ERP è la coerenza fra accesso tecnico e incarico. La guida su permessi e approvazioni approfondisce il passaggio di responsabilità.
Provare errori e volumi, non soltanto il caso migliore
Una risposta incompleta, un accesso revocato o una fonte temporaneamente indisponibile devono produrre un esito riconoscibile. Includete anche i picchi di lavoro nella prova. La documentazione di Business Central online, per esempio, prevede limiti sulle richieste e risposte di errore quando alcuni limiti vengono superati. Fonte: limiti operativi Microsoft. Le condizioni del vostro sistema vanno verificate separatamente.
Se una richiesta di scrittura si interrompe senza un esito certo, ripeterla alla cieca può ripetere un'azione già eseguita. La procedura da concordare deve chiarire come verificare l'esito precedente, quando riprovare e quando coinvolgere una persona. Sono requisiti di progetto da dimostrare nella configurazione proposta, non capacità qui certificate.
Partire da una lettura; valutare le scritture separatamente
Esempio illustrativo: preparare l'elenco delle fatture senza riferimento d'ordine per una società. Si può valutare un flusso che consulta una fonte autorizzata, applica una regola concordata e prepara un elenco con riferimenti e data di estrazione. Il responsabile verifica i casi. Non occorre presumere il diritto di modificare fatture o anagrafiche per produrre quell'output.
Qualunque scrittura successiva richiede un perimetro distinto: campi modificabili, approvazione, controllo dell'esito e modalità di ripristino concordate con chi gestisce l'ERP. Non tutte le azioni si annullano allo stesso modo. Pagamenti, modifiche bancarie e decisioni contabili sensibili restano alle persone autorizzate.
Definire chi mantiene il collegamento
Chiarite chi rileva un aggiornamento dell'ERP, verifica un formato cambiato e gestisce la scadenza degli accessi. Concordate la segnalazione dei guasti, il lavoro che resta in attesa e la ripresa dopo l'intervento. Fate includere queste responsabilità nella valutazione del perimetro e del costo: il collegamento iniziale non esaurisce il lavoro.
La checklist per scegliere il fornitore aiuta a chiedere evidenze su assistenza, responsabilità e uscita dal servizio. Il primo risultato da cercare è una valutazione documentata di ciò che si può fare sui vostri sistemi, con le condizioni ancora da risolvere.