Yirmi yılı aşkın bir süredir semantik ve bilgi grafikleriyle uğraştıktan sonra Bilgi Yönetimi hakkında oldukça iyi bir fikrim olduğunu düşünebilirsiniz, ama öyle olmadığı ortaya çıktı.
Nadiren bu terimin ortaya çıktığını düşünüyorum, onu dahili olarak Bilgi Grafikleri ile birleştirdim ve yoluma devam ettim. Hatırlayabildiğim kadarıyla omuza ilk dokunuş, Suudi Arabistan’da bir mega projede çalışmanın tanıtımını yaptığımız zamandı (anlamadık, ama muhtemelen nedeni bu değil). Neom Line’ın dönüşeceği akıllı şehir için birleştirici lif olarak semantik ve bilgi grafiklerini sunmaya çalışıyorduk.
Bu süreçte, düşündükleri Sertifikalı Bilgi Yönetimi platformlarının kısa bir listesine rastladık. Hiçbirini duymadığım zaman üzüntümü bir düşünün. Artık o listeyi bulamıyorum, ancak o zamandan beri birkaç tane daha buldum.
Çok daha ileri gitmeden önce, bilgi yönetiminin ne olduğunu anlamaya çalışalım. Aşağıdakilerin çoğunda, ChatGPT’den beklediğimiz otorite ve anlamsızlık kombinasyonuna sahip olduğuna dikkat edin. Ama işte gidiyor.
IBM’den başlayalım:
Bilgi yönetimi (KM), bir kuruluş içindeki bilgileri tanımlama, düzenleme, depolama ve yayma sürecidir.1
Kulağa hoş geliyor değil mi? Bunu düşünene kadar. Bunun diğer herhangi bir veri yönetimi, bilgi yönetimi, bilgi grafiği veya açıkçası herhangi bir bilgisayar sisteminden farkı nedir?
Adil olmak gerekirse, size KM’ye sahip olmamanın kötü ve buna sahip olmanın iyi olduğunu söyledikten sonra, bilginin ne olduğu konusunda dolaşmaya başlarlar. Bu umut verici. Bize üç tür bilgi olduğunu söylerler: zımni, örtük ve açık. Örtülü bilgi (bir dilin nasıl konuşulacağı, bisiklete binilmesi veya bir grubun nasıl yönetileceği) tipik olarak kodlanamaz. Örtük bilgi ise henüz belgelenmemiştir. Belgelendiğinde açık hale gelir ve bu nedenle bilgi yönetimi söz konusu olduğunda bir tür bilgi vardır: açık.
Açık bilginin el kitaplarında, raporlarda ve kılavuzlarda saklandığını söylemeye devam ediyorlar. Tamam, şimdi bir yere varıyoruz. Ana KM sistem türlerinin şunlar olduğunu söylemeye devam ediyorlar: belge yönetimi, içerik yönetimi (bunu her zaman ayrımsız bir fark olarak gördüm), intranetler, wiki’ler ve veri ambarları. (Susam Sokağı’nda dedikleri gibi, bunlardan hangisi diğerleri gibi değil?)2
Bir süreliğine IBM’le uğraşmayı bırakıp başka birini seçelim. KM World, Tom Davenport’un 1994 tarihli Bilgi Yönetimi tanımıyla uyumludur:
Bilgi Yönetimi, bilgiyi yakalama, dağıtma ve etkili bir şekilde kullanma sürecidir.3
Konuyla ilgili yetkili makam olarak Gartner’dan alıntı yapmaya devam ediyorlar:
Bilgi yönetimi, bir kuruluşun tüm bilgi varlıklarını tanımlama, yakalama, değerlendirme, geri alma ve paylaşmaya yönelik entegre bir yaklaşımı destekleyen bir disiplindir. Bu varlıklar, veritabanlarını, belgeleri, politikaları, prosedürleri ve daha önce tek tek çalışanlarda elde edilmemiş uzmanlık ve deneyimleri içerebilir.4
Bilgi Yönetiminin ne olduğunu özetlemeye devam ediyorlar.5 içerir:
- İçerik yönetimi
- Uzmanlık Yeri
- Dersler öğrenildi
- Uygulama Toplulukları
Bilgi grafiği projelerimizden biri bir uzmanlık yer belirleme sistemi olduğundan, bu özellikle bir zil çaldı. Kendimi biraz Bay Jourdain gibi hissediyorum. Burjuva Beyefendisi, bunca yıldır bilmeden nesir konuştuğunu bilmekten memnun olan. Belki de bunca yıldır bilmeden Bilgi Yönetimi yapıyorum.
Aslında, bulduğum KM araçları listesindeki tek KM aracının Atlassian’s Confluence (bizim ve birçok kişinin kullandığı dahili bir wiki platformu) olduğunu öğrendiğimde. düşündüm, belki Biz biraz bilgi sahibi olmak Ne yazık ki, sitemizin içeriğine hızlı bir göz atmak beni bu düşünceden vazgeçirdi.
Belki de bilgi yönetimi yapmıyorduk. Daha derin bir göz atalım.
Bilgi Grafiklerine koyduğumuz tüm bu şeyler bilgi mi? Eğer öyleyse, ne tür? Eğer değilse, nedir?
Bazı eski güzel gerçeklerle başlayalım.
Diyelim ki keşfettik:
- Empire State Binası, 350 Fifth Avenue, New York NY adresindedir.
- 1.454 ft boyunda
- Shreve, Lamb ve Harmon firması tarafından tasarlanmıştır.
(Bu arada bu bir sır değil, Wikipedia’dan aldım). Bu bilgi mi? Bazı insanlar öyle diyebilir ama anlambilim ve bilgi grafiklerinde bunların iddia olduğunu söyleyebiliriz. Bunları üçlü olarak uyguluyoruz. “ABox” (İddia Kutusu) içinde var. Bu tür bilgileri yönetmek için herhangi bir özel bilgi yönetim sistemine ihtiyacımız yoktur. Aslında, yoluna girecekti. Bu tür bilgileri üçe indirdiğimizde, bir KM sisteminde olmayan her türlü ortaya çıkan özelliğe sahiptir. Bu bilgiyi çok sayıda başka bilgiyle birleştirebiliriz (bir grafikte!). Sorgulayabilir, toplayabilir, grafik analitiği uygulayabilir ve çok daha fazlasını yapabiliriz. Ayrıca, çok daha iyi ölçeklenir. Bir milyar üçlüyle uğraşmak, yüz milyon belgede eşdeğer bilgileri bulmaktan çok daha kolaydır.
Empire State Building’e geri dönelim ve başka hangi bilgilere sahip olabileceğimizi düşünelim.
Şunları biliyor olabiliriz:
- Bu bir gökdelen,
- Ve bu nedenle, bir bina ve bu nedenle
- Bir Eser ve ayrıca
- Bir dönüm noktası
Ve bu basit kavrayışlardan çok şey çıkarabiliriz. Ayrıca, bu sınıf hiyerarşisinin herhangi bir seviyesinde arama yapabilirsek, bu bilgi külçelerini bulmayı çok daha kolay hale getirebiliriz. Bunu sınıf yapısı olan “TBox”ta (Terminolojik Kutu) ele alıyoruz. Ama yine de, bunu yapmamıza yardımcı olması için KM’ye ihtiyacımız yok. Aslında, bu konuda pek yardımcı olmuyor.
Bilgi olabilecek ve KM’den fayda sağlayabilecek bir yapıt adayı kümesi daha:
Empire State Binasını kategorize edebiliriz. Muhtemelen onu farklı amaçlar için kategorize edebileceğimiz düzinelerce yol vardır. Bu, geleneksel KM’ye yaklaştığımız bir alemdir. Ama gerçekten, bu Taksonomi yönetimine daha yakın. Taksonomi yönetimi, kategori oluşturma ve kullanma sanatı ve bilimidir. Tek başına bir alıştırma olarak anlamsızdır, ancak kategorize ettiği şeylerle birleştirildiğinde faydalı olabilir. Bir içerik yönetim sisteminde veya bir yazarlık sisteminde bu genellikle anahtar kelimeler olarak ortaya çıkar. Bu kategoriler etiketlere indirgenebilir ve daha sonra profesyonellerin “etiketleme” dediği bir süreçte belgelere uygulanabilir. Bir Bilgi Grafiğinde, kategorize etmek için üçlüleri kullanırız. Taksonomik kategorileri içeren sorgulama için tek bir birleştirici yaklaşıma sahip olmak çok daha kolaydır. Buna “CBox” veya kategorik kutu diyoruz.
Dolayısıyla, bir kuruluşta tipik olarak bulunan bilgilerin büyük bir kısmında Bilgi Yönetiminin rolünü baltaladığımızı düşünüyorum. Bir şey kaldı mı? Evet, Bilgi Yönetimi için bir rol olduğu ortaya çıktı. Bilgi Yönetimi ve Bilgi Grafiklerini entegre etmenin bir yolu var mı? Yine, evet, bence var.
Önce geri dönelim ve bu makaleyi açtığımız kibirli dilin bazılarını çürütelim. Gartner’ın tanımının şu bölümünü hatırlayın: “Bilgi yönetimi, bir kuruluşun tüm bilgi varlıklarını tanımlama, yakalama, değerlendirme, geri alma ve paylaşmaya yönelik entegre bir yaklaşımı destekleyen bir disiplindir.” Bir KM sisteminin bir kuruluşun tüm bilgi varlıklarının çok küçük bir yüzdesini bile yapabileceğine kimse inanabilir mi? Gerçekten mi? Maaş verileri? Envanter? Tıklama akışı analizi?
Hepsi bilgi değilse, o zaman hangi alt kümedir ve bilgiyi diğer her şeyle nasıl bütünleştiririz?
Bunun üzerinde çok düşündükten sonra, bilginin şu anda içeriğe (belgeler, videolar vb.) sıkı sıkıya bağlı olduğunu söyleyebilirim. İçerikle ilgili sorun, çoğunlukla insanların onu okumasını veya izlemesini ve uygulamayı anlamasını gerektirmesidir. Hepsi bu kadar kötü değil. Doğru belgeyi doğru kişiye doğru zamanda ulaştırabilirsek bu yardımcı olabilir. Ama daha iyisini yapabiliriz.
Bir an için bir kuruluşun hala çok fazla içeriği olacağını varsayalım. Yapabileceğimiz en iyi şey nedir?
Sallie Mae (öğrenci kredisi şirketi) ile bir proje yaptık. Bulduğumuz şey, sahip oldukları içeriğin çoğunun ya müşterileriyle (öğrenciler ve üniversiteler) ya da kendi ürünleriyle (belirli bir kredi türü için müsamaha isteme prosedürü neydi) ilgili olduğuydu.
Bir bilgi grafiği, çeşitli yapılandırılmış veri sistemlerinden gelen verileri entegre etmenin mükemmel bir yoludur (ve çoğu şirketin bu tür binlerce yapılandırılmış veri kaynağı vardır). İlgilenilen içerik genel olarak yapılandırılmış kaynaklardan gelen verilerle ilgili olduğundan, entegrasyonun mantıksal düzeyi bu gibi görünmektedir. Başka bir deyişle, grafikte normalize edilmiş ve rasyonelleştirilmiş yapılandırılmış verileri, belirli kişilere, organizasyona, etkinliğe, ürünlere ve benzerlerine atıfta bulunduğu içeriğe doğrudan bağlayın. Bu seviyede, tüm bağlantı noktalarını bulmak için bir NLP paletli erişim dışında belge veya içerik yönetim sisteminden ekstra hiçbir şeye gerek yoktur.
Bu, kuruluşta bilgi yönetimi yazılımının rolü olmadığı anlamına mı geliyor? Hayır. Görünüşe göre, yukarıdaki ayrışmanın çatlaklarından düşen bir bilgi kategorisi var.
Damıtılmış veya Birleştirilmiş Bilgi
Gösterildiği gibi, bilgi grafiği temsiline doğal olarak uygun olmayan bir kategori vardır. (Ara sıra yapılır, ancak doğal olmayan bir harekettir).
Bu kategori, şu anda birçok başka verinin insan tarafından damıtılması olan bilgilerdir. Bunu deneyim veya içgörü olarak düşünüyoruz. Empire State örneğinde, aşağıdakilerin tanınması gibi gözlemleri dahil edeceğiz:
- Bu bir gökdelen ve
- Tipik olarak gökdelenler, giydirme duvarları destekleyen çelik çerçevelere sahiptir.
- Rüzgar genellikle gökdelenlerin tasarımında deprem veya ağırlıktan daha önemli bir yük faktörüdür.
- Gökdelenlerde asansör vardır.
- Gökdelenler arsa fiyatlarının yüksek olduğu büyük şehirlerde yapılır.
Bunun bilgi grafikleri için doğal bir eşleşme olmamasının nedeni, bunların tipik olarak belirli örnekler üzerine inşa edilmiş olmalarıdır. Öğrenci kredisi bilgi grafiğinde, milyonlarca öğrenci ve kredileri hakkında milyarlarca gerçek (üçlü) vardır. Bir miktar kategorik bilgi ve belirli bir kredi türünün veya öğrenci türünün tüm örnekleri için geçerli olan şeyler vardır, ancak niteliksel ve nüfusa dayalı bilgiler için normal bir yer değildir. Kolejden ayrılan öğrencilerin, derecelerini tamamlayan öğrencilere göre daha yüksek bir temerrüt oranına sahip olduğunu söyleyebilmemiz gerekir. Bu, bireysel bir öğrenciye iliştirdiğiniz bir gerçek değil, bir öğrenci popülasyonuna iliştirdiğiniz bir öğrenmedir.
Semantic Arts’ta şu anda bir Bilgi Ontolojisi üzerinde çalışıyoruz. Bir ay öncesine kadar, tüm ontolojilerin bilgi ontolojileri olduğunu düşünürdüm. Ama şimdi farklı bir bakış açısı elde ediyorum.
Bu, bu tür bilgileri depolamak ve sorgulamak için ontolojik bir yapı olacaktır. Bunun için çalışma başlığımız “tipik olarak” ontolojidir çünkü içindeki bilgilerin çoğu tipik olarak doğrudur. Brent Ham Petrolü tipik olarak Kuzey Denizi’nde bulunur. Gut tipik olarak yüksek ürik asit seviyelerinden kaynaklanır. Başarılı kimlik avı saldırılarının insidansı, genellikle dahili simüle kimlik avı tatbikatları ile azaltılır. Egemen para birimi enflasyonu tipik olarak döviz kurlarını zayıflatır.
Bir Bilgi Yönetimi platformunun en yüksek kullanımının, bu tür derlenmiş ve damıtılmış bilginin geliştirilmesi ve kodlanması olduğunu düşünüyoruz. Ve bir bilgi grafiğinin rolü, firmanın geri kalan bilgilerinin çoğunu organize etmektir. Bilgi Ontolojisinin rolü özellikle ikisi arasındaki bağlantıyı sağlamaktır.
[1]https://www.ibm.com/topics/knowledge-management
[2] Tamam, sana bu konuda yardım edeceğim. Bir intranet, bir içerik yönetim sisteminden çok bir ağdır. Ve bir veri ambarı, bilgiyi bulmak için garip bir yer olurdu. Çok fazla veri bulabilirsiniz ama kendi bilginizi getirin.
[3]https://www.kmworld.com/About/What_is_Knowledge_Management
[4]aynı eser (Bunu hep bir makalede söylemek istemişimdir ve bir şekilde hiç gündeme gelmemiştir)
[5]aynı eser (bir gazetede iki eser! Burada iyi bir hayat yaşıyorum)
