Come creare un'app web per i flussi di approvazione degli acquisti

Definisci obiettivi, ambito e stakeholder

Prima di scrivere specifiche o scegliere strumenti, chiarisci molto bene il motivo per cui stai costruendo un'app web per gli acquisti. Se salti questo passaggio, potresti finire con un sistema di richieste d'acquisto che funziona tecnicamente ma non riduce gli attriti reali: approvazioni lente, responsabilità poco chiare o 'procurement in ombra' che avviene via email e chat.

Chiarisci i problemi che stai risolvendo

Inizia nominando il problema in linguaggio semplice e collegandolo a risultati misurabili:

• Tempo ciclo: richieste bloccate in attesa, inseguire gli approvatori, escalation dell'ultimo minuto.
• Visibilità: nessun posto unico dove vedere cosa è in sospeso, chi ne è responsabile e cosa è bloccato.
• Conformità e rispetto delle policy: preventivi mancanti, categoria di spesa errata, approvazioni fuori ordine.
• Controllo del budget: approvazioni senza conferma della disponibilità di budget o finanza che lo scopre troppo tardi.

Una domanda utile: che cosa smetteremmo di fare se l'app funzionasse perfettamente? Per esempio: 'smettere di approvare via thread email' o 'smettere di reinserire gli stessi dati in un ERP'.

Elenca gli stakeholder principali (e cosa servono)

Un workflow di approvazione tocca più persone di quanto immagini. Identifica gli stakeholder presto e raccogli i loro vincoli non negoziabili:

• Requester: invio rapido, stato chiaro, minimo scambio di informazioni.
• Approver (manager, responsabili budget): revisione semplice, contesto sufficiente (budget, fornitore, cronologia) e azioni fruibili anche da mobile.
• Finance: approvazioni di budget, codifica corretta, registro di audit, reporting.
• Procurement: controlli di policy, onboarding fornitori, gare competitive, allineamento con il processo PO.
• IT/Sicurezza: SSO, controllo accessi basato sui ruoli, conservazione dati, integrazioni.

Coinvolgi almeno una persona per ciascun gruppo in una breve sessione di lavoro per concordare come dovrebbe funzionare il routing delle approvazioni.

Definisci criteri di successo misurabili

Scrivi cosa significa 'migliore' usando metriche che puoi misurare dopo il lancio:

• Tempo mediano di approvazione (end-to-end e per fase)
• % di richieste che seguono la policy (campi obbligatori, approvazioni richieste)
• Tasso di adozione (richieste create nell'app vs. esternamente)
• Tasso di rilavorazione (richieste rimandate per info mancanti)

Queste diventano la tua stella polare quando si discute sulle funzionalità.

Decidi l'ambito (per non voler fare tutto subito)

Le scelte di ambito guidano il tuo modello dati, le regole di business e le integrazioni. Conferma:

• quali dipartimenti e regioni sono nella fase 1
• valute supportate, tasse e aspettative di cambio
• se servono più entità legali e centri di costo
• politiche di soglia (es. approvazioni di budget sopra X, revisione procurement sopra Y)

Mantieni la fase 1 contenuta, ma documenta ciò che deliberatamente non fai ora. Questo facilita l'espansione futura senza bloccare il primo rilascio.

Mappa l'attuale processo di procurement e approvazione

Prima di progettare schermate o database, ottieni un quadro chiaro di cosa succede realmente da 'ho bisogno di questo' a 'è approvato e ordinato'. Questo evita di automatizzare un processo che funziona solo su carta o solo nella testa di qualcuno.

Parti da come vengono create oggi le richieste

Elenca ogni punto di ingresso che le persone usano: email al procurement, template spreadsheet, messaggi in chat, moduli cartacei o richieste create direttamente in un ERP.

Per ogni punto di ingresso, annota quali informazioni vengono tipicamente fornite (articolo, fornitore, prezzo, centro di costo, motivazione aziendale, allegati) e cosa manca di solito. I campi mancanti sono una grande causa di rimbalzi e blocchi.

Disegna il percorso di approvazione (e i bivi)

Mappa prima il "percorso felice": requester → manager → responsabile budget → procurement → finance (se applicabile). Poi documenta le variazioni:

• passaggi diversi per categoria (IT, marketing, facilities)
• soglie diverse per importo (es. sotto $1k vs. sopra $10k)
• rotte diverse per centro di costo, regione o entità

Un diagramma semplice è sufficiente. Ciò che conta è catturare dove le decisioni si biforcano.

Registra le eccezioni che rompono il flusso

Annota i casi gestiti manualmente:

• acquisti urgenti che saltano passaggi (o richiedono approvazione postuma)
• acquisti a fonte unica e come viene documentata la giustificazione
• acquisti frazionati per restare sotto soglie di approvazione

Non giudicare le eccezioni: registrale in modo che le regole del workflow le possano gestire intenzionalmente.

Identifica punti dolenti e gap di responsabilità

Raccogli esempi specifici di ritardi: approvatore non chiaro, conferma budget mancante, inserimento dati duplicato, assenza di cronologia di audit. Nota anche chi è responsabile di ogni passaggio (requester, manager, procurement, finance). Se "tutti" sono responsabili, allora nessuno lo è: la tua app dovrebbe rendere questo visibile.

Trasforma il processo in requisiti chiari

Un diagramma è utile, ma il team ha bisogno di qualcosa di realizzabile: un set di requisiti chiari che descrivano cosa deve fare l'app, quali dati deve raccogliere e cosa significa 'fatto'.

Scrivi il 'percorso felice'

Inizia con lo scenario più comune e mantienilo semplice:

Richiesta creata → manager approva → procurement verifica → PO emesso → merce ricevuta → richiesta chiusa.

Per ogni passaggio, cattura chi lo esegue, cosa deve vedere e quale decisione prende. Questo diventa il journey di riferimento e aiuta a evitare che la v1 diventi un contenitore di eccezioni.

Specifica i dati da raccogliere

Le approvazioni spesso falliscono perché le richieste arrivano senza informazioni sufficienti. Definisci i campi obbligatori in anticipo (e quali sono opzionali), per esempio:

• Fornitore (fornitore noto o 'nuovo fornitore')
• Articoli/servizi (descrizione, categoria)
• Quantità e prezzo unitario (o totale stimato)
• Valuta, data necessaria, luogo di consegna
• Giustificazione aziendale
• Centro di costo / codice progetto / responsabile budget
• Allegati (preventivo, statement of work, bozza contratto)

Definisci anche regole di validazione: allegati obbligatori oltre una soglia, campi numerici, e se i prezzi possono essere modificati dopo l'invio.

Decidi cosa è fuori scope per la v1

Rendi esplicite le esclusioni così il team può consegnare rapidamente. Esempi comuni per la v1: eventi di sourcing completi (RFP), punteggi complessi dei fornitori, gestione completa del ciclo di vita dei contratti e automazione della three-way match.

Trasforma tutto in un piccolo backlog

Crea un backlog semplice con criteri d'accettazione chiari:

• Must-have: creare richiesta, allegare documenti, approvare/rifiutare, cronologia base dello stato
• Should-have: promemoria, delega, richiesta di onboarding fornitore
• Nice-to-have: dashboard analitiche, timer SLA, form avanzati

Questo mantiene le aspettative allineate e fornisce un piano di sviluppo pratico.

Progetta il modello dati (Richieste, Fornitori, Budget)

Un workflow procurement riesce o fallisce sulla chiarezza dei dati. Se i tuoi oggetti e le relazioni sono puliti, approvazioni, report e integrazioni diventano molto più semplici.

Parti dagli oggetti core

Al minimo, modella queste entità:

• Purchase Request (PR): requester, dipartimento, data necessaria, giustificazione, valuta, importi totali, stato.
• Line Item: descrizione, quantità, prezzo unitario, categoria, fornitore pianificato (opzionale), info fiscali e dettagli di consegna.
• Vendor: ragione sociale, indirizzo, termini di pagamento, identificativi fiscali (se applicabili), contatti e stato (attivo/bloccato).
• Budget: importo disponibile, periodo e il 'bucket' a cui si applica (centro di costo, progetto, codice GL).
• Purchase Order (PO): collegamento alle linee PR approvate, fornitore, totali finali negoziati e ID di riferimento ERP.

Mantieni i totali PR derivati dalle linee (e tasse/spedizioni), invece di permettere modifiche manuali, per evitare discrepanze.

Richieste multi-linea e approvazioni parziali

Le richieste reali spesso mescolano elementi che richiedono approvatori o budget diversi. Progetta per:

• Approvazioni per linea (approva/nega/modifica a livello di riga)
• Decisioni frazionate (alcune righe approvate, altre rimandate)
• Cronologia delle revisioni (una variazione di prezzo dovrebbe innescare regole di riapprovazione)

Un approccio pratico è avere uno stato header per il PR più stati indipendenti per le linee, poi uno stato aggregato per ciò che vede il requester.

Budget: centri di costo, progetti, codici GL, campi fiscali

Se ti serve fedeltà contabile, memorizza centro di costo, progetto e codice GL a livello di riga (non solo nel PR), perché la rilevazione della spesa avviene di solito a livello di singola riga.

Aggiungi campi fiscali solo quando puoi definire regole chiare (es. aliquota IVA, tipo di imposta, flag prezzo comprensivo di imposte).

Allegati, archiviazione e conservazione

Preventivi e contratti fanno parte della storia di audit. Memorizza gli allegati come oggetti collegati a PR e/o linee con metadata (tipo, caricato da, timestamp).

Definisci le regole di conservazione presto (es. mantenere 7 anni; cancellare su richiesta del fornitore solo quando legalmente consentito) e se i file risiedono nel database, in object storage o in un sistema documentale gestito.

Definisci ruoli, permessi e proprietà

Ruoli e permessi chiari prevengono ping-pong nelle approvazioni e rendono i trail di audit significativi. Parti nominando le persone coinvolte, poi traducilo in cosa possono fare nell'app.

Ruoli core da supportare

La maggior parte dei team procurement copre il 90% dei casi con cinque ruoli:

• Requester: crea e modifica richieste d'acquisto, allega preventivi e risponde a domande.
• Manager approver: approva/restituisce richieste per il proprio team e conferma la necessità aziendale.
• Finance approver: verifica budget, codifica e conformità alle policy (e può richiedere modifiche).
• Buyer (procurement): gestisce la selezione fornitori, converte PR approvate in PO e comunica con i fornitori.
• Admin: mantiene impostazioni, soglie, categorie e accessi utente.

Permessi: decidi 'chi può fare cosa'

Definisci i permessi come azioni, non come titoli, così puoi combinare ruoli in seguito:

• Create: iniziare una richiesta, aggiungere articoli, caricare file.
• Edit: modificare campi (spesso limitato dopo l'invio).
• Approve/Reject/Return: registrare una decisione con commenti.
• Cancel: chi può cancellare e fino a quale fase.
• Export: esportazioni CSV/PDF, accesso API e visibilità report.

Decidi anche regole a livello di campo (es. il requester può modificare descrizione e allegati, ma non i codici GL; finance può modificare la codifica ma non quantità/prezzo).

Proprietà e responsabilità

Ogni richiesta dovrebbe avere:

• un owner (di solito il requester),
• un approvatore corrente (o gruppo di approvazione), e
• un buyer assegnato una volta approvata.

Questo evita richieste orfane e rende evidente chi deve agire successivamente.

Delega, 'acting as' e inbox condivise

Le persone vanno in vacanza. Costruisci la delega con date di inizio/fine e registra le azioni come 'Approved by Alex (delegated from Priya)' per preservare la responsabilità.

Per le approvazioni, preferisci approvatori nominati (migliore auditabilità). Usa le inbox condivise solo per passaggi basati su code (es. 'Procurement Team') e richiedi comunque che un individuo reclami e approvi così che sia registrata una persona come decisore.

Crea un'esperienza utente semplice e veloce

Un'app procurement ha successo o fallisce in base a quanto rapidamente le persone possono inviare una richiesta e quanto facilmente gli approvatori possono dire 'sì' o 'no' con fiducia. Mira a meno schermate, meno campi e meno click, pur raccogliendo i dettagli che Finance e Procurement richiedono.

Rendi la creazione della richiesta difficile da sbagliare

Usa form guidati che si adattano a ciò che il requester seleziona (categoria, tipo di fornitore, contratto vs acquisto one-time). Questo mantiene il form corto e riduce i rimandi.

Aggiungi template per acquisti comuni (abbonamento software, laptop, servizi contractor) che precompilano campi come suggerimenti GL/centro di costo, allegati richiesti e la catena di approvazione prevista. I template standardizzano anche le descrizioni, migliorando la reportistica.

Usa validazione inline e controlli di completamento (es. preventivo mancante, codice budget o data di consegna) prima dell'invio. Mostra i requisiti presto, non solo dopo un messaggio d'errore.

Offri agli approvatori una vista orientata alla decisione

Gli approvatori dovrebbero atterrare su una coda pulita con l'essenziale: importo, fornitore, centro di costo, requester e data di scadenza. Poi fornisci contesto on demand:

• Un riepilogo in una schermata con allegati, giustificazione e impatto sul budget
• Cronologia chiara (chi ha approvato, chi ha commentato, cosa è cambiato)
• Azioni a un tap: Approva, Rifiuta, Richiedi modifiche

Mantieni i commenti strutturati: permetti motivi rapidi per il rifiuto (es. 'preventivo mancante') più testo libero opzionale.

Aggiungi ricerca e filtri che rispecchiano il modo di lavorare

Gli utenti dovrebbero poter trovare richieste per stato, centro di costo, fornitore, requester, intervallo di date e importo. Salva filtri comuni come 'In attesa di me' o 'Pending > $5,000'.

Pianifica approvazioni mobile-friendly

Se le approvazioni avvengono in corridoio o tra riunioni, progetta per schermi piccoli: target tattili grandi, riepiloghi a caricamento rapido e preview degli allegati. Evita flussi che richiedono editing in stile spreadsheet su mobile: rimanda quelle attività al desktop.