Use One Knowledge Base for End-to-End Product Delivery
Silo içinde çalışmanın gerçek iş riskleri vardır. Şirketinizin verimli olabilmesi için gerçek bir merkezi bilgi havuzuna sahip olması gerektiğini görün.
"Bunların bir şeyler yaptığını biliyorum, ama o şeyin tam olarak ne olduğunu bilmiyorum."
Bir takımın başka bir takımı ya da departmanı referans alarak, bir meslektaşınızdan bu kelimeleri kaç kez duydunuz (ya da dürüst olalım, söylediniz)? Günlük işlerimizde kendi köşelerimize kaybolmak bizim için kolaydır; bu bazen diğer tarafımızdaki meslektaşlarımızın işimize nasıl katkıda bulunduğunu anlamakta zorluk çekmemize yol açar. Ve haklı bir sebep var: Kendi uzmanınlık ve sorumluluk alanlarımıza odaklanmak, herkesin kendi işlevlerinde büyümesine yardımcı olur. Ama o görüş o kadar daraldığında ve takımlar, çalışmalarının şirketin geri kalanını nasıl etkilediğini görmekte zorluk çektiğinde ne olur?
Şirket bilgisi çapraz işlevsel olmak ister
Takımlar işlevlerini izole bir şekilde gördüklerinde, çoğunlukla kendi takımlarının bilgilerini de izole olarak görürler. Pazarlama takımları için, bu alıcı profilleri veya özellik konumlandırma açıklamaları anlamına gelebilir. Mühendislik takımları için, bu, teknik dokümantasyon veya ortam kurulum talimatları anlamına gelebilir. Ve destek takımları için, bu, SSS'lere yanıtlar veya özellik hataları için sorun giderme kılavuzları anlamına gelebilir. Bu kaynaklar, Google Drive, GitHub, Intercom vb. gibi bireysel takımların güvendiği çeşitli araçlarda bulunabilir ve topluca ya da belgelendirme ile ilgilenen bir lider/uzman tarafından sahiplenilebilir.
Yüzeysel düzeyde, farklı takımların iş akışlarına en uygun dokümantasyon araçlarına ihtiyaç duyması mantıklıdır; ancak daha derine indikçe, operasyonel silolarla ilişkili gerçek iş risklerini ortaya çıkarırız.
Silo bilgisi operasyonları nasıl etkiler
Çoğu dokümantasyon, çapraz işlevsel iş birliği ile bir şekilde ilişkilidir. Bir destek temsilcisinin bir özellik hakkında yardım merkezi makalesini güncelleme örneğini gözden geçirelim. Temsilci, önce takımları tarafından toplanan SSS'lerle başlayabilir ve ardından cevapları almak için mühendislik takımı ile işbirliği yapması gerekecektir. Bu cevapların bazıları GitHub'da belgelenmiştir, ancak çoğu bir konu uzmanının zihninde yer alır.
Destek temsilcisi bu cevaplara sahip olduktan sonra, belki de ürün pazarlama takımlarıyla kontrol etmeleri gerekecektir; böylece özelliğin faydaları için doğru terminolojiyi kullandıklarından emin olabilirler. Ürün pazarlama takımı, onların Google Drive'larından geçen yılki özellik lansmanına ait, belki de bayat olmuş bilgileri içeren bir tek sayfa gönderebilir. Sonunda, destek temsilcisi satış takımıyla irtibat kurar, eğer eklemek için başka soruları varsa, mühendislikle tekrar kontrol etmelidirler.
Destek temsilcisi yeni yardım merkezi makalesini oluşturduğunda, şirket genelinde ekip arkadaşlarıyla görüşmeler yapmışlardır; bu kişiler tüm destekleyici bilgileri bulmak için kendi ayrı bilgi kanallarına girmiştir. Ve bunun yolunda her şeyin sorunsuz gittiğini varsayıyoruz. Özellikte uzman olan mühendis o hafta tatile giderse ne olur? Ya da satış takımı eklemek için başka soruları olduğunu fark ederse, ama bunlar çeşitli Slack kanallarında dağılmışsa? Yolda her engelle, zaman çizelgesi uzatılır ve bilgi sızıntısı ve yanlış iletişim için daha fazla fırsat ortaya çıkar.
Şirket bilgilerini organize edin. Her yerde erişin.
Şimdi, tüm ekiplerin önemli, güncel ürün bilgilerini belgelemek ve erişmek için bir yer paylaştığı alternatif bir senaryoyu düşünelim. Destek temsilcisi başlangıçta mühendislik ekibiyle sorularla irtibat kurarken, mühendislik ekibi o hafta SME'nin tatile gitmiş olmasından korkmamalıdır; daha önce uzmanlıklarını ortak bilgi havuzuyla paylaşmışlardır.
Ürün pazarlama takımı bir yıl önce yazılmış olabilecek belki de eski bilgileri göndermek yerine, her çeyrek doğruluğunu doğruladıkları güncellenmiş mesaj ve konumlandırma bilgilerine erişirler. Ve satış takımı, daha önce yanıt aradıkları soruları bulmak için Slack kanalları arasında koşuşturmak yerine, hepsini kolayca göndermek için belgelendirilmiş bir ortak platformda bulurlar.
Bu sürecin en iyi tarafı, destek temsilcisinin tüm bu bilgiyi kendiliğinden bulabilmesi; böylece diğerlerini iş akışlarından çıkarmadan sadece aramayla bunu gerçekleştirmesidir.
Tüm bu bilgiler takım özel, silolu araçlarda tutulduğunda, kendi kendine hizmet bilgisine erişim mümkün değildir.
Meslektaşlar arasında gerçek zamanlı iş birliğinin rolü asla ortadan kalkmayacaktır; her şeyden önce, bu etkileşimler, bizim birbirimizle bağ kurmamızı ve empati kurmamızı sağlayan şeylerdir. Ama bir ürün teslimi ve etkinleştirme döngüsü boyunca pek çok aşamada, bilgilerin tüm takımlar arasında demokratikleştirildiğinde çok daha verimli bir şekilde tamamlanabilecek görevler vardır. Bilgi arayan ve konu uzmanları kendi iş akışlarında kesintisiz devam edebilirler ve gerçek zamanlı iş birliği yeteneklerini daha anlamlı ve yaratıcı çalışmalara ayırabilirsiniz.
"Bunların bir şeyler yaptığını biliyorum, ama o şeyin tam olarak ne olduğunu bilmiyorum."
Bir takımın başka bir takımı ya da departmanı referans alarak, bir meslektaşınızdan bu kelimeleri kaç kez duydunuz (ya da dürüst olalım, söylediniz)? Günlük işlerimizde kendi köşelerimize kaybolmak bizim için kolaydır; bu bazen diğer tarafımızdaki meslektaşlarımızın işimize nasıl katkıda bulunduğunu anlamakta zorluk çekmemize yol açar. Ve haklı bir sebep var: Kendi uzmanınlık ve sorumluluk alanlarımıza odaklanmak, herkesin kendi işlevlerinde büyümesine yardımcı olur. Ama o görüş o kadar daraldığında ve takımlar, çalışmalarının şirketin geri kalanını nasıl etkilediğini görmekte zorluk çektiğinde ne olur?
Şirket bilgisi çapraz işlevsel olmak ister
Takımlar işlevlerini izole bir şekilde gördüklerinde, çoğunlukla kendi takımlarının bilgilerini de izole olarak görürler. Pazarlama takımları için, bu alıcı profilleri veya özellik konumlandırma açıklamaları anlamına gelebilir. Mühendislik takımları için, bu, teknik dokümantasyon veya ortam kurulum talimatları anlamına gelebilir. Ve destek takımları için, bu, SSS'lere yanıtlar veya özellik hataları için sorun giderme kılavuzları anlamına gelebilir. Bu kaynaklar, Google Drive, GitHub, Intercom vb. gibi bireysel takımların güvendiği çeşitli araçlarda bulunabilir ve topluca ya da belgelendirme ile ilgilenen bir lider/uzman tarafından sahiplenilebilir.
Yüzeysel düzeyde, farklı takımların iş akışlarına en uygun dokümantasyon araçlarına ihtiyaç duyması mantıklıdır; ancak daha derine indikçe, operasyonel silolarla ilişkili gerçek iş risklerini ortaya çıkarırız.
Silo bilgisi operasyonları nasıl etkiler
Çoğu dokümantasyon, çapraz işlevsel iş birliği ile bir şekilde ilişkilidir. Bir destek temsilcisinin bir özellik hakkında yardım merkezi makalesini güncelleme örneğini gözden geçirelim. Temsilci, önce takımları tarafından toplanan SSS'lerle başlayabilir ve ardından cevapları almak için mühendislik takımı ile işbirliği yapması gerekecektir. Bu cevapların bazıları GitHub'da belgelenmiştir, ancak çoğu bir konu uzmanının zihninde yer alır.
Destek temsilcisi bu cevaplara sahip olduktan sonra, belki de ürün pazarlama takımlarıyla kontrol etmeleri gerekecektir; böylece özelliğin faydaları için doğru terminolojiyi kullandıklarından emin olabilirler. Ürün pazarlama takımı, onların Google Drive'larından geçen yılki özellik lansmanına ait, belki de bayat olmuş bilgileri içeren bir tek sayfa gönderebilir. Sonunda, destek temsilcisi satış takımıyla irtibat kurar, eğer eklemek için başka soruları varsa, mühendislikle tekrar kontrol etmelidirler.
Destek temsilcisi yeni yardım merkezi makalesini oluşturduğunda, şirket genelinde ekip arkadaşlarıyla görüşmeler yapmışlardır; bu kişiler tüm destekleyici bilgileri bulmak için kendi ayrı bilgi kanallarına girmiştir. Ve bunun yolunda her şeyin sorunsuz gittiğini varsayıyoruz. Özellikte uzman olan mühendis o hafta tatile giderse ne olur? Ya da satış takımı eklemek için başka soruları olduğunu fark ederse, ama bunlar çeşitli Slack kanallarında dağılmışsa? Yolda her engelle, zaman çizelgesi uzatılır ve bilgi sızıntısı ve yanlış iletişim için daha fazla fırsat ortaya çıkar.
Şirket bilgilerini organize edin. Her yerde erişin.
Şimdi, tüm ekiplerin önemli, güncel ürün bilgilerini belgelemek ve erişmek için bir yer paylaştığı alternatif bir senaryoyu düşünelim. Destek temsilcisi başlangıçta mühendislik ekibiyle sorularla irtibat kurarken, mühendislik ekibi o hafta SME'nin tatile gitmiş olmasından korkmamalıdır; daha önce uzmanlıklarını ortak bilgi havuzuyla paylaşmışlardır.
Ürün pazarlama takımı bir yıl önce yazılmış olabilecek belki de eski bilgileri göndermek yerine, her çeyrek doğruluğunu doğruladıkları güncellenmiş mesaj ve konumlandırma bilgilerine erişirler. Ve satış takımı, daha önce yanıt aradıkları soruları bulmak için Slack kanalları arasında koşuşturmak yerine, hepsini kolayca göndermek için belgelendirilmiş bir ortak platformda bulurlar.
Bu sürecin en iyi tarafı, destek temsilcisinin tüm bu bilgiyi kendiliğinden bulabilmesi; böylece diğerlerini iş akışlarından çıkarmadan sadece aramayla bunu gerçekleştirmesidir.
Tüm bu bilgiler takım özel, silolu araçlarda tutulduğunda, kendi kendine hizmet bilgisine erişim mümkün değildir.
Meslektaşlar arasında gerçek zamanlı iş birliğinin rolü asla ortadan kalkmayacaktır; her şeyden önce, bu etkileşimler, bizim birbirimizle bağ kurmamızı ve empati kurmamızı sağlayan şeylerdir. Ama bir ürün teslimi ve etkinleştirme döngüsü boyunca pek çok aşamada, bilgilerin tüm takımlar arasında demokratikleştirildiğinde çok daha verimli bir şekilde tamamlanabilecek görevler vardır. Bilgi arayan ve konu uzmanları kendi iş akışlarında kesintisiz devam edebilirler ve gerçek zamanlı iş birliği yeteneklerini daha anlamlı ve yaratıcı çalışmalara ayırabilirsiniz.
Guru platformunun gücünü ilk elden deneyimleyin - etkileşimli ürün turumuzu yapın