How to Create a More Efficient Tech Stack

Det finns två versioner av varje teknikstack: den långa listan över verktyg och plattformar du har, och den korta listan över de som du faktiskt använder. När teknikstackar växer och arbetsstyrkor förändras, kan antalet döda appar i ett företags ekosystem (de med låg adoption eller utan tydliga ägare) börja gå obemärkt förbi, vilket blir budgetdränering och säkerhetsrisker. Även årliga budgeteringsprocesser kanske inte löser problemet, med rader kvar för för många platser på huvudsakligen oanvända appar. Exempel: Jag arbetade en gång för ett företag som gav mig en licens för en designprogramvara jag inte visste hur man använde – och aldrig lärde mig – helt enkelt för att det var en del av den standardiserade marknadsföringsverktygen.

Detta betyder inte att du inte ska ta in nya appar i din stack! Faktum är att när du överväger nya appar, kommer du sannolikt att få en bättre förståelse för vilka appar i din nuvarande setup som är underutnyttjade och var du kan behöva göra en investering.

Låt oss ta en titt på hur man gör en helhetsutvärdering av din teknikstack, hur man förstår vad som finns på allas korta och långa listor, och hur man fyller i luckorna.

Hur man utvärderar din befintliga teknikstack

Du kanske tror att det bästa stället att börja är att titta på din budget. Det är det inte. Genom att först granska din budget kan stora poster chockera dig till att avbryta en allmänt använd app. Det tar inte hänsyn till några gratisappar som ditt team kan använda (eller som kanske inte längre används, men som fortfarande har tillgång till dina data via SSO).

1. Det bästa sättet att börja din utvärdering är… att fråga ditt team!

Det finns en anledning till att din läkare gör (eller borde) be dig att lista dina mediciner varje gång. De kan ha gamla recept i sitt system som kan påverka rekommendationen av en ny metod negativt, och de vill förstå vad exakt du tar. För att minska datatröttheten kan du be dem fylla i ett formulär som är förblandat med befintliga verktyg som du vet att de har tillgång till, be dem att kryssa i de objekt de använder och lägga till andra objekt som du kanske inte har fångat.

Du bör också bryta ner ditt intagningsformulär genom att be folk att bedöma hur ofta de använder varje produkt (alternativ: aldrig, 1-2 gånger per månad, nästan varje vecka, ett par gånger per vecka, varje dag) för att få en fullständig förståelse av deras långa och korta listor.

Proffstips: Se till att du betonar att detta inte är en "fånga" övning. Folk kanske inte vill säga att de inte använder en produkt de förväntas använda.

2. Involvera ditt IT-team

Om du använder en SSO-metod som Google som gör att folk kan logga in på appar utan att gå igenom en inhemsk kontoinställning, bör ditt IT-team ha insyn i exakt vilka appar de är och hur ofta de nås. Det ger dig inte bara en mer fullständig förståelse av användningen utan det kan också hjälpa dig att identifiera eventuella potentiella säkerhetsrisker.

3. Titta på data för produktanvändning

Om en produkt har användningsdata, dra ut den! Om du inte kan hitta en instrumentpanel, be supportteamet om du kan få en kopia. För allt, är data objektiv medan personlig rapportering är subjektiv.

4. Titta på budgeten

Nu är det dags att utvärdera din budget. Med all din teams självrapporterade, SSO, och in-product användningsdata i handen kan du a) matcha det mot rader och b) avgöra om den raden är väl spenderade pengar. Men även det är lite knepigare än det kan verka vid första anblicken.

Om du spenderar $30/plats/månad på en produkt som 10 av 100 anställda använder, kanske du känner dig böjd att eliminera utgiften automatiskt. Men här är vad du borde verkligen överväga:

• Varför köpte vi den här produkten från första början?
• Vem äger det internt?
• Köpte vi för många platser? (eller använder de som använder det det mycket?)
• Behöver vi helt enkelt att utbilda användare om värdet?

Här är ett användbart beslutsdiagram:

Vad ska man tänka på när man köper ett nytt verktyg eller plattform

Nu när du förstår vad ditt team faktiskt använder bör du överväga var luckor kan finnas. Om du till exempel har en inkluderad wiki som en del av ett större paket, men ingen använder den – även efter utbildning – kanske du vill överväga att lägga till en ny kunskapsdelande plattform.

När många leverantörer erbjuder liknande funktioner, hur kan du avgöra om du gör en effektiv investering och inte bara lägger till en app för sakens skull? Fråga alltid en leverantör vad deras dagliga och månatliga adoptionsmetrik ser ut efter den första utrullningen.

Varför spelar det här någon roll? Med varje ny app kommer det att finnas en period av spänning där ditt team köper in sig i dess användbarhet. Men efter den initiala hypen kan du börja se sjunkande användning (tills det bara är en av de där verktygen som du måste gå igenom ditt beslutsdiagram för att behålla/klippa). Genom att ta reda på den genomsnittliga långsiktiga dagliga och månatliga adoptionen, kommer du att kunna förstå om andra företag har sett en verklig avkastning på investeringen – och har metriker mot vilka du kan bedöma ditt eget företags framgång.

Effektivitet är en pågående övning

Slutligen vet du detta: att förbättra din teknikstack är inte en en-gångs-övning. Vad som fungerar för ditt team nu kanske inte fungerar för dem i framtiden på grund av tillväxt, minskning, branschvillkor eller förändringar i strategin.

Det är sagt, det är opraktiskt att genomföra denna typ av process varje månad! Så gör det bara efter ett övertygande tillfälle (som de ovan nämnda) och i början av din årliga budgeteringscykel.

Har du några andra insikter om att skapa en effektiv teknikstack? Kommentera nedan eller skicka oss dina tips på Twitter.