ERP Kurmak, Dijital Dönüşüm Değildir

03.08.2026

Bozuk Süreci Yazılıma Taşıdığınızda Neden Daha Hızlı Hata Üretirsiniz?

Şirketin ERP sistemi vardı. Üretim planı Excel'de hazırlanıyor, stoklar sayımla doğrulanıyor, satın alma siparişleri telefonla teyit ediliyor, yönetim raporları dosyalardan birleştiriliyordu.

Siparişler sisteme giriliyor, faturalar kesiliyordu. Ancak yönetici gerçeği hâlâ kişisel tablolarda arıyordu.

Eksik olan yeni bir yazılım değil; süreç, veri, sorumluluk ve karar konusunda ortak bir çalışma düzeniydi.

ERP ile çalışma deneyimim 1993 yılında ETA ile başladı; Logo, Mikro, Tiger, İAS Canias, Workcube ve SAP ile devam etti. Süreçleri tasarlayan, uygulatan ve sonuçlarını takip eden tarafta yer aldım.

Otuz yılı aşan deneyimimde gördüğüm gerçek değişmedi: Süreç sahipliği, veri disiplini ve yönetim kararlılığı yoksa yazılım değişse de sonuç değişmez.

Süreç Tanımlanmadan Yazılım Neyi Standartlaştıracak?

ERP projelerindeki temel hata, mevcut işleyişi sorgulamadan sisteme taşımaktır. Gereksiz onaylar ve kişilere bağlı sorumluluklar yazılımla düzelmez.

Kâğıt üzerinde beş imzayla ilerleyen süreç, ekranda beş dijital onaya dönüşebilir. İş daha doğru olmaz; aynı yavaşlık sürer.

İlk soru "Hangi modülleri alacağız?" değil, "Şirket nasıl çalışmalı?" olmalıdır. Hedef süreç, süreç sahibi, karar yetkisi, kontrol noktaları ve yönetim raporu ihtiyacı önceden tanımlanmalıdır.

Verinin Sahibi Yoksa Gerçeğin de Sahibi Yoktur

Ürün kartı, ürün ağacı, müşteri koşulu, fiyat ve stok lokasyonu birer IT kaydı değil; ticari ve operasyonel kararların dijital karşılığıdır.

Aynı ürünün birden fazla kartla açılması talebi böler, stoku görünmez hâle getirir. Her ana verinin sahibi ve onay yetkisi açık olmalıdır.

Verinin sahibi yoksa, sistemdeki hatanın da gerçek sahibi yoktur.

MRP Neden Doğru Hesaplayıp Yanlış Öneri Üretir?

MRP; talep, stok, ürün ağacı, açık sipariş ve tedarik süresiyle ihtiyaç planı üretir. Hesaplama doğru çalışabilir; girdiler gerçeği yansıtmıyorsa sonuç yanlıştır.

Stok güvenilir değilse sistem depodaki malzemeyi yeniden satın aldırabilir. Üretim kayıtları geç giriliyorsa kapasite görünürlüğü bozulur.

MRP'nin sonucu, içine girilen veriden ve operasyon disiplininden daha güvenilir olamaz.

Her Kullanıcı Direnci Değişime Direnç Değildir

Sistem gerçek iş akışını yansıtmıyor, aynı bilgi tekrar isteniyor veya kullanıcı girdiği verinin hangi kararı etkilediğini bilmiyor olabilir.

Excel analiz için değerlidir. Sorun, kritik stokların veya üretim planlarının kişisel dosyalarda yönetilmesidir. Asıl soru, şirketin gerçeğinin ERP'ye rağmen hâlâ Excel'de aranmasıdır.

ERP Projesi IT'nin Değil, Yönetimin Projesidir

Süreç sahibi iş akışını, veri sahibi ana veriyi, IT teknik sürekliliği yönetir; danışman seçenekleri gösterir. Hangi süreçlerin standartlaşacağına ve hangi kararların sistem verisiyle alınacağına üst yönetim karar verir.

Roller karıştığında proje teknik olarak ilerler, ancak sahipsiz kalır.

Şapkadan Tavşan Çıkartalım

Birçok şirket ERP'den sihirli bir sonuç bekler. Süreçler tanımlanmamış ve stok kayıtları güvensiz olsa da sistem devreye alındığında sorunların çözüleceği düşünülür.

Yazılım firmasından adeta şapkadan tavşan çıkarması beklenir.

Oysa dijital dönüşüm sihirle değil, doğru sırayla alınmış yönetim kararlarıyla gerçekleşir. Naçizane, yıllar içinde geliştirdiğim ve farklı şirketlerde, farklı ERP sistemleri ile dönüşüm süreçlerinde sahada sınayarak uyguladığım bu yaklaşımı TAVŞAN Modeli olarak adlandırıyorum.

1. Yönetim Zemini

Teşhis Et: Şirketin gerçekte nasıl çalıştığını gör. Kritik süreçleri izle; sistem dışı dosyaları, manuel kontrolleri ve kişilere bağlı kararları görünür kıl.

Akışı Sadeleştir: Gereksiz adımları, onayları ve mükerrer veri girişlerini ayıkla. Hedef süreci, karar yetkilerini, kontrol noktalarını ve yönetim raporlarını tanımla.

Şirketin Sahiplik Haritasını Kur: Süreç sahibi, veri sahibi, karar yetkilisi ve sistem sorumlusunu ayır. Yetki ile sonuç sorumluluğunu buluştur.

Yazılım kurulmadan önce şirketin nasıl çalışacağına ve sonuçların nasıl izleneceğine karar verilmelidir.

2. Veri ve Sistem Tasarımı

Veriyi Güvenilir Kıl: Ürün, müşteri ve tedarikçi kartlarını; ürün ağaçlarını, fiyatları, tedarik sürelerini ve stok lokasyonlarını standartlaştır. Eksik ve mükerrer kayıtları temizle; veri sahipliğini kur.

Satış, üretim, satın alma, depo, kalite, finans ve sevkiyat akışlarını birbirine bağla. Erişim haklarını görevlerle uyumlu hâle getir; normal akış ile istisnaları ayır.

Sistem, verinin tutulduğu bir alan değil; doğru iş akışının doğru yetki ve kontrol düzeniyle yürütüldüğü altyapıdır.

3. Kullanım ve Öğrenme Disiplini

Alışkanlığa Dönüştür: Kullanıcıya yalnızca ekranı değil, girdiği verinin stok, maliyet, termin ve nakit üzerindeki etkisini de öğret. Eğitimi gerçek senaryolarla yap, zamanında veri girişini standartlaştır ve desteği canlıya geçişten sonra da sürdür. Üst yönetim de kararlarını sistem verisiyle almalıdır.

Neticeyi Ölç ve Geliştir: Stok doğruluğunu, zamanında veri girişini, sistemde yürütülen işlem oranını, manuel düzeltmeleri, ana veri hatalarını, sistemden üretilen raporları ve kritik Excel bağımlılığını izle. KPI'ları kök nedeni bulmak ve süreci geliştirmek için kullan.

Sistem günlük çalışma ve karar alışkanlığına dönüşmedikçe proje canlıya geçer; şirket dönüşmez.

TAVŞAN Modeli ile İlk 90 Gün

İLK 30 GÜN

Gerçeği Gör

Kritik süreçler, sistem dışı dosyalar, ana veri, stok ve raporlama sorunları çıkarılır.

Çıktı: Mevcut süreç ve veri haritası.

İKINCI 30 GÜN

Hedef Düzeni Tasarla

Süreçler sadeleştirilir; süreç ve veri sahipleri, yetki matrisi, kontrol noktaları ve yönetim raporları belirlenir. Pilot seçilir.

Çıktı: Onaylanmış hedef süreç ve sorumluluk düzeni.

SON 30 GÜN

Pilotla, Ölç ve Geliştir

Uygulama başlatılır, kullanıcılar gerçek senaryolarla eğitilir, veri kalitesi ve KPI'lar izlenir. Takip ritmi ve yaygınlaştırma yol haritası oluşturulur.

Çıktı: Sınanmış pilot ve dönüşüm yol haritası.

Sonuç

Yazının başındaki şirkette sorun ERP'nin bulunmaması değildi. Sorun; üretim planının Excel'de hazırlanmasını, stokların fiziksel sayımla doğrulanmasını ve satın alma siparişlerinin telefonla teyit edilmesini gerekli kılan çalışma düzeniydi. Yazılım kurulmuş, fakat süreç, veri ve sorumluluk şirketin ortak yönetim sistemine dönüşmemişti.

TAVŞAN Modeli'nin amacı da yalnızca yeni bir yazılım kurmak değildir. Önce yönetim zeminini oluşturmak, ardından veri ve sistem tasarımını güvenilir hâle getirmek, son olarak kullanım ve öğrenme disiplinini kalıcılaştırmaktır. İlk 90 gün bu dönüşümün teşhis, tasarım, pilot uygulama ve ölçüm adımlarını başlatır. Asıl değişim ise yönetim, kararlarını sistem verileri üzerinden almaya devam ettiğinde gerçekleşir.

Şapkadan çıkması gereken tavşan ERP değildir.

Asıl sonuç; verisine güvenilen, süreçleri izlenebilir, sorumlulukları açık, kararları ölçülebilir ve kendisini sürekli geliştirebilen bir şirket yaratmaktır.

ERP kurmak bir teknoloji yatırımıdır. Dijital dönüşüm ise şirketin çalışma biçimini değiştiren yönetim iradesidir.

Editoryal Not

Bu makale, Orkun Akçasarı'nın 1993 yılından bu yana farklı sektörlerde, organizasyonlarda ve ERP sistemlerinde edindiği yönetim, süreç tasarımı, uygulama ve dönüşüm deneyimlerinden hareketle hazırlanmış özgün bir değerlendirme yazısıdır.

Makalede açıklanan TAVŞAN Modeli; Orkun Akçasarı tarafından yıllar içinde geliştirilmiş, farklı ERP ve dönüşüm çalışmalarında sahada sınanmış ve uygulama deneyimleriyle şekillendirilmiş bir yönetim yaklaşımıdır. Modelin bu metinde ortaya konulan aşamaları, sınıflandırması, açıklamaları, metinsel kurgusu ve bunların bir bütün olarak sunuluş biçimi yazara aittir.

Metinde yer alan şirket ve saha örnekleri anonimleştirilmiştir. Bazı anlatımlar, ticari sırların, kişisel verilerin ve kuruma özgü bilgilerin açıklanmaması amacıyla birden fazla deneyimden süzülerek genelleştirilmiş olabilir. Yazıda herhangi bir şirketi, çalışanı, yöneticiyi, yazılım firmasını veya danışmanlık kuruluşunu hedef alma, suçlama ya da itibarsızlaştırma amacı bulunmamaktadır.

ETA, Logo, Tiger, Mikro, caniasERP, Workcube, SAP ve metinde anılan diğer ürün, şirket ve marka adları ilgili hak sahiplerine aittir. Bu adlara yalnızca yazarın mesleki deneyim geçmişini ve konu bağlamını açıklamak amacıyla yer verilmiştir. Kullanımları; herhangi bir ticari ilişkiyi, temsil yetkisini, iş ortaklığını, ürün onayını veya ilgili kuruluşların bu yazıyı desteklediğini göstermez.

Yazı genel yönetim, süreç ve organizasyon perspektifi sunmaktadır. Belirli bir şirkete yönelik hukuki, mali, vergisel, teknik, siber güvenlik, yazılım seçimi veya uygulama danışmanlığı niteliği taşımaz. Her kurumun organizasyon yapısı, mevzuatı, veri altyapısı, riskleri ve ihtiyaçları farklı olduğundan, burada açıklanan yaklaşım somut uygulama öncesinde kurumun kendi koşulları içinde değerlendirilmelidir.

Mevzuatın izin verdiği alıntı ve yararlanma hükümleri saklı kalmak üzere; bu yazının veya TAVŞAN Modeli'nin bu metinde yer alan özgün açıklama ve kurgusunun tamamı ya da esaslı bir bölümü, yazarın önceden alınmış yazılı izni olmaksızın çoğaltılamaz, uyarlanamaz, çevrilemez, yeniden yayımlanamaz, dağıtılamaz veya ticari eğitim, danışmanlık, sunum, yayın ve içerik üretiminde kullanılamaz.

Sınırlı alıntılarda yazarın adı, yazının tam başlığı, yayın tarihi ve yazının aktif internet adresi açıkça belirtilmelidir. TAVŞAN Modeli'nin yazarla bağlantı, yetkilendirme veya iş birliği izlenimi yaratacak biçimde kullanılması uygun değildir.

Not: Bu editoryal not genel bir yayın ve fikrî mülkiyet çerçevesidir; somut bir hukuki uyuşmazlık veya tescil süreci için uzman hukuk görüşü alınmalıdır.

Kaynakça

Çevrim içi kaynaklara erişim tarihi: 3 Ağustos 2026. Tüm URL adresleri açık ve tıklanabilir biçimde verilmiştir.

Kurumsal ve Teknik Kaynaklar

Oracle — Overview of Material Requirements Planning

MRP'nin ana üretim programı, ürün ağaçları, planlanmış girişler, mevcut stok, tedarik süreleri ve sipariş parametreleri üzerinden ihtiyaç hesaplamasına ilişkin teknik açıklama.

https://docs.oracle.com/cd/E26401_01/doc.122/e48795/T478564T478850.htm

Oracle Türkiye — ERP Uygulaması Nedir?

ERP uygulamalarında kullanıcı adaptasyonu, süreç uyumu, veri kalitesi ve kurumsal uyumun rolüne ilişkin uygulama çerçevesi.

https://www.oracle.com/tr/erp/what-is-erp/implementation/

SAP — What Is Master Data Management?

Ana veri yönetimi, tek ve güvenilir veri görünümü, veri standardizasyonu, mükerrer kayıtların önlenmesi ve veri yönetişimine ilişkin açıklamalar.

https://www.sap.com/resources/what-is-mdm

Microsoft — Plan an Implementation Strategy

İş süreçlerinin tanımlanması, süreç sahipliği, iş birimleri ile IT'nin rol ayrımı, veri geçişi, entegrasyon, güvenlik, raporlama, eğitim ve değişim yönetimine ilişkin uygulama rehberi.

https://learn.microsoft.com/en-us/dynamics365/guidance/implementation-guide/implementation-strategy

Microsoft — Manage Changes During Transition and Handover

Canlıya geçiş sonrasında kullanıcı adaptasyonunun, işlem kullanımının, stok ve tahmin doğruluğu gibi göstergelerin ölçülmesine ilişkin rehber.

https://learn.microsoft.com/en-us/dynamics365/guidance/implementation-guide/change-management-transition-handover

Microsoft — Manage Changes in the Project Plan

Kullanıcı katılımı, direnç yönetimi, iletişim, süreç tasarımı ve değişim yönetiminin proje planına dâhil edilmesine ilişkin rehber.

https://learn.microsoft.com/en-us/dynamics365/guidance/implementation-guide/change-management-project-plan

IBM — What Is Digital Transformation?

Dijital dönüşümün yalnızca teknoloji kurulumu değil; süreçleri, operasyonları, ürünleri ve teknoloji altyapısını kapsayan bir işletme stratejisi olduğuna ilişkin değerlendirme.

https://www.ibm.com/think/topics/digital-transformation