Il processo di automazione: Team, flussi di lavoro, successo

Dayle Hall: 

Salve e benvenuti alla nostra ultima edizione di Automatizzare l'impresa. Sono il vostro conduttore, Dayle Hall. Questo podcast è stato ideato per fornire alle organizzazioni le intuizioni e le best practice su come integrare, automatizzare e trasformare la propria azienda.

L'ospite di oggi è un veterano della tecnologia con oltre 16 anni di esperienza in tutte le aree dell'integrazione e dell'automazione. Ha iniziato nell'organizzazione IT e ha accresciuto la sua presenza e le sue responsabilità in quest'azienda, dove ora ha un'ampia responsabilità e ha fatto carriera come vicepresidente della tecnologia di Atrium. Oggi abbiamo il privilegio di avere nel nostro podcast Leon Kallikkadan. Leon, benvenuto nel programma.

Leon Kallikkadan:

Grazie. È bello essere qui. Non vedo l'ora di partecipare a questa conversazione.

Dayle Hall: 

Sì, anch'io. Prima di entrare in alcune delle aree di sua responsabilità sugli argomenti che abbiamo esposto oggi, ci dia un po' di informazioni sulla sua esperienza all'interno di Atrium. Non direi proprio che si tratta di umili origini, ma lei ha iniziato praticamente dal basso nell'organizzazione IT. Ci parli quindi un po' di dove ha iniziato, di come è cresciuto e ci faccia sapere cos'è che Atrium fa come organizzazione per dare un contesto agli ascoltatori.

Leon Kallikkadan:

Certo. Ho iniziato ad Atrium come helpdesk di supporto IT tradizionale, se così vogliamo chiamarlo. Assistevo gli utenti finali in caso di problemi, come ad esempio: "Ehi, ho un problema con il mio computer, vado al tuo desk e ti aiuto". Ho iniziato lì più di 16 anni fa, come hai detto tu.

Nel corso di questi 16 anni, ho avuto l'opportunità, mi è stata data l'opportunità e mi è stato affidato il compito di guidare e lavorare su vari progetti. Non mi sono mai concentrato solo sull'IT tradizionale, come le reti e la sicurezza dell'hardware, che sono sempre state aree di grande interesse per me, ma sono stato esposto anche al supporto delle applicazioni e alle applicazioni, e così, lentamente ma costantemente, ho avuto accesso a più progetti tecnologici.

E il gruppo dirigente di Atrium mi ha affidato il compito di far crescere il mio team. Così, ogni volta che si presentava l'opportunità di creare, assumere o guidare un team, la coglievo al volo. Nel 2020 abbiamo lanciato il nostro terzo team, che è quello dell'automazione, responsabile della trasformazione digitale, per così dire, e dell'efficienza. E poi, all'inizio di quest'anno, abbiamo lanciato il nostro team per l'integrazione e le app e l'integrazione e il web. Quindi quattro team sotto di me. Quindi ora supervisiono, non sono più l'uomo dell'IT, l'uomo dell'IT tradizionale, ma ora supervisiono, ho quattro team sotto di me e quattro leader sotto di me che aiutano a fornire tutti i risultati finali all'azienda.

Dayle Hall:

Giusto. È interessante. Quindi ora avete questi quattro team. Correggetemi se sbaglio, si tratta di IT tradizionale, team di applicazioni aziendali, integrazione e web, automazione e trasformazione digitale. È corretto?

Leon Kallikkadan:

Corretto.

Dayle Hall:

Giusto. Ok, quindi avete questi quattro diversi tipi di team. Quello che mi piace fare in podcast e alle persone che stanno ascoltando, è fornire un po' di informazioni sul perché di questi quattro team diversi, ma soprattutto, come fate - quali sono i progetti o le iniziative che avete in cui lavorano insieme?

Leon Kallikkadan:

Già. Ho intenzionalmente suddiviso questi team in modo che ognuno possa concentrarsi sulle proprie competenze principali, giusto? Ognuno di loro, ognuno di questi team ha il suo set di applicazioni o tecnologie principali su cui si concentra. Sono considerati esperti della materia e apportano immense conoscenze e valore al tavolo. È qui che iniziano a lavorare insieme - soprattutto nell'ultimo anno, un anno e mezzo - che mi sono seduto e ho visto tutti e quattro svilupparsi e diventare ottimi membri del team, iniziando a collaborare l'uno con l'altro.

Ad esempio, prima di iniziare un progetto, il nostro team di leadership tecnologica, che è il mio team di leadership, discute di un progetto che potrebbe avere un impatto a livello organizzativo, ma che potrebbe anche avere o collegarsi ad altri team. Quindi, si condivide l'informazione, si condividono i possibili risultati, le possibili sfide o i possibili impatti sui team degli altri. Cerchiamo di capire come i quattro possano sostenersi a vicenda e, ovviamente, anche io. Ma tutti cerchiamo di capire come possiamo sostenerci a vicenda, come ad esempio: "Ehi, possiamo presentare un paio di occhi nuovi, o hai pensato a questo? Cerchiamo di rafforzare, di sfidare. Adoro le persone che si sfidano a vicenda in modo rispettoso. In questo modo si arriva a un risultato migliore del progetto o a una migliore infrastruttura del progetto.

Dayle Hall:

Sì. Mi piace il concetto di discutere o esaminare progetti che, a prima vista, non sembrano avere un impatto sulle responsabilità di tutti o di altri. Ma credo che con la maggior parte delle tecnologie informatiche e delle applicazioni dei dati di oggi, tutti ci rendiamo conto che hanno un grande impatto su più persone e su più organizzazioni. Una delle cose che ho imparato da molti di questi podcast negli ultimi sei mesi o giù di lì è che uno dei consigli chiave che mi sono stati dati da alcuni di questi leader IT è di iniziare a parlare presto, iniziare a condividere le idee e ottenere un feedback prima di fare selezioni, prima di andare a RFP, prima di esaminare le tecnologie, e assicurarsi che tutti siano concentrati su quale sia il vero risultato e quali potrebbero essere esattamente le implicazioni. E credo che più se ne parli in anticipo, probabilmente l'implementazione sarà più fluida. Avete riscontrato la stessa cosa con i vostri team?

Leon Kallikkadan:

Assolutamente sì. È estremamente importante, soprattutto perché ognuno è nella propria corsia, è ancora più importante che i canali di comunicazione siano aperti, giusto? E non si sa... per una vera trasparenza e un vero impatto, bisogna sapere, bisogna avere queste discussioni molto prima di entrare in un progetto, e poi cercare di capire che tipo di conseguenze hanno gli altri team.

L'altra cosa da tenere a mente è che è importante dal punto di vista dell'ampiezza di banda dei singoli team, quindi è possibile che tutti e quattro i team abbiano la loro lista di priorità ed è importante capire a cosa sta lavorando qualcuno in questo momento e come il vostro progetto, che potrebbe essere molto importante, potrebbe prevalere su qualcos'altro. Quindi è importante, dal punto di vista della larghezza di banda, della programmazione e delle risorse, che queste conversazioni avvengano in anticipo.

Nel corso dei miei 16 anni di attività, ciò che mi ha davvero colpito e maturato è la necessità di capire quali sono le aspettative dell'azienda. Un'azienda non vuole un prodotto in cui si inizia a dire: "Questo non rientra nelle mie responsabilità, ma in quelle dell'IT, quindi rivolgetevi a qualcun altro". Quindi, dal punto di vista dell'esperienza dell'utente aziendale, non è questa l'esperienza che voglio mostrargli o dargli, quindi voglio che si interfacci con un team IT o tecnologico. E ciò che accade dietro le tende, ciò che accade dietro le quinte è il nostro flusso di lavoro, la nostra comunicazione che ci porta al successo.

Dayle Hall: 

Sì, no, è un buon consiglio. Se consideriamo un paio di aree molto calde nel mercato odierno, o molto calde per quanto riguarda i requisiti IT, c'è il concetto di passare da interazioni più guidate dagli sviluppatori a interazioni più low-code, no-code, molto popolare là fuori, gli analisti ne parlano, noi ne parliamo. La convinzione è che ciò consenta di supportare meglio l'azienda, che siano necessari meno sviluppatori e meno codici.

Per alcune cose c'è ancora bisogno di quel livello di codifica. Ma se pensate a questo concetto, low-code, no-code, molte applicazioni, avete questi quattro team, come vi avvicinereste a un progetto che è, beh, di supporto all'azienda e quindi non richiede molta codifica o sviluppatori? Come affrontereste il progetto con questi quattro team? Mi spieghi quale sarebbe un buon processo, come lo valuterebbe, come andrebbe avanti, chi lo gestirebbe.

Leon Kallikkadan:

Sì. Quindi... Sono tutte ottime domande. Quando riceviamo un progetto, quello che succede è che siamo maturati anche come organizzazione. Ora abbiamo un repository o una sorta di processo di accettazione in cui chiunque può presentare una richiesta, e una volta che questa arriva, a livello superficiale, viene vagliata per vedere se ha quell'importanza e qual è il livello della richiesta. Sulla base di tutto ciò, collaboriamo con il nostro team di project management che ci aiuta a prendere i requisiti grezzi dell'utente finale e a convertirli in requisiti aziendali. Quindi, una volta scritti i requisiti aziendali, che sono molto diversi dalla richiesta iniziale, questi sono più ponderati, ci sono storie di utenti, ci sono vari break-in, ci sono fasi aggiuntive, o questo è un must da avere, è un bene da avere, cose del genere. E poi tutto questo viene portato al nostro team. E poi viene preso in carico da un analista che lo converte in requisiti tecnici aziendali.

È a questo punto che iniziamo a risolvere i problemi e a considerare l'effettiva applicazione o la fornitura. Non risolviamo le cose al volo. È un gioco molto, molto pericoloso. E gli utenti aziendali ascoltano e pensano: "Oh, questo è facile". Ma non è così. Ci sono molte altre cose che accadono dietro le quinte. Per questo abbiamo cercato di abbandonare la soluzione al volo e di prendere i requisiti tecnici, per poi arrivare alla soluzione o al progetto e a ciò che occorre fare per realizzare l'applicazione.

Dayle Hall: 

Già. Visto quello che ha detto a proposito del tentativo di supportare il business e di non creare soluzioni al volo, probabilmente si sta incontrando di più non solo con i leader IT, ma anche con le linee di business. Secondo lei, quanto le richieste di supporto a nuove applicazioni, a diverse aggregazioni di dati, sono guidate dalle linee di business e quanto da voi, nell'organizzazione IT, è frutto del pensiero: questi sono dati, queste sono cose che dovremmo fornire direttamente all'azienda perché sappiamo che sono preziose? Com'è questo mix?

Leon Kallikkadan:

All'inizio, quindi, siamo partiti da me e dal mio team di leadership, cercando di spingere l'azienda a fare... L'azienda deve essere sensibilizzata, giusto? Questa è la sfida più grande. Se l'azienda non è a conoscenza delle nostre capacità e di ciò che c'è nel nostro kit di strumenti, non lo sa mai, queste conversazioni possono essere fatte nel vuoto. Così abbiamo iniziato a impegnarci, a rivolgerci alla nostra popolazione di utenti. Abbiamo iniziato a parlare con i vari team per capire, ad alto livello, quali sono le sfide che abbiamo e come questo team o la combinazione di questo team può essere d'aiuto.

Quindi ci vuole tempo per costruire una prova di concetto, realizzare le applicazioni e presentarle all'azienda. Ma una volta fatto questo, bisogna iniziare a coinvolgere maggiormente l'azienda in queste conversazioni. Quindi è come se si mostrasse loro ciò che si è in grado di fare, e poi si iniziasse ad avere una conversazione costante con l'azienda. Quest'anno abbiamo sviluppato una conversazione con un leader aziendale. Gli ho chiesto: "Parlami di questo processo, che cosa fa questo processo e perché non sta succedendo qui? E ne è scaturita una buona conversazione che abbiamo costruito in POC per fargliela vedere. E ora questo ci sta sicuramente aiutando e ci ha dato le basi per fare molto di più.

Quindi, quando si iniziano ad avere più conversazioni di questo tipo, diventa come se l'azienda stessa vi chiedesse e vi sfidasse, ehi, potete fare questo per me, potete fare quello per me? È come piantare questo seme in ogni azienda con il leader aziendale, far sì che inizi a pensare all'automazione e che il team tecnologico abbia qualcosa di più di un blocco e di un supporto tradizionale, c'è qualcosa di più del supporto.

Dayle Hall: 

Sento sicuramente un'indicazione simile da parte di altre organizzazioni, ovvero, come hai detto tu, andare prima dalle funzioni, dalle linee di business, assicurarsi che sappiano che sei lì come partner. In questo modo, è probabile che si verifichino meno frustrazioni, perché sapranno che ci siete dentro insieme, e che si possa effettivamente consentire loro di avere più successo, e credo che l'IT si stia spostando verso una visione meno bloccante per l'azienda e più facilitante, ma credo che questo derivi da diversi fattori. Viene da voi e dal vostro team e dal modo in cui vi approcciate alle cose. Deriva dalle persone e dai processi che mettete in atto e anche, chiaramente, dagli strumenti, dalle piattaforme, dalle cose che scegliete, dalle cose che scegliete per assicurarvi di poter abilitare l'azienda.

Leon Kallikkadan:

Sì. Aggiungerei solo che per noi la conversazione è ora cambiata in: come può l'IT essere un fattore di crescita? Quindi per il mio team ora la sfida è: voglio che pensiamo in modo diverso, che ci concentriamo sulle iniziative, sulle richieste, che identifichiamo le opportunità in cui il team IT più ampio può aiutare più che limitarsi a gestire le cose in modo efficiente. Non è più così. Abbiamo accesso a tutti i dati. Abbiamo accesso a tutta la tecnologia. Conosciamo i processi. Da un punto di vista operativo, riceviamo i ticket, quindi sappiamo che le persone hanno problemi e capiamo cosa succede dietro le quinte. Quindi, come possiamo utilizzare questi dati per presentare una soluzione all'azienda e dire: "Guardate, questo era il vostro processo prima. Con la nostra raccomandazione, ora il vostro processo può andare da A a B. E nel processo, potete risparmiare X, Y e Z. Oppure cerchiamo di portare questo flusso di dati nel vostro flusso di lavoro in modo da avere una migliore visibilità o maggiori capacità di vendita o qualsiasi cosa sia. Stiamo quindi cercando di cambiare il nostro approccio, passando da un approccio di tipo block and tackle o da un team IT tradizionale a un approccio di tipo revenue enabling.

Dayle Hall: 

Sì, credo che sia un ottimo approccio. Se pensiamo... prima di passare alla parte dei processi e degli strumenti, ma se pensiamo alle persone e al lato gestionale, c'è... ovviamente, avete già dei processi in atto. Ha già parlato un po' del fatto di arrivare in anticipo alle linee di business e ai leader aziendali, il che mi sembra ottimo, e ha parlato anche di arrivare in anticipo al processo con i suoi team. Ma come vi comportate con le linee di business? Quanto tempo dedicate alla pianificazione, alla discussione e quanto alla costruzione, all'esecuzione e ai test in corso e al vostro backlog? E quali sono i processi che avete in atto per assicurarvi di avere successo?

Leon Kallikkadan:

Adesso è il momento migliore, giusto? Per esempio, se iniziamo a pianificare tutti i progetti per il prossimo anno, tutte le iniziative per l'anno successivo, iniziamo ad avere queste conversazioni adesso. In passato, facevo l'errore di non avere queste conversazioni con l'azienda. Avevo un elenco di 30 progetti per l'anno successivo e mi sono reso conto che questo non è il modo di fare le cose, è un fallimento di successo, perché si cerca di fissare obiettivi e di lavorare su cose per le quali l'azienda dice: "Non ci interessano necessariamente queste cose", oppure "Abbiamo questi problemi" e non si lavora su questi problemi.

Quindi iniziamo da lì, abbiamo queste conversazioni con l'azienda, chiediamo il parere dell'azienda prima di iniziare qualcosa. E poi collaboriamo con il nostro team di gestione dei progetti, che definisce tutti questi progetti con le aziende, con il gruppo di partner, in questo caso, nel nostro caso, e stabiliamo le priorità. Valutiamo quale dei miei team sarà il più utilizzato, se si tratta di un team di automazione o di integrazione, o di un team di applicazioni aziendali. E in base alla priorità stabilita dall'azienda, creiamo una mappa di tutti gli sforzi. Consideriamo quali progetti partono nello stesso momento e dove possiamo spostarli. Quindi, attraverso l'intero processo di valutazione, classifichiamo i progetti come alti, medi e bassi. E ci impegniamo a raggiungere tutti i progetti più alti. Su questa base, abbiamo un dialogo con l'azienda.

In termini di dove spendiamo la maggior parte del tempo, soprattutto negli ultimi mesi, forse anche in un anno, quello che abbiamo visto è che molto tempo viene speso per l'analisi, come prendere i requisiti, convertirli in requisiti di business, ma anche per assicurarsi che il team di sviluppo stia lavorando su quei requisiti, per fare in modo che questi due si sposino, giusto? Per noi, quindi, molto tempo è dedicato alla [freccia B], riceviamo molti nuovi progetti. E l'ultima cosa che si vuole fare è avere tutti questi progetti in arretrato, avere queste conversazioni con l'azienda e prepararli il più possibile.

Quindi, vediamo sempre più tempo necessario per l'analista di business e meno tempo per lo sviluppatore, perché i progetti sono già pronti. Stiamo quindi cambiando un po' il nostro approccio, cercando di ottenere più BA piuttosto che aggiungere semplicemente il numero di risorse sul lato sviluppo, perché questo è un aspetto che possiamo controllare. Se c'è bisogno di più risorse per lo sviluppo, in base alla nostra strategia attuale, possiamo aggiungere e togliere risorse a seconda delle necessità.

Dayle Hall: 

È un concetto interessante. E credo che se si chiedesse a 100 leader diversi come descriverebbero un analista aziendale, probabilmente avrebbero una descrizione leggermente diversa. Ma mi piace quello di cui parli, ovvero un maggiore impegno nella pianificazione e nell'analisi prima di iniziare a creare un mucchio di cose. Quindi, mi parli un po' di cosa definisce un analista aziendale, di cosa fa, di che tipo di competenze apporta questa persona all'organizzazione per aiutare voi e i vostri team ad avere più successo.

Leon Kallikkadan:

Certo. Per me, un analista aziendale è una persona che conosce bene la tecnologia o gli strumenti, ma non è uno sviluppatore. Quindi è essenzialmente qualcuno che capisce quali sono le vostre capacità. È quindi importante che abbia una comprensione completa e profonda di ciò che si può fare e di ciò che non si può fare. Deve essere qualcuno che sia in contatto con l'azienda, che capisca ciò che l'azienda chiede e che sia in grado di contestualizzarlo, perché l'ultima cosa che vogliamo fare è togliere un'attività dai requisiti aziendali e poi consegnarla agli sviluppatori dicendo: andate e sviluppate, perché non sarà fatto in modo molto, molto efficiente. 

Vogliamo quindi qualcuno che abbia una comprensione dell'azienda, ma anche degli strumenti tecnologici, e qualcuno che abbia un'ottima comprensione e capacità di gestione dei progetti, come la larghezza di banda e ciò che accade dietro le quinte. Poiché la nostra organizzazione IT è relativamente piccola, cerco di massimizzare l'uso di ogni persona che abbiamo. Il nostro BA è anche colui che parla costantemente con l'azienda. Quindi capire cosa succede dietro le quinte dal punto di vista della larghezza di banda e del carico di lavoro ci aiuta anche a gestire le aspettative, giusto? Per me queste tre aree sono le più importanti.

Sto anche cercando di utilizzare ciò che abbiamo fatto per l'automazione in tutti gli aspetti del nostro team tecnologico. Forse la gente non pensa che l'IT abbia bisogno di un analista aziendale, ma io voglio che il mio team arrivi a un punto in cui ogni richiesta tecnologica che arriva passi attraverso un analista aziendale. Perché, come hai detto tu, più si investe in anticipo, migliore è il risultato, perché non c'è ambiguità, come se quello che l'azienda ha chiesto, fosse ripetuto in 10 modi diversi per assicurarsi che sia accurato. Ed è qui che voglio arrivare. Quindi le nostre soluzioni sono più rapide e vanno più al sodo.

Dayle Hall:  

Per essere chiari, avete analisti di business nel vostro team o sono al di fuori della vostra organizzazione?

Leon Kallikkadan:

È un misto. Abbiamo un analista aziendale, ma abbiamo anche analisti aziendali, non tecnici, ma il nostro team di progetto ha accesso ai nostri analisti aziendali. Quindi lo fanno ad alto livello. E grazie alla nostra partnership con loro e al tempo che stiamo investendo, anche loro hanno iniziato a migliorare il loro gioco. Quindi abbiamo una buona soluzione ibrida in questo momento.

Dayle Hall: 

È davvero un'ottima intuizione. Ancora una volta, spero che alcuni degli ascoltatori che lo stanno ascoltando pensino che forse stanno percorrendo questa strada, che forse hanno degli analisti aziendali che non stanno utilizzando, ma che ovviamente potrebbero fare di più.

Parliamo ora un po' della terza sezione, dell'integrazione specifica, dell'automazione per l'azienda e di ciò che state facendo. Parlatemi un po' dell'importanza di ciò che automatizzate. E credo che una delle cose che abbiamo discusso in precedenza sia stata quella di capire dove l'uomo e l'intelligenza dell'individuo che conosce l'organizzazione possano giocare nel processo di automazione dell'azienda.

Leon Kallikkadan:

Certo. Prima di iniziare a rispondere, è importante condividere come sono arrivato a questa conclusione. Quando abbiamo avviato il nostro team, il team di automazione, eravamo così entusiasti, abbiamo lanciato un team nuovo di zecca, abbiamo tutti questi strumenti di lusso e ci siamo detti: "Sai cosa? Possiamo risolvere i problemi di tutti o automatizzare tutti i processi". Ed era la cosa sbagliata da fare. Non si può mai automatizzare al 100%. Ogni processo ha molte possibilità di automazione, grandi e piccole. Ma abbiamo imparato che non è mai possibile automatizzare al 100%. Ci sono così tante complessità, la tecnologia stessa, il processo stesso, l'eccezione a volte si intromette, e ci può essere un numero infinito di eccezioni.

Questi sono i motivi per cui abbiamo scelto di passare a un approccio più ibrido in cui, sapete cosa, facciamo in modo che il compito sia ripetibile, che le eccezioni non siano illimitate e infinite, che le automatizziamo e che proviamo a vedere se riusciamo a ottenere quei dati. Ma vogliamo comunque che la nostra risorsa, il cui tempo è stato risparmiato, esamini i dati, li convalidi e analizzi i risultati, si assicuri che siano all'altezza della situazione, che rientrino nel range normalmente previsto, che identifichino le eccezioni o le aree in cui ci sono errori, in modo che la persona che lo stava facendo ora sia l'analista. Il processo richiedeva un'intera giornata per uno dei nostri dipendenti ogni settimana. Era un processo lungo e noioso.

Anche in questo caso, pensavamo di poterlo automatizzare al 100%, ma poi abbiamo capito che non era possibile. Quindi, ciò che prima richiedeva a questa persona sette-otto ore, ora richiede circa due-tre ore. Ma ora sono seduti ad aspettare che il bot invii loro i dati. Una volta che il bot li invia, sanno come applicare le regole di business, che sono al di fuori, che non si possono inserire in uno script di automazione, per così dire. Una volta pronti, invieranno un'e-mail al bot e quest'ultimo completerà il resto del processo. Quindi la conversazione umana nel ciclo è importante per noi, visti i successi che stiamo riscontrando. Inoltre, abbiamo bisogno che i nostri utenti finali o le persone che eseguono queste attività siano il nostro controllo e bilanciamento. Vogliamo assicurarci che le nostre automazioni siano accurate, ma anche che, nel caso in cui non lo siano, qualcuno sia in grado di dire: "Sai cosa, ehi, fermati, c'è qualcosa che non va".

Dayle Hall: 

Giusto, giusto. Sì, è interessante. E sembra che tu abbia imparato da alcuni errori perché, ancora una volta, hai preceduto questa risposta con: "Beh, lascia che ti dica perché sono arrivato a questa conclusione". C'è qualcosa che... se qualcuno è là fuori e sta pensando: "Oh, faremo la stessa cosa, abbiamo così tante cose da automatizzare", c'è qualche esempio che puoi condividere con noi, senza svelare troppo dei tuoi processi interni, ma qualcosa di specifico, come hai detto tu, abbiamo seguito questo processo ed è andato in pezzi? C'è qualcosa che può condividere con il pubblico?

Leon Kallikkadan:

Si. Il caso di cui parlavo è la creazione di rapporti. E quando parlo di rapporti, mi riferisco al modo in cui esaminiamo il rendimento di una persona e così via, quindi alcuni di questi rapporti di alto livello. La cosa più importante che abbiamo notato è che molti di questi utenti esperti non hanno in testa le conoscenze per gli utenti esperti, giusto? Per noi diventa molto difficile estrarre tutte queste informazioni.

Oltre a questo, ce ne sono altri in cui abbiamo ricominciato pensando di poterlo fare, ma poi la tecnologia finale non è in grado di supportarci, giusto? Abbiamo iniziato l'intero processo e poi è crollato nella parte posteriore. Quindi abbiamo pensato: "Se dovete farlo, fatelo in più parti. Se volete estrarre il file, lasciate che l'automazione si attivi, lo estragga e lo porti allo stato desiderato. Ma prima di caricarlo o di qualsiasi altra cosa, assicuratevi che l'altro sistema funzioni. So che si possono creare controlli e contrappesi, ma cercate di fare in modo che sia pronto per il caricamento e cose del genere. Ci sono alcuni casi in cui abbiamo imparato a nostre spese.

Dayle Hall:  

Sì. Beh, credo che tutti debbano passare per questo. Quindi, per concludere questa discussione, come ho detto, quello che tendo a scoprire è che le persone che ci contattano, quando ascoltano cose come questi podcast, sono alla ricerca di suggerimenti pratici, di consigli pratici. Quindi, se pensate - avete detto che non potete automatizzare al 100%, ma che avete un processo in atto - a cosa dovrebbero guardare per identificare le parti dell'azienda che sono più importanti da automatizzare rispetto a quelle meno importanti? Come pensa a questo aspetto per la sua organizzazione?

Leon Kallikkadan:

Già. Quando abbiamo iniziato, il modo in cui abbiamo iniziato a cercare e identificare le opportunità è stato quello di cercare i frutti a portata di mano. Come sempre, i frutti a portata di mano sono i modi più semplici per ottenere delle vittorie e per guadagnare slancio. Così abbiamo iniziato in questo modo. E poi abbiamo costruito il nostro processo. E vorrei dire a chi sta iniziando che il processo si costruisce con il tempo, matura con il tempo. Cambia costantemente, si evolve. Man mano che si impara, che si matura, che si collabora con l'azienda, le cose cambiano, giusto? Quindi il nostro processo non era quello del primo giorno, che era molto sottile e non pesante, ma ora è molto diverso. E lo abbiamo cooptato di nuovo - altri team lo hanno cooptato.

Ora consideriamo il valore di un'automazione. Guardiamo la quantità di tempo che spendiamo o il preventivo che ci porterà dal punto A al punto B. Guardiamo il valore che questa automazione ci darebbe, come se... quello che è nel nostro sweet spot è qualcosa che richiede uno sforzo ridotto, ma ha un ROI davvero alto, un valore elevato, giusto? E soprattutto se si riesce a mettere in conto un importo in dollari, la quantità di dollari che si possono risparmiare o di entrate che si possono generare, per me quello è lo sweet spot. Ma mi rendo conto che non tutte le aziende ne dispongono, quindi consideriamo queste metriche, la quantità di sforzo rispetto al ROI, al risparmio, a prescindere da cosa sia.

Abbiamo istituito un comitato direttivo che comprende i nostri leader aziendali, il mio supervisore, e portiamo i dati, i requisiti e diciamo: "Sapete, sono arrivate queste quattro richieste, questo è l'ammontare dello sforzo, questo è l'ammontare dei benefici". A volte chiediamo anche all'utente aziendale di partecipare al comitato direttivo e di parlare, in modo che possa esporre direttamente il caso. Poi, come comitato direttivo, decidiamo ciò che è considerato di grande importanza e lo eseguiamo, definendo il nostro approccio e dicendo: inizieremo a lavorare su questo sprint A o sprint 1, e poi ci vorrà un numero X di sprint per completarlo.

Quindi il nostro processo è più che altro quello di coinvolgere il più possibile l'azienda. Questo non vuol dire che non faremo piccoli progetti, anzi li vogliamo fare. Ma dobbiamo anche capire il nostro ruolo. Se cerchiamo di automatizzare tutto per tutti, falliremo. Quindi dobbiamo essere selettivi su dove vogliamo mostrare il massimo valore all'azienda, e sarà l'azienda a decidere. Ad esempio, se si tratta di un'attività che genera entrate, è lì che vogliamo che le entrate dell'azienda aumentino. Quindi è più facile usare questo approccio.

Dayle Hall: 

Quando si parla di comitato direttivo, si intende che questo include i leader funzionali o i leader aziendali che seguono il processo. Quindi sono coinvolti fin dal primo giorno di analisi.

È un ottimo consiglio. Sono sicuro che potremmo parlare per altre due o tre ore. Ma mi è piaciuto molto quello che hai trattato. Abbiamo parlato dei vostri team principali. Vi assicurate che discutano di tutti i loro progetti e potenzialmente, prima dell'inizio di qualsiasi lavoro, dell'impatto sulla loro organizzazione. Inoltre, è importante stabilire un ordine di priorità tra i vari team. In questo modo ogni team non si trova a lottare per la cosa più importante per lui, ma per l'azienda, il che è fantastico. Lei ha parlato del fatto che l'IT si rivolge alla popolazione degli utenti, assicurandosi di capire e di impegnarsi maggiormente sui loro requisiti, il che credo sia un ottimo modo di gestire l'organizzazione.

La cosa che mi piace di più di quello che hai detto, Leon, è come l'IT possa essere un fattore di stimolo per le entrate: è una mentalità straordinaria da avere. E penso che quello che hai appena detto, come il comitato direttivo e l'assicurazione che l'azienda sia convinta delle priorità, e se il fatturato è al primo posto, sono sicuro che otterrai il giusto tipo di supporto in tutta l'azienda.

L'altra parte che mi è sembrata molto interessante è quella dell'analista di business, che sia all'interno dell'IT o in altre parti dell'azienda, ma qualcuno che comunichi, gestisca le aspettative di questi progetti con i leader aziendali, non l'ho visto in molte organizzazioni direttamente come loro ruolo, quindi è davvero interessante che stia funzionando per voi. Sono sicuro che alcune delle persone che ascoltano il podcast potrebbero pensare: "Siamo stati analisti aziendali. Mi chiedo perché non lo facciano per noi.

Ma sentite, è fantastico. Penso che stiate facendo un lavoro straordinario. Mi piace il modo in cui pensate all'automazione dell'impresa, che è ovviamente il mantra di questo podcast. E Leon, grazie mille per aver condiviso i tuoi pensieri oggi. È stato un episodio eccellente.

Leon Kallikkadan:

Grazie. È stato divertente ed è stata una grande conversazione.

Dayle Hall: 

Giusto. Grazie a tutti per essere stati con noi oggi e ci vediamo nel prossimo episodio di Automazione dell'impresa con SnapLogic.