Eskiden (bazen hala daha) yazılımın kaynak kodlarını veriyor musunuz diye sorulurdu. Cevabın ne olmasını isterdiniz ?

Çoğunlukla bu işten anlamayanlar “elbette açık olsun, kodları almak iyi bir güvence olur” diye düşünür. İşte böyle düşünenler için açık kaynak kodlu ERP (Enterprise Resource Planning – Kurumsal Kaynak Planlama) yazılımları artık bir iki tuş mesafesinde. Peki kullanılıyorlar mı ?

Açıkçası ben hiç gözümle görmedim ancak bir keresinde bir şirkette kullanıldığını duydum bir keresinde de bir Türk firmasının bu işe giriştiğini duyunca merak edip ziyaret etmiştim (firma şu anda yok).

Bu tip ERP uygulamaları ne ülkemizde ne de dünyada bir türlü ana yola çıkamadılar, bazı meraklı veya fırsat bulduğunu düşünen firmanın dışında bir iki örneğin ötesine geçilemedi. Hem bedava hem de geliştirme imkanını kullanıcıya aktaran bu öneri niçin talep görmedi ?

ERP yazılımı normal bir kullanıcının kendi başına çözümleyebileceği bir konu değildir

Düşünülenin aksine kodları almak bir işe yaramaz (sadece bu işle profesyonel olarak uğraşan ve çok vakti olanlar için belki) çünkü oldukça fazla ve karışık olacaktır. Program yazan bir arkadaşınıza şunu sorabilirsiniz  “başkasının yazdığını düzeltmek mi yoksa yeniden yazmak mı” diye … cevap muhtemelen “yeniden yazmak” olacaktır.

Eğer kodlar ve dökümantasyon eksiksiz, çok anlaşılır ve ekip çok kuvvetli ise (bunların yan yana gelmesi zor) belki !

Göründüğünden daha pahalı, başladıktan bir süre sonra bu anlaşıldı …

Ne kadar kaynağınız var diye sorarak başlayayım. Eğer bir KOBİ iseniz ve siz program yazmıyor iseniz unutun gitsin. Eğer şirketinizin ihtiyacı en azından orta kategori bir ERP ise şöyle düşünmek hatalı olmaz:

Uygun bir ekip ile baştan yazmanız yaklaşık 4-5 yıl sürer, açık bir kod bulup devamını getirmeniz de yaklaşık o kadar sürer … Maliyetini siz hesaplayın.

ERP uygulamaları alınan değil satılan uygulamalar

ERP uygulaması seçmek ve almak için tecrübe gerekiyor, uzman bir satıcı tarafından cevaplanması gereken bir dizi soru ve sorun var. Bu konuda çalışan firmaların çok para harcadıkları satış, pazarlama, danışmanlık ekipleri var. Açık kaynak kodu ile uğraşanların ise yok. Bu durumda şansları nerede ise kalmamış oluyor.

İş dünyası paylaşmayı sevmiyor hatta istemiyor

Açık kaynak kodu dünyasında geliştirileni paylaşmak temel davranış biçimidir.  Bu model, geliştiricilerin geliştiriciler için kod geliştirdiğinde çalıştı. Çünkü bu insanlar için önemli olan geliştirmek, paylaşmak, tanınmak ve bir grubun üyesi olabilmekti. Ancak iş dünyası için bu böyle değil. Hatta geliştirdiklerinin öğrenilmemesi için çalışan bu insanların dünyasına hitap eden ERP uygulamaları bu kanalı kullanamadı.

Aslında kimse uğraşmak istemiyor, büyük şirketlerde bu sorumluluğu almak daha da güç

Herkes işini yapmak istiyor, normal bir şirketin işi de ERP yazmak değildir. Diğer yandan büyük bir şirkette bu işe kim karar verecek ? Bir ERP danışmanı mı, şirketin IT Müdürü mü, CEO’su mu, sahibimi, hissedarları mı …

Ancak bu işin kural seti değişirse her şey değişebilir, bunu bize zaman gösterecek …

Ben yıllarca yazılım ve ERP işi ile uğraşmış birisiyim (halen devam ediyor), ticari yazılım konusunda ise ilk yazılım şirketini kuran iki kişiden birisiyim (1980, iki kişiydik, parasızdık ve okulu yeni bitirmiştik). Benim fikrim bu işin ana kural seti diğer bir deyim ile paradigması değişmeden bu işin olamayacağı, değiştiğinde de bu yönde mi değişecek yoksa başka yönde mi diye sorarsanız bence bu yön kapalı. Böyle düşünmemin temel sebebi ise bu yolun zahmetli ve uzman gerektiriyor olması. Peki ERP paradigması hangi yönde değişecek veya değişebilir … Yorumlarınızı bekliyorum …

ERP projelerinde direnç işin doğasında vardır

ERP projeleri şirketinizin “iş yapma” şeklini, teknik tabiri ile “iş süreçlerinizi” değiştirmeye talip olduğu için doğal olarak bir direnç ile karşılaşırlar.

ERP proje yöneticileri projenin teknik veya finansal kısımlarından çok teknik olmayan, insanlar ile ilgili olan konulara eğilmezler ise projenin başarılı olma şansı çok değildir. “ERP yazılımı aldık ama kullanamadık” şeklinde ifade edilen sonuç cümlesinin arkasında çoğunlukla teknik ayrıntılara boğulmuş, çalışma ortamını dikkate almamış tercihler ve yaklaşımlar bulunur. Başarı elde edilecek ise bunu insanlar gerçekleştirecektir.

Başarılı olmak isteyen ERP Proje Takımı işin içindeki herkes ile yüz yüze konuşur (e-mail aracılığı ile değil) ve hedefleri beraber tespit edebilir ise proje hiç bir önemli direnç ile karşılaşmaz.

Değişiklikleri yukarıdan aşağıya itmek veya en aşağıdan geliştirerek yukarı doğru çekmek yerine yalınlaştırmak, evrensel hedefler etrafında görüş birliği sağlayarak hem biraz itmek hem de biraz çekmek en iyisidir.


Başarısız olursanız bunun sebebi direnç değildir

Her ERP projesine karşı çalışanlar direnç gösterebilir, sorun direnç değil onun nasıl yönetildiğidir. Proje yöneticisi bu direnci herkesle konuşarak, onların endişelerini dinleyerek, söyleyemedikleri korkuları algılayıp çözüm üreterek aşabilir.


Temel olarak 2 farklı direnç türü ile karşılaşılır.

1. Değişim fikrinin kendisine gösterilen direnç :

Uygulayıcılar gösterilen direncin en çok bu şekilde olduğuna inanırlar. Eğer gerçekten direnç değişim fikrinin kendisine ise ve arkasında gizli bir konu yok ise çok önemli bir sonuç yaratmaz. İnsanlar değişime bir çok sebepten dolayı direnebilirler, örneğin

- sizin ne yapmak istediğinizi anlamamış olabilirler,
- yapılmak istenen şeyin niçin önemli olduğunu bilmiyorlardır,
- mevcut durumun devamına inanıyor olabilirler,
- sizin bu işi yapabilip yapamayacağınızı sorguluyor olabilirler,
- şirketin geleceğine ait kendi fikirleri vardır.

Eğer direncin sebebi bunlar ise konuyu sakince açıklamak, soruları açık yüreklilik ile cevaplandırmak yeterli olacaktır. Ancak eğer gerçek sebep bunlar değil ve daha derin bir direnç var ise bu yaklaşım şekli yetersiz kalır.

Değişim projelerini yürütme durumunda olanların çoğu ve genel kurumsal yaklaşım yapılacak bir sunum sonrası fikirlerinin büyük tezahürat eşliğinde destek bulacağını varsayar. Ancak direnç derinden geliyor ise böyle olmaz, hatta bu şekilde yaklaşmak çözümü iyice güçleştirebilir ve sistem içinde “ötekiler” dalgası bile yaratabilir.

Bu nedenle direç ile karşılaşıldığında doğrudan ve yüz yüze yöntemler kullanarak müdahale etmek, sorulamayan soruları cevaplandırabilmek gereklidir.

2. Daha derin sebepler :

Bu direnç türünün kaynağı entellektüel veya teknik değil tamamen kişiseldir. Çalışanların işlerini veya statülerini kaybetme korkusu, kariyerlerinin risk altında olduğunu düşünmeleri çok kuvvetli bir direnç yaratır. Direç kaynağının bu olduğunu anket veya toplantılar ile keşfetmeniz güçtür. Onun yerine birebir görüşme ve bu tür kişileri değişim projesinin parçası, görevlisi haline getirmek sorunun çözülmesine yardımcı olur.
ERP proje yöneticisi insanların ne söylediğini dikkatle dinlediği, sorulara açık olduğu sürece hem direnç azalır hem de gerçek sebepleri anlamak kolaylaşır.


“Şimdi Ne Olacak ?” yöntemini deneyebilirsiniz

ERP projelerinde direnç ilk başta gösterilmeyebilir, çalışma ilerledikçe ortaya çıkabilir. Bunun nedeni başlangıçta insanların neyle karşı karşıya olduklarını bilmemeleridir.

Grup olarak muhtemel problemleri veya başarısızlık olasılıklarını listeleyerek herhangi biri başınıza geldiğinde ne yapabileceğinizi tartışmış olmanız hem öğreticidir hem de oluşabilecek olan direnci engelleyici etki yapar.

İnsanlar değişime direnirler, bunu öngörmeli ve doğal karşılamalısınız. Çaresi açık yüreklilikle onlarla konuşmak, olası sorunları önceden tartışmak, herkesin çözüm yolları için katkı yapabileceği ortamı sağlamaktır.

Haydi şimdi 1-2 dakikanızı ayırın, aşağıda bulunan formu doldurup bana gönderin, kullandığınız veya kullanmadığınız ERP yazılımı hakkında düşüncelerinizi, duygularınızı benimle paylaşın …

** Bu anket tamamlandığı için soru formu devreden çıkmıştır, teşekkür derim “”

.Not : Bu çalışmanın sonucunda elde edebildiğim değerlendirmeleri hepiniz ile paylaşacağım,  elbette hiç bir ticari firmanın markasını belirtmeden. Eğer hem sonuçlar sayıca anlamlı hem de yazılım şirketleri talep ederler ise sadece kendilerine ait olan sonuçları, onlara kullanıcının düşüncelerini aktarabilmek amacı ile herhangi bir isim bilgisi olmaksızın onlar ile paylaşabilirim.

ERP,  şirketleri, çalışanlarını ve iş ortaklarını iş yapma yöntemlerini yeniden düşünmeye, değişiklikler yapmaya çağırır ama insanların çoğu yıllardır izledikleri yolu değiştirmekten pek de hoşlanmazlar. ERP projelerinden umulan faydayı geciktiren sebeplerden biri de budur.

ERP projelerinin yarısı yazılım ise diğer yarısı bu değişimi yönetmek ve gerçekleştirmektir. Eğer ERP yazılımını etkin sipariş alma, imalatı yönetme, zamanında sevkiyat,  doğru bilginin firma içinde hızlı gezinmesi için kullanırsanız size fayda sağlayacaktır. Ancak ERP yazılımını kurarken kendi iş yapma biçiminizin olabilecek en iyi yol olduğunu, yazılımın buna ayak uydurması gerektiğini düşünür ve süreçlerinizin arasından gerekenleri değiştirmeyi hedeflemezseniz elde edebileceğiniz sonuçlara muhtemelen ulaşamazsınız.

Üretim yapan firmalar için 40 soruluk bir test:

 “Yazılımınız size ne kadar hizmet ediyor veya siz onu ne kadar etkin kullanıyorsunuz ?”

Aslında bilgisayar yazılımınızın (ERP veya Ticari Otomasyon Yazılımı olabilir)size ne kadar hizmet ettiği veya onu ne kadar etkin kullandığınız konusu biraz karışıktır ancak yine de bu testin size bir miktar ışık tutacağını ümit ediyorum.

 

Bu testi tek başınıza değil de bir grup çalışması olarak uygulamanızı öneririm, bu sayede uzun zamandır konuşmaya fırsat bulamadığınız noktalara da değinme şansı bulacağınızı düşünüyorum, iyi eğlenceler …

Not: Bu Test Kitapçığı siteye üye olduğunuzda adresinize otomatik olarak gönderilecektir, üyelik için sağ tarafta bulunan formu kullanabilirsiniz …


Şimdi vereceğim liste size sıkıcı gelebilir ama ERP Projeleri sadece konuşarak yapılmıyor. İzlemeniz gereken hem bilgisayar yazılımlarının devreye alınması için yapılması gereken teknik veya düzenleme çalışmaları hem de mevcut süreçlerin yenileri ile yer değiştirip değiştirmedikleri (çalışanların bir yandan da eski düzeni koruyor olmaları sık rastlanan bir olaydır).

Örneğin Satınalma Bölümü ile ilgili bir çalışma yaparken :

- Talepten başlayıp depoya yerleştirme aşamasına kadar izleyeceğiniz yol ve ERP yazılımınızın hangi aşamalarda karşınıza çıkacağı
- Bu süreçte kullanılan formların listesi, hangileri ve nasıl yeni süreçte yer alacak, tasarımları nasıl olacak
- Normal olmayan bir durumda ne yapılacak (örneğin siparişte olandan fazla malzeme geldiğinde kim kime ne söyleyecek)
- Etiketleme yapılacak ise ne tür malzeme kullanılacak, etiketler tedarikçi tarafından mı sizin tarafınızdan mı hazırlanacak
- Malzeme depoya geldiğinde ne kadar süre içinde bilgisayar sistemine işlenecek, ne kadar sürede raftaki yerini alacak
- Geciken siparişleri tedarikçiye hatırlatmak için nasıl bir düzen kurulacak
- Malzemelere ait planlama parametreleri kim tarafından, hangi kurallara göre hazırlanacak, planlama parametresi eksik olan malzemeler için ne yapılacak
- Süreç inceleme ve güncelleme çalışması ne kadar sürede bir tekrar edilecek
- Yazılım kullanıcı girişlerinde neleri kontrol edip uyarmalı …

Bu liste gerçeğin sadece bir kısmı. Siz de ERP projenizde yer alan her bölüm, departman veya uygulama için bu tür listeler oluşturmalısınız. Takip için oluşturacağınız listelere ilaveten hem yönetimin hem de herkesin kolayca anlayabileceği “Anahtar Performans Ölçekleri – KPI – Key Performance Index” çalışması yapmanız da yolunuzu şaşırmamanızı sağlar. Örneğimizi yine Satınalma ile ilgili verelim.

- Malzemelerinizin A-B-C analizi sonucu kategorileri, her kategoride kaç değişik malzeme var
- Her malzemenin Stok Devir Hızı
- Dönem sonu malzemelerin depoda bekleme süresine göre puanlama
- Beklentilere uygun malzeme teslimat oranı
- Geciken malzemelerin oranı
- Kullanılamaz duruma geçen / ayrılan malzeme miktarı, oranı …

Bu listede uzayıp gidebilir, uzatmak kolay kısaltmak zordur. Firmanız için en önemli olanlarını her dönem değerlendirerek ilerlerseniz ne tarafa gittiğinizi de görmüş olursunuz.

ERP projesinin en eğlenceli kısmı satın alma sürecidir. Şirketin çeşitli güç merkezleri başlarına ne geleceğini kestirmeye çalışırken bir yandan destekleme bir yandan engelleme hamlelerine şahit olunur ama genellikle toplantı odaları kalabalıktır. Satınalma sürecinin sonuna doğru işin kimin tarafından yapılacağı, projeyi kimin yöneteceği, kimin ana kayıtları aktaracağı, kimin formları tasarlayacağı gibi gerçekle yüzleşme dönemine geçilir. İşte bu aşamada topu başka sahaya atma girişimleri başlar…

- Projeyi gerçekleştirmek için çoğunlukla genç birinin işe alınması ve projenin onun sorumluluğuna verilmesi. Buna ?sobeleme? yöntemi diyoruz. Şirkette yıllardır çalışan, tecrübeli ve işi bilenlerin bir kenara çekilip bundan sonraki yıllarda şirketin nasıl çalışacağını, süreçlerinin nasıl işleyeceğinin kararlarını şirketi hiç bilmeyen birisinden beklemek aslında kötü bir fikir değildir ancak projeyi ?benimsememe? göstergesi olabilir.

- MRP/ERP çalışmaları bazı şirketlere mühendislik veya bilgisayar çalışması gibi görünür ve proje çoğunlukla bilgisayar veya IT departmanına ihale edilir sonra da bu arkadaşların muhasebe bilgileri hakkında espriler üretilir. Her ne kadar projenin içinde yazılım ve donanım elemanları yer alsa da bu bir bilgisayar projesi değildir; çalışmanın hedefi şirketinizin iş yapma biçimini çağın gereklerine uyarlamaktır. İşin içinde hem iş bilgisi hem de yalınlaştırma arzusu olmalıdır. Eğer şirketin IT bölümünde bu tür bir çalışan var ise ne mutlu o şirkete.

- En çok boş vakti olanı proje yöneticisi yapma önerisi ile belki de toplantılara hiç katılmamış birisinin bir anda olayla yüz yüze kalması da oldukça heyecanlı ve eğitici bir yaklaşımdır çünkü bu sayede kimlerin çok meşgul olduğu da anlaşılmış olmaktadır. Bu yöntem ?dışarıdan gelen proje yöneticisi? yöntemine benzediği için sonuç sürprizler ile dolu olabilir. Yeni bir bakış açısı ile çok başarılı sonuçlar da alınabilir ancak bir kuralı ihmal etmemek şartı ile :
Ya seçilen kişi liderliği tartışılmaz birisi olacak ya da arkasında bir adım bile geri gitmeyen ve yönetim alanı herkes tarafından kabul edilmiş birisi olacak.

- Projeyi bir danışmana teslim etmek. Tecrübeli ve bilgisi kanıtlanmış bir danışman size çok faydalı olabilir ancak  her zaman proje sizin ve şirketinizin olmalıdır. Danışmanlar tıpkı ?kavramlar? gibidir, faydalıdır, bir çok çelişkiyi çözebilirler, yolunuzu çok kısaltabilirler ama onların önerilerini hayata geçirebilmeniz için uygulayıcılara, yani size ihtiyaç vardır.

- Projeyi demokratik ortamda değerlendirmek ve herkesin fikir birliğini aramak. Bu yöntem ?ne yapılacağını bilmiyorum veya sonuç kötü olursa ben karar vermiş olmayayım ?? anlamına da gelebilir.

ERP projesinin satınalma süreci eğlenceli olsa da gerçekleştirme sürecinin özellikle ilk kısmı zor ve gerilimlidir. Bu aşamada birisinin ortaya çıkması veya şirket tarafından bulunarak  olayı sürüklemesi gerekir, eğer herkesin üzerinde anlaşacağı bir senaryo aranmaya başlanır ise bu yıllar sürebilir.

Stok için Üretim yapmakla (Make To Stock, MTS) Siparişe Üzerine Üretim yapmanın (Make To Order, MTO) farklarını ve firmaların içinde bulunduğu pazar koşullarını gözlemlediğimizde nelerin daha önemli olduğu ve planlama parametreleri ortaya çıkar. Burada bahsedilen planlama sadece üretimin kendi içinde planlanması değil, tüm firma faaliyetlerinin koordinasyonudur.

Diğer yandan aşağıdaki farklılıklar ERP yazılımının seçimi ve uygulama sürecini doğrudan etkiler..

Yeşil satırlar = Stok için Üretim yapan firmalar

Mavi Satırlar = Sipariş Üzerine Üretim yapan firmalar

Ürünler

Genellikle tanımları standart,daha az çeşit veya daha büyük üretim partileri. Ürün tanımlarındaki değişme pazar trendine bağlı.

Bir çok farklı standart, daha fazla çeşit, tanımlar hem pazar trendine bağlı hemde müşteriler tarafından değiştirilebiliyor. Standart parti büyüklüklerini yakalayabilmek tesadüflere bağlı.

Üretim Kaynakları

Üretilen çeşitler yavaş değiştiği için özel tezgah, aparat ve işgücü kullanabilme imkanı.

Standartların ve isteklerin çeşitliliğinden dolayı çok amaçlı tezgah, aparat kullanma mecburiyeti, esnek iş gücü kullanımı.

Talep

Ürünlerin çoğu standart olduğu için istatiski yöntemler ile tahminler yapabilme imkanı.

Müşteri sipariş ve spesifikasyonlarına bağlı olan bir talep yapısı. Tahmin yöntemlerinin ihtiyaç duyduğu verilerin toplama zorluğu.

Kapasite Planlama

İmalat Planı tahmini talep eğrilerine göre önceden yapılabilir. Tahmin ve Planlama arasında genellikle yeterli süre vardır.

Genellikle önceden tahmin edilemez. Müşteri taleplerine göre planlama yapılır. Plan sık sık değişebilir. Alınan siparişle, planlama çalışması arasında zaman farkı yoktur, bir arada yapılmalıdır.

Hammadde Planlama

Üretim planları daha uzun dönemler için yapılabilir, ani değişiklikler pek az olur. Hammadde alım planlarında ani değişiklikler olmaz.

Üretim planları uzun dönemler için tahmin üzerine yapılamaz, dolayısı ile hammadde ihtiyaçları aktifteki işlere bağlıdır, ani değişikler olabilir. Satın Alma bölümünün reaksiyon süresi ve imalat planı ile bağlantısı son derece düzenli ve hızlı olmalıdır.

Fiyat

Genellikle pazar koşullarına bağlı olarak üretici tarafından belirlenir.

Müşteri ile yapılacak pazarlık sonucu karar verilir, teslim süresi pazarlık konularından birisidir.

Finansal Dengeler

Üretimde önceden planlanmayan ani artışlar pek olmaz, eksilişler ise pazar trendine bağlıdır. Bu nedenle dengeleri korumak daha kolaydır.

Üretim planlarında ani artış veya eksilişler olabilir (büyük bir siparişin alınması veya iptali gibi) dolayısı ile harcamalarda dalgalanma ihtimali daha fazladır.

Teslim Süresi

Müşteri talepleri stoktan karşılandığı için müşteri tarafından bilinmez.

Müşteri ile beraber karar verilir, işin alınabilmesi, için pazarlık unsurudur.

ERP veya MRP-II sadece bilgisayar programı değildir, uygulama sorumluluğunu  bilgi işlemcilere bırakmamanızı öneririm …

MRP veya MRP-II kelimeleri birer mühendislik ve iş yöntemidir. Bildiğiniz gibi bir şey yöntem ise kendisine göre bir çalışma kurgusu, algoritması vardır. Her algoritma mükemmel olmak zorunda değildir ancak başı sonu belli bir konudan bahsediyor olmak belirsizliği engeller. ERP ise kendi başına bir yöntem değildir. Bundan yıllar önce ilk kez tanımlandığında “entegre uygulamalar içeren bilgisayar yazılımı” olarak kayıtlara geçmişti. Bugün ise ERP, bir entegrasyon anlayışı veya çabası olarak algılanmalıdır. ERP prensip olarak şirket içi bir uygulamadır, iç entegrasyona yönelik bir ağırlığı vardır.

İster MRP-II ister ERP olsun şirketin satış, satınalma, üretim, muhasebe, planlama, ambar, insan kaynakları, finansman gibi departmanlarının günlük işleyişlerini düzenleyici kurgular yaratır, dolayısı ile kullanıcıları bu bölümler de çalışanlardır. Bilgi işlemciler ise genellikle bu konulara uzaktırlar, zaten yakın olsalardı bilgi işlemci olamazlardı.

Bilgi işlem grubu ERP projesinde çok önemli destek görevi üstlenmeli ve herkesin işini kolaylaştırıcı katkılar sağlamalıdır. Ancak onlardan planlama bölümünün uygulama sorumluluğunu almalarını beklememelisiniz.

ERP Uzmanlık Dizisi : MRP Nasıl Çalışıyor

12 Şubat GESİAD – Gebze

Bu seminer, üretim yapan firmalarda ERP veya MRP çalışması yapacak veya yapmakta olan ekiplere en temel bilgi olan MRP Yöntemini tüm boyutları ile  inceleme ve pratik yapma fırsatını vermektedir

Seminerin İçeriği

* ?A Class? MRP-II Performans Ölçekleri Nelerdir, Hedefimiz Nedir ?

* MRP?nin çıkış noktası nedir, Bağımlı Talep ile Bağımsız Talep, Sipariş Noktası Yöntemleri ile MRP arasındaki fark nedir

* Ana İmalat Planını (MPS) destekleyecek bir Malzeme İhtiyaç Planının adımları nelerdir

* Ana İmalat Planından ?Planlanmış Siparişlerin? yaratılması.

* MRP Tablosu ve elemanları nedir.

* Ürün Ağacı ve Planlanmış Siparişler kullanılarak Toplam İhtiyacın hesaplanması.

* MRP Tablosunun matematiği.

* Güvenlik Stoğu ve Parti Büyüklüğü ile MRP Tablosu

* MRP?nin sinirlenmesi (Nervousness MRP), nasıl sakinleştirilir

* MRP ve Satınalma İlişkisi

* MRP?nin 3 temel mesajı ve sonuçları

Kullanılan Kaynaklar

Seminerin içeriği hazırlanırken hem çok sayıda uluslararası kaynak hem de saha tecrübesi kullanılmıştır.

MRP-II?ye ilişkin ?klasik? kısım genel olarak Orlicky tarafından belirlenen orjinal kurguya dayanmaktadır. Bu sayede katılımcıların kullandıkları veya kullanacakları yazılım ne olursa olsun MRP-II?nin ortak lisanı ile tanışmaları sağlanmaktadır.

Seminerde kullanılan tanımlar için APICS Dictionary kullanılmıştır.

Bu seminer hazırlanırken faydalanılan kaynakların listesi aşağıdadır :

- APICS Study Notes for Material and Capacity Requirements Planning
- APICS Study Notes for Master Planning
- MRP / Terry Lunn
- Case Studies In Material Requirements Planning
- Manufacturing for Survival ? The How to Guide for Practitioners and
Managers
- Production and Inventory Management in the Computer Age/Oliver W.
Wight
- Bill of Materials / R.D. Garwood
- Capacity Management / John H. Blackstone
- APICS Dictionary

Kimler Katılmalı

ERP / MRP uygulama grup üyeleri, satınalma, planlama ve üretim yöneticileri, üretim ekip liderleri ve operatörleri, maliyet muhasebesi, mühendislik ve kalite bölümü çalışanları.

Sertifika Semineri düzenleyen kurum tarafından sertifika verilmektedir.

erp_wayMRP veya ERP çalışmaları konusunda başarıya giden yol için en önemli iki nokta hedefler ve performans kriterleridir. Bu tip çalışmalar içinde olan firmaların sıkça yaptıkları hatalar onların uygulama süreçlerinin karmaşık ve gereksiz yere uzun olmasına yol açmakta, sürecin uzaması ise hedeflerin aşınmasına ve giderek unutulmasına neden olmaktadır.
Halbuki firma, bilmediği bir çalışmanın içinde değildir. Aksine çok iyi bildiği, kendi günlük hayatını ve iş yapma süreçlerini değiştirmeye çalışmaktadır. Elbetteki asıl zorluk alışkanlıkların değiştirilmesi, bir arada çalışmanın getirdiği güçlükler ve sınırlardır.

Bütün yaşayan sistemler kendi hallerine bırakıldığı zaman minimum enerji harcayacakları pozisyonu elde etmeye çalışır, şirketlerde böyledir.

Yapılması gereken, pozitif enerji harcayarak şirketinizin entegrasyonunu ve dik durabilmesini sağlamaktır. İşte bunun için hedef olmalıdır ve bu hedefe doğru gidip gitmediğinizi gösteren performans kriterleriniz.

Net Hedefleriniz Var mı ?

Çalışma başlamadan önce firma hedeflerini net olarak ifade etmelidir, örneğin :

Teslim tarihlerinde % 50 – 75 azalma
Kalite maliyetlerinde % 45 – 55 azalma
Envanterde % 40 – 60 azalma
Kullanılan alanda % 40 – 60 azalma
Yeni ürün geliştirme zamanında % 30 – 50 azalma
Üretim maliyetlerinde % 20 – 40 azalma
Malzeme maliyetlerinde % 5 – 20 azalma

Yukarıdakiler birer hedeftir, bu aşamada firmanın yazılım ihtiyaçları henüz gündemde
değildir.

Kavram ve Metodları iyice sindirmelisiniz

MRP / ERP projelerinde birçok kavram ve metod kısaltmalar ile anılır ve bir süre sonra anlamları unutulur ama kendileri kullanılır. Firmaların hedefi bunlardan birini (MRP, MRP-II, JIT, KANBAN, MES, ERP, TQ, SM vs?) uygulamak değildir, bu kavram ve yöntemler Dünya Klasında Üretici olabilmek için sadece birer araçtır.
Kavram ile metod?un farkını anlamak ve çalışmaları bu bilgi zemini üzerinde yürütmek son derece yararlıdır, aksi takdirde JIT?mi MRP?mi gibi cevabı olmayan sorular arasında kaybolursunuz.

Entegrasyon kolay iş değildir

Bu tür bir uygulama bir başkasının sizin adınıza yapabileceği türden değildir. Bu nedenle, şirket dışından veya günlük operasyonunuzdan haberdar olmayan ekiplere teslim edilemez.

Nedense bazı şirketler MRP/ERP çalışmalarını mühendislik veya bilgisayar çalışması gibi görürler, halbuki böyle değildir. Çalışmanın hedefi, şirketinizin iş yapma biçimini çağın gereklerine uyarlamaktır. Bunu da en iyi siz yapabilirsiniz. Dikkat edilmesi gereken, operasyonu iyi bilen insanların çalışmalara dahil edilmesidir, boş vakti olanların değil.

Bazı şirketlerde ise konu açık tartışma ortamında değerlendirilmeye çalışılır, halbuki değişim kararı tartışmaya açık olmamalıdır. Karar verilir ve harekete geçilir; ancak bütün gerekçeler ve hedef herkese anlatılmalı ve anlaşılması sağlanmalıdır.

Siz bir komutanın bütün ordusu ile tartışıp, sonra da kararı oya sunduğunu hiç gördünüz mü ?

Gerçek ile yüzleşin, ne kadar çok boşuna iş yaptığınızı öğrenmek sizi üzmesin

İşletmelerin bugünkü performans ölçeklerine göre ortada hiç bir problem
görünmeyebilir, ancak görünmemesi olmadığı anlamına gelmez. Bu nedenle yeni
performans ölçekleri kullanılmalıdır, örneğin herhangi bir operasyon veya prosedür için
şu tip sorular sorulmalıdır :

Bu işlem envanteri azaltıyor mu ?
Satış gelirini arttırıyor mu ?
Masrafları düşürüyor mu ?

Yukarıdaki üç soruya?da Hayır cevabı alıyorsanız o yapılan iş veya prosedürün sebebi iyice araştırılmalıdır. Belki bu aşamada şu düşünülebilir, ?yapıyoruz çünkü müşteri memnuniyeti için gerekiyor?; ancak bu durumda da satış gelirimizi etkilemesi gerekmiyor mu?

Sorgulayacağınız işlem herhangi bir şey olabilir. Örneğin imalatı süren bir iş emrinin parçalarını fork-lift ile başka bir yere taşıyıp arkadan gelen ?acil? işe yer açmak işlemi için bu soruları sormak gibi.

Kanunlar tarafından emredilenler dışında herşeyin değiştirilebileceğini ve şirketinizin amacının para kazanmak olduğunu lütfen unutmayın. Şirketinizi sebebi unutulmuş, hedefi olmayan işlem ve prosedürlerden kurtarmak sizin göreviniz.

Klasik ölçekler size yetmeyebilir

Şimdi Klasik performans ölçeklerimizi (hepimizin çok kullandığı) bir gözden
geçirelim, bunlar :
Net Karlılık
Yatırım karlılığı
Nakit Akış
Lokal iyileştirme ve maliyet muhasebesi

Bunlar çok global ölçeklerdir ve bir çoğu bizi hatalı yerlere götürebilir. Örneğin bunlara
bakıp teslim tarihlerinizin kısalıp kısalmadığını, darboğazınızın fiyatını, hatta malzeme
maliyetlerinin azalıp azalmadığını bile göremezsiniz.

İşte bu yüzden yeni, farklı ölçeklere ve sorgulama biçimine ihtiyacımız vardır, bunlar:

Süre
Süre varyansı
Katma değer sağlama
Bottleneck – Non Bottleneck
WIP ve Mamul envanteri (hammadde değil)

gibi kavramları içerirler. Her firma ölçeklerini kendi oluşturabilir, ölçeklerimiz yukarıdaki
hedeflere hizmet etmelidir.

Sessiz çoğunluk sizi iktidara getirebilir veya götürebilir, anahtar onların elindedir

Yapılan araştırmalara göre çalışanların %5?i değişime çok açık ve çok isteklidir, bir diğer % 5 ise değişime açık olarak direnir. (Bu oranlar yaklaşık sayılardır).
Geriye kalan %90 ise sessiz çoğunluğu oluşturur, bu grup ne karşı ne de taraftardır, bir köşede kimin galip geleceğini seyretmekte, konuyala pek de ilgilenmemektedir.

İşte çalışmanın başarısı bu büyük grubu harekete geçirmekte yatar. Ancak çoğu firma bu grubu ihmal eder ve istekli gruptan bir kaç kişiyi eğitimlere gönderir ve çalışmanın iskeletini oluşturmak ister.

Neyin, niçin yapıldığının anlaşılmadığı ortamlarda süre uzar, uzayan süre çalışmayı hedefinden uzaklaştırır ve muhtemelen sonu gelmeyen bir proje olarak kayıtlara geçer ve bir gün herkes unutur. Halbuki kaybedilecek zaman yoktur, süratle sessiz çoğunluğu harekete geçirmeli, sistemin parçası haline getirmelisiniz.

Aman, kısır döngülere dikkat

Üst yönetim desteklemiyor & çalışanlar katılmıyor kısır döngüsü kırılmalıdır.
Her iki taraf için de, ne yapınca desteklemiş olacakları ve ne yapmayınca engellemiş olacakları açıkça ifade edilmelidir.

Bu tip çalışmalarda üst yönetim yönlendirici ve destekleyici olmalı, bu tavrını çalışanların yetki ve sorumluluklarını arttırarak göstermelidir.

Üst yönetime düşen bir başka görev de örnek olmaktır. Eğer çalışanlar eğitim toplantılarına katılıyor ise üst yönetim herkesten önce orada olmalı, başı çekmelidir.

Ancak yapılan genellikle bunun tersidir, üst yönetim çok meşgul olduğu için toplantılara gelmez; onlar bu çalışma ile düzene sokulması düşünülen işler ile ilgilenmektedir.

Şirketin gelecek 10 yıl?da nasıl çalışacağına karar verilirken içeride olsalar daha iyi olmaz mı ?

Bazen bir katalizör (danışman) gerekebilir

Uzun sürebilecek tartışmalara engel olabilmek ve herşeyi tarafsız bir bakış açısı ile gözden geçirebilmek için uygun ortam yaratılmalıdır. Bunun için prensip olarak iki yol vardır.
* Endüstriyel danışman kullanımı
* Firma içinde çapraz takım oluşturma

Bu sayede, bilindiği varsayılan süreçlerin, kuralların ve prosedürlerin herkes
tarafından gerçekten anlaşılması sağlanmış olur. Aksi takdirde bugünkü düzeninizi
bilgisayar ortamına geçirmekten başka bir şey yapamazsınız, üstelik yıllardır kök
salmış informal düzeninizi (kurtulmak istediğiniz) bilgisayar ortamında
canlandırmak için enerji harcamış olursunuz.

Hiç bir danışman sizin işinizi sizden iyi bilemez, işte bu yüzden önyargısız olarak
sorgulayabilir. Bu sorgulamaya cevaplar üretirken doğruyu gene siz bulacaksınız
ama bazen bir ateşleyici gerekli olabilir.

MRP/ERP çalışmalarının bazı işletmelerde çok kısa bazılarında ise çok uzun sürmesinin ardında genellikle yönetim becerileri veya hataları yatar. İşletme kendi içinde informal sistemi besliyor, yöneticiler de buna göz yumuyor ise
o işletmede sistematik bir yöntemi hayata geçirmek güçtür.

Dünya Klasında Üretici olmak ve sonuçlarından yararlanmak isteyenler bizce mutlaka sistematik yöntemleri izlemeli, kendi içlerindeki entegrasyona çok önem vermelidir, sadece çalıştıkları iş kolunda ?0? rekabet olanlar bir süre daha bu konularla hiç ilgilenmeme lüksüne sahiptir.

URUN_AGACI_SEMINERI

Bu seminer size ERP sistemi içinde ürün ağaçlarınızı nasıl yapılandıracağınıza veya nasıl yapmamanız gerektiğine dair gerçek bir yol haritası verecektir.

Bu seminere niçin katılmalısınız

Ürün Ağacı ERP veya Maliyet Sisteminizin temel bilgisidir, nasıl organize edildiği veya edilmediği sizin yapacağınız çalışmaların başarılı veya başarısız olup olmayacağını belirler. Yıllar sonra geriye dönüp tekrar ürün ağaçlarınızı tartışmaya başlamak yerine uzun sürecek bir işleme tam bilgi ile başlamanız daha iyi olacaktır. Bu seminerde ürün ağaçlarınızın nasıl oluşturulması gerektiğini, kullandığınız veya kullanmayı düşündüğünüz yazılımlarda neleri sorgulamanızın yerinde olacağını bu seminer boyunca izleyeceksiniz.

Seminer Hakkında Daha Fazla Bilgi İçin Tıklayınız >>>

05_gallery_typewriter… Satış mümessilleriniz siparişlerini bir kağıda yazar,
… sonra bu kağıtlar elden ele gezer,
… birileri bunları bilgisayara işler veya hiç işlemez,
… satış mümessiliniz siparişini izleyebilmek için bir yerlere not alır,
… üretim bu siparişi kendi bildiği bir yere yazar,
… malzeme talep formu doldurup satınalmaya verir,
… satınalma bunu bir sipariş mektubuna yazar,
… sonra siparişin termin tarihi değişir …

Tanıdık geliyor mu. Bu size tanıdık gelmiyorsa üretim süreci içinde doldurulan formlara bir bakın; ya da finans bölümünüzün yöneticiler için hazırlamakta olduğu elektronik tablolara bir göz atın …

Bunların hepsi var olan bilginin tekrar tekrar işlenmesidir ve işletmenize herhangi bir özel değer katmaz.

Bu tip işlere ayrılan zaman arttıkça veriminiz düşer. Fakat asıl etkisi yavaşlayan karar süreci ve müşteri hizmetlerinde görülür ve her ikisi de işletmenizin en kritik noktalarıdır.

Bunları yaşamamak için öncelikle entegrasyona önem vermelisiniz. Şirketinizin bütün bölümleri ortak bilgi deposunu kullanabilmelidir.

manuel_islem_cengizpak

Diğer yandan sisteminiz ikinci bir işleme gerek bırakmayan formlar üretebilmeli, bu formlar elektronik olarak bir başkasına gönderilebilmelidir. Aksi takdirde hem bilgiyi işleyecek hem de formları tanzim edeceksiniz demektir.

Şirketinizde bilgisayar kullanımını yaygınlaştırmalı ve iletişim olanaklarını arttırmalısınız. Bugünün işletmelerinde sadece muhasebe bölümünün otomasyonu veya bölümlerin kendi lokal sistemleri ile yaşamaları verimli değildir.

İş yapma prosedürlerinizden gereksiz adımları elimine etmelisiniz, bir adımın gerekli olup olmadığını anlamak için aşağıdaki basit testi yapabilirsiniz :

Yasal olarak yapılması mı gerekiyor ?
Bu işlem sonucu stok azalacak mı ?
Bu işlem sonucu masraf azalacak mı ?
Bu işlem sonucu satış artacak mı ?
Kesin bir müşteri isteği veya beklentisi mi ?

Eğer 5 sorudan hiç ?Evet? cevabı çıkmıyor ise bir daha düşünmelisiniz.

Bu, tipik bir bizim sistemimiz sendromudur. Bu sistem öyle bir sistemdir ki bizden başkası bunu çalıştırmayı beceremez; daha dünyada bunu çözebilecek program yazılmamıştır (keşke böyle olmasa idi daha çok tatil yapabilirdiniz). Gerçekten de işinize uygun bir yazılım bulamamış olabilirsiniz ancak işin mantığının size uygun olmadığını düşünüyor iseniz ciddi problem var demektir. Çünkü bu düşünce biçimi şirketi yeniliklere de kapatacaktır.

Geç Kalma İhtimalini Yok Etmelisiniz

Firmalar zorlanmadıkları sürece yeni yöntem ve iş yapma biçimi arayışına girmez, problemler bıçak kemiğe dayanana kadar göz ardı edilir.  Zorlanma başladığında ise re-engineering / re-structuring gibi doğrusal gelişme yöntemleri gündeme getirilir.  Doğrusal gelişme yöntemleri mevcut durumu biraz iyileştirebilir ancak asıl ihtiyacınız doğrusal olmayan / seviye atlatıcı bir yaklaşımdır, kısacası bir zıplamaya ve başka bir boyuta geçmeye ihtiyacınız vardır.

Diğer yandan sürekli ve küçük adımlar ile iyileştirme yöntemi de düşünülebilir ancak bu yaklaşımın sonuç verebilmesi önünüzde ne kadar zaman olduğuna ve pazarın nasıl bir değişim içinde bulunduğuna bağlıdır.

Örneğin yan tarafınıza bir gross market açıldı ve siz de bakkal dükkanı sahibi iseniz küçük iyileştirmelerin size pek yararı olmayabilir; çünkü gross market onun yaklaşımı ile mağlup edilemez. Dolayısı ile yan dükkanda kalmak istiyorsanız daha radikal olmalısınız.

Peki hangi firmaların geç kalma riski vardır ? Elbetteki gerçekle yüzleşmek istemeyen, performans kriterlerini pazarın yönüne göre yenilemeyen firmalar için ?geç kalmak? kaçınılmazdır.

Başlamak işin yarısıdır

ERP entegrasyonu çok emek isteyen, enerji gerektiren bir çalışmadır ancak zor değildir.

Ama bu tip bir çalışmayı zor hale sokmak istiyorsanız çok kolaydır. Eğer uygulamaya başlamak için herşeyin % 100 tamam olmasını bekler, basit konuları bile günlerce hatta haftalarca tartışır iseniz işiniz güç. Bu tip bir çalışmaya başlamak önemli bir sıçramadır, gerisini ise küçük ama sürekli adımlar atarak gerçekleştirmeniz mümkündür.

stok_yonetimi

Stok yönetimi gerçekten zordur, özellikle de üretim yapan firmalarda. İşin içine üretim katıldığında stok,  çok karmaşık zincirlerin içinde yer alabilir ve izlenmesi oldukça güç olabilir.

Stok yönetiminin güç bir iştir ancak bugünün şirketlerinin elinde son derece gelişmiş bilgisayarlar, eğitilmiş iş gücü vardır. Dolayısı ile bu problemin üstesinden gelmeyi becermelidirler.

stok_yonetimi_cengizpakPeki, bunca teknolojik imkana rağmen işletmeler niçin bu problemleri yaşarlar ?

Bence bunun en önemli sebebi problemle yüzleşilmemesidir.

Bir çok işletme stoklarını sağlıklı olarak izlediğini düşünür; halbuki eğer bir işletmede yukarıdaki problemlerin bir kısmı bile varsa stokları ile problemi var demektir. Problem küçümsenir, örneğin işletmelerdeki en yetersiz bilgisayarlar stokla uğraşanlara verilir. Yöneticilerin konsantrasyonu ufuktaki ?para? üzerine yoğunlaşmıştır, stok ise zaten elde olan bir şeydir.

Halbuki stoklarınızın değeri ?kasanızdaki? para ve çeklerden çok daha fazladır, bunu hayal edebilmek için stoklarınızın olduğu her yerde deste deste para varmış gibi düşünün ve siz nerede ne var bilmiyorsunuz… Ne korkunç değil mi !

Bu problemi çözmek isteyenler aşağıdaki listeyi uygulayabilir :

Stoğu artı veya eksi etkileyen tüm eylemler tek sistem içinde toplanmalı, işlemler oldukları zaman ve yerde kayıt altına alınmalıdır.

Stok sisteminin anlaşılır ve kullanışlı bir kod düzeni olmalıdır.

Ürün ağaçları hatasız olmalıdır.

Sistem herkes tarafından ulaşılabilir olmalı, kayıt doğruluğu sağlanmalıdır. Ufak aksiliklerde bölümler kendilerini kurtarmak yerine sistemi iyileştirerek problemi çözmeli, bilgi adacıklarına izin verilmemelidir (örneğin elektronik tablo programları ile stok takibi yapmak gibi).

Stok, şirketin tüzel kişiliğine ait olduğu sürece izlenebilir olmalıdır.

Bilgisayar yazılımınız izlenmesi gereken detayı içermelidir. Aksi takdirde ikinci, üçüncü yazılımların kullanılması kaçınılmaz bir sonuç olacaktır.