"Kurumsal yazılıma geçelim" cümlesi, aynı toplantıdaki üç kişi için üç ayrı şey anlatabiliyor. Mali işlerden sorumlu kişi ERP'yi kastediyor, satış müdürü CRM'i, operasyon ise kendi ekibinin sipariş takibini yapabileceği bir panel istiyor. Üçü de haklı, ama üçü farklı ürün kategorisi, farklı bütçe ve farklı proje süresi demek.
Bu yazı, karar vermeden önce manzarayı görmek için yazıldı. Kurumsal yazılımın kategorilerini, bunların hangi ihtiyaca cevap verdiğini, hazır ürün ile özel geliştirmenin toplam sahip olma maliyetinde nerede ayrıldığını ve bütün bu sistemleri birbirine bağlayan entegrasyon katmanının neden projelerin en zor kısmı olduğunu anlatıyoruz. Özel geliştirmenin nasıl yürütüldüğünü, analizden bakıma kadar olan süreci ise ayrı bir yazıda, özel yazılım rehberinde ele aldık.
Kurumsal yazılım nedir, hangi ihtiyaçtan doğar
Kurumsal yazılım, bir şirketin iş süreçlerini kayıt altına alan, o kayıtları departmanlar arasında ortak hâle getiren ve üzerinde yetki tanımlanabilen yazılım sınıfıdır. Tek kişilik bir araçtan ayıran şey özellik zenginliği değil, üç özelliktir: çok kullanıcılı olması, rol bazlı yetki taşıması ve verinin tek kaynakta toplanması.
İhtiyaç genelde şirket büyüdüğünde değil, bilgi bir kişinin kafasından çıkmak zorunda kaldığında doğar. Sipariş durumunu yalnızca bir kişi biliyorsa, o kişi izne çıktığında süreç durur. Fiyat listesinin en güncel hâlinin hangi dosya olduğu tartışılıyorsa, ortada tek kaynak yok demektir. Kurumsal yazılımın çözdüğü asıl problem budur; raporların güzelleşmesi sonucudur, sebebi değil.
Kurumsal yazılım çözümleri: kategoriler ve sınırları
Piyasadaki kurumsal yazılım çözümleri kabaca altı kategoriye ayrılıyor. Kategoriyi doğru adlandırmak, teklif alırken elmayla armudu karşılaştırmayı önlüyor.
ERP: kaynak planlama
Muhasebe, satın alma, stok, üretim ve finans süreçlerini tek veri tabanında birleştirir. Türkiye'de e-Fatura, e-Arşiv ve e-Defter yükümlülükleri ERP seçiminde belirleyici olur, çünkü bu alanlar sürekli değişen mevzuata bağlıdır ve takibi ürün sağlayıcısına bırakmak neredeyse her zaman doğrudur. ERP'nin sınırı da buradadır: size özgü satış kurallarını, saha operasyonunuzu veya müşteri deneyimi süreçlerinizi zorlayarak ERP'ye sığdırmak, hem pahalı hem kırılgan sonuç verir.
CRM: müşteri ilişkileri
Aday, fırsat, teklif ve müşteri geçmişini tutar. CRM projelerinin başarısızlık sebebi genelde yazılım değil kullanım: satış ekibi kaydı kendisi için değil yönetim için giriyorsa veri eksik kalır ve rapor güvenilmez olur. CRM seçerken sorulacak asıl soru "hangi özellikler var" değil, "satışçı bu kaydı girdiğinde kendi işi kolaylaşıyor mu"dur.
İnsan kaynakları ve bordro
Özlük, izin, puantaj ve bordro. Mevzuata en sıkı bağlı kategori olduğu için özel geliştirme burada neredeyse hiç mantıklı olmuyor; hazır ürün alıp diğer sistemlerle entegre etmek doğru yaklaşım.
Depo, üretim ve saha
Depo yönetimi, üretim takibi ve saha servis uygulamaları. Bu kategori şirketten şirkete en çok değişen kategoridir; çünkü depo yerleşimi, üretim akışı ve saha ekibinin çalışma şekli sektöre ve hatta tesise özgüdür. Özel geliştirmenin en sık haklı çıktığı alan burasıdır.
Raporlama ve iş zekâsı
Farklı sistemlerdeki veriyi birleştirip yönetim panosuna dönüştürür. Kritik nokta şu: iş zekâsı aracı, altındaki verinin kalitesini yükseltmez. Kaynak sistemlerde aynı müşteri üç farklı isimle kayıtlıysa pano da üç farklı müşteri gösterir. Bu yüzden iş zekâsı yatırımı, veri düzeni yatırımından sonra gelmelidir.
Özel panel ve iş yönetim yazılımı
Yukarıdaki kategorilerin hiçbirine tam oturmayan, şirkete özgü süreçleri yürüten sistemler. Bayi portalı, proje ve iş emri takibi, onay akışları, teklif hesaplama araçları, sipariş konsolidasyonu bu başlığa girer. Kurumsal yazılım tartışmasında en çok gözden kaçan kategori budur; oysa şirketleri asıl yavaşlatan işler genellikle tam olarak burada birikir.
İş yönetim yazılımı ile ERP arasındaki fark
Bu ikisi sık karıştırılıyor ve karışıklık teklif aşamasında pahalıya mal oluyor. Aradaki farkı en net şu şekilde ayırabilirsiniz:
| ERP | İş yönetim yazılımı | |
|---|---|---|
| Odak | Kaynakların muhasebeleştirilmesi: stok, maliyet, cari, finans | İşin akışı: kim ne yapacak, hangi onaydan geçecek, ne zaman bitecek |
| Değişim hızı | Yavaş; mevzuata ve standartlara bağlı | Hızlı; şirketin çalışma şekli değiştikçe değişir |
| Kim kullanır | Mali işler, satın alma, depo | Operasyon, saha, proje ekipleri, bayiler |
| Özelleştirme | Mümkün ama pahalı ve sürüm yükseltmeyi zorlaştırır | Zaten şirkete özel yazılır |
| Doğru karar | Hazır ürün | Genelde özel geliştirme veya esnek platform |
Pratikte gördüğümüz en sağlıklı kurgu ikisinin birlikte yaşamasıdır: ERP kayıt tutar, iş yönetim yazılımı işi yürütür, aralarındaki bağlantı otomatik kurulur. Bu ayrımı yapmayan şirketler ERP'yi zorlayarak operasyon aracına çevirmeye çalışır ve genelde Excel'e geri döner.
Şirket içi yazılım mı, buluttaki hazır ürün mü?
Şirket içi yazılım kavramı iki farklı şeyi anlatmak için kullanılıyor: birincisi yalnızca çalışanlara açık olan sistemler, ikincisi kendi sunucunuzda barındırılan sistemler. Karar verirken bu ikisini ayırmak gerekiyor, çünkü "iç kullanım" ile "kendi sunucumuzda" aynı şey değil.
| Başlık | Bulut (hazır ürün) | Kendi sunucunuzda |
|---|---|---|
| Başlangıç | Hızlı, altyapı işi yok | Sunucu, ağ ve kurulum planı gerekir |
| Güncelleme | Sağlayıcı yapar, siz takip edersiniz | Sizin planlamanız gerekir |
| Veri konumu | Sağlayıcının belirlediği yer | Sizin belirlediğiniz yer |
| Erişim güvenliği | Sağlayıcının standartlarına bağlı | Tamamen sizin sorumluluğunuzda |
| Maliyet biçimi | Kullanıcı başına aylık, öngörülebilir | Peşin yatırım, sonra bakım |
| Uzaktan çalışma | Doğrudan çalışır | Güvenli erişim kurgusu gerekir |
| Kesinti sorumluluğu | Sağlayıcıda | Sizde; yedeklilik yatırımı gerekir |
Karar kriteri genelde ideoloji değil sözleşme oluyor. Müşterileriniz ya da mevzuat verinin belirli bir ülkede veya sizin kontrolünüzdeki bir altyapıda kalmasını şart koşuyorsa tartışma biter. Böyle bir kısıt yoksa, bulut çözümün toplam yükü çoğu şirket için daha hafiftir; çünkü sunucu bakımı görünmeyen ama sürekli işleyen bir maliyettir.
Kurumsal yazılım fiyatları: liste fiyatı buzdağının görünen kısmı
Kurumsal yazılım fiyatları karşılaştırılırken genelde tek bir sayıya bakılıyor: kullanıcı başına aylık lisans ya da proje bedeli. Oysa üç yıllık toplam sahip olma maliyetinde bu kalem çoğu zaman yarıyı bile bulmuyor. Karşılaştırmayı aşağıdaki tablo üzerinden yaparsanız iki seçenek gerçekten kıyaslanabilir hâle gelir.
| Maliyet kalemi | Hazır ürün | Özel geliştirme |
|---|---|---|
| Lisans / geliştirme | Kullanıcı başına aylık veya yıllık | Proje başında tek seferlik |
| Kurulum ve yapılandırma | Genelde ayrı danışmanlık kalemi | Projeye dahil |
| Özelleştirme | Ürünün izin verdiği ölçüde; sınırı aşınca hızla pahalılaşır | Zaten kapsam içinde |
| Entegrasyonlar | Hazır bağlayıcı varsa ucuz, yoksa ayrı proje | Her biri ayrı iş kalemi |
| Veri göçü | Ayrı kalem | Ayrı kalem |
| Eğitim | Ayrı kalem, kullanıcı devri oldukça tekrarlar | Ayrı kalem |
| Sürüm yükseltme | Dahil, ancak özelleştirmeleriniz varsa her yükseltmede test gerekir | Yok; bakım kalemi olarak yönetilir |
| Mevzuat değişikliği | Sağlayıcının sorumluluğu | Sizin bakım faturanız |
| Altyapı | Fiyata dahil olabilir | Sunucu, yedekleme, izleme sizde |
| Kullanıcı sayısı arttığında | Doğrudan artar | Genelde artmaz; altyapı maliyeti artar |
| Çıkış maliyeti | Veri dışa aktarım formatı ve geçiş emeği | Kod ve veri sizde kalır |
Tablodaki en çok yanılgı üreten satır sürüm yükseltmedir. Hazır ürünlerde yükseltme fiyata dahil görünür; ancak ürünü özelleştirmiş bir şirket için her yükseltme, özelleştirmelerin yeniden test edilmesi demektir. Bu kalem faturada görünmez, ekip zamanında görünür.
Entegrasyon katmanı: işin gerçekten zor kısmı
Kurumsal yazılım projelerinin çoğunda asıl zorluk tek bir sistemi kurmak değil, sistemleri birbirine bağlamaktır. Aşağıdaki üç soruya baştan cevap verilmeyen entegrasyonlar, altı ay sonra kimsenin güvenmediği veriler üretir.
Ana veri kimde tutulacak
Müşteri, ürün ve fiyat gibi temel kayıtların "doğru" hâli hangi sistemdedir? Bu soruya tek bir cevap verilmezse iki sistem de kendi doğrusunu yazar ve çakışma çözülmez. Kural basit: her veri türü için tek bir sahip sistem belirlenir, diğerleri o veriyi okur ama değiştirmez. İstisna gerekiyorsa hangi alanın hangi sistemde değiştirilebileceği alan alan yazılır.
Akış tek yönlü mü çift yönlü mü
Çift yönlü senkronizasyon kulağa daha iyi geliyor ama maliyeti ve risk profili çok farklı. Aynı kayıt iki tarafta birden değiştiğinde hangisinin kazanacağını tanımlamak gerekir. Çoğu senaryoda doğru cevap, çift yön yerine her alan için tek yön tanımlamaktır: stok ERP'den mağazaya, sipariş mağazadan ERP'ye.
Hata olduğunda ne oluyor
Entegrasyonların gerçek kalitesi mutlu senaryoda değil hata senaryosunda belli olur. Karşı sistem cevap vermediğinde ne olacak, aynı sipariş iki kez gönderilirse ne olacak, kısmen aktarılmış bir kayıt nasıl tamamlanacak? Sağlam bir entegrasyon katmanında şunlar bulunur: tekrar denemede aynı kaydın mükerrer oluşmasını engelleyen kimlik kontrolü, başarısız kayıtların düştüğü ayrı bir kuyruk, her akış için kayıt tutan bir günlük ve akış durduğunda insana ulaşan bir uyarı. Bunlar olmadan kurulan entegrasyonlarda hata sessizce birikir; fark edildiğinde geriye dönük düzeltme çok pahalı olur.
E-ticaret tarafında bu katmanın nasıl kurulduğunu ürün, stok ve sipariş akışları üzerinden özel çözümler ve entegrasyonlar sayfasında anlatıyoruz; pazaryeri tarafında ise veri eşleştirmenin zorluklarını pazaryeri veri aktarımı rehberinde somut örneklerle yazdık.
Yetki ve denetim izi: kurumsal yazılımı iç araçtan ayıran şey
Bir yazılımı "kurumsal" yapan şey, ekran sayısı ya da fiyatı değil; kimin neyi yapabildiğinin ve kimin neyi yaptığının kayıt altında olması. Bu iki başlık projelerde en çok sona bırakılan, sona bırakıldığında da en pahalıya mal olan başlıklar.
Yetkilendirme tarafında baştan cevaplanması gerekenler şunlar: yetki role mi kişiye mi bağlı, aynı kişi birden fazla rol taşıyabilir mi, yetki yalnızca ekranı mı yoksa veriyi de mi kapsıyor (örneğin bir bölge müdürünün yalnızca kendi bölgesinin kayıtlarını görmesi), onay gerektiren işlemler hangileri ve onaycı izindeyken ne oluyor. Son soru pratikte en çok tıkanma üreten sorudur; vekâlet mekanizması olmayan onay akışları, ilk izin döneminde elle müdahaleyle çözülmeye başlar ve sistem güvenilirliğini kaybeder.
Denetim izi tarafında ise asgari beklenti, kritik kayıtların kim tarafından ne zaman ve hangi değerden hangi değere değiştirildiğinin görülebilmesi. Bu, denetim gerekliliği olmayan şirketlerde bile işe yarıyor: bir fiyat ya da stok yanlış girildiğinde tartışmayı bitiren şey kayıttır. Silme işlemlerinde de kaydın gerçekten silinmesi yerine pasife alınması, geçmiş raporların tutarlılığını koruyor.
Veri göçü: projenin en çok küçümsenen kalemi
Kurumsal yazılım projelerinde takvimi en çok sarsan iş genelde geliştirme değil, eski verinin taşınması oluyor. Sebebi teknik zorluk değil, verinin gerçekte sanıldığı gibi olmaması: aynı müşteri farklı yazımlarla üç kez kayıtlı, ürün kodları bir dönem farklı kurala göre verilmiş, tarih alanlarının bir kısmı metin olarak girilmiş, zorunlu olması gereken alanlar yıllar içinde boş bırakılmış.
Bu yüzden veri göçünü tek adımlı bir aktarma işi değil, üç aşamalı bir süreç olarak planlamak gerekiyor. Önce bir deneme aktarımı yapılır ve çıkan hata raporu okunur; bu rapor genelde şirketin kendi verisi hakkında bilmediği şeyleri gösterir. Sonra temizlik kuralları belirlenir ve mükerrer kayıtların hangi kurala göre birleştirileceğine karar verilir; bu kararı yazılım değil iş tarafı vermelidir. Son olarak gerçek aktarım yapılır ve aktarım sonrası doğrulama listesi çalıştırılır: kayıt sayıları, toplam bakiyeler ve örnek kayıtların karşılaştırması.
Eski sistemi aktarım sonrası hemen kapatmamak da önemli. Salt okunur bir kopya olarak bir süre erişilebilir kalması, aktarımda gözden kaçan bir alan çıktığında geri dönülecek bir yer bırakıyor.
Kurumsal yazılım projeleri neden başarısız olur
- Kategori yanlış seçilir. Operasyon aracı ihtiyacına ERP alınır, ERP ihtiyacına panel yazdırılır.
- Veri temizliği projeye dahil edilmez. Yeni sistem eski kirli veriyle doldurulur ve güven ilk haftada kaybedilir.
- Sahiplik belirsizdir. Projenin iş tarafından bir sahibi yoksa kararlar gecikir, kapsam sürüklenir.
- Her şey aynı anda devreye alınır. Tüm departmanların aynı gün geçmesi, hata olduğunda geri dönüşü imkânsız kılar.
- Eğitim tek seferlik yapılır. Ekipteki devir sonrası yeni gelenler sistemi kendi yorumlarıyla kullanmaya başlar ve veri bozulur.
- Entegrasyonlar sona bırakılır. En riskli iş en sona kalırsa, takvim baskısı altında yapılır.
Nereden başlanmalı
Sırayla üç iş yapmanızı öneriyoruz. Birincisi envanter: bugün hangi işlerin hangi araçta yapıldığını, hangi verinin nerede tutulduğunu ve hangi adımların elle yapıldığını tek bir tabloya çıkarın. Bu tablo genelde tek başına bir yol haritası üretir, çünkü elle yapılan adımlar kendini gösterir.
İkincisi önceliklendirme: hangi süreç en çok zaman kaybettiriyor ve hangisi en çok hata üretiyor? Yatırımı buradan başlatın, en çok konuşulan yerden değil. Üçüncüsü sınırlı kapsamlı bir ilk devreye alma: tek departman, tek süreç, gerçek veriyle. Bu ilk adım hem ekibin sisteme güvenini kurar hem de sonraki aşamaların tahminini gerçekçi hâle getirir.
Bizim yaklaşımımız
STools Digital olarak kurumsal tarafta üç işi ayrı ayrı yürütüyoruz. Standart kategorilerde hazır ürün kullanılmasını öneriyor, o ürünlerin birbirine bağlanmasını üstleniyoruz. Şirkete özgü süreçler için kişiye özel yazılım geliştiriyoruz. Sistemler arasındaki veri akışını ise ayrı bir entegrasyon katmanı olarak kurup izleme ve uyarı mekanizmasıyla birlikte teslim ediyoruz.
E-ticaret operasyonu olan şirketlerde bu üçlü genelde tek bir yerde birleşiyor: kendi geliştirdiğimiz RapiSoft altyapısında ürün, stok, sipariş, ödeme ve faturalama tek panelde toplanıyor, pazaryeri kanalları da aynı veri kaynağından besleniyor. Hangi kategoride olduğunuzdan emin değilseniz envanter tablosuyla bize yazın; ilk görüşmede kategoriyi birlikte netleştiriyoruz.