Qualche settimana fa, un rivenditore specializzato mi ha chiesto se potessimo stampare le bolle di consegna per i suoi clienti finali con il suo logo, i suoi dati mittente e il suo sistema di numerazione. Ha chiesto con quel tono apologetico che si assume quando si è abituati a ricevere un no a domande del genere. Presso un distributore che utilizza un software standard, la risposta sarebbe stata effettivamente no – o, più precisamente: un ticket aperto con il fornitore del software, un posto nello schedule di rilascio e una data di implementazione per qualche momento dell'anno prossimo. La nostra risposta è stata: da lunedì. Il motivo risale a trentotto anni fa e, all'epoca, non era una strategia ma una necessità. Quando abbiamo iniziato nel 1988, semplicemente non esisteva un software adatto da acquistare per quello che facciamo. Avremmo potuto comprare qualcosa e adattare i nostri processi ad esso. Abbiamo fatto il contrario e adattato il software ai nostri processi. A posteriori, è stata la decisione più importante che questa azienda abbia mai preso, e voglio essere onesto: all'epoca, non avevo idea di quanto sarebbe stata significativa. Perché un sistema ERP standard fa qualcosa di molto specifico per un'azienda. Impone i propri processi in una struttura che qualcun altro ha progettato per la media di tutti i propri clienti. Ogni eccezione diventa una soluzione temporanea, ogni soluzione temporanea finisce per essere un foglio di calcolo Excel separato, e alla fine metà dell'azienda lavora attorno al proprio software. Si nota abbastanza facilmente dall'esterno, per inciso: ogni volta che si pone una domanda che dovrebbe essere semplice e la risposta è che purtroppo non si può fare perché il sistema non lo consente. Nessun sistema si rifiuta di consentire qualcosa. Nessuno ha scritto il codice per questo, tutto qui. La seconda parte è arrivata nel 1995, anche se all'epoca nessuno la chiamava cloud. Avevamo clienti che si collegavano al nostro sistema per vedere cosa avevamo in magazzino – in un momento in cui il modo usuale per ottenere tali informazioni era che qualcuno ti richiamasse dopo aver controllato il magazzino. Il vantaggio era lo stesso allora come lo è oggi: non chiedi, vedi da te. Nulla di tutto ciò è spettacolare. È semplicemente la differenza tra lavorare e aspettare. Il modo migliore per capire perché ciò è importante è cambiare prospettiva per un momento e chiedere a un produttore di cosa ha realmente bisogno da un distributore. La risposta raramente è "entrate". Quello che vogliono è sapere dove finiscono i loro dispositivi, tempestivamente e nel loro formato, non il nostro. Vogliono che un progetto registrato sia genuinamente protetto piuttosto che superato tre settimane dopo da un prezzo di listino. Vogliono che una variazione di prezzo effettuata dall'oggi al domani si rifletta in ogni listino prezzi clienti piuttosto che concludersi con rinegoziazioni. Se c'è un problema di firmware, vogliono sapere quali numeri di serie sono interessati – non sentirsi dire che purtroppo tracciamo solo i prodotti a livello di articolo. E vogliono che un nuovo prodotto sia disponibile per l'ordine il giorno in cui viene annunciato, completo di tutte le sue specifiche tecniche, piuttosto che quattro settimane dopo, quando qualcuno da qualche parte ha finalmente aggiornato i dati anagrafici. In un sistema standard, ciascuno di questi requisiti è o un costoso modulo aggiuntivo o un processo che due persone devono gestire manualmente. Per noi, è una domanda per i nostri stessi sviluppatori. Ecco perché i produttori ci affidano cose che altrimenti farebbero da soli: preconfigurando intere gamme di dispositivi, creando pacchetti specifici per il cliente e fornendo secondo un piano di rollout piuttosto che nell'ordine in cui arrivano gli acquisti. Questi non sono processi standard, motivo per cui il software standard non può ospitarli. Per te, come rivenditore, lo stesso meccanismo funziona semplicemente dall'altra direzione. I tuoi numeri di prodotto invece dei nostri sull'ordine. Il tuo listino prezzi, che il tuo collega vede anche quando chiama il venerdì. I tuoi accordi quadro con ordini aperti distribuiti su diversi mesi. Un flusso in tempo reale dei livelli di stock e dei prezzi nel tuo webshop invece di un file CSV che arriva via email al mattino ed è già errato a pranzo. Numeri di serie sulla bolla di consegna in modo da poter fornire al tuo cliente finale la documentazione per i suoi dispositivi senza doverla copiare manualmente. E, naturalmente, una bolla di consegna con il tuo logo quando spediamo direttamente al tuo cliente finale. Calcola il valore anche in uno solo di questi punti. Un rivenditore che inserisce manualmente duecento ordini al mese invece di elaborarli tramite un'interfaccia, impiega, quattro minuti per ordine, più di tredici ore al mese a digitare – oltre centocinquanta ore all'anno in cui nessuno sta vendendo; qualcuno sta semplicemente reinserendo informazioni che erano già digitali in primo luogo. E un operatore di webshop i cui dati di stock sono obsoleti di mezzo giorno venderà affidabilmente qualcosa alcune volte al mese che non è più disponibile. Ciascuna di queste cancellazioni costa loro non solo il margine sull'ordine, ma il cliente. Il vero punto, tuttavia, è che entrambe le parti stanno parlando dello stesso sistema. Il feedback di cui il produttore ha bisogno e i dati che desideri estrarre sono semplicemente due estremità dello stesso processo. Se acquisti un sistema e ne agganci un altro di lato, finisci con due sistemi e un foglio di calcolo Excel che li collega – e quel foglio di calcolo dovrà poi essere mantenuto da qualcuno che dovrebbe essere al telefono con te. Ora la parte scomoda, perché questo approccio non è gratuito. Se costruisci il tuo software, sostieni tu stesso i costi di sviluppo – con un prodotto standard, tali costi sono condivisi tra mille clienti. Paghiamo per ogni riga di codice noi stessi, e paghiamo anche per ogni errore noi stessi. Perché introduciamo bug che non esisterebbero in un software acquistato, e quando ciò accade non c'è nessun fornitore a cui puntare il dito. Questo è scomodo, ma è un accordo più onesto: le persone che hanno commesso l'errore sono anche quelle che lo risolvono. In definitiva, è lo stesso principio di cui ho scritto di recente. Se una decisione qui richiede un giorno o un trimestre non dipende da quanto sia intelligente una persona, ma da quante porte ci sono tra la tua domanda e la decisione. Quando si tratta di software, ce n'è esattamente una. Ecco perché la nostra risposta a un requisito insolito non è quasi mai "non si può fare", ma "quando ti serve?". **Ricorda:** "Nessun sistema si rifiuta di consentire qualcosa. Nessuno ha scritto il codice per questo – l'unica domanda è se la persona che può è nello stesso edificio.