Use One Knowledge Base for End-to-End Product Delivery
Det finns verkliga affärsrisker som följer med att verka i silos. Se varför ditt företag förtjänar en verklig centraliserad kunskapsbas för att vara effektiv.
“Jag vet att de gör saker, jag är bara inte helt säker på vad den där saken är.”
Hur många gånger har du hört (eller låt oss vara ärliga, sagt) de orden från en av dina kollegor i referens till ett annat team eller avdelning? Det är lätt för oss att gå vilse i våra egna hörn av företaget i vårt dagliga arbete, vilket ibland leder till en brist på förståelse för vad våra kollegor på andra sidan företaget gör för att få verksamheten att fungera. Och med god anledning: att hålla fokus på sina egna expertområden och ansvar hjälper alla att växa i sina egna funktioner. Men vad händer när den utsikten blir så smal att team kämpar för att se på vilka sätt deras arbete påverkar resten av företaget?
Företagskunskap vill vara tvärfunktionell
När team ser sina funktioner i ett vakuum, ser de ofta sitt teams kunskap i ett vakuum också. För marknadsföringsteam kan detta betyda köparpersonas eller beskrivningar av funktionspositionering. För ingenjörsteam kan detta betyda teknisk dokumentation eller instruktioner för att konfigurera miljön. Och för supportteam kan detta betyda svar på vanliga frågor eller felsökningsguider för funktionsfel. Dessa resurser kan finnas i ett antal verktyg som enskilda team använder, såsom Google Drive, GitHub, Intercom, etc., och kan ägas kollektivt eller av en ledare/ specialist i teamet som fokuserar på dokumentation.
På ytan verkar det rimligt att olika team behöver olika dokumentationsverktyg för att bäst passa sina arbetsflöden, men när vi gräver djupare, avtäcker vi de verkliga affärsriskerna kopplade till att verka i silos.
Hur siloerad kunskap påverkar verksamheten
Det mesta av dokumentationen involverar tvärfunktionellt samarbete på något sätt. Låt oss gå igenom ett exempel där en supportagent uppdaterar en hjälpcenterartikel om en funktion. Agenten kan börja med vanliga frågor som har samlats in av deras team, och kommer sedan att behöva samarbeta med ingenjörsteamet för att få svaren. Några av svaren är dokumenterade i GitHub, men de flesta av dem finns i en ämnesexperts huvud.
När supportagenten har de svaren, kan de också behöva kolla med sitt produktmarknadsföringsteam för att säkerställa att de använder rätt terminologi för funktionens fördelar. Produktmarknadsföringsteamet kan då skicka över ett dokument från deras Google Drive, som har en del meddelanden från fjolårets lansering av funktionen som kan vara föråldrade. Slutligen kollar supportagenten med försäljningsteamet för att se om de har några ytterligare frågor att tillägga, och om de gör det, måste de då kolla tillbaka igen med ingenjörsteamet.
Vid den tidpunkt då supportagenten har byggt ut sin nya hjälpcenterartikel, har de haft samtal med kollegor över hela företaget, som alla har behövt gå in i sina egna separata kunskapskanaler för att hitta stödinformationen. Och det förutsätter att allt flyter smidigt längs vägen. Vad kan hända om ingenjören som är ämnesexperten på funktionen är på semester den veckan? Eller om försäljningsteamet inser att de har fler frågor att lägga till, men de är spridda i olika Slack-kanaler? Med varje hinder på vägen, sträcker sig tidslinjen, och fler och fler möjligheter för kunskapsläckage och misscommunication uppstår.
Organisera företagsinformation. Åtkomst till det var som helst.
Låt oss nu överväga ett alternativt scenario—ett där alla team delar en plats för att dokumentera och få tillgång till viktig aktuell produktkunskap. När supportagenten först kontaktar ingenjörsteamet med frågor, behöver ingenjörsteamet inte oroa sig för om ämnesexperten är på semester den veckan—de har tidigare delat sin expertis med resterande team via den delade kunskapsbasen.
Istället för att produktmarknadsföringsteamet skickar över potentiellt föråldrad information som skrevs för ett år sedan, får de tillgång till sin uppdaterade meddelande- och positioneringsinformation som de verifierar för korrekthet varje kvartal. Och istället för att försäljningsteamet skyndar sig över Slack-kanaler för att hitta frågor som de tidigare har sökt svar på, har de dem alla dokumenterade i en delad plattform som sedan är lätt att skicka över.
Vad som är bättre med hela denna process är att supportagenten till och med skulle kunna hitta mycket av denna information på egen hand, utan att ta andra ur deras arbetsflöde, bara genom att söka.
När all denna information hålls i teamspecifika, isolerade verktyg, är självservice-kunskapsåterhämtning helt enkelt inte möjligt.
Rollerna för realtids-samarbete mellan kollegor kommer aldrig att eliminera; trots allt är dessa interaktioner vad som hjälper oss att skapa kopplingar och empati för varandra. Men i många faser under en produktleverans- och möjliggöringscykel, finns det uppgifter som skulle kunna genomföras mycket mer effektivt när kunskap är demokratiserad över alla team. Både den som söker kunskap och ämnesexperterna kan fortsätta i sitt arbetsflöde utan avbrott, och kan spara sin realtids-samarbetskapacitet för mer meningsfullt och kreativt arbete.
“Jag vet att de gör saker, jag är bara inte helt säker på vad den där saken är.”
Hur många gånger har du hört (eller låt oss vara ärliga, sagt) de orden från en av dina kollegor i referens till ett annat team eller avdelning? Det är lätt för oss att gå vilse i våra egna hörn av företaget i vårt dagliga arbete, vilket ibland leder till en brist på förståelse för vad våra kollegor på andra sidan företaget gör för att få verksamheten att fungera. Och med god anledning: att hålla fokus på sina egna expertområden och ansvar hjälper alla att växa i sina egna funktioner. Men vad händer när den utsikten blir så smal att team kämpar för att se på vilka sätt deras arbete påverkar resten av företaget?
Företagskunskap vill vara tvärfunktionell
När team ser sina funktioner i ett vakuum, ser de ofta sitt teams kunskap i ett vakuum också. För marknadsföringsteam kan detta betyda köparpersonas eller beskrivningar av funktionspositionering. För ingenjörsteam kan detta betyda teknisk dokumentation eller instruktioner för att konfigurera miljön. Och för supportteam kan detta betyda svar på vanliga frågor eller felsökningsguider för funktionsfel. Dessa resurser kan finnas i ett antal verktyg som enskilda team använder, såsom Google Drive, GitHub, Intercom, etc., och kan ägas kollektivt eller av en ledare/ specialist i teamet som fokuserar på dokumentation.
På ytan verkar det rimligt att olika team behöver olika dokumentationsverktyg för att bäst passa sina arbetsflöden, men när vi gräver djupare, avtäcker vi de verkliga affärsriskerna kopplade till att verka i silos.
Hur siloerad kunskap påverkar verksamheten
Det mesta av dokumentationen involverar tvärfunktionellt samarbete på något sätt. Låt oss gå igenom ett exempel där en supportagent uppdaterar en hjälpcenterartikel om en funktion. Agenten kan börja med vanliga frågor som har samlats in av deras team, och kommer sedan att behöva samarbeta med ingenjörsteamet för att få svaren. Några av svaren är dokumenterade i GitHub, men de flesta av dem finns i en ämnesexperts huvud.
När supportagenten har de svaren, kan de också behöva kolla med sitt produktmarknadsföringsteam för att säkerställa att de använder rätt terminologi för funktionens fördelar. Produktmarknadsföringsteamet kan då skicka över ett dokument från deras Google Drive, som har en del meddelanden från fjolårets lansering av funktionen som kan vara föråldrade. Slutligen kollar supportagenten med försäljningsteamet för att se om de har några ytterligare frågor att tillägga, och om de gör det, måste de då kolla tillbaka igen med ingenjörsteamet.
Vid den tidpunkt då supportagenten har byggt ut sin nya hjälpcenterartikel, har de haft samtal med kollegor över hela företaget, som alla har behövt gå in i sina egna separata kunskapskanaler för att hitta stödinformationen. Och det förutsätter att allt flyter smidigt längs vägen. Vad kan hända om ingenjören som är ämnesexperten på funktionen är på semester den veckan? Eller om försäljningsteamet inser att de har fler frågor att lägga till, men de är spridda i olika Slack-kanaler? Med varje hinder på vägen, sträcker sig tidslinjen, och fler och fler möjligheter för kunskapsläckage och misscommunication uppstår.
Organisera företagsinformation. Åtkomst till det var som helst.
Låt oss nu överväga ett alternativt scenario—ett där alla team delar en plats för att dokumentera och få tillgång till viktig aktuell produktkunskap. När supportagenten först kontaktar ingenjörsteamet med frågor, behöver ingenjörsteamet inte oroa sig för om ämnesexperten är på semester den veckan—de har tidigare delat sin expertis med resterande team via den delade kunskapsbasen.
Istället för att produktmarknadsföringsteamet skickar över potentiellt föråldrad information som skrevs för ett år sedan, får de tillgång till sin uppdaterade meddelande- och positioneringsinformation som de verifierar för korrekthet varje kvartal. Och istället för att försäljningsteamet skyndar sig över Slack-kanaler för att hitta frågor som de tidigare har sökt svar på, har de dem alla dokumenterade i en delad plattform som sedan är lätt att skicka över.
Vad som är bättre med hela denna process är att supportagenten till och med skulle kunna hitta mycket av denna information på egen hand, utan att ta andra ur deras arbetsflöde, bara genom att söka.
När all denna information hålls i teamspecifika, isolerade verktyg, är självservice-kunskapsåterhämtning helt enkelt inte möjligt.
Rollerna för realtids-samarbete mellan kollegor kommer aldrig att eliminera; trots allt är dessa interaktioner vad som hjälper oss att skapa kopplingar och empati för varandra. Men i många faser under en produktleverans- och möjliggöringscykel, finns det uppgifter som skulle kunna genomföras mycket mer effektivt när kunskap är demokratiserad över alla team. Både den som söker kunskap och ämnesexperterna kan fortsätta i sitt arbetsflöde utan avbrott, och kan spara sin realtids-samarbetskapacitet för mer meningsfullt och kreativt arbete.
Upplev kraften i Guru-plattformen förstahands - ta vår interaktiva produktturné
.webp)
