Giriş

Soru şu: Analist yani bazen iş analisti, bazen ihtiyaç ya da gereksinim analisti bazen de daha klasik bir isimlendirmeyle sistem analisti dediğimiz rol için iş bilgisi ne kadar önemlidir? “Hoppaaa! Böyle de soru mu olur?” demeyin. Ben de farkındayım, iş bilgisinin, analistin varlık sebebi olduğunun. Analistin en temel sorumluluğudur iş bilgisi, tamam da demek istediğim şeyi açıpa çıkarabilmek için şu soruyu da sorayım: Analistin, benzer şekilde iş bilgisine sahip operasyonel bir kullanıcıdan farkı yok mudur? Vardır deriz ama nedir tam olarak bu fark? Daha analitik olması, daha iyi sorular sorabilmesi, ya da iletişiminin daha güçlü olması mıdır sadece?

Analist Yetkinlikleri

Konuyu biraz açayım. Analistin yetkinlikleri 3 boyutta ele alınabilir:

1. İş alanı bilgi ve yetkinlikleri (business/application domain knowledge and skills): Analistin çalıştığı sektördeki terimlere, süreçlere, rollere ve çıktılara ne kadar hakim olduğu, onun iş bilgisinin ölçüsüdür. Örneğin bankacılık sektöründeki bir analistin çalıştığı alt alanın krediler olduğunu düşünelim. Bu analist, kredilerle ilgili başvuru ve değerlendirme süreçlerini bilmesi, bunlarla alakalı analiz toplantılarında bulunması vb. yetkinlikler, analistin iş alanı ile ilgili yetkinliklerine örnektir.
2. İş ve yazılım ihtiyaç analizi bilgi ve yetkinlikleri (business and software requirements analysis knowledge and skills): Analistin, formal olarak bir süreci tanımlayabilme, oradaki adımları, iş kurallarını ve aktörleri detaylarıyla belirleyebilme, detaylar arasındaki benzerlik, farklılık, çelişiklik vb. çıkarımları yapabilme, bu bilgileri bir yazılıma dönüştürebilecek şekilde daha formal ve matematiksel formlara örneğin diyagramlara dökebilme, ihtiyaçlarla alakalı önceliklendirme ve risk analizi yapabilme ve tüm bunları dokümana yansıtma yetkinlikleri.
3. Bireysel yetkinlikler (individual skills): İletişim, ikna, sorgulama, toplantı yönetimi vb. daha yumuşak yetkinlikler (soft skills). Örneğin bir analistin iyi bir dinleyici olması, iyi not alabilmesi, hızlı ve analitik düşünüp çıkarımlarda bulunarak bir analiz toplantısında geri sorularla muhatabını yönlendirebilmesi, çatışan ihtiyaçlara sahip kullanıcılar arasında inisiyatif alabilmesi, onları yönlendirmesi ve karar verilmesini sağlayacak girdileri sunabilmesi vs. bu türden yetkinliklerdendir.

Yukarıdaki 3 farklı yetkinlik alanından hangisi sizce en önemli olandır? İş bilgisi mi, işi çözümleyebilme yetkinlikleri mi yoksa müşteriyle daha iyi iletişim kurabilme yetkinlikleri mi?

Ülkemizde eğitim ve danışmanlık vesilesiyle gittiğim yerlerde bunu devamlı gözlemliyorum. Hatta ben de, tam zamanlı çalışırken ya da sonrasında danışmanlıklarda, uzun seneler analist işe alımıyla uğraştım ve uğraşıyorum. Dolayısıyla analist işe alma ve seçme süreçlerinden haberdarım. Özellikle eğitimlerde ve seminerlerde katılımcılara soruyorum, sizin kurumunuzda hangisi daha çok öne çıkıyor diye. Örneğin, “siz buraya hangi yetkinliklerinizle alındığınızı düşünüyorsunuz?” diye soruyorum. Elde ettiğim kanı şu: Ülkemizde analist denince akla gelen en temel şey, iş bilgisidir. Tabiri caizse, işi bilmek, o sektörde senelerdir bulunmuş olmak, genel olarak bir kişiyi analist olarak tanımlamada kullanılan en temel etmendir. İkinci sırada gelen, bireysel yetkinliklerdir. Yani iletişimi güçlü mü, müşterilerle konuşurken ne kadar düzgün cümleler kurabiliyor vs. Bu iki yetkinliği bir araya getirdiğimizde, işi bilen ve iletişimi güçlü kişi, ülkemizde mükemmel analist adayıdır. Kurumlar kendi kültürlerine göre bu iki faktörden birisine daha fazla önem verebilirler. Yani örneğin bir kurum, özellikle daha az tecrübe seviyelerinde, iletişim becerileri güçlü bir adayın zekasına da güvenerek, iş bilgisini hızlıca elde edebileceğini düşünerek onu analist olarak işe alabilir.

Bu yazıyı yazdığıma göre benim de kendi fikrimi belirtmem gerekir. Bence bir analistin en temel yetkinliği, rolüne adını veren, iş ve yazılım ihtiyaçları analizi bilgi ve yetkinlikleridir. Bir analist, her şeyden önce, bir süreci nasıl ifade edeceğini, o süreçteki tüm adımları, aktiviteleri, aralarındaki ilişkileri, çıktıları, süreçte yer alan rolleri ya da aktörleri, süreçler arasındaki ilişkileri, süreçleri yönlendiren iş kurallarını vs. ortaya koymakla sorumludur. Bu yetkinlikler, tabi olarak farklı sektörlerde edinilen tecrübeyle kazanılır ama nihayetinde sektörden bağımsızdır. Bir örnek vereyim: Bir süreçte, durumu önemli olan ve farklı durumlar arasında gezen temel bir nesne var. Örneğin bir başvuru sürecinde, başvurunun pek çok duruma sahip olması, buna iyi bir örnektir. Başvuru ilk defa alınmış olabilir, ön elemeyi geçmiş, evrakları bekleniyor, son incelemede, vb. durumların birinde olabilir. Tüm bu durumların, sonlu durumlu bir makina (finite-state machine) olarak ortaya konması, yani durumlar ve aralarındaki geçişlerin detaylı olarak ortaya belirlenmesi yetkinliği, ne bir iş bilgisi ne de iletişim yetkinliğidir. Bu yetkinlik, analisti en temelde analist yapan şeydir. Böyle bir modelleme yetkinliğine sahip bir analist, herhangi bir iş alanında sonlu durum makina modellemesi yapabilir, oluşturduğu modelin tasarımda bir durum tasarım kalıbıyla (state design pattern) tasarlanmasını sağlayabilir ve nihayetinde de developerlar dahil herkes kendisine duacı olur. Çünkü böyle çok durumlu nesneler, kodlamada en problemli nesnelerdir, sebebi ise iş bilgisi çok yüksek olsa bile analistin bu durumları formal bir şekile çözümleyip ifade etmemiş ya da edememiş olması, açıkçası, ne tasarıma ne de programlamaya bir katkı sunmaz.

Nasıl her iş alanı, apayrı süreçleri ve iş kuralları olan bir alan (domain) ise, iş ve yazılım ihtiyaçları mühendisliği (business and software requirements engineering) de apayrı bir iş ve uzmanlık alanıdır. Bu alanın da kendine göre süreçleri, iş kuralları, çalışmaları ve çıktıları vardır. Bu alanın çalışanlarının da kendisine has yetkinlikleri, yaptıkları işleri ve ürettikleri çıktıları vardır.

İş bilgisini çözümleme yetkinliklerine sahip olmayan bir analist ancak postacı olur. Ya da analistlerin kafasına kazındığı şekliyle sadece “köprü” olmaya devam eder, tek yaptığı “al-ver”dir, ne çözümleyici olmak söz konusudur ne de bir katma değer ortaya koymak. Böyle ortamlarda zaten iş bilgisi de malumattan öteye gitmez, bilgi seviyesine çıkamaz çünkü. O ortamda senelerce çalışsanız bile hala aklınızdaki iş bilgisini bir başkasına aktarabilir hale getirmekte güçlük çekersiniz. Aktarsanız bile karşı tarafı zorlarsınız çünkü standart ve verimli yöntemleri kullanmazsınız. Çözümleme süreç ve tekniklerinden haberdar olmayan bir analist iğne oyası gibi malumatla uğraşır, onlar arasında kaybolur. Analistten beklenen, bir soru karşısında “hikmet” (wisdom) seviyesinde katkıda bulunmasıdır ama o ekranın şurasındaki bir arayüz elemanın üzerinden konuşur. Ondan beklenen, iki farklı durumu birbiriyle kıyaslayıp, etki analizi vs. yapmaktır ama o bunu sağlıklı bir şekilde yapamaz çünkü kafasında sistemli ilişkiler değil, malumat bulutları vardır. Ama unutmayın, buradaki temel sorun analistten ziyade, kurumdadır. Analiz çalışmalarında “analitik” olmayan bir kurum, analistinin çözümleme süreç ve tekniklerinden haberdar olmasını da isteyemez çünkü bu konuda fikri yoktur.

İş bilgisi, tabi olarak bir analist için önemlidir, sistemli bilgiyi hazmetmek çok daha kolaydır. İş bilgisine sahip bir analist daha hızlı iş yapar, daha rahat ve doğru davranır. Müşterisiyle daha rahat iletişime geçer ve ona güven verir. Ama iş bilgisi, bilgi olursa işe yarar, değilse, bir malumat yığınından ibaretse, vakit kaybettiren bir stres unsuru olur. Ve analistin yeterince teknik çalışmaması, bu malumatı sadece büyütür, bilgiye çevirmez.

İşte, bir analisti, operasyonel kullanıcıdan temelde farklı kılan şey, formal bir çözümlemeci disipline sahip olmasıdır. Analitik düşünebilen, işini gözlemleyen, baştan sonra kavramaya çalışan operasyonel çalışanların analist olmaları iyi bir şeydir, çözümleme ve modelleme tekniklerini öğrenmeleri kaydıyla.

Ülkemizdeki Durum

Ülkemizde sistemli iş bilgisi biriktiren kurumlar maalesef pek azlar. İşini en detayına kadar anlatabilecek bırakın operasyonel kullanıcıyı, iş birimi sorumlusu, müdürü bulmak bile şanstır bu ülkede. Amerika’dan ilk döndüğüm zamanlardı, ilk projelerimin birinde, sürecin sahibi olan birim müdürüyle analiz amaçlı bir araya gelmiştik. Müdür, daha toplantının başında, süreçlerle ilgili olarak analizi BT’deki programcılarla yapmamızı istemişti bizden! Zaten toplantıda bir de tecrübeli programcı vardı. Aynı kurum agile ödülleri almaya devam ediyor, şatafatlı uluslararası danışmanlık şirketleriyle 3-5 senede bir süreç çalışması yapıyor vs. Ama gidin sorun bakalım, müşteri memnuniyeti artıyor mu? Ya da bugların sayısında azalma olmuş mu? Ya da ya da developerlar, kendilerine gelen analiz dokümanlarından memnunlar mı? Örneğin şöyle tipik durumlar olur ülkemizde: Kurumlar agile metodolojilere geçtiklerini söylerler ama hala hantaldırlar, hala çıktılarının kalitesi kötüdür, hala başarı kişilerin özveriyle çalışmalarına bağlıdır, hala her yeni sürümü canlıya almak çok stresli bir iş olmaya devam eder. Neden? Formal çözümleme teknikleri gibi mühendislik disiplinin gerektirdiği işler yerine “dostlar ‘agile’da görsün” şeklinde, görüntü üzerinden iyileştirmelerle yetindiğimiz için.

Ülkemizde bu durumlardan dolayı mesela “iş analizi danışmanlığı” pek görülen bir durum değildir. Halbuki ABD’de böyle çalışan, 6 ay petrol çıkaran bir organizasyonda çalışıp, süreçlerini analiz eden, sonra bir sigorta şirketinde ürün biriminde analiz danışmanlığı yapan, sonra başka bir yerde örneğin ticari olmayan (non-profit) bir kurumda yine analiz sürecinde çalışan profesyoneller var. Çünkü, PM gibi, programcı gibi, analist olmanın en temel yetkinliklerini kendinde barındırıyor ve her ortamda bunları kullanıyor.

Ve Bir Referans

Bu noktada size, iş ve ihtiyac analizi konusunda çok iyi bir otorite olan Karl Wiegers’ın Software Requirements isimli kitabını tavsiye ederim. Kitabın 3. bölümü “Business Analyst” başlığını taşımaktadır ve bir analistin yetkinliklerini ve sorumluluklarını, kimlerle nasıl iletişimde bulunacağını, hangi geçmişe sahip kişilerin nasıl bir geçiş süreciyle analist olabileceklerini ayrıntılı olarak anlatır. Ayrıca bu kitapla beraber gelen malzemeler arsında, Türkçesini bu yazıda paylaştığım iş analisti görev tanımını da var. O tanımda, bir iş analistinin sahip olması gereken bilgiler anlatılırken, “Gerekli Bilgiler” başlığı altındaki son madde şöyledir:

“Kullanıcı temsilcileri nezdinde güvenilirlik sağlaması ve onlarla etkin çalışabilmek için, zorunlu olmamakla birlikte, uygulama alanı bilgisi bir artıdır.”

Ya da orijinal haliyle:

“Application domain knowledge is a plus, to have credibility with user representatives and be able to work effectively with them.”

Bu yazıyı okuyup da bu cümleye katılmayacak pek çok kişi olacaktır. Ama ben şunu her zaman iddia ediyorum: İş süreçlerini çözümleme formal yetkinliklerine sahip, iletişim yetenekleri iyi bir analist, herhangi bir iş alanını en çok bir senede çok iyi bir şekilde öğrenebilir, o alandaki iş sorunlarını çözebilir, çok etkin analiz toplantıları yapabilir. Yeter ki çalıştığı ortamda iş bilgisi, bölük pörçük, insanların kafalarındaki malumatlardan ibaret olmasın, derli toplu, soyuttan somuta gider şekilde, farklı formal modellerle ifade edilmiş olsun. Ama gelin görün ki, senelerdir aynı iş alanında, hatta aynı kurumda çalışan analistlerin sıklıkla bana, iş alanlarıyla ilgili olarak kaotik bir ortamda olmaktan kaynaklanan rahatsızlıklarını ilettiklerini bilirim. Dahası, böyle bir analist, fırsat verilse, sistemli çalışmasıyla, malumat yığını da olsa bu yığını, çözümleyerek, formal iş bilgisine dönüştürebilir. İş süreçleri mühendisliği (business process engineering) adı verilen böyle bir çalışma, bir kurumun en değerli olan iş bilgisini, rahatça anlaşılacak ve tekrar tekrar kullanılacak bir formata döker. Ve bu bilgi, o kurumun en değerli varlığı olur.

Son bir soruyla yazımı bitireyim: Düşme tehlikesi olan bir uçağın pilotu olarak, uçağı kurtarmak için içeride bulunan sadece 2 kişiden, bir analist ve bir developerdan hangisini aşağıya atarsınız? Bu yazıdan sonra tabi ki “developer” diye cevap vereceksiniz muhtemelen. Ben ise daha ağır olanı atmayı tercih ederdim 🙂

Toplam görüntülenme sayısı: 1680