Özel Web Uygulaması mı, Hazır Platform mu?

Bu karar genellikle bir fiyat karşılaştırmasıyla başlar: bir tarafta aylık abonelik, diğer tarafta geliştirme teklifi.

İki sayıyı yan yana koymak kolaydır ve neredeyse her zaman yanıltıcıdır. Çünkü kıyaslanan şeyler aynı türden değildir: biri bugünün maliyeti, diğeri birkaç yıla yayılan bir sahiplik maliyetidir. Abonelik kalem kalem büyür, geliştirme ise büyük bölümünü başta ödetir.

Daha işe yarar soru maliyetten önce gelir: bu iş, sizin yapma biçiminize ne kadar bağlı?

Süreç uyumu, kararın merkezinde durur

Hazır bir platform, belirli bir çalışma biçimini varsayar. Bu bir kusur değildir; ürünün tamamı o varsayım üzerine kurulmuştur ve varsayım size uyduğunda platform son derece verimlidir.

Sorun, süreciniz o varsayımdan uzaklaştığında başlar. Uzaklık küçükse alışmak makuldür — çoğu şirket için kendi sürecini standarda yaklaştırmak, standardı kendine benzetmeye çalışmaktan ucuzdur.

Uzaklık büyükse iki kötü sonuçtan biri çıkar. Ya süreç araca uydurulur ve işin gerçekten değer üreten kısmı törpülenir; ya da araç zorlanır: her boşluk için bir eklenti, her istisna için bir alan, her raporlama ihtiyacı için bir dışa aktarım. İkinci yol genellikle "hazır çözüm" olarak başlar ve iki yıl içinde bakımı kimsenin üstlenmediği bir yamalar bütününe döner.

Buradaki ayırt edici soru şudur: bu süreç sizi rakiplerinizden ayıran şeyin parçası mı, yoksa herkesin benzer biçimde yaptığı bir işlem mi?

Muhasebe, e-posta, dosya paylaşımı ve çoğu İK süreci ikinci gruptadır. Bunlar için özel geliştirme neredeyse her zaman gereksizdir.

Hazır platformun gerçekten üstün olduğu yerler

Özel geliştirme yapan bir ekip olarak da söylemek gerekir: çoğu ihtiyaç için doğru cevap hazır bir üründür.

Hazır platform, ilk günden çalışır durumdadır. Kenar durumları sizin fark etmediğiniz kullanıcılar tarafından yıllar içinde bulunmuş ve düzeltilmiştir. Güvenlik güncellemeleri, yedekleme, uptime ve uyumluluk sizin sorumluluğunuzda değildir. Yeni bir ekip üyesi aracı zaten biliyor olabilir.

Bunlar küçük avantajlar değildir. Özel geliştirilen her sistem, bu işlerin tamamını sizin tarafınıza taşır.

Standart bir ihtiyacı özel geliştirmek, çoğunlukla sonu gelmeyen bir bakım yükümlülüğünü satın almak anlamına gelir.

Özel geliştirmeyi haklı çıkaran durumlar

Özel geliştirme, aşağıdakilerden biri veya birkaçı doğru olduğunda anlamlı hâle gelir.

İş akışı ürünün kendisidir. Müşterinize sunduğunuz şeyin farkı, o akışın nasıl işlediğinden geliyorsa, akışı bir başkasının varsayımına teslim etmek doğrudan rekabet gücünü teslim etmektir.

Sistemlerin arasındaki boşluk asıl iştir. Birkaç sistem arasında veri taşıyan, eşleştiren ve kural uygulayan işler hazır ürünlerin doğal olarak zayıf olduğu yerdir; çünkü o boşluk her şirkette farklı şekillenir.

Veri sahipliği bir gereklilik. Verinin nerede durduğu, nasıl dışa aktarıldığı ve ilişki bittiğinde ne olacağı sizin için belirleyiciyse, bunu baştan kendi tarafınızda tutmak sonradan çıkarmaya çalışmaktan kolaydır.

Ölçek eğrisi ters dönüyor. Kullanıcı başına fiyatlanan bir araç, ekip büyüdükçe pahalılaşır. Belirli bir eşikten sonra sabit maliyetli bir sistem daha ucuz hâle gelebilir. Bu eşiği tahmin etmek yerine hesaplamak gerekir.

Sık atlanan üç kalem

Karşılaştırma yapılırken hesaba katılmayan maliyetler genellikle aynı üç yerden gelir.

Entegrasyon

Hiçbir sistem tek başına durmaz. Hazır bir platformun API'si varsa iş görülebilir; yoksa veya sınırlıysa, entegrasyon manuel dışa aktarımlara ve elle düzenlenen tablolara dönüşür. Bu maliyet abonelik ücretinde görünmez ama her ay ödenir.

Bakım kapasitesi

Özel bir sistemin sorusu "yapılabilir mi" değil, "bir yıl sonra kim bakacak" sorusudur. Sistemi kuran ekiple bakımını üstlenecek ekip aynı değilse, devir planı projenin parçası olmalıdır. Bakım kapasitesi olmayan bir kurumda özel geliştirme, çalışan ama dokunulamayan bir yazılım üretir.

Bu sorunun cevabı üç biçimde olabilir ve üçü de meşrudur: iş kurum içinde üstlenilir, geliştiren tarafla süregelen bir bakım ilişkisi kurulur, ya da sistem bilinçli olarak başkasının devralabileceği kadar sade tutulur. Kabul edilemez olan, sorunun hiç sorulmamasıdır — çünkü o durumda cevap kendiliğinde üçüncü seçeneğin en kötü hâli olur: kimsenin tam anlamadığı, bu yüzden de kimsenin değiştirmeye cesaret edemediği bir sistem.

Hazır platformda bu yük satıcıdadır, ama bedelsiz değildir: ürünün yönü, fiyatlandırması ve devamlılığı sizin kararınız dışındadır.

Geçiş

Mevcut veriyi taşımak, insanları yeni araca alıştırmak ve bir süre iki sistemi birlikte yürütmek gerçek ve genellikle küçümsenen bir maliyettir. Geçiş planı olmayan bir seçim, teknik olarak doğru olsa bile operasyonda karşılığını bulamaz.

Kararı ucuz biçimde test etmek

Bu karar genellikle bir toplantıda, iki teklif ve birkaç varsayımla verilir. Oysa çoğu durumda test etmek, tartışmaya devam etmekten ucuzdur.

Hazır bir platform için en gerçekçi deneme, demo verisiyle değil kendi verinizle yapılanıdır. Bir aylık bir kullanım, gerçek bir sürecin baştan sona bir kez yürütülmesi ve en sık karşılaşılan üç istisnanın denenmesi, sunumda görünmeyen sınırların çoğunu ortaya çıkarır. Denemenin sonunda sorulacak soru "beğendik mi" değil, "sürecimizin neresi buraya sığmadı" olmalıdır.

Özel geliştirme tarafında karşılığı, tek bir akışla sınırlı küçük bir pilottur. Amaç ürünün ilk sürümünü çıkarmak değil, tahminlerin doğru olup olmadığını görmektir: entegrasyon gerçekten mümkün mü, veri beklenen biçimde geliyor mu, kullanıcılar yeni akışı benimsiyor mu.

Her iki durumda da asıl kazanç, kararın geri alınabilir kalmasıdır. Altı haftalık bir pilot yanlış çıktığında kaybedilen altı haftadır; iki yıllık bir taahhüt yanlış çıktığında kaybedilen çok daha fazlasıdır.

Melez yaklaşım çoğu zaman en gerçekçi olan

Karar ikili sunulur ama gerçek sistemler nadiren saf haldedir.

Yaygın ve sağlıklı bir düzen şudur: standart olan her şey hazır ürünlerle çalışır — muhasebe, e-posta, dosya, destek. Şirkete özgü olan tek akış ise özel geliştirilir ve gerisiyle entegre edilir.

Bu, özel geliştirmenin kapsamını küçültür. Küçük kapsam daha erken yayına çıkar, daha az bakım gerektirir ve yanlış çıktığında daha ucuz geri alınır.

Müşteriye bakan yüzeyle iç operasyonu ayırmak da işe yarar. Bir kurumsal site veya ürün arayüzü şirketin kendi tasarım diline ihtiyaç duyar; arka plandaki muhasebe duymaz.

Bu ayrım aynı zamanda bütçeyi doğru yere taşır. Kullanıcının gördüğü ve kararını etkileyen yüzeye harcanan emek geri döner; kimsenin görmediği standart bir işlemi yeniden üretmeye harcanan emek genellikle dönmez.

Sonuç

Bu tartışmanın sağlıklı hâli "hangisi daha iyi" değil, "hangi kısım hangisine ait" biçimindedir.

Şirketlerin çoğu her iki yanlıştan birine düşer: ya standart bir ihtiyaç için özel yazılım yaptırıp gereksiz bir bakım yükü satın alır, ya da kendine özgü bir akışı hazır bir aracın içine sıkıştırıp işin değerli kısmını törpüler.

Karardan önce süreci bir kez yazılı olarak tarif etmek, bu iki hatanın çoğunu baştan eler — çünkü kâğıda döküldüğünde hangi adımların gerçekten size ait olduğu genellikle beklenenden azdır. Bu netleştikten sonra özel web uygulaması geliştirme tarafında konuşulacak kapsam da belirgin biçimde küçülür.

Sistemin görünen yüzü için karar verirken, yenileme kararının ne zaman haklı olduğu sorusu da aynı çerçeveden ilerler.