1  ERP Sistemleri

1.1 ERP’nin sınırlamalarını anlamak

Bu kitabın okuyucularının birçoğunun bir veya daha fazla ERP sistemini satın alıp uygulamaya geçirdiğini tahmin ediyorum. ERP satıcıları, sistemlerinin belki kahve yapmak dışında her şeyi yapacağını güvenle iddia edeceklerdir. Bunu ilk elden biliyorum çünkü o sunumu yapanlardan biri de bendim. Bu iddialar genellikle kimseyi yanıltmak amacıyla değil, doğru olduklarına dair dürüst bir inançla ortaya atılır.

Savunmamda, beni bir keşif yoluna sokan sorular sormaya başlamıştım. Veya daha doğrusu müşterilerim sorular sormaya başlamıştı. Bu keşif yolu Eli Goldratt’ın “The Goal” adlı kitabını okuduktan sonra daha pekişmiştir.

Benim Eureka1 anım, 1990 yılının sonlarında, ERP sistemlerinin aslında yöneticilerin ve idarecilerin onlardan beklediği her şeyi yapmasının mümkün olmadığını fark ettiğimde geldi. Çalıştığım ERP yazılım şirketinden hemen istifa ettim ve kendi işimi kurdum. Bu iş, şirketlerin ERP sistemlerinin planlama sınırlamalarını aşmalarına yardımcı olmaya adanmıştır.

Bu Eureka anı birçok zorluğu beraberinde getirdi. Her şeyden önce, benim vardığım sonuç APICS’in söylediklerinden çok farklıydı. Ve bazı APICS üyeleri, onlarla aynı fikirde olmayacak cesareti gösteren birileri varsa neredeyse şiddete başvuracaklardı. APICS’e karşı adil olmak gerekirse, son birkaç yılda görüşlerini yavaş yavaş yumuşattılar.

İlk yıllarda sorunu anlamak ile nasıl çözüleceğini bilmek arasında bir boşluk vardı. İlk çözümler yalnızca kısmen etkiliydi ve insanları risk almaya ikna etmek zordu. Şu anda durum artık böyle değil. Küçük ve büyük şirketlerin ihtiyaçlarına uyacak şekilde özelleştirilebilecek birkaç güçlü yazılım paketi var. Ancak bu kolay bir iş değil.

Sınırlı çizelgelemenin, yalnızca başka bir yazılım modülü olduğunu söylemek, Micheal Jordan’ın yalnızca başka bir basketbolcu veya Pele’nin yalnızca başka bir futbolcu ve beynin yalnızca başka bir vücut parçası olduğunu söylemeye benzer.

Sınırlı bir çizelgeleme modülünün uygulanması, arkadaşınızın zorlaması ile çıkıp buluştuğunuz kişinin güzel bir kadın olduğunu bulmaya benzer. Yani ona aşık oluyorsunuz ve düğünden sonra onun milyonlarca dolar değerinde bir mirasın sahibi olduğunu keşfediyorsunuz. Demek istediğim şey, bir APS sisteminin, en güçlü uzun vadeli faydalarının başlangıçta belirgin olmayabileceğidir.

Konuya açıklık getirmek amacıyla: Çoğu üreticinin kesinlikle bir ERP sistemine ihtiyacı olacaktır. ERP sistemleri, işlemler oluşturma, veri depolama ve anında bilgi paylaşımını fantastik bir şekilde yaparlar. ERP’leri uyarlayacak kadar akıllı olan şirketler, ERP ile akıllı özelleştirilmiş süreçler oluşturarak şaşırtıcı sonuçlar elde edebiliyor.

Şirketlerin mevcut ERP sistemlerini atıp yenisini yerleştirme eğilimi son çare olmalıdır. Dikkatli olmazlarsa büyük miktarlarda para harcayacaklar ve yıllar sonra aynı sorunlarla karşılaşacaklardır. Bu, çalışanların harcadığı zamanı ve müşterilerin yaşadığı hayal kırıklığını ve kafa karışıklığını bile hesaba katmaz. Birçok şirket bu durumdan asla kurtulamıyor. Çoğu zaman daha iyi bir alternatif vardır. Eğer iş sorunları; zayıf müşteri hizmetleri, zamanında teslimat yapamama, önemli müşterilerin kaybı ve uzun teslim sürelerinin yarattığı hayal kırıklığıyla ilgiliyse, o zaman kesinlikle çok daha basit, çok daha ucuz ve sonuça ulaşma olasılığı çok daha yüksek olan başka bir yol vardır.

Bu kitap, çok fazla ayrıntıya girmeden, çoğu ERP sisteminin şaşırtıcı sınırlamalarından bazılarını açıklıyor. Ve bunlar hakkında neler yapabileceğinizi anlamanıza yardımcı oluyor. Bir sonraki bölümde ERP sistemlerinin evrimi anlatılacaktır. Çok basit terimlerle nasıl çalıştıkları ve neden sınırlı oldukları açıklanacaktır. Bu sınırlamaların çoğunun, bugün piyasada olan ERP sistemlerinin doğası gereği olduğu açıktır. Bu kısıtlamalar çoğu şirketi etkilese de, siparişe göre üretim yapan üretici için zayıflatıcı olabilir.

Bu kitap, mevcut ERP sistemini değiştirmesi gerektiğini düşünen şirketlere alternatifler sunuyor. Kilit müşterileri mutlu tutmanın ve yeni müşteriler kazanmanın önemini anlayanlar, değişimi bir sorun olmaktan çıkarıp kendilerine rekabet avantajı sağlayacak bir şeye nasıl dönüştürebileceklerini görecekler.

1.2 ERP sistemlerinin basitleştirilmiş geçmişi

ERP’den önce MRP2 vardı. MRP, Malzeme Kaynak Planlaması anlamına gelir ve 1970’lerde Ollie Wight tarafından popüler hale getirildi. MRP, bir şirketin satın alması gereken malzemeleri veya bitmiş bir ürünü üretmek için yapması gereken alt parçaları belirlemek için çok seviyeli Malzeme Listesini (BOM3) patlatmaya yönelik bir teknikten başka bir şey değildi.

Bu bölümün amacı okuyuculara Kurumsal Kaynak Planlaması (ERP), Malzeme İhtiyaç Planlaması (MRP), Ana Üretim Çizelgelemesi (MPS4), Üretim Yürütme Sistemleri (MES5), Kapasite Kaynak Planlaması (CRP6), Malzeme Listeleri (BOM) ve rotalar hakkında kapsamlı fakat basitleştirilmiş bir anlayış sağlamaktır.

Basitçe ifade etmek gerekirse, MRP’nin stoğa üretim yapan bir üretici için daha iyi çalışmasının nedeni, talebi mümkün olan yerlerde uzun vadeli çalışmalar halinde gruplandırarak, üretim verimliliği elde etmek üzere tasarlanmış olmasıdır. Bunu yapabilmesinin nedeni, satın alınan parçaların ve alt parçaların emniyet stoklarını tutmasıdır.

Ancak sipariş üzerine üretim yapan üreticinin tamamen farklı sorunları vardır. Fazla stok yapmak için harcadığı her dakika, müşteri siparişlerini zamanında teslim etmek için ihtiyaç duyduğu malzemeleri ve kapasiteyi tüketir.

Stoka üretim yapan üretici stok satar, siparişe göre üretim yapan üretici ise kapasite satar. Gerçekte elbette herkesin kapasitesi bir düzeyde sınırlıdır. Dolayısıyla stoğa üretim yapan üreticiler bile planlama ve çizelge yapma yeteneklerini geliştirerek karlılıklarını artırabilirler.

Aşağıdaki çok basit örnek, bitmiş bir A parçasını ve bitmiş bir B parçasını yapmak için gereken alt parçaları göstermektedir.

flowchart TD
    A --> X1[X]
    A --> Y

    B --> C 
    B --> Z
    C --> X2[X]

Stoka üretim yapan bir üretici 10 A ve 10 B yapmak isterse, Malzeme İhtiyaç Planlaması (MRP), Malzeme Listesini (BOM) patlatır ve alt parçaların her biri için talebi gruplandırır:

  • X parçası 20 tane (çünkü her iki parçanın da X’e ihtiyacı vardır)
  • Y parçası 10 tane
  • C parçası 10 tane
  • Z parçası 10 tane

Daha sonra bu alt parçaların her birinin stok seviyelerini kontrol edecektir. Arkasından envanteri azalan alt parçalar için “satın alma” veya “oluşturma” iş emirlerine karar verecektir. Genellikle her alt parça için bir minimum sipariş miktarı bulunur.

Stok seviyeleri nedeniyle şirket muhtemelen 10 A’yı ve 10 B’yi hemen üretmeye yetecek kadar her alt parçaya sahip olacaktır. Eğer alt parçalardan herhangi birinde gerçek bir eksiklik varsa, MRP bir istisna mesajı oluşturacak ve bu eksikliği gidermek için bir iş emri başlatılacaktır. A ve B parçalarından herhangi biri için iş emirlerine başlanabilmesi için bu eksiklik iş emrinin tamamlanması gerekir.

Ancak sipariş üzerine üretim dünyasında muhtemelen alt parça envanteri (stokları) yoktur. Dolayısıyla, 10 B’ye ilişkin iş emrinin başlayabilmesi için, 20 X’e ilişkin iş emrinin tamamlanması ve envantere geri konulması gerekir. Daha sonra 10 C ve 10 Z’ye ait iş emri tamamlanarak envantere tekrar konulmalıdır. Ancak o zaman 10 B’nin iş emri başlayabilir.

Tüm bu iş emirlerini planlamak ve çizelgelemek çok daha karmaşıktır. Bu, stokları azaltmak isteyen bir şirketin ödemesi gereken bedeldir. Bu şekilde mi olması gerekiyor? Bu durumda siparişe göre üretim yapan üreticinin iki seçenekten birini izlemesini öneririm:

Seçenek 1, bir iş emrinin diğerine sabitlenmesini gerçekleştirebilecek bir çizelgeleme sisteminin bulunmasıdır. Bu iyi bir fikirdir, eğer:

  1. Şirketin karmaşık, çok düzeyli bir yapısı varsa veya

  2. BOM veya bazı alt parçaların stokları tutuluyorsa.

Çünkü MRP iş emirlerini önerirken bu sabitlemeyi dikkate alır.

Seçenek 2, Malzeme Listesini ve yönlendirmeyi düzleştirmektir. Aşağıda, BOM ve rotanın bitmiş B parçası için düzleştirilmesi durumunda iş emirlerinin nasıl görüneceğine dair bir örnek verilmiştir.

Op 10 alt parça oluştur X
Op 20 alt parça oluştur C
Op 30 alt parça oluştur Y
Op 40 bitmiş B parçasını birleştir

Ne yazık ki bu seçenek yalnızca nispeten basit bir ürün reçetesine sahip üreticiler için geçerlidir. Bu tarife uyan birçok şirket için çok cazip bazı avantajlar var:

  • Süreci basitleştirir.
    • Birden fazla iş emrini bir arada sabitlemeye gerek yok.
    • Genellikle satış siparişi ile iş emri arasında bire bir ilişki vardır.
    • Müşteri siparişlerinin ilerlemesini takip etmek daha kolay.
  • Sıralama kurallarını yöneten bir planlama sisteminiz olduğu varsayılarsa, siparişler tesis verimliliği için kolayca gruplandırılabilir.
  • Gerekli işlem sayısını basitleştirir ve azaltır; alt parçaları envantere girip çıkarmaya devam etmenize gerek yoktur.

İlk MRP sistemleri basitti ve üreticilere stoklarını ve satın almalarını yönetmeleri için güçlü bir araç sağlıyordu. Bazı yazılım şirketleri bir fırsatın farkına vardılar ve 1980’lerin başında başlangıçta MRPII adını verdikleri ve sonunda Kurumsal Kaynak Planlama (ERP) adını verdikleri bir şeyi yarattılar. ERP satıcıları parasına uygun olabilmek için sipariş girişi, envanter yönetimi, satın alma ve muhasebe gibi çok sayıda işlevsellik eklediler. Birçok açıdan bu çok mantıklıydı çünkü ERP şirket içindeki verilerin çoğunu bir yerde entegre ediyordu. Bu, bilgilerin tek bir yerde idame edilebileceği ve sistemdeki herkesin kullanımına sunulabileceği anlamına geliyordu.

Sorun, “Kurumsal Kaynak Planlama” teriminin en hafif ifadeyle yanıltıcı olmasıydı. Çünkü ERP sistemleri, makineler, insanlar ve araçlar gibi kaynakları gerçekten planlamaya ve çizelgelemeye ihtiyaç duyan üreticiler için çok az işlevsellik sağlıyordu.

1970’lerin sonlarında MRPII ve ardından ERP sistemleri, planlamacılara zaman aşamasında yardımcı olacak ve işlerini önceliklendirecek bir araç sağlaması beklenen Ana Üretim Planlama (MPS) kavramını kullanmaya başladı. Bugüne kadar çoğu ERP sistemi hala MPS ve MRP kullanıyor. MPS, nihai ürün SKU7’ları veya ana montajlar için fiili talebi (müşteri siparişleri) ve tahmini talebi gruplandırır. Bu gruplamayı mevcut nihai ürün stoğuna ve üretim planından gelenlere göre düzenler. Bu gruplama, zaman dilimleri (genellikle haftalık) kavramı kullanılarak yapılır. En basit haliyle bir MPS raporu şuna benzer (Aşağıdaki tabloya bakın).

SKU: XYZ Başlangıç Ay 1
Bakiye Hafta 1 Hafta 2 Hafta 3 Hafta 4
Öngörülen Brüt Gereksinimler 250 250 300 300
Planlanmış fişler 350 200 100 100
Tahmini Kullanılabilir Bakiye 100 200 150 -50 -250

Bu süreçte tespit edilen herhangi bir eksiklik, planlayıcıya ne zaman yeni iş emirleri oluşturması gerektiğini bildirmek için kullanılır. MRP daha sonra bu iş emirlerini, daha önce açıklandığı gibi ürün reçetelerini ve rotaları kullanarak alt bileşenlere ve satın alınan parçalara yönelik talebi patlatmak ve gruplandırmak için kullanır.

Ne yazık ki MPS ile ilgili büyük bir sorun var:

Satınalma siparişlerinin ve iş emirlerinin, planlandıkları tarihte tamamlanacağını varsayar. MPS’in gerçek dünyada meydana gelen herhangi bir soruna uyum sağlamak için bir mekanizması yoktur. Örneğin, bir iş emrinin, bir tedarikçiden geç sevk edilmesi gibi veya bir iş merkezinin kapasitenin %100’ünü aşacak şekilde planlanması sorununa cevap veremez.

Bir veya daha fazla kapasite kısıtlaması sorununu çözmek amacıyla ERP satıcıları, Kapasite İhtiyaç Planlaması (CRP8) modülü adını verdikleri başka bir yeni modülü geliştirdiler. Açıkçası, tüm iş emirlerini tamamlamak için yeterli kapasitenin bulunup bulunmadığını görmek için bu tür gerçeklik kontrolüne ihtiyaç vardı. Ama CRP modülü kesinlikle cevap değildi. ERP sistemlerinin sınırlamalarının çoğu doğrudan CRP modülünün sınırlamalarına bağlıydı.

CRP modülü, öngörülen talebi ve kapasite kullanımını doğru bir şekilde hesaplayamıyor. Çünkü aşağıdakiler gibi ciddi sınırlamalara sahip bir takım teknikler kullanıyor:

  • Sonsuz kapasite
  • Geriye doğru çizelgeleme
  • Zaman aralıkları

Aşağıda bu tekniklerin nasıl yanlışlıklara yol açtığına dair daha fazla açıklama bulunmaktadır:

  • Sonsuz kapasite kavramını kullandığından, CRP modülünün aşırı yüklenmiş bir iş merkezinin daha sonraki iş merkezlerinin kapasitesi üzerindeki etkisini hesaplamasının bir yolu yoktur.

  • Geriye doğru çizelgeleme kullandığından CRP modülü, mevcut kapasite veya siparişlerin planlanan tamamlanma tarihleri üzerindeki herhangi bir değişikliğin nedenini ve etkisini hesaplayacak bir mekanizma sağlamaz. Bu durumda CRP’nin yapabileceği en iyi şey, şirketlere bir sorun olduğunu bildiren bir istisna mesajı vermektir.

  • Çoğu ERP sistemindeki rotalama verileri genellikle gerekli kaynakları iş merkezi düzeyinde tanımlar. Gerçekte bu tanımlama genellikle yeterli değildir. Çünkü o iş merkezindeki tüm makinelerde, her ürünün işlenmesi mümkün olmayabilir.

  • Rotalama verileri genellikle iş merkezi çalışma sürelerini tutar. Ancak gerçekte her makine farklı bir hızda çalışabilir. Bu, kapasitenin tüketilme biçiminde bir bozulmaya neden olabilir. Dolayısıyla iş merkezi düzeyinde bir kısıtlama olmasa bile makine düzeyinde bir kısıtlama olabilir.

  • CRP modülü, öngörülen kapasite talebini hesaplamak için zaman dilimleri kavramını kullanır. Zaman dilimleri, verileri özetlemenin ve raporlamanın yararlı bir yolu olabilir. Ancak mevcut kapasitenin hesaplanması veya siparişlerin planlanması söz konusu olduğunda aşağıdaki nedenlerden dolayı son derece yetersizdirler:

  1. Zaman dilimleri, bir olayın zaman dilimin başında mı yoksa sonunda mı gerçekleştiğini bilmez veya umursamaz, dolayısıyla daha sonraki kaynaklar üzerindeki etkisi tahmin edilemez.

  2. Zaman dilimleri, birden fazla zaman diliminden oluşan olayları yönetmekte zorluk çeker.

  3. Zaman dilimleri, aynı zaman dilimindeki bir sipariş için birden fazla işlemi planlamanıza izin vermez.

  4. Fazla mesai, tatiller ve planlı bakım gibi takvim etkinlikleri nedeniyle bir zaman diliminin kapasitesini değiştirmenin kolay bir yolu yoktur.

  5. Zaman dilimleri, siparişlerin sıralanmasının kapasite üzerindeki etkisini dikkate almaz (daha fazla açıklama için “Sıralamanın Gücü” bölümüne bakın).

  6. Zaman dilimleri bir siparişin kuyrukta bekleyeceği süreyi doğru bir şekilde hesaplayamaz. Dolayısıyla ortalama kuyruk süresi kavramını kullanmaları gerekir. Ortalama kuyruk süreleriyle ilgili sorun, bir kişi bunu doğru bir şekilde hesaplasa bile bunun tamamen işe yaramaz bir bilgi parçası olmasıdır.

  7. Zaman dilimleri sıraya bağlı kurulum süresini hesaplayamaz. Dolayısıyla ortalama kurulum süreleri kavramını kullanmaktan başka seçenekleri yoktur.

  8. Hammaddelerin geç sevk edilmesi veya makinenin arızalanmasının, kapasite veya siparişin planlanan tamamlanma tarihi üzerindeki etkisini belirleyecek bir mekanizma bulunmamaktadır.

  9. Bir iş emrinin ilk adımında bir gecikme varsa, bu gecikmenin daha sonraki operasyonların zamanlamasını ve o siparişin veya başka bir siparişin planlanan tamamlanma tarihini nasıl etkileyeceğini hesaplamanın bir yolu yoktur.

Daha önce de belirttiğim gibi kapasite hesaplaması doğru olsa ve bir kaynağın aşırı yüklendiği tespit edilse bile bu bilgiyle ne yapılabilir?

Bu kaynağın kullanılabilir kapasitesi, fazla mesai eklenerek değiştirilebilir. Ancak bunun sorunu çözeceğinin veya maliyetleri artırarak durumu daha da kötüleştirmeyeceğinin garantisi yoktur. Diğer bir seçenek ise kapasite kullanımınızı dengelemek amacıyla iş emirlerinizin planlanan tarihlerini değiştirmeye devam etmektir. Bu, çözülmesi en iyi ihtimalle günler sürebilecek bir deneme yanılma oyunu haline gelir.

Üretim orta ve üst seviye yöneticilerinin anlamaları gerekir ki, herhangi bir değişikliğin sonraki sonuçlarını tahmin etme konusunda, ERP sistemleri tarafından sağlanan CRP ve çizelgeleme araçları, yalnızca çok sınırlı bir yeteneğe sahiptir. Örneğin, iş yüklerini akıllıca önceliklendirmelerine yardımcı olacak araçlara sahip değiller. Yeni bir siparişin taahhüt tarihini doğru bir şekilde tahmin etme yetenekleri yoktur. Malzeme ile kapasite kısıtlamalarını senkronize etme yetenekleri yoktur.

Bu, gözleriniz kapalı araba sürmeye benzer. Bir sorununuz olduğunu bildiğiniz tek zaman, bir şeye çarptığınız zamandır.

Yıllar boyunca hiç kimse bu sınırlamaların önemini kavrayamadı. Aslında kimse çıkıp “Kral Çıplak!” demedi. Ta ki Eli Goldratt Hedef ve Kısıtlamalar Teorisi 9 gibi kitaplar yazmaya başlayana kadar. O zaman bile onun söylediklerinin anlamını gerçekten anlayan çok az kişi vardı. Winston Churchill’in çok yerinde olduğunu düşündüğüm harika bir sözü var. “Ara sıra gerçeğe rastlarız ama çoğumuz sanki hiçbir şey olmamış gibi kendimizi toplayıp aceleyle uzaklaşırız.”

Peki böyle bir sistemle insan nasıl hayatta kalabilir? Bu iyi bir soru ama eğer böyle bir tesiste çalıştıysanız aslında cevabı biliyorsunuzdur.

Genellikle olan olay, bir müşterinin panik içinde arayıp siparişinin neden geciktiğini sormasıdır. Daha sonra bu emri hızlandırmak için biri gönderilir. Hızlandırma, başka bir kişinin tesise gitmesi ve söz konusu siparişi fiziksel olarak bulması gerektiği anlamına gelir. Bu ancak siparişin gerçekten bulunabileceğini varsayarak (ki bu bazen büyük bir varsayımdır) yapılabilir. Bu noktada, geciken emir, kırmızı bir etiket alır ve yüksek öncelikli bir emir haline gelir. Bu da beklenmedik bir sonuçlar zincirini başlatır. Basit bir değişikliğin birçok istenmeyen sonuca yol açabilmesi açısından Rubik küpüyle oynamaya benzer.

Çalıştığımız ve ismi bizde saklı bir kozmetik üreticisinin “Hızlandırıcı” ünvanlı yirmi çalışanı vardı. Bu hızlandırıcılar çok güçlüydü. Ve onlar olmadan, hiçbir şey olmayacağı varsayımı üzerine çok yüceltilmişlerdi. Bütün gün yaptıkları tek şey yangınları söndürmekti çünkü tüm üretim tesisi tepki modundaydı. Planlama haftalık olarak hazırlanmıştı. Tüm departmanlar tarafından imzalandığında zamanda, işe yaramaz hale gelmişti. Zamanında teslimatlar hiçbir zaman ölçülmedi veya tartışılmadı.

İyi haber şudur. ERP sistemleri bir değişiklik yapmanın olası sonuçlarını tahmin edemez. Bundan dolayı, bir sonraki zavallı, kafası karışmış müşteri arayıp, kendi siparişinin de geciktiğinden şikayet edene kadar, değişikliğin sonucu anlaşılmaz. Hiç kimse yapılan bir önceki değişikliğin katastrofik ardışık sonuçlarının farkında olamaz. Ve böylece durumu kontrol altına alma umudu olmadan günden güne kaostan kaosa gider.

Yıllar boyunca yüzlerce üreticiyle çalışma deneyimim, üreticilerin çok azının zamanında teslimat performansını doğru bir şekilde ölçtüğünü gösteriyor. Zamanında teslimat ile müşterileri mutlu etmek arasındaki kritik ilişki göz önüne alındığında bu biraz şaşırtıcı.

Şirketimin bir müşteri için yaptığı değerlendirmede, halihazırda gecikmiş 4.000’den fazla açık sipariş kaleminin olduğu gerçeği tespit edildi. Gerçekten şaşırtıcı olan, geç siparişlerin sayısını kimsenin takip etmemesiydi. Daha da şaşırtıcı olanı, kimsenin bu sayıya şaşırmamasıydı.

Yeni planlama sisteminin uygulanmasından sonraki üç ay içinde geç siparişlerin sayısı ellinin altına düşürüldü. Görünüşe göre insan doğası bizi kontrol edemeyeceğimizi bildiğimiz şeyleri ölçmekten caydırıyor.

O zaman bir sonraki soru şu: Şirketler bu şekilde faaliyet göstererek işlerini nasıl sürdürüyorlar? Çoğu üreticinin böyle bir dünyada hayatta kalabilmesinin tek yolu, devasa malzeme, bitmiş ürün ve teslim süreleri için tamponlar oluşturmasıdır. Bu tamponlar, tesisinizde olup bitenler üzerinde sıfır kontrole sahip olduğunuz gerçeğini ortadan kaldırmak için tasarlanmıştır. Bu tamponların elbette maliyetler ve sonuç üzerinde büyük etkisi var.

Şimdi, yalın üretim tekniklerini benimseyerek maliyetleri azaltabileceklerini ve verimliliği artırabileceklerini söyleyen harika bir danışman geliyor. Böylece tüm bu katma değeri olmayan tamponları süreçlerinden çıkarmaya başlarlar. İlk başta maliyetleri düşürmeye bile başlayabilirler. Ama tahmin edin ne olur? Birkaç eksiklik nedeniyle teslimatları kaçırmaya başladıklarında: BOM!!!…KAZA!!!…KAOS!!!

Benim önerdiğim şey (aslında önermek doğru kelime değil), eğer bir işletme siparişe göre üretim, yalın iş modeline doğru ilerliyorsa, büyük olasılıkla planlama ve çizelge yapma şeklini değiştirmesi gerekecektir.

1980’lerin ortalarında, ERP sistemlerinin üreticilere üretim alanına bilgi göndermek ve üretim bölümünde neler olup bittiğini takip etmek için ihtiyaç duydukları araçları sağlamadığı fark edildi.

Bu, yazılım satıcılarına artık Üretim Yürütme Sistemleri (MES) olarak adlandırılan sistemi sağlamanın kapısını açtı.

Bu, kökleri MRP’ye dayanmasına rağmen, ERP şirketlerinin aslında günlük üretim işlerini yapan kişilere yalnızca sınırlı işlevsellik sağladığının bir başka kabulüydü.

Son birkaç yılda, üretim alanını otomatikleştirmek için çok çeşitli araçlar sunan MES sistemleri giderek daha popüler hale geldi. MES gerçek zamanlı verileri doğrudan makinelerden okuyabilmeyi sağladı. Ayrıca operatörlerin, teknik çizimleri ve diğer kritik bilgileri kağıt kullanmadan görebilmesini sağladı.

Piyasadaki MES sistemlerinin çoğu çizelgeleme/planlama yeteneklerine sahip olmasa da bazıları APS satıcılarıyla birlikte çalışmıştır.

Küçük üreticiler tam kapsamlı bir MES sistemine ihtiyaç duymayabilirler. Ancak çizelgelerin istenildiği anda güncellenebilmesi için üretim alanından işlem verilerini toplamanın otomatik bir yoluna kesinlikle %100 ihtiyaç duyarlar.

Günümüzün ERP sistemleriyle ilgili olarak çok ciddi sonuçlar doğurması nedeniyle net olarak anlaşılması gereken son bir nokta daha var. Rekabet edebilmek için ERP satıcılarına rakipleri ve müşterileri tarafından sürekli baskı yapılıyor. Bu baskı, ERP’lerin tüm insanlar için her tür çözümü üretmeye çalışmasına neden olmaktadır.

Bu da onları sundukları ve destekledikleri entegre modüllerin sayısını sürekli artırmaya zorluyor. Örneğin birçok ERP satıcısı yakın zamanda Müşteri İlişkileri Yönetimi (CRM10 ) modülleri veya Kalite Kontrol modülleri ekledi.

Ayrıca, belirli endüstrilerin benzersiz ihtiyaçlarını karşılamak için temel modüllerinin özelleştirilmiş versiyonlarını oluşturma konusunda giderek artan bir baskı görüyorlar. Hepimizin bildiği gibi karmaşıklığın da kendine has sorunları var. Ve bana göre birçok ERP satıcısı temelleri gözden kaçırmış durumda. Kullanıcıların kafasını karıştırmanın yanı sıra, bu stratejinin başka daha ciddi sonuçları da var.

Entegre bir ERP sistemini çekici kılan şey onun en kötü kabusu haline gelir. Demek istediğim, her biri arasındaki sıkı entegrasyon nedeniyle modüller arasında binlerce temas noktası var.

Bir modülde yapılan her değişiklik, diğer birçok modül üzerinde istenmeyen sonuçlara yol açabilir. Bu, iyileştirmeler yapmayı ve hataları düzeltmeyi giderek daha zor ve daha pahalı hale getirir. Bu gerçek göz önüne alındığında, bir ERP satıcısının her alanda en iyi çözüme sahip olduğunu iddia etmesinin neredeyse imkansız hale geldiğini görmek kolaydır ve bu da kapıyı açar.

Baktığımız her yerde, ERP şirketlerinin müşterilerinin ve pazarın sürekli değişen ihtiyaçlarını karşılamak için sınırlarını zorladığını görüyoruz.

Akıllı ERP geliştiricileri bu gerçeğin farkındadır ve tekliflerindeki boşlukları doldurmak için tasarlanmış ortaklıklar kurmaya yatırım yapmak için zaman ayırırlar. ERP geliştiricileri, bu ortaklara, entegrasyon sürecini basitleştiren araçlar sağlamaya odaklanıyorlar.

Pek çok üretici, ERP satıcılarından bıktı. Bu durum başka yazılım satıcılarının devreye girip Türünün En İyisi 11 çözümler yaratmasının kapısını açtı.

Şirketin yaptığı tek şey buysa, çözümü en üst düzeyde tutmak elbette çok daha kolaydır. Türünün En İyisi çözümler ve entegrasyon araçlarının giderek daha iyi hale gelmesi, üreticilerin kendi seçeneklerine bakışını değiştiriyor.

Daha önce de belirttiğimiz gibi, bazı ERP geliştiricileri sorunun farkına vardılar ve tekliflerine APS modüllerini eklediler. Bu şirketlerin çoğu bunu üçüncü parti yazılım geliştiricilerden APS teknolojisini satın alarak yaptı. Hatta bazıları bu APS sistemlerini, üretim modüllerine entegre edebildi.

Burada ERP geliştiricilerinin neden sadece kendi APS modüllerini oluşturmadıklarını açıklamanın önemli olduğunu düşünüyorum. APS sistemlerinin geliştirilmesi zordur çünkü zaman dilimlerini kullanmadan zaman kısıtlamalarını yönetmeleri gerekir. En başarılı APS sistemleri kendi özel planlama motorlarını oluşturmuştur. Bu APS sistemlerinin gücü ve esnekliği, planlama motorlarının etkinliğiyle doğrudan ilgilidir. Ve bu planlama motorları çok karmaşıktır. Kısacası elektronik tablolar (spreadsheet) ve veritabanı teknolojisi gibi yaygın araçlarla hızlı bir şekilde oluşturulamazlar.

Ne yazık ki hiçbir şeyden haberi olmayan üretici için, bazı üçüncü parti yazılım geliştiricileri, kendi APS sistemlerini satmaktan fazlasıyla mutluydu. Çünkü sadece teknolojilerinin sağladığı faydaları kullanarak, finansal olarak hayatta kalmaları zordu. Bu, bazı ERP satıcılarının başlangıçta pek de iyi olmayan APS araçlarını entegre ettiği anlamına geliyordu. Bu sistemleri uygulamaya koymak için harcanan zaman ve para, karmaşık kısıtlamalarla ve alaylı bilgileriyle12 baş edememeleri nedeniyle büyük olasılıkla boşa gidecektir.

APS modüllerini tekliflerine entegre edebilen az sayıda ERP satıcısı, başlangıçta bu çekici işlevselliği sergileyerek rekabet avantajı elde edebildi. Görünüşte bu yaklaşımın neden pek fazla başarı öyküsü üretmediğini anlamak biraz kafa karıştırıcıydı.

Hazır planlama çözümlerini uygulamaya yönelik bu girişimlerin başarısız olmasının bariz nedenleri, çoğu ERP satıcısının muhtemelen yeni APS işlevselliği geliştirmeye devam etmek için gereken beceri setine sahip olmamasıdır. Ve neredeyse kesinlikle çoğu ERP satıcısının, yazılımlarının bu karmaşık planlama gereksinimlerini nasıl çözebileceğini anlamak için gerekli beceri setine sahip olmamalarıdır.

Benim sonucum, bu planlama sistemlerinin çalışmamasının çok daha önemli bir nedeninin daha olduğudur. Bu konuyu çok daha detaylı tartışacak olsam da, APS için geçerli olan ancak diğer ERP modüllerinin çoğu için geçerli olmayan bir temel önermenin olduğunu söyleyerek bu bölümü bitirmek istedim.

“Üretim şeklinizi APS sisteminize uyacak şekilde değiştiremezsiniz”. Bu kesinlikle bir seçenek değildir. Bu, APS sisteminizin tüm gerçek dünya kısıtlamalarınızı ve tüm alaylı bilginizi modelleyecek kadar esnek olması gerektiği anlamına gelir. Mükemmeli aramadığınızı ancak 80/20 testini karşılamanız gerektiğini ve otomatik oluşturulan çizelgelerin size sürekli olarak iyi kararlar sunması gerektiğini burada belirtmeliyim.

Eğer programınız operatörler için bir anlam ifade etmiyorsa o zaman hiç kimse onu takip etmeyecektir ve bu noktada işe yaramazdan da öte bir şey olur. Herhangi bir APS sistemi bir çizelge oluşturacaktır. Ancak bu geçerli bir çizelge değilse bilgiler yanlış olacaktır ve yanlış kararlar vereceksiniz.

Bu, bir APS sisteminiz olsa bile bu kitapta belirtilen önemli avantajlardan herhangi birini kazanamadığınız anlamına gelir. Benim sonucum, planlama ve çizelgeleme sistemlerinin, stratejik hedefler de dahil olmak üzere, bir işi benzersiz kılan şeyleri yansıtması gerektiğidir.

İlk APS uygulamanız işe yarasa bile, işiniz ve ihtiyaçlarınız neredeyse kesinlikle zaman içinde değişeceği için sorundan kurtulmuş sayılmazsınız. Bir APS sistemi büyüyecek ve bir şirketin değişen ihtiyaçlarını karşılayacak kadar esnek değilse, o zaman değiştirilmesi gerekeceğinin farkında olmanız gerekir. Bu da genellikle her şeyi kaybetmeniz ve yeniden başlamanız gerektiği anlamına gelir.

Değişim, bir şirketin hayatta güvenebileceği birkaç şeyden biri olduğundan, büyüyüp değişebilen bir sistemle başlamak çok mantıklıdır.

  1. Kendi adıyla bilinen yasayı hamamda keşfeden Arşimet ’in buldum anlamında kullandığı sözcük↩︎

  2. MRP:Material Requirements Planning↩︎

  3. BOM: Bill of Materials↩︎

  4. Master Production Scheduling↩︎

  5. Manufacturing Execution Systems↩︎

  6. Capacity Resource Planning↩︎

  7. Stock-Keeping Units,Stok Saklama Birimleri↩︎

  8. Capacity Requirement Planning↩︎

  9. The Goal and The Theory of Constraints↩︎

  10. CRM:Customer Relationship Management↩︎

  11. Best of Breed↩︎

  12. Çeviren not: yazar tribal knowledge, kabile bilgisi terimini kullanmış. Ben bunu alaylı bilgisi olarak çevirdim. Bu terim ile o fabrikaya özel bilgileri kast ediliyor.↩︎