Use One Knowledge Base for End-to-End Product Delivery
Er zijn echte zakelijke risico's verbonden aan het opereren in silo's. Bekijk waarom jouw bedrijf een echte gecentraliseerde kennisbasis verdient om efficiënt te zijn.
“Ik weet dat ze dingen doen, ik ben alleen niet precies zeker wat dat ding is.”
Hoe vaak heb je die woorden gehoord (of laten we eerlijk zijn, gezegd) van een van je collega's in verband met een ander team of departement? Het is gemakkelijk voor ons om verloren te raken in onze eigen hoeken van ons bedrijf in ons dagelijkse werk, wat soms leidt tot een gebrek aan begrip van wat onze collega's aan de andere kant van het gebouw doen om ons bedrijf te laten functioneren. En terecht: gefocust blijven op je eigen expertisegebieden en verantwoordelijkheden helpt iedereen om te groeien in hun eigen functies. Maar wat gebeurt er wanneer dat zicht zo smal wordt dat teams moeite hebben om te zien op welke manieren hun werk de rest van het bedrijf beïnvloedt?
Bedrijfskennis wil cross-functioneel zijn
Wanneer teams hun functies in een vacuüm zien, zien ze vaak de kennis van hun team ook in een vacuüm. Voor marketingteams kan dit betekenen: koperpersona's of functiepositioneringsbeschrijvingen. Voor engineeringteams kan dit betekenen: technische documentatie of instructies voor het opzetten van omgevingen. En voor ondersteuningsteams kan dit betekenen: antwoorden op veelgestelde vragen of troubleshootinggidsen voor functiefouten. Deze bronnen kunnen zich in een aantal tools bevinden die individuele teams gebruiken, zoals Google Drive, GitHub, Intercom, enz., en kunnen collectief of door een leider/specialist van het team worden beheerd die zich richt op documentatie.
Op oppervlakkig niveau is het logisch dat verschillende teams verschillende documentatietools nodig hebben om hun workflows het beste te ondersteunen, maar als we dieper graven, ontdekken we de werkelijke zakelijke risico's die gepaard gaan met het functioneren in silo's.
Hoe gesiloode kennis de operaties beïnvloedt
Meeste documentatie omvat cross-functionele samenwerking op een of andere manier. Laten we een voorbeeld bekijken van een ondersteuningsagent die een artikel in het helpcentrum bijwerkt over een functie. De agent kan beginnen met veelgestelde vragen die door hun team zijn verzameld en zal dan moeten samenwerken met het engineeringteam om de antwoorden te krijgen. Sommige van die antwoorden zijn gedocumenteerd in GitHub, maar de meeste bevinden zich in het hoofd van een onderwerpsexpert.
Zodra de ondersteuningsagent die antwoorden heeft, moeten ze misschien ook contact opnemen met hun productmarketingteam om er zeker van te zijn dat ze de juiste terminologie gebruiken voor de voordelen van de functie. Het productmarketingteam kan dan een één blad uit hun Google Drive opsturen, dat enkele boodschappen bevat van de lancering van de functie vorig jaar die misschien verouderd is. Ten slotte controleert de ondersteuningsagent bij het verkoopteam of ze nog aanvullende vragen hebben om toe te voegen, en als ze dat doen, moeten ze weer terugkijken met engineering.
Tegen de tijd dat de ondersteuningsagent hun nieuwe helpcentrumartikel heeft opgesteld, hebben ze gesprekken gehad met teamgenoten in het hele bedrijf, die allemaal naar hun eigen aparte kenniskanalen zijn gegaan om de ondersteunende informatie te vinden. En dat is ervan uitgaande dat alles soepel verloopt. Wat zou er gebeuren als de engineer die de onderwerpsexpert op de functie is die week op vakantie is? Of als het verkoopteam zich realiseert dat ze aanvullende vragen hebben om toe te voegen, maar ze verspreid zijn in verschillende Slack-kanalen? Bij elke hobbel op de weg, wordt de tijdlijn uitgerekt, en worden er steeds meer kansen voor kennisverlies en miscommunicatie geboden.
Laten we een alternatief scenario overwegen—een waarin alle teams een plek delen om belangrijke up-to-date productkennis te documenteren en te benaderen. Wanneer de ondersteuningsagent aanvankelijk contact opneemt met het engineeringteam met vragen, hoeft het engineeringteam zich geen zorgen te maken als de SME die week op vakantie is—ze zouden hun expertise eerder hebben gedeeld met de rest van het team via de gedeelde kennisbank.
In plaats van dat het productmarketingteam mogelijk verouderde informatie opstuurt die een jaar geleden is geschreven, krijgen ze toegang tot hun bijgewerkte boodschappen en positioneringsinformatie die ze elk kwartaal verifiëren op nauwkeurigheid. En in plaats van dat het verkoopteam door Slack-kanalen moet rommelen om vragen te vinden waar ze eerder antwoorden op hebben gezocht, hebben ze alles gedocumenteerd in een gedeeld platform dat vervolgens gemakkelijk kan worden opgestuurd.
Wat beter is aan dit hele proces is dat de ondersteuningsagent zelfs veel van deze informatie zelf kan vinden, zonder anderen uit hun workflow te halen, gewoon door te zoeken.
Wanneer al deze informatie wordt bewaard in teamspecifieke, gesiloede tools, is zelfbediening van kennisretrieval gewoon niet mogelijk.
De rol van realtime samenwerking tussen collega's zal nooit worden geëlimineerd; tenslotte zijn die interacties wat ons helpt om verbindingen met en empathie voor elkaar te vormen. Maar in veel fasen gedurende een productlevering en capaciteitscyclus bestaan taken die veel efficiënt kunnen worden uitgevoerd wanneer kennis is gedemocratiseerd over alle teams. Zowel de kenniszoeker als de onderwerpsexperts kunnen hun workflow ononderbroken voortzetten, en kunnen hun realtime samenwerkingbandbreedte behouden voor meer betekenisvol en creatief werk.
“Ik weet dat ze dingen doen, ik ben alleen niet precies zeker wat dat ding is.”
Hoe vaak heb je die woorden gehoord (of laten we eerlijk zijn, gezegd) van een van je collega's in verband met een ander team of departement? Het is gemakkelijk voor ons om verloren te raken in onze eigen hoeken van ons bedrijf in ons dagelijkse werk, wat soms leidt tot een gebrek aan begrip van wat onze collega's aan de andere kant van het gebouw doen om ons bedrijf te laten functioneren. En terecht: gefocust blijven op je eigen expertisegebieden en verantwoordelijkheden helpt iedereen om te groeien in hun eigen functies. Maar wat gebeurt er wanneer dat zicht zo smal wordt dat teams moeite hebben om te zien op welke manieren hun werk de rest van het bedrijf beïnvloedt?
Bedrijfskennis wil cross-functioneel zijn
Wanneer teams hun functies in een vacuüm zien, zien ze vaak de kennis van hun team ook in een vacuüm. Voor marketingteams kan dit betekenen: koperpersona's of functiepositioneringsbeschrijvingen. Voor engineeringteams kan dit betekenen: technische documentatie of instructies voor het opzetten van omgevingen. En voor ondersteuningsteams kan dit betekenen: antwoorden op veelgestelde vragen of troubleshootinggidsen voor functiefouten. Deze bronnen kunnen zich in een aantal tools bevinden die individuele teams gebruiken, zoals Google Drive, GitHub, Intercom, enz., en kunnen collectief of door een leider/specialist van het team worden beheerd die zich richt op documentatie.
Op oppervlakkig niveau is het logisch dat verschillende teams verschillende documentatietools nodig hebben om hun workflows het beste te ondersteunen, maar als we dieper graven, ontdekken we de werkelijke zakelijke risico's die gepaard gaan met het functioneren in silo's.
Hoe gesiloode kennis de operaties beïnvloedt
Meeste documentatie omvat cross-functionele samenwerking op een of andere manier. Laten we een voorbeeld bekijken van een ondersteuningsagent die een artikel in het helpcentrum bijwerkt over een functie. De agent kan beginnen met veelgestelde vragen die door hun team zijn verzameld en zal dan moeten samenwerken met het engineeringteam om de antwoorden te krijgen. Sommige van die antwoorden zijn gedocumenteerd in GitHub, maar de meeste bevinden zich in het hoofd van een onderwerpsexpert.
Zodra de ondersteuningsagent die antwoorden heeft, moeten ze misschien ook contact opnemen met hun productmarketingteam om er zeker van te zijn dat ze de juiste terminologie gebruiken voor de voordelen van de functie. Het productmarketingteam kan dan een één blad uit hun Google Drive opsturen, dat enkele boodschappen bevat van de lancering van de functie vorig jaar die misschien verouderd is. Ten slotte controleert de ondersteuningsagent bij het verkoopteam of ze nog aanvullende vragen hebben om toe te voegen, en als ze dat doen, moeten ze weer terugkijken met engineering.
Tegen de tijd dat de ondersteuningsagent hun nieuwe helpcentrumartikel heeft opgesteld, hebben ze gesprekken gehad met teamgenoten in het hele bedrijf, die allemaal naar hun eigen aparte kenniskanalen zijn gegaan om de ondersteunende informatie te vinden. En dat is ervan uitgaande dat alles soepel verloopt. Wat zou er gebeuren als de engineer die de onderwerpsexpert op de functie is die week op vakantie is? Of als het verkoopteam zich realiseert dat ze aanvullende vragen hebben om toe te voegen, maar ze verspreid zijn in verschillende Slack-kanalen? Bij elke hobbel op de weg, wordt de tijdlijn uitgerekt, en worden er steeds meer kansen voor kennisverlies en miscommunicatie geboden.
Laten we een alternatief scenario overwegen—een waarin alle teams een plek delen om belangrijke up-to-date productkennis te documenteren en te benaderen. Wanneer de ondersteuningsagent aanvankelijk contact opneemt met het engineeringteam met vragen, hoeft het engineeringteam zich geen zorgen te maken als de SME die week op vakantie is—ze zouden hun expertise eerder hebben gedeeld met de rest van het team via de gedeelde kennisbank.
In plaats van dat het productmarketingteam mogelijk verouderde informatie opstuurt die een jaar geleden is geschreven, krijgen ze toegang tot hun bijgewerkte boodschappen en positioneringsinformatie die ze elk kwartaal verifiëren op nauwkeurigheid. En in plaats van dat het verkoopteam door Slack-kanalen moet rommelen om vragen te vinden waar ze eerder antwoorden op hebben gezocht, hebben ze alles gedocumenteerd in een gedeeld platform dat vervolgens gemakkelijk kan worden opgestuurd.
Wat beter is aan dit hele proces is dat de ondersteuningsagent zelfs veel van deze informatie zelf kan vinden, zonder anderen uit hun workflow te halen, gewoon door te zoeken.
Wanneer al deze informatie wordt bewaard in teamspecifieke, gesiloede tools, is zelfbediening van kennisretrieval gewoon niet mogelijk.
De rol van realtime samenwerking tussen collega's zal nooit worden geëlimineerd; tenslotte zijn die interacties wat ons helpt om verbindingen met en empathie voor elkaar te vormen. Maar in veel fasen gedurende een productlevering en capaciteitscyclus bestaan taken die veel efficiënt kunnen worden uitgevoerd wanneer kennis is gedemocratiseerd over alle teams. Zowel de kenniszoeker als de onderwerpsexperts kunnen hun workflow ononderbroken voortzetten, en kunnen hun realtime samenwerkingbandbreedte behouden voor meer betekenisvol en creatief werk.
Ervaar de kracht van het Guru-platform uit de eerste hand - maak onze interactieve producttour