Valutare il percorso B2B prima di sostituire l’ERP

Valuterei prima un percorso d’ordine difficoltoso per clienti aziendali (B2B) separatamente dalla sostituzione del sistema di gestione aziendale (ERP). Una ricerca migliore, una lista articoli riutilizzabile o uno stato più chiaro possono essere sviluppati nell’applicazione cliente. La validità del percorso dipende dall’integrazione esistente e dalle regole aziendali necessarie.

Definire il confine per funzione

Un grossista fittizio di forniture tecniche vuole facilitare il riordino. L’ERP esistente resta responsabile dei prezzi cliente e della creazione degli ordini. La seguente ripartizione è una proposta progettuale.

Diventa così visibile quale lavoro riguardi davvero l’interfaccia. Una ricerca migliore non richiede automaticamente una nuova gestione ordini. Aiuta però poco se gli articoli scelti vengono poi trasferiti male al sistema esistente.

La traduzione non crea una capacità mancante

Microsoft descrive un livello di traduzione tra sistemi modellati diversamente. Questo confine può essere utile se applicazione cliente ed ERP usano forme di dati diverse. Nell’esempio dovrebbe mantenere l’associazione concordata invece di creare due logiche di prezzo gestite separatamente.

Se l’ERP non risponde in tempo a una richiesta di creazione ordine, l’applicazione deve gestire l’esito incerto. Riprovare non deve creare un ordine aggiuntivo senza controllo. La pianificazione richiede quindi un’operazione riconoscibile e un modo affidabile per chiarirne l’esito. Un messaggio visivo di successo non fornisce questa prova.

Dove il rinnovo separato incontra un limite

Se il sistema esistente non può fornire i prezzi necessari, creare ordini in modo controllato o supportare le autorizzazioni adatte, una nuova interfaccia da sola non basta. Occorre allora valutare adattamenti, un’altra integrazione o la sostituzione dell’ERP. Scegliere una prima misura più piccola non è un fine in sé.

Non tutti i progetti richiedono un servizio di mediazione aggiuntivo. Se un’interfaccia esistente e mantenuta soddisfa l’associazione necessaria, l’infrastruttura ulteriore deve giustificare il proprio carico di lavoro.

Per il grossista sarebbe significativo un test limitato: trovare un articolo nel contesto corretto, mostrare il prezzo confermato, trasferire un ordine di test e associarne l’esito. Se fallisce l’interfaccia, il lavoro riguarda quella. Se manca una capacità nel sistema centrale, la decisione deve tenerne conto. L’ambito di una sostituzione ERP deriva così da un problema dimostrato.

Fonti

• Microsoft Azure Architecture Center: Anti-Corruption Layer pattern