SAP PM modülü, R/3′e geçildiğinden beridir merkezi işlevleriyle hemen hemen aynıkaldı. Elbette WCM gibi, Maintenance Event Builder gibi, Refurbishment Ordergibi pek çok yenilik yavaş yavaş eklendi. Ama merkezi çatı aynı kaldı.
Bazı işlevler pek kullanılmadı. Örneğin Installed Base, ObjectNetworking ve en önemlisi WCM gibi. Kullanılmama veya kullanılamama sebepleri arasında elbette pek ihtiyaç olmaması gibi (mesela Installed Base veya ObjectNetworking), bazen de ihtiyaç olduğpu halde çözümün karmaşıklığı nedeniyle kullanılamadı ya da çok az firma tarafından kullanıldı (WCM gibi). Bazen sadece entelektüel bir haz verdiği için denediğimiz ama hemen hiç bir endüstrinin kullanmaya cesaret edemediği işlevler de oldu, Configurable Task Lists gibi.
Bu süreçte, elbette dünyada reaksiyoner bakım ya da düzeltici bakım (corrective maintenance) yerini yavaş yavaş koruyucu (preventive) ve hatta şimdilerde proaktif bakım stratejilerine bıraskmaya başladığından SAP PMde o yönlere daha çok yatırım yaptı. Pekiyi ama, bundan sonra nereye doğru ilerleyecek SAP PM? Bu soruyu elbette kehanette bulunmak için sormuyoruz. Dünyadaki trendlerin bize belki bir parça fikir verebileceğine inanarak,futurology modasına pek kulak asmadan, bir analiz yapmaya çalışacağız.
Bakım ve Onarımda Yeni Eğilimler:
RCM ve FMEA gibi savunöma sanayiinden türemiş yöntemler pek hızlıca olmasa da digger endüstrilerce uygulanmaya başladı. Pek hızlıca değil çünkü bu yöntemler en az 50 yıldır savunma sanayinde mevcuttu. Ama diğer endüstrilerde kullanılan ekipmanlar, savunma sanayindeki kadar pahalı ve komplike olmadığından, pek de genel geçer çözümler olarak yaygınlaştırılıp kullanılmadı. (Elbette otomotiv devleri, uçak firmaları ve madencilik sektörü bu çözümleri ilk kullananlardan oldu. Uçaklar için çoğunlukla uçak bakımcıları farkında olmasalar bile, FMEA temelli analizler yapılmakta. Bunların gelişmiş ve paraya kıyabilmiş olanları, RCM’i de işin içine sokuyorlar.)
Ama şimdi cihazlar gittikçe komplikeleşti, üretim süreçlerinde kayıplar daha katlanılmaz oldu (Malumunuz rekabet denen çıldırtıcı hastalıktan dolayı!) Üstüne üstlük arızalar maliyetli cihazlar ise aşırı pahalı hale geldi. Arızanın maliyetinin sadece onarım maliyeti olmadığı, yıllardır bakımcıların söylediği bir şeydi, nihayet anlaşıldı. Bir arızanın üretim, satış ve itibar kaybından tutun, çevre felaketlerine ve can kayıplarına yol açabilen ciddiyetlere.sahip olabildiği ve risk yönetimi kapsamında ele alınması gerektiği anlaşılmaya başlandı. İşte arızaların azaltılması ve üretim kayıplarının sınırlandırılması bakımından RCM ve FMEA önemli olanaklar sağladı insanlara. Ancak malumunuz, SAP’nin bu konuda bir çözümü yok. Ama Meridiıum, IVARA,Reliasoft, Isograph, RCM Turbo gibi bir sürü ürün piyasada dolaşımda. Bunların bazıları SAP ile standart entegrasyonları olduğunu söylüyorlar. (Bu konuda dededen kalma şüpheciliği elden bırakmayın deriz biz. Standart denen entegre çözümlerin içerikten bağımsız, sadece birer linkten ibaret olmadığından emin olsun. Sizin kullanmakta olduğunuz SAP PM çözümü ile bahsedilen entegrasyonun gerçekten de entegre olabildiğinden emin olun. Örnek mi? Bu firmalar çoğunlukla olayıbasitleştirerek anlatırlar size ama RCM failure mode temelli işler. Yani klasik RCM. Acaba sizin bildirimleriniz failure mode temelli bildirimler mi? Acaba sizin tarihçeniz ve mevcut uygulamalarınız gerçekten de verimli bir RCM uygulamasına elverişli mi? Bu konuya daha önce de değindik. RCM system ve alt-sistemlere yönelik bakım stratejisi belirler. Sizin ana verileriniz buna gore oluşturulmuşmu? Kodlamalarınız yeterli detayı içeriyor mu? Siz iyisi mi Moubray’in kitabına bir kez daha göz atın.
İşte tam da bu ihtiyaçlarda ötürü, ve bakım denen şeyin içeriğine daha çok riskler alınmaya başladığından, eskiden öldüklerinde rahmet okunan çalışanların artık yaşamlarının değerli olduğuna pek çok firma ikna olduğundan, SAP bu alanda yenilikler getirmeye başladı ve devam da edecek. Bizce PM ve GRC entegrasyonu genişletilecek. Workers Safety ile WCM ile elde edilemeyen işçi temelli risk yönetimi de devreye girmeye başladı.
Cihazların konfigürasyon yönetimi, SAP’nin savunma sanayi için hazırladığı bir çözümde mevcut. Bu çözüm yavaş yavaş digger sektörlere de yaygınlaştırılıyor. Maintenance Event Builder, IE4N gibi bir kaç savunma kökenli yenilik buralara girmeye başladı. Cihazların bakımı komplikeleştikçe, konfigürasyon yönetimi, PM-ippe entegrasyonu için de SAP yatırım yapacaktır ve mevcut işlevleri, digger endüstrilere de yaygınlaştıracaktır.
Ana Veri:
Ana verilerdeki karmaşıklık artık LSMW gibi ana very yaratma araçlarını yetersiz kilmaya başladı. Pek çok firma Winshutte gibi alternatifler kullanıyor. SAP ya LSMW’yu geliştirecek ve detaylandıracak, ya da Winshuttlebenzeri bir ürün geliştirecek. Terminlemede bunu yaptı zaten. MRS çözümü bir süredir Prometheus, Prievera ya da MS Project ile SAP’yi entegre eden çözümlere rakip olarak doğdu. SAP PM, PP ve PS’in en zorlanan noktalarından biri olanterminlemede böyle bir adım attılar Sanıyoruz ana veride de bunu atacaklar ki hafiften atılan adımlara dair sesler geliyor.(MDM, Data Services vs.)
Ana veriler iiçin toplu değiştirme işlevleri de geliştirildi malumunuz ama hala eksik olan, misal üzerinde 1000 tane planlı bakım olan bir ekipman kopyalandığında bakım planlarını kopyalayamamanız… Bu özellikle komplike ekipmanlar için elzem. SAP bu konuda da adımlar atacak ki buna dair izler de savunma çözümlerinde belirmeye başladı gibi.
Pool Asset Management:
Porsche için yapılan bu geliştirme, artık merkezi bir işlev olarak kullanıma hazır. Ama henüz emekleme aşamasında çünkü uyarlama tablolarıacemi ABAPçıların bile yapmayacağı türden gediklerle bezeli. Aletlerin kapasiteleri planlanabiliyordu, hatta biraz teknik bir detay ama aynı alet bakıma girdiğinde mevcut kullanılabilir kapasitesi de düşebiliyordu. Ama bir alet bir kişiye belli bir periyot için zimmetlenemiyordu. PAM bu iş için geliştirildi. Ama PAM’in eksik kanadı, yukarıda bahsettiğimiz bir aracın bakıma sokulması durumu… Bu henüz göz önüne alınmamış. Ha bir de bahsettiğimiz korkunç uyarlama tabloları da düzenlenecektir belli ki.
İşYerleri
Artık pek çok firma iş yerleri ile HR verilerini entegre etmeyi öğrendi. Ama burada da eksikler var. Misal kapasite sayısı ile iş yerine bağlıHR personeli sayısında bir otomatik entegrasyon yok. Bunu yapmak için geliştirmeler kullanılıyordu, ama sanıyoruz burada da bir ihtiyaç olduğu ortaya çıkmaya başladı.
Projeler
SAP PM ve SAP PS modülleri epey zamandır içli dışlı oldular. Ama SAP PM – PPM ilişkisi hala çok netlemiş değil. Arada mutlaka projeler olmasıgerekiyopr. Bu ilişki de daha netleşecek gibi görünüyor. Inspection Roundsişlevi ile illa da proje yaratmaya gerek kalmadan komplike bazı bakım işlemleri yapılabiliyor artık. Her daim proje yaratmadan belki direct PPM ile ya da bütçeleme ile ilişkilenecek çözümlere bakılacaktır. (Malum, PM için pek çok bütçeleme çözümü var. Ama bütçe kontrolü sadece PM-PS entegrasyonu ile yapılıyor. Bunun için de illa projelendirmeler gerekiyor. Oysa bütçe adımları, proje WBS’leri yerine daha sabit birer sepet halinde ele alınıyor malumunuz. SAP’nin bunu da göz önüne alacağını düşünüyoruz.
Bazı işlevler pek kullanılmadı. Örneğin Installed Base, ObjectNetworking ve en önemlisi WCM gibi. Kullanılmama veya kullanılamama sebepleri arasında elbette pek ihtiyaç olmaması gibi (mesela Installed Base veya ObjectNetworking), bazen de ihtiyaç olduğpu halde çözümün karmaşıklığı nedeniyle kullanılamadı ya da çok az firma tarafından kullanıldı (WCM gibi). Bazen sadece entelektüel bir haz verdiği için denediğimiz ama hemen hiç bir endüstrinin kullanmaya cesaret edemediği işlevler de oldu, Configurable Task Lists gibi.
Bu süreçte, elbette dünyada reaksiyoner bakım ya da düzeltici bakım (corrective maintenance) yerini yavaş yavaş koruyucu (preventive) ve hatta şimdilerde proaktif bakım stratejilerine bıraskmaya başladığından SAP PMde o yönlere daha çok yatırım yaptı. Pekiyi ama, bundan sonra nereye doğru ilerleyecek SAP PM? Bu soruyu elbette kehanette bulunmak için sormuyoruz. Dünyadaki trendlerin bize belki bir parça fikir verebileceğine inanarak,futurology modasına pek kulak asmadan, bir analiz yapmaya çalışacağız.
Bakım ve Onarımda Yeni Eğilimler:
RCM ve FMEA gibi savunöma sanayiinden türemiş yöntemler pek hızlıca olmasa da digger endüstrilerce uygulanmaya başladı. Pek hızlıca değil çünkü bu yöntemler en az 50 yıldır savunma sanayinde mevcuttu. Ama diğer endüstrilerde kullanılan ekipmanlar, savunma sanayindeki kadar pahalı ve komplike olmadığından, pek de genel geçer çözümler olarak yaygınlaştırılıp kullanılmadı. (Elbette otomotiv devleri, uçak firmaları ve madencilik sektörü bu çözümleri ilk kullananlardan oldu. Uçaklar için çoğunlukla uçak bakımcıları farkında olmasalar bile, FMEA temelli analizler yapılmakta. Bunların gelişmiş ve paraya kıyabilmiş olanları, RCM’i de işin içine sokuyorlar.)
Ama şimdi cihazlar gittikçe komplikeleşti, üretim süreçlerinde kayıplar daha katlanılmaz oldu (Malumunuz rekabet denen çıldırtıcı hastalıktan dolayı!) Üstüne üstlük arızalar maliyetli cihazlar ise aşırı pahalı hale geldi. Arızanın maliyetinin sadece onarım maliyeti olmadığı, yıllardır bakımcıların söylediği bir şeydi, nihayet anlaşıldı. Bir arızanın üretim, satış ve itibar kaybından tutun, çevre felaketlerine ve can kayıplarına yol açabilen ciddiyetlere.sahip olabildiği ve risk yönetimi kapsamında ele alınması gerektiği anlaşılmaya başlandı. İşte arızaların azaltılması ve üretim kayıplarının sınırlandırılması bakımından RCM ve FMEA önemli olanaklar sağladı insanlara. Ancak malumunuz, SAP’nin bu konuda bir çözümü yok. Ama Meridiıum, IVARA,Reliasoft, Isograph, RCM Turbo gibi bir sürü ürün piyasada dolaşımda. Bunların bazıları SAP ile standart entegrasyonları olduğunu söylüyorlar. (Bu konuda dededen kalma şüpheciliği elden bırakmayın deriz biz. Standart denen entegre çözümlerin içerikten bağımsız, sadece birer linkten ibaret olmadığından emin olsun. Sizin kullanmakta olduğunuz SAP PM çözümü ile bahsedilen entegrasyonun gerçekten de entegre olabildiğinden emin olun. Örnek mi? Bu firmalar çoğunlukla olayıbasitleştirerek anlatırlar size ama RCM failure mode temelli işler. Yani klasik RCM. Acaba sizin bildirimleriniz failure mode temelli bildirimler mi? Acaba sizin tarihçeniz ve mevcut uygulamalarınız gerçekten de verimli bir RCM uygulamasına elverişli mi? Bu konuya daha önce de değindik. RCM system ve alt-sistemlere yönelik bakım stratejisi belirler. Sizin ana verileriniz buna gore oluşturulmuşmu? Kodlamalarınız yeterli detayı içeriyor mu? Siz iyisi mi Moubray’in kitabına bir kez daha göz atın.
İşte tam da bu ihtiyaçlarda ötürü, ve bakım denen şeyin içeriğine daha çok riskler alınmaya başladığından, eskiden öldüklerinde rahmet okunan çalışanların artık yaşamlarının değerli olduğuna pek çok firma ikna olduğundan, SAP bu alanda yenilikler getirmeye başladı ve devam da edecek. Bizce PM ve GRC entegrasyonu genişletilecek. Workers Safety ile WCM ile elde edilemeyen işçi temelli risk yönetimi de devreye girmeye başladı.
Cihazların konfigürasyon yönetimi, SAP’nin savunma sanayi için hazırladığı bir çözümde mevcut. Bu çözüm yavaş yavaş digger sektörlere de yaygınlaştırılıyor. Maintenance Event Builder, IE4N gibi bir kaç savunma kökenli yenilik buralara girmeye başladı. Cihazların bakımı komplikeleştikçe, konfigürasyon yönetimi, PM-ippe entegrasyonu için de SAP yatırım yapacaktır ve mevcut işlevleri, digger endüstrilere de yaygınlaştıracaktır.
Ana Veri:
Ana verilerdeki karmaşıklık artık LSMW gibi ana very yaratma araçlarını yetersiz kilmaya başladı. Pek çok firma Winshutte gibi alternatifler kullanıyor. SAP ya LSMW’yu geliştirecek ve detaylandıracak, ya da Winshuttlebenzeri bir ürün geliştirecek. Terminlemede bunu yaptı zaten. MRS çözümü bir süredir Prometheus, Prievera ya da MS Project ile SAP’yi entegre eden çözümlere rakip olarak doğdu. SAP PM, PP ve PS’in en zorlanan noktalarından biri olanterminlemede böyle bir adım attılar Sanıyoruz ana veride de bunu atacaklar ki hafiften atılan adımlara dair sesler geliyor.(MDM, Data Services vs.)
Ana veriler iiçin toplu değiştirme işlevleri de geliştirildi malumunuz ama hala eksik olan, misal üzerinde 1000 tane planlı bakım olan bir ekipman kopyalandığında bakım planlarını kopyalayamamanız… Bu özellikle komplike ekipmanlar için elzem. SAP bu konuda da adımlar atacak ki buna dair izler de savunma çözümlerinde belirmeye başladı gibi.
Pool Asset Management:
Porsche için yapılan bu geliştirme, artık merkezi bir işlev olarak kullanıma hazır. Ama henüz emekleme aşamasında çünkü uyarlama tablolarıacemi ABAPçıların bile yapmayacağı türden gediklerle bezeli. Aletlerin kapasiteleri planlanabiliyordu, hatta biraz teknik bir detay ama aynı alet bakıma girdiğinde mevcut kullanılabilir kapasitesi de düşebiliyordu. Ama bir alet bir kişiye belli bir periyot için zimmetlenemiyordu. PAM bu iş için geliştirildi. Ama PAM’in eksik kanadı, yukarıda bahsettiğimiz bir aracın bakıma sokulması durumu… Bu henüz göz önüne alınmamış. Ha bir de bahsettiğimiz korkunç uyarlama tabloları da düzenlenecektir belli ki.
İşYerleri
Artık pek çok firma iş yerleri ile HR verilerini entegre etmeyi öğrendi. Ama burada da eksikler var. Misal kapasite sayısı ile iş yerine bağlıHR personeli sayısında bir otomatik entegrasyon yok. Bunu yapmak için geliştirmeler kullanılıyordu, ama sanıyoruz burada da bir ihtiyaç olduğu ortaya çıkmaya başladı.
Projeler
SAP PM ve SAP PS modülleri epey zamandır içli dışlı oldular. Ama SAP PM – PPM ilişkisi hala çok netlemiş değil. Arada mutlaka projeler olmasıgerekiyopr. Bu ilişki de daha netleşecek gibi görünüyor. Inspection Roundsişlevi ile illa da proje yaratmaya gerek kalmadan komplike bazı bakım işlemleri yapılabiliyor artık. Her daim proje yaratmadan belki direct PPM ile ya da bütçeleme ile ilişkilenecek çözümlere bakılacaktır. (Malum, PM için pek çok bütçeleme çözümü var. Ama bütçe kontrolü sadece PM-PS entegrasyonu ile yapılıyor. Bunun için de illa projelendirmeler gerekiyor. Oysa bütçe adımları, proje WBS’leri yerine daha sabit birer sepet halinde ele alınıyor malumunuz. SAP’nin bunu da göz önüne alacağını düşünüyoruz.