M-Files ile Satınalma Sürecini Dijitalleştirmek
Orta ölçekli bir işletmede satınalma dosyaları ortak klasör, e-posta ve kişisel takip tablolarına dağılmıştı. Talep formunun son sürümü, hangi teklifin onaylandığı ve sözleşmenin nerede olduğu ancak süreci bilen kişilerden öğrenilebiliyordu. M-Files gündeme geldiğinde ilk beklenti bütün belgeleri tek klasöre taşımaktı. Oysa eski klasör mantığını yeni araca kopyalamak, dağınıklığı yalnızca daha modern bir ekrana taşır.
DMS projesinde odak dosyanın konumu değil, belgenin ne olduğu ve hangi iş kararına bağlı olduğudur. Talep, teklif, değerlendirme, sipariş ve sözleşme ayrı nesneler olsa da ortak süreç kimliğiyle ilişkilendirilmelidir. Teknoloji ancak karar hakları, veri sahipliği ve ERP sınırı tanımlandığında fayda üretir. Bu nedenle kuruluma ekranlardan değil, gerçek satınalma akışından başladık.
Sorunun ortaya çıkışı
Farklı birimler kendi talep şablonlarını kullanıyor, teklifler e-postada kalıyor ve onaylar bazen yalnızca mesajla veriliyordu. Dosya adındaki “son”, “final” ve tarih ekleri versiyon kontrolü sanılıyordu. Denetimde bir satınalma kararının talep, karşılaştırma ve yetkili onay zincirini göstermek zaman alıyordu. Aynı tedarikçiye ait belgeler farklı klasörlerde tekrar tutuluyor, saklama süreleri uygulanamıyordu.
İlk belirtiler ve yanlış varsayımlar
İlk varsayım taranmış PDF yüklemenin dijitalleşme olduğuydu. Aranabilirlik artsa da zorunlu metadata ve süreç durumu olmadan kontrol gelişmez. Diğer varsayım bütün alanları ilk günden zorunlu yapmaktı; bu kullanıcıyı sistem dışı kanallara iter. ERP’nin ya tamamen devre dışı kalacağı ya da her şeyi yöneteceği düşüncesi de yanlıştı. İşlem sistemi ile belge ve onay sistemi arasında açık sınır gerekiyordu.
Teknik analiz
Talep numarası, şirket, lokasyon, maliyet merkezi, kategori, tutar aralığı, süreç sahibi ve saklama sınıfını temel metadata olarak belirledik. Nesne ilişkileri sayesinde teklifleri talebe, siparişi onay kararına bağladık. Yetki modeli belge türünden çok süreç rolü ve organizasyon bağlamına dayandı. ERP’de oluşan tedarikçi ve sipariş anahtarlarının DMS’ye nasıl aktarılacağı, hata ve yinelenen kayıt senaryolarıyla birlikte analiz edildi.
Uygulanan çözüm veya önerilen mimari
Önce tek bir satınalma kategorisinde pilot workflow kurduk: taslak, birim onayı, bütçe kontrolü, satınalma değerlendirmesi, karar ve arşiv. Her durumda düzenleme ve görüntüleme hakları ayrı tanımlandı. M-Files versiyon geçmişini resmi kayıt olarak tuttu; onay yorumu ve zaman damgası korundu. ERP entegrasyonunda yalnızca gerekli ana veriler ve onaylanmış sonuç taşındı. Kullanıcılara ekran eğitimi yerine örnek iş senaryoları verildi.
Alternatifler ve karar gerekçesi
ERP’nin yerleşik satınalma modülü işlem bütünlüğünde güçlü olabilir; DMS ise belge yoğun süreç, arama ve kayıt yönetiminde avantaj sağlar. SharePoint veya başka içerik platformları da doğru bilgi mimarisiyle aynı ihtiyacın bir bölümünü karşılayabilir. Ürün seçimini mevcut lisans, entegrasyon yetkinliği ve kayıt yönetimi ihtiyacına göre yaptık. M-Files’ı ERP yerine değil, kontrollü belge ve karar katmanı olarak konumlandırdık.
Güvenlik ve operasyonel riskler
Teklifler, sözleşmeler ve ticari koşullar geniş erişime açılmamalıdır. Kalıtımlı yetkiler, dış paylaşım, indirme ve çevrimdışı kopya senaryoları test edildi. Entegrasyon hesabına yalnızca gerekli nesne ve işlemler için yetki verildi; kişisel hesap kullanılmadı. Workflow arızasında satınalmanın durmaması için kontrollü manuel prosedür ve sonradan sisteme işleme kuralı tanımlandı. Saklama ve silme hukuki gereksinimlerle uyumlu tutuldu.
Çıkarılan Dersler
- Klasörü taşımak süreç dijitalleşmesi değildir.
- Metadata iş kararlarını ve aramayı desteklemelidir.
- ERP ile DMS sınırı açık tanımlanmalıdır.
- Pilot kapsam gerçek ama yönetilebilir olmalıdır.
- Yetki ve saklama tasarımı workflow kadar önemlidir.
Kontrol Listesi
- Süreç ve karar hakları çizildi mi?
- Metadata sözlüğü onaylandı mı?
- ERP veri sahipliği belli mi?
- Yetki senaryoları test edildi mi?
- Kesinti prosedürü yazıldı mı?