Ci sono 2 versioni di ogni stack tecnologico: l'elenco lungo delle app che hai e l'elenco corto di quelle che utilizzi davvero. Scopri come trovare maggiore efficienza.
Ci sono due versioni di ogni stack tecnologico: l'elenco lungo degli strumenti e delle piattaforme che hai e l'elenco corto di quelli che usi davvero. Man mano che gli stack tecnologici si espandono e le forze lavoro cambiano, il numero di app moribonde nell'ecosistema di un'azienda (quelle con bassa adozione o senza proprietari chiari) potrebbe cominciare a passare inosservato, diventando drenaggi di budget e rischi per la sicurezza. Anche i processi di budgeting annuale potrebbero non risolvere il problema, con voci di spesa che rimangono per troppe licenze su app ampiamente non utilizzate. Un caso esemplare: ho lavorato una volta per un'azienda che mi ha dato una licenza di utilizzo di un software di design che non sapevo utilizzare – e non ho mai imparato – semplicemente perché faceva parte dell'arsenale standard di marketing.
Questo non significa che non dovresti portare nuove app nel tuo stack! Infatti, quando consideri nuove app, probabilmente avrai una migliore comprensione di quali app nel tuo attuale setup sono sottoutilizzate e dove potresti aver bisogno di un investimento.
Diamo un'occhiata a come fare una valutazione olistica del tuo stack tecnologico, come capire cosa c'è nelle brevi e lunghe liste di tutti e come colmare le lacune.
Come valutare il tuo stack tecnologico esistente
Potresti pensare che il posto da cui iniziare sia guardare il tuo budget. Non è così. Esaminando prima il tuo budget, voci di spesa grandi potrebbero sorprenderti e costringerti a disattivare una app ampiamente utilizzata. Non tiene nemmeno conto di eventuali app gratuite che il tuo team potrebbe utilizzare (o che potrebbero non essere più in uso, ma che hanno comunque accesso ai tuoi dati tramite SSO).
1. Il modo migliore per iniziare la tua valutazione è... chiedere al tuo team!
C'è un motivo per cui il tuo dottore fa (o dovrebbe fare) chiederti di elencare i tuoi farmaci ogni volta. Potrebbero avere prescrizioni vecchie nel loro sistema che potrebbero influenzare negativamente il consiglio su un nuovo approccio e vogliono capire cosa, esattamente, stai assumendo. Per ridurre l'affaticamento da dati, puoi far compilare loro un modulo pre-caricato con gli strumenti esistenti a cui sai che hanno accesso, chiedere loro di selezionare le voci che utilizzano e aggiungere altre voci che potresti non aver catturato.
Dovresti anche suddividere il tuo modulo di raccolta chiedendo alle persone di valutare quanto spesso utilizzano ciascun prodotto (opzioni: mai, 1-2 volte al mese, quasi ogni settimana, alcune volte a settimana, ogni giorno) per avere una comprensione più completa delle loro brevi e lunghe liste.
Suggerimento: assicurati di enfatizzare che questo non è un esercizio di “trappola”. Le persone potrebbero non essere disposte a dire che non usano un prodotto che dovrebbero utilizzare.
2. Coinvolgi il tuo team IT
Se utilizzi un metodo SSO come Google che consente alle persone di accedere alle app senza passare attraverso una configurazione nativa dell'account, il tuo team IT dovrebbe avere visibilità esatta su quali app sono e con quale frequenza vengono accessibili. Non solo ti dà una comprensione più completa dell'uso, ma potrebbe anche aiutarti a identificare potenziali rischi per la sicurezza.
3. Guarda i dati di utilizzo del prodotto
Se un prodotto ha dati di utilizzo, estraili! Se non riesci a trovare una dashboard, chiedi al team di supporto se puoi avere una copia. Del resto, i dati sono obiettivi, mentre le segnalazioni personali sono soggettive.
4. Guarda il budget
Ora è tempo di valutare il tuo budget. Con tutti i dati auto-riportati dal tuo team, dati SSO e dati di utilizzo del prodotto a disposizione, puoi a) abbinarli a voci di spesa e b) decidere se quella voce di spesa è un investimento ben speso. Ma anche questo è un po' più complicato di quanto potrebbe sembrare all'inizio.
Se stai spendendo $30/licenza/mese su un prodotto utilizzato da 10 dipendenti su 100, potresti essere incline ad eliminare automaticamente questa spesa. Ma ecco cosa dovresti veramente considerare:
Perché abbiamo comprato questo prodotto in primo luogo?
Chi lo possiede internamente?
Abbiamo comprato troppe licenze? (ovvero le persone che lo utilizzano lo utilizzano molto?)
Dobbiamo semplicemente rieducare gli utenti sul valore?
Ecco un utile diagramma decisionale:
Cosa considerare quando acquisti un nuovo strumento o piattaforma
Ora che comprendi cosa sta realmente utilizzando il tuo team, dovresti considerare dove potrebbero esserci delle lacune. Se, ad esempio, hai una wiki inclusa come parte di un pacchetto più grande, ma nessuno la utilizza - anche dopo aver rieducato - potresti voler considerare l'aggiunta di una nuova piattaforma di condivisione della conoscenza.
Quando molti fornitori offrono funzionalità simili, come puoi determinare se stai facendo un investimento efficiente e non stai semplicemente aggiungendo un'app solo per il gusto di farlo? Chiedi sempre a un fornitore quali sono le loro metriche di adozione giornaliera e mensiledopo il rilascio iniziale.
Perché questo è importante? Con qualsiasi nuova app, ci sarà un periodo di entusiasmo in cui il tuo team crede nella sua utilità. Tuttavia, dopo quel primo entusiasmo, potresti cominciare a vedere un calo dell'uso (fino a diventare semplicemente uno di quegli strumenti che devi passare attraverso il tuo diagramma decisionale di mantenere/cut). Scoprendo la media degli utili quotidiani e mensili a lungo termine, sarai in grado di capire se altre aziende hanno visto un reale ritorno sugli investimenti – e avere metriche contro cui giudicare il successo della tua azienda.
L'efficienza è un esercizio continuo
Infine, lo sai: affinare il tuo stack tecnologico non è un esercizio da fare una sola volta. Quello che funziona per il tuo team ora potrebbe non funzionare per loro in futuro a causa di crescita, contrazione, condizioni di settore o cambiamenti nella strategia.
Detto ciò, è poco pratico passare attraverso questo tipo di processo ogni mese! Fallo solo dopo un evento significativo (come quelli elencati sopra), e all'inizio del tuo ciclo di budgeting annuale.
Ci sono due versioni di ogni stack tecnologico: l'elenco lungo degli strumenti e delle piattaforme che hai e l'elenco corto di quelli che usi davvero. Man mano che gli stack tecnologici si espandono e le forze lavoro cambiano, il numero di app moribonde nell'ecosistema di un'azienda (quelle con bassa adozione o senza proprietari chiari) potrebbe cominciare a passare inosservato, diventando drenaggi di budget e rischi per la sicurezza. Anche i processi di budgeting annuale potrebbero non risolvere il problema, con voci di spesa che rimangono per troppe licenze su app ampiamente non utilizzate. Un caso esemplare: ho lavorato una volta per un'azienda che mi ha dato una licenza di utilizzo di un software di design che non sapevo utilizzare – e non ho mai imparato – semplicemente perché faceva parte dell'arsenale standard di marketing.
Questo non significa che non dovresti portare nuove app nel tuo stack! Infatti, quando consideri nuove app, probabilmente avrai una migliore comprensione di quali app nel tuo attuale setup sono sottoutilizzate e dove potresti aver bisogno di un investimento.
Diamo un'occhiata a come fare una valutazione olistica del tuo stack tecnologico, come capire cosa c'è nelle brevi e lunghe liste di tutti e come colmare le lacune.
Come valutare il tuo stack tecnologico esistente
Potresti pensare che il posto da cui iniziare sia guardare il tuo budget. Non è così. Esaminando prima il tuo budget, voci di spesa grandi potrebbero sorprenderti e costringerti a disattivare una app ampiamente utilizzata. Non tiene nemmeno conto di eventuali app gratuite che il tuo team potrebbe utilizzare (o che potrebbero non essere più in uso, ma che hanno comunque accesso ai tuoi dati tramite SSO).
1. Il modo migliore per iniziare la tua valutazione è... chiedere al tuo team!
C'è un motivo per cui il tuo dottore fa (o dovrebbe fare) chiederti di elencare i tuoi farmaci ogni volta. Potrebbero avere prescrizioni vecchie nel loro sistema che potrebbero influenzare negativamente il consiglio su un nuovo approccio e vogliono capire cosa, esattamente, stai assumendo. Per ridurre l'affaticamento da dati, puoi far compilare loro un modulo pre-caricato con gli strumenti esistenti a cui sai che hanno accesso, chiedere loro di selezionare le voci che utilizzano e aggiungere altre voci che potresti non aver catturato.
Dovresti anche suddividere il tuo modulo di raccolta chiedendo alle persone di valutare quanto spesso utilizzano ciascun prodotto (opzioni: mai, 1-2 volte al mese, quasi ogni settimana, alcune volte a settimana, ogni giorno) per avere una comprensione più completa delle loro brevi e lunghe liste.
Suggerimento: assicurati di enfatizzare che questo non è un esercizio di “trappola”. Le persone potrebbero non essere disposte a dire che non usano un prodotto che dovrebbero utilizzare.
2. Coinvolgi il tuo team IT
Se utilizzi un metodo SSO come Google che consente alle persone di accedere alle app senza passare attraverso una configurazione nativa dell'account, il tuo team IT dovrebbe avere visibilità esatta su quali app sono e con quale frequenza vengono accessibili. Non solo ti dà una comprensione più completa dell'uso, ma potrebbe anche aiutarti a identificare potenziali rischi per la sicurezza.
3. Guarda i dati di utilizzo del prodotto
Se un prodotto ha dati di utilizzo, estraili! Se non riesci a trovare una dashboard, chiedi al team di supporto se puoi avere una copia. Del resto, i dati sono obiettivi, mentre le segnalazioni personali sono soggettive.
4. Guarda il budget
Ora è tempo di valutare il tuo budget. Con tutti i dati auto-riportati dal tuo team, dati SSO e dati di utilizzo del prodotto a disposizione, puoi a) abbinarli a voci di spesa e b) decidere se quella voce di spesa è un investimento ben speso. Ma anche questo è un po' più complicato di quanto potrebbe sembrare all'inizio.
Se stai spendendo $30/licenza/mese su un prodotto utilizzato da 10 dipendenti su 100, potresti essere incline ad eliminare automaticamente questa spesa. Ma ecco cosa dovresti veramente considerare:
Perché abbiamo comprato questo prodotto in primo luogo?
Chi lo possiede internamente?
Abbiamo comprato troppe licenze? (ovvero le persone che lo utilizzano lo utilizzano molto?)
Dobbiamo semplicemente rieducare gli utenti sul valore?
Ecco un utile diagramma decisionale:
Cosa considerare quando acquisti un nuovo strumento o piattaforma
Ora che comprendi cosa sta realmente utilizzando il tuo team, dovresti considerare dove potrebbero esserci delle lacune. Se, ad esempio, hai una wiki inclusa come parte di un pacchetto più grande, ma nessuno la utilizza - anche dopo aver rieducato - potresti voler considerare l'aggiunta di una nuova piattaforma di condivisione della conoscenza.
Quando molti fornitori offrono funzionalità simili, come puoi determinare se stai facendo un investimento efficiente e non stai semplicemente aggiungendo un'app solo per il gusto di farlo? Chiedi sempre a un fornitore quali sono le loro metriche di adozione giornaliera e mensiledopo il rilascio iniziale.
Perché questo è importante? Con qualsiasi nuova app, ci sarà un periodo di entusiasmo in cui il tuo team crede nella sua utilità. Tuttavia, dopo quel primo entusiasmo, potresti cominciare a vedere un calo dell'uso (fino a diventare semplicemente uno di quegli strumenti che devi passare attraverso il tuo diagramma decisionale di mantenere/cut). Scoprendo la media degli utili quotidiani e mensili a lungo termine, sarai in grado di capire se altre aziende hanno visto un reale ritorno sugli investimenti – e avere metriche contro cui giudicare il successo della tua azienda.
L'efficienza è un esercizio continuo
Infine, lo sai: affinare il tuo stack tecnologico non è un esercizio da fare una sola volta. Quello che funziona per il tuo team ora potrebbe non funzionare per loro in futuro a causa di crescita, contrazione, condizioni di settore o cambiamenti nella strategia.
Detto ciò, è poco pratico passare attraverso questo tipo di processo ogni mese! Fallo solo dopo un evento significativo (come quelli elencati sopra), e all'inizio del tuo ciclo di budgeting annuale.
