Bir önceki yazıda, “analiz” diye dilimize pelesenk ettğimiz kavram ve çalışmanın, aslında “iş analizi” ve “yazılım ihtiyaç analizi” diye bir ayırıma tabi tutulması gerektiğinden bahsedip, iş analizinin, bir yazılım sisteminden bağımsız olarak, işin sahibinin yani kurumun, işini süreç olarak sistematik bir şekilde bilmesi ve bunu formal olarak dokümanlarla ifade etmesidir demiştik. Var olan süreçlerin bu şekilde yakalanmasına “as is” analizi de denir. Sonrası iş süreçlerinin gittikçe daha verimli hale getirilmesi, yeniliklerin süreçlere dahil edilmesi gibi çalışmalardır. Verimli hale getirmekten kasıt da, iş sürecinde problemli olduğu düşünülen, hantallık yaratan vb. problem noktalarının bulunması ve bunların ya süreçten çıkarılması ya da iyileştirilmesi ve  sürecin gittikçe daha az kırtasiye üreten, yüksek performansta çalışan ve müşterilerini memnun eden hale getirilmesidir. İş süreçleri yönetimi (business process management) denen şey de temel olarak budur.

Dolayısıyla bir işin süreçlerinin sistemli olarak çözümlenmesine iş analizi (business analysis) denir. İş analizi, işin nasıl yapıldığına odaklanır ve

sistemli bir şekilde çözümler. Bu anlamda iş analizi, herhangi bir yazılım sisteminin varlığını zorunlu tutmaz, sadece işin yapılışına odaklanır

Eğer kurum, kendi süreçlerini bir yazılım sistemiyle daha etkin, hızlı vs. yapmak amacıyla otomatize etmek isterse, bu süreçler için bir yazılım alır, geliştirtir ya da kendisi geliştirir. Her halukarda, kurum, nasıl bir yazılım istediğini, süreçlerinin otomatize edilmesinden neyi kastettiğini detaylı olarak bir dokümanda belirlemelidir. Formal iş literatürüne RFP (request for proposal) olarak geçen bu doküman, yazılım ihtiyaçlarını son detaya kadar vermese bile ciddi bir seviyede yazılımdan beklenenleri, en azından özellik tabanında yakalamış olmalıdır.

Eğer bir kurum, kendi işini tanımlayamıyorsa, bu durumda ister satın alınsın ister geliştirilsin, işi otomatize edecek yazılım sisteminin, kullanıcılarının ihtiyaçlarına cevap verebilme şansı son derece düşük olacaktır. Bu yüzden genel olarak olan biten, böyle bir yazılım sistemi alınması ya da geliştirilmesi vesilesi ile bir miktar iş analizi yapılmasıdır. Tabiki bu çalışma, “iş analizi” niyetinden ziyade, bir yazılım sistemine yönelik olarak, o yazılım sisteminin ihtiyaçlarını anlamak niyetiyle yapılmaktadır. Bu durum çok tipiktir ve biz de bu durum üzerine, “hiç yoktan iyidir” diyerek sevinebiliriz.

Bazen de hakikatten bir iş süreci ya yoktur ya da çok ilkel ve kişiye bağımlı olarak vardır ve bir yazılım sistemiyle bu konunun otomatize edilmesi bekleniyordur. Dolayısıyla yukarıdakine benzer şekilde ama daha farklı bir durum olarak, sürecin kurgulanması da söz konusudur. Durum ne olursa olsun, yazılım projeleri çoğu zaman süreç kurgulamayı yani kuruma “bu işi artık böyle yapacaksın” demeyi de kendi içinde barındırıyor. Bu durumda risk, süreci kurgulayanların işe ne kadar hakim oldukları, kurumun stratejisini bilip bilmedikleri, biliyorlarsa bu stratejileri ne kadar sürece yansıttıkları gibi noktalara kayacaktır. Stratejiyi geçersek (önemsiz olduğundan değil ülkemizde böyle bir kavramın henüz çok da yerleşmemiş olmasından 🙁 ), süreci kurgulamanın ne kadar sağlıklı yapıldığından bahsetmek söz konusudur.

Doğru düzgün bir iş analizinin olmadığı ama buna rağmen bir yazılım sistemi geliştirmeye yönelik olarak yazılım ihtiyaç analizi yapmanın gerekli olduğu durumlarda, ilk ve en önemli olarak yapılacak şey, iş süreçlerini, akılda herhangi bir yazılım sistemi düşüncesi olmadan ele almak yani bulmak, detaylandırmak ve dokümante etmektir. “Akılda herhangi bir yazılım sistemi düşüncesi olmadan” sözünden de kasıt, ister veri tabanı ister kullanıcı arayüz detayları olsun, herhangi bir yazılım sisteminin varlığını düşünmeden, tamamen kullanıcı süreçlerine ve ihtiyaçlarına odaklı olarak, var olsun ya da henüz var olmayıp yeni kurgulanacak olsun, yazılım ile otomatize edilecek olan süreçlerin bilgisini yakalamaktır. Buradaki en riskli durum, iş analizi de bir yazılım sistemi geliştirme amacıyla yapıldığı için, geliştirilecek yazılımın detaylarına hızlıca girmek ve bundan dolayı var olan ya da tasarlanacak süreçleri yakalamada zorluk çekme riskidir. Bu da çok tipik bir durumdur. Odaklanılması gereken şey aslında, süreçlerin detaylarıdır, yani iş açısından “ne”yin olup bittiğidir. İşin akışı ve akıştaki adımlar, akışı yönlendiren iş kuralları, akışta üretilen, taşınan, işlenen ve saklanan veri, akışa müdahil olan roller, akışların birbirleriyle olan alış-verişi, öncelik-sonralık ilişkileri vb. noktalara odaklanıp, bunları doğru düzgün yakalamadan, yazılımın özellikle arayüzlerinin ve işlenen verinin tasarım ve gerçekleştirme detaylarına girmek çok sık rastlanan bir durumdur. Bu durum çok problemlidir çünkü aslolan işin nasıl olması gerektiğidir, kullanıcı arayüzü ve veri, ancak iş süreci tarafından belirlenebilir, tersinin olması, ya da belirlemenin tamamen arayüz ve veriden çıkılarak yapılması, süreçlerin sağlıklı yakalanamaması sonucunu doğuracaktır.  Böyle bir hedeften sapma aslında çok kolaydır, kolaycılıktır ve ortaya çıkacak yazılım sisteminin pek de fazla bir işe yaramayacağının da garantisidir.

Ben gidip ne ihtiyaçları olduğuna bir bakayım, siz de bu arada kodlamaya başlayın!

Şimdi isterseniz yazılım ihtiyaç analizine biraz daha yakından bakalım. Benim yazılımı ilk öğrendiğim ABD’de ve uzun süredir yaptığım ülkemde, yazılım süreçleriyle ilgili en fazla ıskalanan, en fazla zorlanılan, kafa karışıklığının en fazla olduğunu düşündüğüm alan yazılım ihtiyaç analizi ya da daha kısa ifadeyle ihtiyaç analizidir. Proje yöneticileri, programcılar, sistem yöneticileri gibi rollerde çalışanlar, ne yaptıklarını daha formal bir şekilde ifade edebilirlerken, benim tecrübeme göre ihtiyaç analistlerinin yaptıklarını formal yollarla tanımlayabilenlerine pek az rastladım. Bir başka yazımda da anlattığım ve cok sık yaşadığım tecrübemi burada da tekrarlayayım:

İş görüşmelerinden bir sahne bu. Ben, “Yazılım İhtiyaç Analisti” ilanına başvuran, muhtemelen Endüstri Mühendisi, 10 küsür yıl analistlik tecrübesi olduğunu söyleyen kişiye soruyorum, “nasıl iş analizi yapıyorsunuz?” diye. Cevap veriyor: “İşte, müşterimiz iç müşteri oluyor her zaman. Onlardan istek geliyor. Gidip görüşüyorum onlarla, sonra görüşmeden çıkardıklarımdan bir Word dokümanı oluşturuyorum. Ayrıca PowerPoint’de ekran tasarımı yapıyorum.” “Peki” diyorum içimden ve soruyorum kendi kendime: Burada “analiz” nerede? PowerPoint ile yapılan şeyin analiz olmadığı kesin çünkü zaten adında “tasarım” var. Geriye kalıyor “Word dokümanı”. Oradan birşeyler çıkarmaya çalışıyorum, çünkü adayın anlatımından “Word dokümanına yazılan şey, iş analizidir” ya da “cümleleri, analitik yapan şey, onların bir Word dokümanına yazılmış olmasıdır” (!) şeklinde birşey çıkıyor. Soruyorum,” o Word dokümanındaki temel kısımlar, başlıklar nelerdir?” Ya da “herhangi bir diyagram çiziyor musunuz” diye, ama nafile. Tek derdim, “iş analisti” olarak çalışan arkadaşımızın zihninde “iş” ve “analiz” ile ilgili bir kırıntı var mı onu anlamak. Belli ki iş analisti olarak çalışan herkes kendine göre bir “analitik” 🙂 süreç izliyor. Ve Word dokümanına yazılan şeyler bir şekilde “analiz” oluyor ama dokümanda herhangi bir yapısallık bile yok. Çünkü aday, dokümandaki başlıklardan bile bahsederken sıkıntı çekiyor. Halbuki merak edip, 10 senedir yaptığı iş ile ilgili kendini geliştirmeye çalışsa, Internet’te tonla kitap, makale, şablon vs. bulabilir.

Hadi bu çok uç bir örnek diyelim ama yine de bu konuda konuşan kişilerin kullandıkları kelimelere bakarak bile sahip oldukları kafa karışıklığını anlayabilirsiniz. En temel kafa karışıklığı, bu ve bir önceki yazıda açıkladığım ayırımı ıskalamaktan kaynaklanıyor. İş analistliği başka yazılım ihtiyaç analistliği başkadır.  Bir başka kafa karışıklığı analiz ile tasarım arasındaki fakla ilgili. Analiz, “ne” sorusuna cevap arar, “ne istiyoruz?”, tasarım ise “nasıl” sorusuna cevap arar, “nasıl olmasını istiyoruz?”. Bunlar o kadar ayrı iki sorudur ki, birbirlerine karıştırılmasının bedeli pahalı olur.

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