Bir yazılım projesinin maliyetini ve süresini en çok etkileyen kararlardan biri, hangi özelliklerin geliştirileceğidir. Her ihtiyacı ilk sürüme dahil etmek projeyi gereksiz yere büyütebilir. Kapsamı fazla dar tutmak ise birkaç ay sonra yeni geliştirmeleri zorunlu hale getirebilir.
Bu nedenle ilk soru “Hazır yazılım mı, özel yazılım mı?” olmamalı. Önce işletmenin gerçekte neyi çözmeye çalıştığı netleşmeli.
Hazır bir sistem mevcut ihtiyacın büyük bölümünü karşılıyorsa sıfırdan yazılım geliştirmek çoğu zaman iyi bir yatırım değildir. İş süreçleri standart ürünlerin sınırlarına sürekli takılıyor, yoğun manuel işlem gerektiriyor veya farklı sistemler arasında özel bir veri akışı kurulması gerekiyorsa özel geliştirme daha anlamlı hale gelir.
Önce yazılımı değil, iş sürecini tanımlayın
“Bir CRM'e ihtiyacımız var” proje kapsamı değildir. Hangi müşterilerin takip edileceği, satış sürecinin hangi aşamalardan geçtiği, kimlerin hangi verilere erişeceği, hangi işlemlerin otomatikleşeceği ve hangi raporların gerektiği bilinmeden sağlıklı kapsam çıkarılamaz.
Aynı durum ERP entegrasyonu, bayi yönetimi, rezervasyon sistemi, stok takibi veya şirket içi yönetim panelleri için de geçerlidir.
Kapsam belirlenirken mevcut süreç mümkün olduğunca somut şekilde çıkarılmalıdır:
-
Hangi işlem bugün nasıl yapılıyor?
-
Kim yapıyor?
-
Hangi bilgiler giriliyor veya başka bir sistemden geliyor?
-
Nerede zaman kaybediliyor?
-
Hangi hatalar tekrar ediyor?
-
Hangi işlemler mutlaka yazılıma taşınmalı?
-
Hangileri mevcut yöntemle devam edebilir?
Buradaki amaç şirkette yapılan her işi dijitalleştirmek değildir. Yazılımın gerçekten değer üreteceği alanları bulmaktır.
Hazır yazılım ne zaman daha doğru seçimdir?
Hazır ürünlerin temel gücü, daha önce çözülmüş bir problemi yeniden geliştirmeye ihtiyaç bırakmamalarıdır.
Standart bir e-ticaret operasyonu, temel müşteri takibi, proje yönetimi, insan kaynakları veya ön muhasebe ihtiyacı için piyasadaki bir ürün şirketin çalışma biçimine yeterince uyuyorsa hazır çözüm daha hızlı devreye alınabilir.
Başlangıç maliyeti de genellikle daha öngörülebilirdir. Lisans veya abonelik bedeli, kurulum giderleri ve varsa ek modüller üzerinden karar verilebilir.
Sorun, işletmenin süreçleri ürünün izin verdiği sınırların dışına çıktığında başlar. Şirket bir süre sonra işini yazılıma uydurmaya çalışıyorsa, kritik işlemler Excel dosyaları ve manuel kontrollerle tamamlanıyorsa veya farklı sistemler arasında sürekli veri taşınıyorsa görünürde ekonomik olan ürün pahalı bir operasyona dönüşebilir.
Hazır çözüm seçerken yalnızca aylık lisans ücretine bakmak bu yüzden yanıltıcıdır.
Özel yazılım hangi durumda anlam kazanır?
Özel yazılım, şirketin çalışma biçiminin çözümün merkezinde olması gerektiğinde avantaj sağlar.
Örneğin bir işletmenin teklif, sipariş, üretim, sevkiyat ve faturalama arasında kendine özgü bir akışı varsa hazır bir uygulamanın her aşamayı doğal biçimde karşılaması beklenemez. Benzer şekilde bayi fiyatlandırması, müşteriye özel yetkilendirme, ERP bağlantısı veya kurum içinde kullanılan farklı sistemlerden veri toplama gibi gereksinimler standart ürünlerin sınırlarını aşabilir.
Özel geliştirmede ekranlar, kullanıcı rolleri, kurallar, raporlar ve entegrasyonlar bu işleyişe göre tasarlanabilir.
Bu özgürlük aynı zamanda kapsam disiplinini daha kritik hale getirir. Çünkü teknik olarak yapılabilecek her şeyin yapılması gerekmez.
Bir projeye “ileride lazım olabilir” düşüncesiyle özellik eklemek geliştirme süresini artırır, test alanını büyütür ve bakım yükü oluşturur. Kullanılmayan özellik de ücretsiz değildir. Kodun içinde yaşamaya devam eder.
İlk sürümün sınırı nerede çizilmeli?
Sağlıklı bir ilk sürüm, işletmenin belirli bir sürecini baştan sona çalıştırabilmelidir.
Örneğin hedef bir bayi sipariş sistemi kurmaksa ilk sürümün temel kapsamı bayi girişi, ürün görüntüleme, yetkiye veya müşteriye göre fiyatlandırma, sipariş oluşturma ve sipariş durumunu takip etme olabilir.
Aynı sisteme kampanya motoru, gelişmiş satış analitiği, mobil uygulama, otomatik teklif oluşturma ve çok katmanlı sadakat sistemi de eklenebilir. Bunların mümkün olması ilk sürümde bulunmaları gerektiği anlamına gelmez.
Her özellik için basit bir ayrım yapılabilir:
Olmadan süreç çalışmıyorsa: İlk kapsama alınır.
İşi belirgin biçimde kolaylaştırıyor ancak süreç onsuz da yürüyorsa: Önceliğine göre ilk veya sonraki sürüme bırakılır.
Muhtemel bir gelecek ihtiyacına dayanıyorsa: Gereksinim somutlaşana kadar bekletilir.
Bu yaklaşım yalnızca bütçeyi kontrol etmez. Yazılımın gerçek kullanıcılarla daha erken karşılaşmasını da sağlar. Kullanım başladıktan sonra hangi geliştirmelerin gerçekten değerli olduğu çok daha net görülür.
Esneklik sınırsız özellik demek değildir
Özel yazılımın sık kullanılan gerekçelerinden biri esnekliktir. Buradaki esnekliği, sisteme her talebin hızla eklenebilmesi şeklinde anlamak doğru değildir.
Asıl değer, yazılımın yeni ihtiyaçlar çıktığında tamamen yeniden kurulmasını gerektirmeyen bir yapıya sahip olmasıdır.
Örneğin bugün tek depo kullanan bir işletmenin yakın gelecekte birden fazla depoya geçeceği biliniyorsa veri yapısının buna göre tasarlanması mantıklıdır. Fakat “bir gün yurt dışında faaliyet gösterebiliriz” ihtimaline dayanarak ilk sürümde çoklu ülke, çoklu dil, çoklu para birimi ve farklı vergi sistemlerini geliştirmek projenin gereksiz büyümesine yol açabilir.
Ölçeklenebilirlik, gelecekte ortaya çıkabilecek bütün senaryoları bugünden kodlamak değildir. Değişimi engellemeyen bir temel kurmaktır.
Piasoft da web yazılım projelerini işletmenin iş süreçleri ve operasyonel ihtiyaçları üzerinden planlıyor; yönetim panelleri, süreç otomasyonları, veri yönetimi ve ERP veya CRM gibi kurumsal sistemlerle entegrasyonları proje ihtiyacına göre ele alıyor.
Maliyeti yalnızca geliştirme fiyatıyla karşılaştırmayın
Hazır ve özel çözüm arasında karar verirken başlangıç fiyatını karşılaştırmak kolaydır. Fakat doğru karşılaştırma toplam sahip olma maliyetidir.
Hazır bir yazılımda maliyet kalemleri arasında abonelikler, kullanıcı başına lisans ücretleri, ek modüller, entegrasyonlar, danışmanlık veya ürüne uyum sağlamak için sürdürülen manuel operasyonlar bulunabilir.
Özel yazılımda ise analiz, tasarım, geliştirme ve test için daha yüksek bir başlangıç yatırımı gerekebilir. Sonraki dönemde sunucu, bakım, güvenlik, geliştirme ve teknik destek giderleri oluşur.
Beş kişinin kullandığı basit bir süreç ile yüzlerce kullanıcıya, farklı sistemlerle entegrasyona ve şirkete özgü iş kurallarına sahip bir operasyon aynı yöntemle değerlendirilmemelidir.
Karar verirken şu soruya bakmak daha yararlıdır:
Bu çözümü birkaç yıl boyunca kullanmanın şirkete gerçek maliyeti nedir?
Bu hesabın içine çalışanların yaptığı manuel işlemler de girmelidir. İki sistem arasında her gün veri kopyalayan bir ekip varsa bunun da bir maliyeti vardır, yalnızca yazılım faturasında görünmez.
Süre tahmini kapsam netliğiyle doğrudan ilişkilidir
“Bu yazılım kaç haftada biter?” sorusuna kapsam belirlenmeden güvenilir cevap vermek mümkün değildir.
Kullanıcı tipleri, iş kuralları, ekranlar, entegrasyonlar, veri aktarımı ve yetkilendirme gibi temel gereksinimler netleştikçe geliştirme süresi de daha doğru tahmin edilebilir.
Belirsiz kapsamın başka bir etkisi daha vardır: Proje ilerlerken verilen küçük kararlar birikerek sistemi değiştirebilir.
Başlangıçta tek bir kullanıcı tipi planlanırken daha sonra bayi, müşteri, satış temsilcisi ve yönetici için farklı yetkiler istenmesi yalnızca dört farklı giriş ekranı anlamına gelmez. Veri erişimi, iş akışı, test senaryoları ve güvenlik kuralları da değişir.
Kapsam dokümanının işlevi her ayrıntıyı sözleşmeye kilitlemek değil, tarafların ne geliştirdiğini aynı şekilde anlamasını sağlamaktır.
Entegrasyonları kapsamın dışında bırakmayın
Özel yazılım projelerinde en fazla gözden kaçan alanlardan biri entegrasyonlardır.
Yeni sistemin ERP'den stok çekmesi, CRM'e müşteri göndermesi, ödeme kuruluşuyla çalışması, kargo firmasına veri aktarması veya başka bir uygulamadan geçmiş kayıtları alması gerekebilir.
“ERP entegrasyonu yapılacak” ifadesi tek başına yeterli değildir.
Hangi verilerin hangi yönde aktarılacağı, aktarımın ne zaman gerçekleşeceği, hata durumunda ne olacağı, kullanılan sistemin gerekli entegrasyon imkânını sağlayıp sağlamadığı ve verilerin nasıl eşleştirileceği belirlenmelidir.
Arayüzde birkaç satır gibi görünen bir özellik, arka tarafta projenin ciddi bölümlerinden birine dönüşebilir. İnsanlık “şuraya bir entegrasyon ekleriz” cümlesini epey masumlaştırmış durumda.
Bakım da teknoloji kararının parçasıdır
Yazılımın yayına alınması projenin teknik ihtiyaçlarını ortadan kaldırmaz.
İşletim sistemi ve sunucu bileşenleri güncellenir, üçüncü taraf servislerin API'leri değişebilir, güvenlik ihtiyaçları ortaya çıkar, tarayıcılar ve cihazlar değişir. İşletmenin kendi süreçleri de aynı kalmaz.
Bu nedenle özel yazılım değerlendirilirken geliştirme kadar yayın sonrası sorumluluk da konuşulmalıdır:
Bakımı kim yapacak? Hatalara nasıl müdahale edilecek? Güncellemeler nasıl yönetilecek? Yedekleme ve güvenlik kontrollerinden kim sorumlu olacak? Yeni özellik talepleri nasıl planlanacak?
Piasoft, yayın sonrası süreçler için ayrı bir [Bakım & Destek hizmeti] Bakım & Destek hizmeti sunuyor ve web siteleriyle özel yazılım sistemlerinde güncelleme, güvenlik, performans ve teknik destek süreçlerini bu kapsamda ele alıyor.
Hazır ürün mü, özel geliştirme mi?
Kararı tek bir kurala indirmek pek mümkün değil.
İhtiyaç standartsa, mevcut ürünlerden biri süreci ciddi taviz vermeden karşılıyorsa ve özelleştirme ihtiyacı sınırlıysa hazır çözüm daha mantıklı olabilir.
İşletmenin rekabet avantajı kendi çalışma yönteminden geliyorsa, süreçler standart yazılımlara uymuyorsa, yoğun entegrasyon gerekiyorsa veya sistemin şirket büyüdükçe özel biçimde gelişmesi bekleniyorsa özel yazılım daha uygun hale gelir.
Bazı projelerde iki yaklaşımı birlikte kullanmak da en iyi çözümdür. Örneğin mevcut bir ERP korunurken müşterilerin veya bayilerin kullandığı özel bir web uygulaması geliştirilebilir. Yeni yazılım ERP'nin yerine geçmek yerine onunla veri alışverişi yapar. Böylece yıllardır çalışan bir sistemi gereksiz yere yeniden üretmeden ihtiyaç duyulan esneklik sağlanabilir.
Doğru kapsam da tam olarak burada ortaya çıkar: Neyi yeniden geliştirmeye gerek olmadığını bilmek, neyin hazır çözümlerle karşılanabileceğini görmek ve yalnızca işletmeye özgü değerin bulunduğu alanlara yatırım yapmak.
Piasoft'ta proje süreci ihtiyaç analiziyle başlayarak işletmenin hedefleri, mevcut altyapısı ve kullanıcı gereksinimleri üzerinden planlanıyor. Kapsam, teknik yapı ve takvim bu analizden sonra netleştiriliyor. Hazır bir sistem yeterliyse özel yazılımı sırf “özel” olduğu için seçmek gerekmez. İşletmeye özgü bir yapı gerekiyorsa da genel amaçlı bir ürünü yıllarca zorlamak çoğu zaman gerçek tasarruf sağlamaz.
Teknoloji seçiminden önce ihtiyacın doğru tarif edilmesi bu yüzden projenin en değerli adımıdır.