Geçen yazımızda 'Kurumsal Sosyal Ağ Yazılımları yayılabilir mi?' sorusunu incelemeye çalışmıştık. Bu uygulamalar bir miktar ütopik gelse de bir kaç önemli noktaya temas etmiştik. İş yapma şeklinin nasıl hızlı değiştiğini, pragmatizmin bu tip uygulamalarda nasıl etkide bulunduğunu ve 'yönetimsel moda'nın tercihleri nasıl etkilediğini anlatmıştık. Şimdi de sosyal yazılımların nasıl evrimleştiğine dair biraz ukalalık yapalım.

Öncelikle 'collaboration' kelimesinin altını çizmek lazım. Türkçe'ye çevirirken sıklıkla 'işbirliği', 'birlikte çalışma' gibi tanımlamalar kullanıyoruz.  Wikipedia makalesine  bakarsak bir kaç temel parametre öne çıkıyor:
 

• İletişim (communication)
• Dağıtık gruplar (decentralized groups)
• Koordinasyon (coordination)
• Ortak amaç (common goal)
• Bilgi paylaşımı (sharing knowledge)
• Fikir paylaşımı (sharing ideas)

Lotus Notes/Domino ve Microsoft Outlook/Exchange gibi uygulamalara 'collaboration' uygulamaları demek çok yetersiz olur, mesajlaşma uygulamaları olarak kategorize edilebilirler. Tabii ki Lotus Notes, sunduğu bir takım fonksiyonlar ve uygulama geliştirme olanakları sayesinde 'groupware' ismini hakediyor. Nitekim Microsoft yıllardır bu yapıya saldırıyor. Bir yandan Lotus Notes yazılımını kendi tabanına çekerek mesajlaşma özelliklerine saldırıyor, bir yandan da ona rakip olacak (Groove gibi) uygulamalar satın alıyor/geliştiriyor. Bu süreç, Microsoft'un 'satın alma' stratejisini pek sevmemesinden dolayı epey yavaş işliyor.

Peki Lotus Notes/Domino altyapımızı bir 'collaboration' sistemine çevirebilir miyiz? Parçalar halinde geliştirilmiş uygulamalar 'birlikte çalışma' fonksiyonlarını bir miktar karşılayacaktır. Parçalar halinde dememizin nedeni IBM Lotus yazılımlarının her dönem belirli 'collaboration' fonksiyonlarını içeren yapılar içermesidir. İş akışları (Lotus Workflow), farkındalık/anında mesajlaşma (Lotus Sametime), takım çalışması (Lotus Quickplace/Quickr), doküman yönetimi (Domino.Doc/Quickr) veya kurumsal portal (Websphere Portal) ürünleri birbiriyle entegre bir şekilde çalışmalarını sürdürüyor. Bu yapılar doğru ve entegre şekilde çalıştıklarında yukarıda saydığımız şartları gerçekleştiren total bir 'collaboration' yaklaşımı oluşturabiliyorlar.

Bir sonraki aşamaya geçtiğimiz zaman daha fazlasını bekliyoruz. Öncelikle ihtiyaç duyulan yapı daha 'ad-hoc' bir platform çözümü. Bilgi Sistemleri profesyonellerinin önderlik ettiği klasik yaklaşımların yetersiz kaldığı sıklıkla karşılaştığımız bir durum. Örneğin Lotus Workflow (IBM'in söylediklerine rağmen) bilgisiz bir kullanıcı tarafından yönetilemeyecek kadar kompleks bir yapı sunuyor aslında. Bu projeler fonksiyonel ya da sektörel ihtiyaçlar doğrultusunda şekillendiriliyor ve kullanıcılara sunuluyor. Benzer şekilde doküman yönetim uygulamalarında belirli bir otorite tarafından ortaya konulan bir 'meta-enformasyon' var. Legal dokümanlar, kalite dokümanları gibi tipler belirlenip her dokümana özel süreçler atanıyor.

E-Posta Bağımlılığı

Geri dönüp çalışan davranışlarını incelediğimizde çözdüğümüz sorunların yaşananların %20'sini geçmediğini farkediyoruz. Doküman ve bilgi paylaşımı çok katı sınırlarla belirlenemeyecek kadar açık yapıda olmalı. Oysa mevcut uygulamalar bu düzeyde basit ve anlaşılabilir olanaklar sunmuyor kullanıcılara. Bu yüzden kullanıcılar ellerindeki en esnek yapıya dönüyor ve  e-posta kullanımına yoğunlaşıyorlar. Hep yazıyorum: 10 yıllk mesaj kutumun büyüklüğü yalnızca 800 MB ve 100 MB'ı her biri 4-5 MB tutan fault report'lardan, yaklaşık 50 MB'ı da maalesef silemediğim müşteri tekliflerinden oluşuyor. Benim durumumda 'yer kaplamak' tek başına bir kaygı olabilir. Fakat işlerini sistematik, yapısal ve metodolojik olarak düzgün tabana oturtmaya çalışan şirketlerde iki temel sıkıntı oluşuyor.

Birincisi kişi işten ayrıldığında tüm yaptıklarının kronolojik kayıtlarını içeren bilgi ansiklopedisi (e-posta veritabanı) çöpe gidiyor. Bir çok müşterim bu verileri transfer ediyor yeni gelene. Fakat bu durum yalnızca satış ve müşteri temsilciliği gibi ne aradığı belli olan pozisyonlarda işe yarıyor. İkinci sorun da bilginin paylaşılamaması sorunu. Bırakın aynı bilgiye ihtiyaç duyan başka bir kişiyi, çalışanın kendisi bile bir süre sonra bu bataklığa attığı enformasyonu kaybediyor.

Dosya Sunucusu Yanılgısı

Dosya sunucularının e-postadan çok fazla farkı yok. IT departmanları bu yapıyı seviyorlar, çünkü yönetilebilir güvenlik ve güvenilirlik sunuyor. Kullanıcılar için de doküman paylaşımının en ilkel ve en esnek yöntemi. Fakat e-posta veritabanları kişi ayrıldıktan sonra silinip sistemimizden çıkıyor. Peki dosya sunucusundaki dosyalar? Bir proje yapıldı, 100 adet dosya üretildi. Alınan yedekler, anlık çalışmalar, analizler, hepsi burada kalmaya devam ediyor. Kimse bu dosyaları temizlemiyor çünkü kullanıcı algısı dosya sunucusunun 'sınırsız' olduğu yönünde.

Ayrı bir sorun da kategorizasyon. Maalesef eski paradigmanın getirdiği klasör yapısı bizi çok kısıtlıyor. Bir lisans teklifi vermek istediğimde şablon olarak kullanmak için bir dosya aramam gerekiyor. Ama benim klasör yapım müşterilere göre kategorize edilmiş durumda. Bu durumda aradığımı bulmak için onlarca klasöre girip çıkmak zorundayım. Kısayol kullanmamı önerenlere de 'siz kullandınız mı?' diye sormak istiyorum. Gerçekten çok zor!

Sektör Oryantasyonu Hastalığı

Peki yönetim bilgi sistemi (CRM, ERP vs.) dediğimiz yazılımlarla bu sorunlar çözülemiyor mu? Bir yere kadar belki... Ama bu uygulamaların tasarım ve uyarlama aşamalarında birincil önceliğin ne olduğu tartışma konusu. Bizim yerel alışkanlığımız temel hedef olarak 'raporlama' ya da 'finansal kontrol' fonksiyonlarını kullanmak yönünde şekillenmiş. Bir baz oluşturup oradan geriye doğru bir uygulama bütünü oluşturuyorsunuz. Örneğin yöneticiler size hangi raporları görmek istediklerini anlatıyor. Analist ise buna göre bir süreç ağacı ve meta enformasyon yapısı oluşturuyor. Uygulama geliştirmeci ise uyarlamayı yapıyor. Daha kötüsü bu zorlu süreç benzer sektörlerde tekrarlanmaya ihtiyaç duyulmadan kopyalanıyor ve bir anda bir takım varsayımlara göre tasarlanmış sektör odaklı yazılımlar türüyor.

Peki uygulamayı geliştirenler kullanıcıların çalışma yöntemlerini dikkate alıyorlar mı? Pek değil... Genelde süreç belirleniyor ve kullanıcı bu sürece uyması yönünde (ödül ve cezayla) ikna ediliyor. Bu arada kaçan pek çok şey oluyor tabi kaçınılmaz olarak. Müşteri bilgilerini kendisine saklamak isteyen satışçı, bazen faturalama aşamasına kadar bu bilgiyi sisteme girmeyebiliyor. Bazı durumlarda da işi ilgilendiren önemli bilgiler kayıt altına alınamadan uçup gidiyor.

Çözüm?

Görünürde çözmek çok zor değil mi? Zor gözükmesinin sebebi düşünce tarzımızdan kaynaklanıyor aslında. Biz bugüne kadar problemimizi ortaya koyup uzman bir takım adamların gelip çözüm üretmesine alışmışız. Oysa bu şekilde insanların çalışma sistemini belirleyemiyoruz. Sipariş ve faturalarını kağıtlar ve çekmeceli dosyalıklarla yarattığı dünyasında takip eden satın alma uzmanlarıyla karşılaşmıştık. Çıktı almasını engellediğimizde bile 'screen shot' alarak kendi yöntemlerine devam ediyordu. Bir analisti o masaya gönderip sistemini çözene ve kendi uygulamamızda bu yönde değişiklikler yapana kadar bu çalışan yöntemlerinde ısrar ediyordu. Özellikle bilgi çalışanları (knowledge worker) belirli kurallarla ve sabit yapılarla 'terbiye' edilemeyecek kadar farklı çalışma sistemlerine sahipler. Çünkü çalışma sistemlerinin önemli bir kısmı belirli 'iş modelleri' şablonu oluşturmuyorlar. Bir örnek verelim.

Bir ürün yöneticisini düşünelim. Yeni bir ürün çıkartacaktır. Finans departmanıyla çeşitli analizler yapar. Bütçe'den ve satış raporlarından bir takım veriler ister. Dışarıdan bir araştırma şirketi tutup pazar araştırması yaptırır. Bu verileri alır. Değişik senaryolar içeren bir sürü Excel dokümanı üretir. Bazı beyin fırtınası toplantılarına girer. Bunlardan çıkan sonuçları diğer arkadaşlarına mesaj olarak yollar... Örnekler fazlalaştırılabilir. Ama temel kaygımı anlatabildiğimi düşünüyorum. O kadar farklı formasyonda veri işleniyor ki bunları 'top-down', 'bottom-up', 'side-by-side', herhangi bir şekilde organize edemiyoruz. Ne yapacaktık, Yeni Ürün Tasarlama Uygulaması mı? Yapabileceğimiz tek şey satış otomasyonu uygulamamıza kampanya modülü eklemek ve satış raporlarıyla sonucu incelemek. Amaç da buydu zaten değil mi?

Peki, Çözüm?

Bu noktada bir platform öneriyoruz. Bu platformun özelliği kullanıcı ihtiyaçlarına göre epey esneyebilir olması. Belli şablonlarımız var. Örneğin bir takım takvimi kullanıyoruz. Ama kullanıcımız bu takvime eklenecek dokümanları isimlendirebiliyor. Örneğin pazar araştırmasıyla ilgili ikinci bir takvim ihtiyacı varsa onu da ekleyebiliyor. Doküman kütüphanemiz var. Kullanıcımız istediği kadar farklı kütüphane kullanabilirken her kütüphane için farklı kategorizasyonlar tanımlayabiliyor. Hatta belirli tipte 'bilgi'lerin kendi onayından geçmesi gerektiğini düşünebiliyor. Aktiviteler tanımlayabiliyor. Bu aktiviteler zaman sınırlı ya da süreç odaklı olabiliyor. Internette bulduğu web sitelerini kategorize ederek paylaşabiliyor. Tüm bilgi kalıpları için belli bir etiket listesi tanımlayabiliyor.

Herhangi bir kullanıcı bu platformu kullanırken bir miktar bocalayacaktır. Ama zaman içerisinde kendi çalışma koşullarını yaratacak, bir şablon oluşturacaktır. Yapabildikleri çok kısıtlanmamakla birlikte gene belirli kalıplar içerisinde kalacağı için ardından gelenler neye baktığını çok iyi anlayacaktır. İyi bir arama fonksiyonuyla benzer iş yapan diğer kullanıcılar da bu yapıdan faydalanabilecektir. Önemli olan anlamlı bir şablonu esnek kullandırabilmektir. Wiki her zaman wiki kalacak, bookmark her zaman bookmark olacaktır ama kullanıcı bunları istediği şekilde düzenleyebilecektir.

Tabi bu arada kullanıcılarımızın çalışma yöntemi kökten değişti. E-posta ile bilgi edinmeye alışık olan çalışanlar için yeni bilgi kaynakları ortaya çıktı. Takımın, takım üyelerinin, proje yöneticilerinin neler yaptığını anlık bilmek isteyebiliyor. Bunları görmek ve anında aksiyon alabilmek gerekiyor. Kendisiyle ilgisiz yürüyen süreçler ilgili hale gelebiliyor ve bu noktalarda haberdar olmak istiyor. Kısacası her gün baktığı ekranın değişmesi gerekiyor artık.

Bu yapılar şu anda kullanılıyor/geliştiriliyor. Önümüzdeki yazıda biraz da bunlardan bahsedeceğiz.