Yayım tarihi

Entegrasyon Değil Yönetişim

Bir organizasyonda herhangi bir sürecin, kendisini besleyen ön koşullar yeterli olgunluğa ulaşmadan tetiklenmesi sistematik bir yürütme riski yaratır. Bir süreç, doğrulanmış ve tamamlanmış çıktılar yerine eksik veya kısmi girdiler üzerine başlatıldığında, belirsizlik bir üst aşamaya taşınır. Bu belirsizlik zamanla revizyon artışı, yeniden planlama ihtiyacı, kalite sapmaları ve operasyonel maliyet yükselişi olarak geri döner. Temel prensip açıktır: Her süreç, yalnızca önceki sürecin doğrulanmış ve tutarlı çıktısı üzerine inşa edilmelidir (Premature release in upstream increases variability in downstream).

Bu ilke özellikle ETO sistemlerinde kritik hale gelir. ETO ortamında mühendislik verisi birbirine bağımlı üç domainde olgunlaşır: Structural (S), Process (P) ve Compliance (C). S verisi ürünün teknik kimliğini tanımlar ve temel oluşturur. P verisi ürünün nasıl üretileceğini belirler ve S’ye bağımlıdır. C verisi ise ürünün nasıl doğrulanacağını ve standartlara uygunluğunu tanımlar; P’ye bağımlıdır. Bu nedenle bağımlılık yapısı S → P → C şeklindedir. Her geçiş belirsizliği azaltır ve yürütme güvenilirliğini artırır.

Ancak bu üç veri seti farklı fonksiyonel domainlerde, farklı ekipler tarafından ve farklı zamanlarda üretilir. Tasarım mühendisliği S’yi oluştururken, üretim mühendisliği P’yi geliştirir, kalite ve regülasyon ekipleri ise C’yi tanımlar. Doğal olarak bu veriler eş zamanlı değildir. Sorun, bu bağımlı fakat dağınık veri yapısı konsolide edilmeden ERP aktivasyonunun tetiklenmesidir.

Birçok uygulamada PDM–ERP entegrasyonu yalnızca yapısal (S) veriler üzerinden gerçekleştirilir. Yapısal veri ERP’ye aktarıldığında sistem aktive edilir; oysa süreç (P) ve uygunluk (C) olgunluğu henüz tamamlanmamıştır. Bu durum erken yürütme riskini doğurur. ERP, yaşam döngüsü olgunluğu tamamlanmadan üretim, satın alma ve planlama kararları üretmeye başlar. Sonuç olarak routing değişiklikleri artar, revizyon zincirleri büyür, kalite problemleri ortaya çıkar…

Buradaki temel hata ERP veri aktarım sürecini bir entegrasyon problemi olarak görmektir. Oysa mesele sistemler arası veri senkronizasyonu değil, yaşam döngüsü olgunluğunun yönetimidir. ERP readiness veri varlığı değildir; doğrulanmış yaşam döngüsü olgunluğudur. ERP’nin yürütme otoritesi üretmesi için S + P + C verilerinin birlikte tamamlanmış ve tutarlılıklarının doğrulanmış olması gerekir.

Bu nedenle PDM ile ERP arasındaki yapı bir entegrasyon katmanı değil, bir governance layer olarak tasarlanmalıdır. Bu governance katmanı:

  • S → P → C bağımlılıklarını doğrular
  • Domainler arası olgunluğu ölçer
  • Eksik veri varken ERP aktivasyonunu engeller
  • SPC verilerini konsolide ve sertifikalı bir olgunluk paketi haline getirir
  • ERP aktivasyonunu zaman damgasına değil, doğrulanmış duruma bağlar

Böylece ERP aktivasyonu teknik bir veri transferi olmaktan çıkar; kontrollü bir üretim serbest bırakma kararına dönüşür. ETO sistemlerinde operasyonel istikrarın anahtarı, ERP’yi erken tetiklemek değil; mühendislik olgunluğunu yönetişimle güvence altına almaktır.

Yayım tarihi

Design Thinking and Integration

Kontrol edilemeyen teknolojik gelişim birçok şeyi değiştiriyor. Her ne kadar metotlar ve süreçler değişikliğe uğrasa da iş dünyasının temel prensipleri hala aynı şekilde yerinde duruyor: Hız, kalite ve maliyet…

Teknolojinin en net etkisini ‘ürün’ tarafında görüyoruz. SCP (Akıllı ve Bağlantılı Ürün) konsepti, ürün ağacı yapısını temelinden değiştiriyor. Ürün içinde hem fiziksel hem de sanal bileşenlerin olması (data artık bir BoM bileşeni) ürünü daha kompleks bir yapıya büründürerek, ürün kavramının bir sisteme dönüşmesine sebep oluyor: PaaS (Product as a Service).

Bu sonuç bize iki ana temaya odaklanmamız gerektiğini işaret ediyor?

  1. Design Thinking: Ürünlerin teknolojik açıdan kompleks hale gelmesi her ne kadar birçok fonksiyonun bir arada sunulmasına imkân sağlasa da kullanıcıların ürünle olan etkileşimlerinde (user experience) sorunlara yol açabilmektedir. Anlaşılabilir ve kullanılabilir ürünleri kullanıcı gözünden bakarak (empati) tasarlamak, tasarım süreçlerinde mühendislik mantığı yerine insan odaklı tasarım (HCD: Human Centric Design, Don Norman) ilkelerine odaklanmak bu aşamada oldukça önemli unsurlaredır.
  • Integration: Artık ürün yerine servis satılması, üreticilerin PLM süreci boyunca sistemle ilişkilerinin/etkileşimlerinin devam etmesini zorunlu kılıyor. Bunun için, tüm iş süreçlerinin, yani SCOR fazlarının (Plan – Design – Source – Make – Deliver – Return) birbirleri ile entegre olması gerekir. Dijital Dönüşümün ana teması olan CPS ile dikey entegrasyonu sağlayıp, tedarikçi ve müşterilerin de yatay entegrasyon üzerinden sürece entegre edilmesi bu amaca hizmet edecektir.

Design Thinking, müşteri ihtiyacını tam anlamanızı ve doğru probleme çözüm üretmenizi; Integration ise hem ‘ürün ağacında olan verinin hem de ‘fiziksel malzeme akışını tetikleyen bilginin’ doğru ve hızlı akmasını temin eder. Bu sayede daha çevik ve rekabetçi olabilirsiniz. Bunun üzerine bir düşünün derim.

Yayım tarihi

RPA ile Entegrasyon

Dijital Dönüşümün özünde ‘süreçlerin dijitalleştirilmesi (IoT Ready)’ ve ‘dijitalleşen süreçleri birbiri ile iletişime geçirebilir olmak (inter-operability)’ yatar dersek sanırım yanılmış olmayız. Bilgiyi üreten (produce data) ile bilgiyi tüketenin (consume data) buluşabilmesi bu iki konu ile ilintilidir.

PPAP (Production Part Approval Process) dosyası hazırlamak oldukça karmaşık bir süreçtir. Farklı sistemlerden gelen birçok veriyi (örneğin onlarca test ekipmanını ürettiği test verileri) doğru ve eksiksiz olarak tek bir PPAP dosyasına aktarmanız gerekir. Hatalı veri girişi ya da arama/bekleme gibi zaman kayıpları bu süreçte oldukça can sıkan konulardır. Hatalı bilgi ya da gecikme, tüm emeğin boşa gitmesine bile sebep olabilir.

RPA konusu giderek yaygınlaşıyor. Robotlar, muhasebe, satın alma, raporlama gibi standart/tekrarlamalı süreçlerin otomatikleştirilmesinin ötesinde farklı sistemler arasında kompleks ağ yapıları kurmadan entegrasyon yapılabilmesinin de önünü açıyor. 

Geçtiğimiz gün bir müşterimde, test ekipmanlarının ürettiği verilerin PPAP dosyasına otomatik aktarılması sürecini RPA üzerinden gerçekleştirdik. Süreç oldukça basit bir şekilde kurgulandı.

  • Test ekipmanları ürettikleri dosyalar (xls, pdf, csv,) belirli bir klasöre kopyalandı,
  • RPA, klasördeki dosyaları tek tek açarak, tanımlanmış alanları/sonuçları buldu ve ilgili PPAP dosyasına otomatik yazdı.
  • Çevrim süresi istasyon başına 3 sn., hata oranı 0% olarak gerçekleşti.

Daha önceleri bir PPAP için 2-3 saat zaman alan bu süreç (manuel bilgi transferi: dosya arama, açma, okuma, yazma), RPA ile 30 sn. (10 test ekipmanı) mertebesine indirgendi. Yılda ortalama 300 PPAP dosyası hazırlandığı göz önüne alındığında yaklaşık 900 saatlik mühendislik zamanı ve en önemlisi sıfır hata (poka&yoke) oranına erişilmiş oldu. 

Eğer, bu çalışmayı sistemleri birbiri ile entegre ederek yapmaya çalışsaydık, farklı iletişim protokollerine sahip her bir cihaz için bir entegrasyon yazılımı yapmak ya da OPC/UA, MQTT gibi çözümler üzerine gitmemiz gerekecekti. Elbette ki her iki yöntem birbiri ile aynı değil ancak amaç fonksiyonuna baktığımızda istenilen sonuca ulaşmada RPA işe yaramış gibi görünüyor. Dijital Eko-Sistemi, yeteri kadar iyi konsepti üzerinden en basit/hızlı yöntemle genişletme konusunda RPA ile entegrasyon sonuç verdi.

İş süreçlerinde buna benzer birçok farklı süreç mevcut. RPA, süreçlerin yönetimi anlamında hız, maliyet ve kalite açısından fark oluşturuyor ve işletmenin hem Lean hem de Agile olmasına katkı sunuyor. Bu konuyu araştırın ve üzerine sıkı sıkı düşünün derim. 

Yayım tarihi

PDM-ERP-MES Entegrasyonu ve Alan Bilgisi

Ü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. 

  1. Model geliştirecek MİMAR (domain knowledge / architect), 
  2. Modeli uyarlayacak MÜHENDİS (software developer /engineer).  

Üzerine düşünün derim.