PLM (Product Lifecycle Management) is a software solution that helps organizations manage the entire lifecycle of a product, from its initial concept and design to its retirement. It integrates different functional areas of an organization such as engineering, manufacturing, sales, and marketing to ensure that everyone has access to the same product information, and that the product development process is efficient and streamlined.
PDM (Product Data Management) is a component of PLM that focuses on managing the data and documentation related to a product. It includes tools for version control, collaboration, and data sharing, and it ensures that all stakeholders have access to the latest and accurate product information.
ERP (Enterprise Resource Planning) is a software solution that helps organizations manage their business operations, such as accounting, inventory management, and human resources. It integrates different functional areas of an organization such as finance, manufacturing, sales, and marketing.
MES (Manufacturing Execution System) is a software solution that helps organizations to manage and control the production process. It covers the production planning, scheduling and monitoring, and it ensures that the production process is efficient and aligned with the company strategy.
Overall; PDM, ERP, and MES are different software solutions that help organizations to manage different aspects of their business. PLM is a holistic solution that integrates all these solutions, PDM focus on product data management, ERP on business operations, and MES on the production process.
Üretimde üç domain vardır. 1)Business Domain (ERP), 2) Product Domain (PDM/CAx), 3) ManufacturingDomain (MES). Bu üç domain bir araya gelerek PLM yapısı oluşturlar.
ERP yani BD, satış, malzeme ana verileri, ürün ağaçları, stok, finans/muhasebe ve lojistik gibi temel süreçleri yönetmekten sorumludur. Bu domainin iyi çalışması için iki önemli unsur vardır: 1) doğru ürün ağacı, 2) gerçek zamanlı bilgi girişi (transaction). Ürün ağacı yanlış olur ve üretim sonu kayıtları zamanında ERP’ye girilmez ise MRP doğru çalışmaz, satın-alma ve imalat iş emirlerini doğru çıkaramaz. Planlar yanlış olur, üretimde kısa kalınır, teslimatlar gecikilir, vs.….
PDM/CAx, ürün geliştirme aşamasındaki tüm verilerin üretildiği domaindir. Burada üretilen verilerin (BoM: materials/parts info and manufacturing routing) zamanında ve doğru olarak ERP’ye aktarılması gereklidir. Ancak, PDM ile ERP domainleri arasında entegrasyon yok ise, BoM transferi manuel yapılır ve büyük oranda yanlış/eksik bilgi aktarımı sonucunda MRP istenilen sonucu üretemez, yukarıda bahsedilen sorunlar meydana gelir. O nedenle, O nedenle, PDM – ERP entegrasyonu mutlaka düşünülmesi gereken konuların başında gelmektedir.
Öte yandan, önceleri ERP tarafından yönetilen kalite süreçleri artık yavaş yavaş PDM domainine kaymaya başladı. PDM/Cax yazılımları ile tüm kalite planları ürün geliştirme süreci esnasında yapılabilmektedir. BoM ’un yanında ERP’ye aktarılması gereken bir diğer önemli bilgi ise PDM domain ’inde üretilen kalite planlarıdır.
MES’in temel fonksiyonu PEM (Planning, Execution, Monitoring) olarak düşünülebilir. MRP’den alınan iş emirlerinin imalata yönlendirilmesi ve gerçek zamanlı bilgi girişinin yapılmasını sağlayarak, ERP stok verilerinin sürekli güncel kalmasını sağlamak MES’in temel fonksiyonudur. MRP’lerin doğru çalışabilmesinde MES’lerin rolü önemlidir. MES’lerin de aynen PDM gibi ERP’lerden rol çaldığını da görmekteyiz. Özellikle bakım süreçlerinin artık MES’ler üzerinden yönetilmektedir.
Bu kapsamda, işletmeler artık ERP değil PLM sürecine girmek zorundalar. ERP belki ilk adım ancak diğer iki domaini de dikkate almak gerekiyor.
Bunlara ilave olarak ihtiyaçların doğru tanımlanması (domain expertise), süreci yönetecek yetkin danışmanların mevcudiyeti (PDM/Cax admin, ERP admin) ve işletme karar vericilerinin desteği (leadership) bu sürecin başarıya ulaşabilmesindeki kritik faktörler olarak gösterilebilir.
Yazılımlar bizi kendi ağlarına çekiyor. Çevik olabilmek için etkin bilgi yönetim sistemlerine olan gereksinim her zamankinden daha fazla. Artık, ara çözümler sonuç üretmiyor. Entegrasyon yapmak ve bunun için de her sürecin kendi dinamiklerine uygun, beklentileri karşılayacak yazılım modülleri üzerinden yönetilmesi gerekiyor. İşletmeler kar elde edebilmek için satış yapmak, ciro üretmek ve bu işi verimli yapmak zorundalar. Ancak, özellikle satışın ilk aşamalarındaki yetersiz-eksik-yanlış bilgi iletimi/paylaşımı ya da süreç yönetiminin eş zamanlı olmaması gibi etkenler, işletmelerin istedikleri performansı sergileyememelerine neden olabilmektedir. CRM (Customer Relationship Management) modülleri bu aşamada oldukça önem arz etmektedir. Zira; iş süreçleri pazarlama, fırsat oluşturma ile başlıyor. Yani işin başında, ciro potansiyelinin doğuşunda CRM modülleri yer alıyor.
Şimdi bu konuyu biraz açalım. Ancak, öncelikle işletmenin ciro kanallarının neler olabileceğini tanımlayalım. Bir proje firması olduğumuzu düşünelim. Bu anlamda satış kanallarımız (segment) şu şekilde olabilir.
Proje satış: İçeriğinde en az bir ürün içeren, genelde işletme içinde tasarlanan, üretilen ancak bazı ürünleri dış kaynaklara da yaptırılabilen, üretimden sonra da süreci devam eden ve proje yöneticisi atanması gerektiren siparişler bu kapsama girer. Siparişin alınması aşamasından sonra ‘tasarım – tedarik – üretim – sevkiyat – devreye alma’ iş süreçleri vardır. Proje firmalarının ağırlıklı ciroları bu kanaldan gelir.
Ticari satış: Dışarıdan, bayisi olunan ana tedarikçiden, ürün ya da malzeme olarak alınarak satışı yapılan tek ya da birden fazla ticari ürünün oluşturduğu siparişler bu kapsama girer. Siparişler, ürün/malzeme üzerinde değişiklik yapılmadan geldiği şekilde müşteriye gönderilir. Siparişin alınması aşamasından sonra ‘depo elleçleme – sevkiyat’ iş süreçleri vardır. Proje firmalarında bu kanal da önemli bir ciro unsurudur.
Servis satış. Müşteriler tarafından talep edilen arızi-bakım, planlı bakım, revizyon, eğitim gibi taleplerinin karşılanması için, işletme içinde ya da dışında yapılan tüm garanti içi ya dışı hizmetlerdir. Proje bazlı işletmelerde bu kanal hem ciro hem de müşteri memnuniyeti açısından oldukça önemlidir.
Mühendislik hizmeti satışı. Herhangi bir üretim çıktısı olmayan, mühendislik hesaplamaları (CAx), yazılım hizmetleri, danışmanlık gibi konuları içeren hizmetlerdir.
Bu kanallar elbette farklılık gösterebilir. Ancak, proje bazlı işletmeler nereden para kazanıyor sorusuna cevap olarak en genel anlamı ile satış kanalları bu şekilde tanımlanabilir.
Şimdi, CRM sürecinin içeriğine bakalım. CRM süreci genel olarak üç fazdan oluşur: 1) Fırsat, 2) Teklif, 3) Sipariş. Her fırsatın bir teklife, her teklifin de bir sipariş kazanma olasılığı mevcuttur. Fırsatların teklife, tekliflerin siparişlere dönüşme oranı CRM sürecinin ya da satış/pazarlama süreçlerinin ne derece etkin yönetildiği belirler. Şimdi bu süreci biraz açalım.
Fırsat, potansiyel satış olasılığı demektir. Hangi müşteri ya da müşteri adayında ve hangi satış kanalında/kanallarında satış potansiyeli olduğunun CRM sistemine tanımlanması aşamasıdır. Her satış fırsat ile başlar, ancak her fırsat siparişe dönüşmez. Bu sonuç işin doğası gereğidir. Ancak, satış ve pazarlama süreçlerinde ne efor harcanıyor ne kadar doğru planlama yapılıyor ya da pazarın beklentileri ne kadar doğru anlaşılıyor gibi sorulara cevap vererek, işletme satış stratejisini daha rekabetçi kurgulayabilmek için CRM veri tabanlarından elde edilen bilgiler oldukça önem taşır. Zira, CRM’e tanımlanan her müşteri sistemde bir iz bırakır ve bu izler bize fırsatın satışa nasıl dönüştüğü ya da neden dönüşemediği hakkında önemli ip uçları verir. Fırsat sürecinde ana hedef, potansiyel satış olasılığını bir sonraki aşamaya yani teklif aşamasına geçirebilmektir. Bu amaç doğrultusunda potansiyel müşterilere düzenli ziyaretler ve bilgilendirmeler yapılarak, müşteri tarafında ihtiyaç oluşturulmaya çalışılır. Tüm faaliyetlerin, aktivitelerin planlanması ve yönetilmesi süreci CRM üzerinden yapılır.
Teklif, potansiyel fırsatın sipariş dönüştürülebilmesi için gereken bir sonraki adımdır. Müşteri probleminin anlaşılması, uygun çözümün geliştirilmesi ve çözümün teklif olarak müşteriye sunulması bu aşamada gerçekleşir. Proje firmalarında bu süreç oldukça uzun ve meşakkatlidir. Saha incelemesi (survey), ön mühendislik çalışması gibi satış bölümümün tek başına yapamayacağı bazı faaliyetler içerebilir. Bu kapsamda, mühendislik – üretim – tedarik gibi bölümlerden destek alınması, bu destek taleplerinin ve talebe karşılık yapılan tüm işlemlerin, yani tüm bilgi akışının CRM üzerinden olması gereklidir.
Teklif hazırlama bazen oldukça uzun ve hataya oldukça açık bir süreçtir. Teklifin hatalı, geç ya da eksik verilmesi olası siparişin kaybedilmesine dahi yol açabilir. CRM sistemlerinde otomatik teklif hazırlama şablonları bu aşamada oldukça işe yarar. Her satış kanalı (segment) için daha önceden hazırlanmış şablonlar kullanılarak teklifler hızlı bir şekilde oluşturulabilir, tekliflerde yapılan revizyonalar düzenli bir şekilde saklanabilir. Benzeri şekilde ürün konfiguratörü üzerinden modüler ürün teklifleri çok daha kolay hazırlanabilir ya da müşteri finansal risk öngörüsü hakkında bilgiler CRM ortamından alınabilir.
Teklifin sondan bir önceki aşaması sözleşme sürecidir. Bu süreçte dikkat edilmesi gereken en önemli aşama burasıdır. Çünkü, bu aşamadan sonra tüm süreç müşteri ile yapılan sözleşme koşullarına göre ilerler. Sunulan çözümün teknik olarak müşteri tarafından onaylanması, proje kabul onay süreci, müşteri ve işletmenin bu süreçteki ayrı ayrı yükümlülükleri, ödeme koşulları gibi konuların net olarak tanımlanması gerekir. Birçok proje firmasında özellikle bu alanda görülen eksikliklerin ciddi sorunlara yol açtığını gözlemliyoruz.
Teklifin son aşaması müşteri onayı sürecidir. Müşteri tarafından verilen onay sonrasına teklif kesin siparişe dönüştürülür.
Sipariş kesinleştikten sonra satış bölümünün işi bir bakıma bitmiş, fırsat siparişe dönüşmüştür. Artık, siparişin karşılanması için gerekli sürecin bir an önce başlatılması gerekir. Bu aşamada sipariş içeriği ile ilgili ayrıntılı bilginin satış bölümü tarafından proje ekibine aktarılması, proje master planının genel hatları ile hazırlanarak müşteriye sunulması gerekir. Artık, sipariş ile ilgili müşterinin ana muhatabının proje yöneticisi olduğu bilgisi, master proje planı ile müşteriye bildirilmelidir. Burada şu ayrımı yapmak yerinde olacaktır. Satış yapmak ile proje yönetmek farklı süreçlerdir. Satışın görevi ihtiyaç oluşturmak, sipariş almak; projenin görevi ise alınan siparişi hedefler dahilinde gerçekleştirmektir. O nedenle, birçok işletmede satış sonrası ‘handover’ toplantıları üzerinden sipariş proje bölümüne ayrılır ve bu aşamadan sonra tasarım – tedarik – üretim – sevkiyat – kurulum süreçleri proje yöneticisinin kontrolünde yürütülür.
CRM verileri sistemdeki ilk anlamlı verilerdir. Sürecin geri kalanı buradan çıkan veriler üzerinden yönetilir. Tüm sistemin tek bir yerden beslenmesi, kararların doğru ve hızlı alınabilmesinin önünü açar, işetmeye rekabet avantajı sağlar. Bu kapsamda, CRM sürecini daha etkin yönetebilmek için strateji geliştirin ve uygulayın derim.
Üretim süreçlerinde VSM (Value Stream Mapping) yaparken öncelikle iki ana konuya bakılır. Malzeme akışı, bilgi akışı. Malzeme, süreçlerde akarak yarı mamule; daha sonra da mamule dönüşerek müşteri ile buluşur. Ancak, bu işlemin gerçekleşebilmesi için sipariş, ürün ağacı, teknik dokümanlar, makine programları gibi birçok bilginin üretilmesi/türetilmesi ve ilgili fonksiyonlar ile doğru/zamanında paylaşılması gerekir. Bu işlemlerin manuel yapılması bilgiyi arama, bilgiyi bekleme veya bilgiyi yeninden üretme gibi işletmenin çevik olmasını engelleyen sonuçlara neden olur. Çeviklik için etkin bilgi yönetim sistemi, bunun için de sistemler arasında entegrasyon kurulması gereklidir.
İşletme içinde dikey, tedarik zincirinde yatay entegrasyon konusu ‘Dijital Tabanlı Yalın Dönüşümün’ (DBLT) esasını teşkil eder. İşletmelerin gündemi şu aralar dikey entegrasyon, yani PDM-ERP-MES sistemlerinin birbirleri ile etkileşime geçebilmelerine olanak sağlayan bilgi yönetim sistemini (IT integration) kurabilmek. Ancak, bu gereksinimi tek başına sağlayan bir çözüm henüz mevcut değildir. İşletme gereksinimlerinin değişken olması, her süreçte farklı yazılımların kullanılması bu sonucun sebepleri arasında gösterilebilir.
Literatürde birçok çalışmada, etkin bilgi yönetimi sistemi kurabilmek için işletmelerin kendi amaç ve beklentileri doğrultusunda özel entegrasyon tasarımı/modeli geliştirmeleri ve geliştirilen modeli süreçlerine uyarlamalarının gerekliğine vurgu yapılmıştır. Yani, önce kurgu/kavramsal tasarım akabinde uyarlama. Zira, bir bina/köprü ya da baraj önce tasarlanır sonra yapılır.
Bu bağlamda, bilgi yönetim sisteminin doğru kurulabilmesi için iki bileşenin bir araya gelmesi gereklidir.
Model geliştirecek MİMAR (domain knowledge / architect),
Modeli uyarlayacak MÜHENDİS (software developer /engineer).
Endüstri 3.0’ın ön koşulu olan ERP devreye alma süreçlerinde son zamanlarda eskiye oranla önemli artışlar gözlemliyoruz. Birçok işletme ya sıfırdan ERP kuruyor ya da daha önceleri kısıtlı alanlarda kullandıkları ERP’lerine yeni modüller ekliyorlar. Bu durum hem hizmet verilen hem de alınan tarafta yetkin iş gücüne olan ihtiyacı her geçen gün artırıyor. Zira, ERP süreç danışmanı ve işletmedeki ERP proje yöneticisinin konuya hakimiyeti, ERP projelerin başarılı olabilmesi açısından son derece önemli iki faktör. Bu alanda sektörde önemli boşlukların/ihtiyaçların olduğunu ve genç arkadaşlara bu alana yönelmelerini tavsiye ederek asıl konumuza girelim: ERP kurulum sonrasında neden istenilen sonuçlara (büyük oranda) ulaşılamıyor?
Bu konu üzerine literatürde ya da gerçek hayat deneyimlerinde birçok değerli görüş/yorum mevcut. Ancak, ben kendi gözlemlerimi sizlerle paylaşmak istiyorum. Konumuz ERP seçimi değil; ERP kurulumundaki başarısızlıkları finansal (evdeki hesap çarşıya uymaması) ve fonksiyonel (dağın fare doğurması) açıdan tartışmak.
Proje ile dönüşüm farklı kavramlardır. Projelerin başlangıcı ve sonu, dönüşümün ise sadece başlangıcı vardır. ERP süreci, sizi dönüşüme sokacak bir projedir. Yani, başlangıcı/bitişi ve bununla ilintili olarak ‘kalite, maliyet ve zaman’ performans endeksleri mevcuttur. İyi bir proje yönetiminde bu üç endeksin planlananı ile gerçekleşeni arasında çok fark olmaz. Ancak, ERP projelerinde bu duruma oldukça az rastlanılır. Maliyetler şaşar, zaman uzar, kalite (fonksiyonalite) beklentiyi karşılamaz.
Bu durumun birçok alt nedeni vardır ancak kök neden analizi yaptığımızda ana etkenin işletmedeki karar vericilerin bilgisizliği olduğunu söyleyebiliriz.
Neden mi? Açıklamaya çalışalım…
ERP projelerine başlamak Katolik nikahına benzer. Bir kere karar verildiğinde geri dönüş öyle kolay değildir. O nedenle işi başından sıkı tutmak ve ne istediğinizi/karşıdan ne alacağınızı iyi bilmek durumundasınız. Hemen hemen birçok ERP proje sürecinde, artık klasik! haline gelen kavramsal tasarım süreci vardır. Bu öyle bir süreçtir ki, ERP firmasının danışmanları ile tüm işletme bölümleri arasında haftalarca hatta aylarca toplantılar, analizler yapılır ve süreç sonunda genelde pek de anlaşılmayan bir rapor ile karşı karşıya kalını verilir. Bunca zamanın karşılığı bu muydu diye kendinize sormaya başlarsınız. İşin gerçeğinde, siz ne isterseniz isteyin birçok ERP firması sonuçta size yapabildiğini ya da bütçe dahilinde yapmak istediğini sunar. İstisnalar elbette vardır, ancak bir kere anlaşma yapılmıştır ve kopabilmek öyle kolay değildir.
Kavramsal taşarım aşaması aslında müşteri beklentilerinin tam olarak anlaşılması ve anlaşılan konuların ERP’ye uyarlanması için yapılacakların belirlenmesi sürecidir. Temel beklenti, bir daha soru sorulmaya gerek kalınmadan projenin antat kalınan taslak üzerinden ilerletilebilmesidir. Her modül için farklı danışmanlar gelirler, konuşurlar, yazarlar ve sizden aldıklarını rapor olarak size sunarlar! Peki gerçekte bu kadar efora/zamana cidden gerek var mıdır? (Çok özel süreçleri olan işletmeleri bu kapsam dışında tutuyorum ki 3-5% yi geçmez bu oran).
Peki ne yapmak gerekiyor? Bir bakalım…
Derim ki; bu süreci kendiniz öncesinde yapın. İçeriden bir ekip kurun ve başına bu işi yönetecek/konuyu bilen birini atayın; böyle biri yoksa mutlaka birini işe alın. Bu kişi (ERP Proje yöneticisi) hem işletme içi kavramsal analizi hem de ERP proje sürecini yönetecek nitelikte olmalıdır. ERP projesine / seçimine başlamadan en az 3-4 ay önce bu işe başlayın ve kendi kavramsalınızı kendiniz oluşturun.
Kavramsala doğru soruları sorarak başlayın: İlk soru ‘ciromuz nereden geliyor (segment)?’ olmalıdır. Her segmentin iş akışı, dinamikleri birbirinden farklıdır. Ticari al/sat segmenti, sipariş-üretim segmenti / sipariş-tasarım segmenti ya da proje yönetimi segmenti farklılıklar gösterir. Klasik olarak, segmentler ‘teklif – sipariş – tedarik – üretim – lojistik – devreye alma – tahsilat süreci’ gibi adımları izlerler. Bazı segmentler tamamını, bazıları ise bir kısmını. Burada düşünülmesi gereken ana konu MIFA (Material Information Flow Analysis) konseptidir. Malzemenin ve bilginin nasıl aktığı, süreçler arasında nasıl etkileşim/iletişim olduğu gibi konuların segment bazında detaylı düşünülmesi ve akışa uygun bir şekilde tasarlanması gerekir. Ana veriler konsepti de bu aşamada önemlidir (malzeme ana verileri, müşteri/tedarikçi ana verileri, ürün ağacı/reçete yapısı, kalite planları, ürün geliştirme süreci, proje yönetimi, temel raporlama/analiz gereksinimleri, maliyetlendirme modelleri, vs.,). Süreçlerinizi AZ’ye önce kendiniz tanıyın, ihtiyaçlarınızı iyi belirleyin, ekibinizi eğitin ve işletme içinde farkındalığı/bilinç seviyesini artırın (standart). Kolay değildir bu süreç ancak daha sonradan yapmaktan çok daha faydalıdır/kazançlıdır. Bu sayede hem kendi iş akışlarınızı daha iyi anlamış hem de karşı tarafa sunabileceğiniz net bir dokuman (kendi kavramsal tasarımınız) hazırlamış olursunuz herhangi bir lisans ve danışmanlık ücreti ödemeden. Unutmayın ERP lisans ve danışmanlık ücretleri anlaşma sonrası hemen başlar! Oysa, bu süreci kendiniz yaparsanız hiçbir ERP firmasına ödeme yapmadan kavramsal tasarım sürecini geçmiş olursunuz. Bu adımın hem maliyet hem de zaman açısından size oldukça önemli getirisi olacaktır.
Bahsettiğim gibi bu süreci bir başkasına değil, kendiniz yapmalısınız. Bilmiyorsanız, önce öğrenmeniz ve sonrasında yapmanız gerekir. Cehaletin bedelini ödememek için bu işi taşere etmeyin; öncelikli işiniz bu olsun.
Bu çalışmanın tamamlanması akabinde artık ERP firmaları ile görüşmeye hazırsınızdır. Yaptığınız çalışmayı ERP seçiminde/teklif isteme sürecinde ‘işte biz bunları istiyoruz ne bir eksik ne de bir fazla’ diye firmanın önüne koyun ve buradaki isteklere göre teklifleri değerlendirin.
Buraya kadar konuştuklarımızı şöyle özetleyelim.
ERP proje yöneticiniz mutlaka olsun,
Herhangi gibi ERP firması ile görüşmeden önce kavramsal tasarımınız hazır olsun.
Tabi bu işin bir de teklif toplama/değerlendirme süreci vardır. Genelde, sohbet tarzında ve beklenti/umut vaadi şeklinde geçen tanışma toplantılarında birçok konu havada kalır (ortada net bir dokuman olmadığı durumlarda). Defalarca konuşulur, görüşülür ve nihayetinde bir teklif gelir. Ancak, teklif oldukça geneldir. Çünkü tam olarak istenilenler incelenememiştir teklif veren tarafından. İçeriğinde birçok gri alan vardır daha sonradan beyaza ya da siyaha kayabilecek. İşte bunu engellemek için ilk kısımda bahsettiğimiz kavramsal tasarım süreci oldukça işe yarar.
Şimdi gelelim maliyet konusuna. Evdeki hesap çarşıya uymadı sorunu ile karşı karşıya kalmamak için bu aşamada da proje yöneticisine ihtiyacınız var. ERP projesinin gerçek maliyetini anlayabilmek ciddi uzmanlık gerektirir. Zira, lisanslama maliyetlerinin oldukça karmaşık olması, ileride oluşabilecek gereksinimlerin maliyetlere nasıl yansıtılacağının net aktarılmaması, müşteri istek ve beklentilerinin hangisinin standart hangisinin geliştirmeye gireceğinin tam tanımlanmaması, entegrasyonları nasıl ve ne seviyede yapılacağı veya ERP firması satış sorumlusunun hizmet alacak işletmenin gerçekte ERP projesini yapabilme kabiliyetin olup olmadığının hiç sorgulanmaması gibi konulardan türeyen problemler süreç sonunda beklenti ile gerçekleşen anlamında (hem fonksiyonel hem de finansal) ciddi farklılıklar meydana getirir ve bu sonuç daha sonradan oldukça baş ağrıtır. Müşterinin (yani sizin) yeterince konuya hâkim olmaması (cehaletin bedeli), hizmet verenin işi bir şekilde bağlamak istemesi nedeniyle tüm gerekenleri açıklamaması (ciro elde etme isteğinin ön plana çıkması) ya da müşteri gereksinimlerinin tam anlaşılamaması (bilgisizlik) gibi unsurlar bu sonuca etken olarak gösterilebilir. Bu gibi durumları çokça gözlemliyoruz.
ERP projeleri maliyetlidir ancak literatürde bu maliyetin gerçekte ne olması gerektiği ile ilgili, herkes tarafından kabul görmüş örnek bir çalışma yoktur. Gelen firmanın insafına, satış döneminin zamanına, sizin beklentilerinize ya da size sunulanlara göre çok değişir maliyetler.
Lisans maliyetleri, ki türlü türlü çeşidi vardır (bazen satan kişiler dahi aralarındaki farkı bilmez), tam bir muammadır. Kullanıcı sayısının belirlenmesi ile lisanslama maliyetinin biteceğini sanmak büyük bir yanılgıdır. ERP haricinde kullanmanız gereken diğer yazılımlar, o an için aklınıza hiç gelmeyen ancak ileride gereksinim olabilecek birçok konu için de lisans maliyetleri vardır. Örneğin, ileride bir portal üzerinden müşterilerinizin sipariş girmelerini ya da IoT ready ürünlerinizden ERP’ye bağlantı yapmak istediğinizde lisans maliyetleri bu durumdan nasıl etkilenir? Bir sorun bakalım teklif veren ERP firmasına.
Entegrasyon konusu bambaşka bir konudur. Bazı ERP’ler her modülü içer(e)mez, ya da içerse dahi işletme o alanda başka yazılım kullanmak isteyebilir. Bu bağlamda ERP modülleri içinde yer almayan farklı birçok programın ERP’ye tek tek entegre edilmesi kolay bir süreç değildir. Teknik olarak her yerden her yere tek ya da çift taraflı entegrasyon yapılabilir. Ancak, buradaki soru entegrasyonun hangi detayda, kim tarafından yapılacağı ve bunun maliyetlere dahil olup/olmadığıdır.
Danışmanlık adam gün sayıları ayrı bir tartışma konusudur. Aynı proje için kimi firma 300 adam gün kimi ise 1000 adam gün danışmanlık önerir. Nasıl hesaplanır bu adam günler, nedir bu işin sırrı benim pek aklımın almadığı konular. Zira, bu konuda da literatürde herkes tarafından kabul görmüş bir çalışmaya da rastlanılmamıştır.
Donanım maliyetleri kısmen daha anlaşılırdır.
Bu bağlamda, ERP değerlendirme toplantılarına mutlaka konunun uzmanı ile girin. Yapabiliyorsanız; bu süreci, konu hakkında uzman birini işe alarak yapın (ki doğrusu budur); keza projeyi yönetecek kişinin en başında sürece dahil olması her açından faydalıdır. Ancak, o an için bu mümkün değilse mutlaka bir danışman ile anlaşın. Ne istediğinizi iyi çalışın (ilk kısımda konuştuklarımız: Proje yöneticisi ve kavramsal tasarım). ERP firmasından, ileride oluşabilecek olası isteklerinizi de göz önünde bulundurarak beş yıllık nakit akışı projeksiyonu isteyin (özellikle ekstra lisans maliyetlerinin neler olabileceğini iyi anlamak gerekir) ve teklifteki her detayı enine/boyuna iyice sorgulayın. Süreç anlaşmanızda hiçbir gri alan ortada kalmasın. Unutmayın; gri beyaza da gider siyaha da!
Özetlemek gerekirse karar verici olarak şu unsurları dikkate alarak sürece başlamalısınız.
ERP sürecine önce kendiniz başlayın. Bir proje yöneticisi alın, gerekirse danışmanlık ile destekleyin ve kendi kavramsalınızı tanımlayan net bir doküman hazırlayın (MIFA). Bu süreç size çok şey katacaktır – ERP almasanız dahi asla boşa gitmez.
Teklif toplama / değerlendirme süreçlerinde, eğer yukarıdaki adımı yaparsanız danışmanlık adam günlerinde önemli azalma olacaktır. Daha kısa zamanda uyarlama sürecine geçilecek ve bu sonuç size zaman, maliyet ve kalite olarak geri dönecektir.
ERP lisans maliyetlerini, ERP danışman yetkinliğini mutlaka sıkı sorgulamak gerekir. ERP projesinin iyi sonuçlanması hizmet veren firma ERP proje yöneticisinin yetkinliğine, deneyimine son derece bağlıdır. İyi bir proje yöneticisi, işletme içinde kendisi ile birlikte süreci koordine edecek karşılığı olmadan ve hatta bu kişiyi sınamadan sürece başlamaz; bekler. Çünkü, eğer işletme içinde yetkin bir ERP proje yöneticisi yoksa gösterilecek çabanın büyük oranda boşa gideceğini bilir. Eğer işletme içinde böyle birisi henüz yoksa ve ERP sürecini proje yönetici başlatmak istiyorsa, siz durun ve sürece başlamayın. Önce, sizin adınıza süreci yönetecek yetkin birini bulun, sonra başlayın.
Yapay zekâ çağında, bir önceki dönemim standardı olan ERP olmadan işletme dinamikleri işleyemiyor ve şekillenemiyor. Veriyi üretme, saklama ve kullanma süreçlerinde ERP’ler anahtar rol üstleniyor. Ülkemiz geneline bakıldığında bu alanda oldukça fazla sayıda projenin yapılacağını tahmin etmek hiç de zor değil. Bu bağlamda, özellikle genç arkadaşlarıma bu alana da ilgi duymalarını / yönelmelerini tavsiye ederim.
Transformation (dönüşüm) ve flow (akış) her daim bilimin üzerine çalıştığı konuların başında gelmiştir. Isı, elektrik, kütle transferi derken, şimdiler de ise ana konumuz bilginin transferi ya da iletimi (information flow).
Dijital dönüşümde ERP’nin önemi yadsınamaz ancak, sanki şu aralar, özellikle proje tarzı imalat yapan işletmeler için yeni/alternatif çözüm modelleri de çıkıyor gibi. Business – Product – Manufacturing segmentleri arasında artık başka yöntemlerle de bilgi iletimi (connectivity & inter-operability) sağlayabiliyoruz.
Product segment yazılımları (CAx) ve üretim yönetimi yazılımları (MES/MOM) kendi platformlarında connectivity ve inter-operability sağlayarak, sanki ERP’nin bazı fonksiyonlarını üzerlerine almaya başlıyorlar gibi. Örneğin, product segment tarafında yeni yeni uyarlanmaya başlanan PDM/PLM süreç entegrasyonları ile uçtan uca temel süreçleri birbirine bağlayabiliyor, CPS için gerekli olan IT omurgasını tek bir platform üzerinde kurgulayabiliyorsunuz. Benzer şekilde MES/MOM lar üzerinden de planlama, kalite, bakım gibi temel fonksiyonları entegre ederek OT tarafında entegrasyon sağlanabiliyor. ERP ise kaynak planlama, tedarik, malzeme, maliyet ve lojistik gibi temel iş süreçlerinin yönetimine odaklanıyor.
ERP’nin fonksiyonlarının azalması, entegrasyon sorunlarını ortadan kaldıracak ve de dönüşümün daha da hızlı olabilmesine olanak sağlayacak gibi görünüyor. Özelikle, proje bazlı imalat yapan Kobiler için ERP kurulumunun büyük sıkıntı olduğu şu dönemde, IT&OT entegrasyonu PDM/PLM ve MES/MOM entegrasyonu ile yapılarak, süreçler arasında önemli oranda entegrasyon sağlanabilmesi, belki de yakın zaman içinde product segment yazılım üreticilerinin henüz içine giremedikleri diğer ERP fonksiyonlarını da içine alarak, uçtan uca tam entegrasyonu sağlamaya itecek gibi duruyor.
