Kapasite planlama veritabanı tasarımı, planlama motorunun doğruluğunu tek başına belirlemez; ancak planlama hesaplarının hangi tanımlarla, hangi zaman çözünürlüğünde ve hangi kısıt mantığıyla çalışacağını belirleyen temel zemindir. Teknik ekip için asıl zorluk, kapasiteyi sadece “kaynak sayısı” olarak değil; takvim, yetenek, set-up, bakım, operatör kısıtı, malzeme uygunluğu ve süreç rotası gibi çok katmanlı kısıtların ölçülebilir bir veri modeline dönüştürülmesidir. Bu yazıda kapasite planlama veritabanı tasarımında kavramsal modelin sınırları, zaman boyutunun nasıl ele alınacağı, veri akışında olay temelli kayıt ve versiyonlama yaklaşımı ile performans/izlenebilirlik ihtiyaçlarının aynı yapıda nasıl dengelenebileceği teknik prensipler üzerinden ele alınır.
Kapasite Planlama Veritabanı için Kavramsal Çekirdek
Kapasite planlama veritabanı, “hangi iş, hangi kaynağı, ne kadar süre meşgul eder?” sorusunu yanıtlamak için üç çekirdeği aynı anda taşır: iş tanımı (iş emri/operasyon), kaynak tanımı (makine/hat/iş istasyonu/operatör grubu) ve zaman tanımı (takvim/slot). Üretim yönetimi prensipleri çerçevesinde bu çekirdeğin üzerine kısıt katmanları eklenir; bu katmanların her biri veritabanında ayrı bir varlık ve ayrı bir ilişki olarak modellenmezse, planlama mantığı uygulama koduna “gömülür” ve denetlenebilirlik zayıflar.
Teknik literatürde kapasite iki farklı bakışla ele alınır: nominal kapasite (teorik üst sınır) ve efektif kapasite (planlı duruşlar, verim kayıpları, kısıtlar sonrası kullanılabilir alan). Veritabanı tasarımında bu ayrımın yeri ölçüm noktasıdır. Nominal kapasite genellikle kaynak ana verisiyle ilişkilidir; efektif kapasite ise takvim, bakım planı ve vardiya parametreleriyle türetilir. Bu nedenle aynı “kapasite” kavramını hem saklanan bir değer (master data) hem de türetilen bir değer (derived) olarak ele alıp, hangi noktada kalıcılaştırılacağını açıkça tanımlamak gerekir.
ISA-95 seviyeleri perspektifinde, kapasite planlama veritabanı çoğunlukla Seviye 3 (MES/MOM) veri nesneleri ile Seviye 4 (ERP) plan nesneleri arasında yer alır. Bu konum, veri modelinde kimlik bütünlüğü (idempotency), referans anahtarlar ve zaman damgası disiplinini zorunlu kılar.
Veri Modeli: Anahtarlar, Normalizasyon ve Kısıtların Temsili
Kapasite planlama veritabanı tasarımında ilk teknik karar, ana veri ile işlem verisinin sınırını netleştirmektir. Kaynak tanımları, ürün/yarı mamul tanımları, rota ve operasyon sözlüğü “yavaş değişen” varlıklardır; iş emirleri, gerçekleşen duruşlar, setup başlangıç-bitişleri ve çizelge atamaları ise “olay” niteliğindedir. Normalizasyon burada sadece tekrarları azaltmak için değil, kısıtların izlenebilir şekilde ifade edilmesi için gereklidir.
Bir kapasite modelinde sık karşılaşılan hata, operasyon süresini tek bir alana indirgemektir. Planlama açısından operasyon süresi bileşenlere ayrılır: hazırlık (setup), çevrim (run), bekleme (queue), taşıma (move) gibi. Bu ayrım veritabanında ayrı alanlarla tutulduğunda, kapasite tüketimi hesapları hem daha denetlenebilir olur hem de farklı planlama algoritmalarına veri sağlamak kolaylaşır.
Aşağıdaki tablo, kapasite planlama veritabanı için sık kullanılan çekirdek tabloların sorumluluklarını özetler. İsimlendirme şeması örnektir; önemli olan varlıkların sınırlarının net olmasıdır.
| Varlık | Amaç | Temel Anahtarlar |
|---|---|---|
| resource | Makine/istasyon/hat tanımı, kapasite türü, yetenek profili | resource_id, resource_code |
| calendar | Vardiya, tatil, planlı duruş ve istisna kuralları | calendar_id, calendar_version |
| routing_operation | Ürün rotası, operasyon sırası, alternatif operasyon seçenekleri | routing_id, operation_seq |
| operation_time | Süre bileşenleri ve birim dönüşümleri | operation_id, time_model_id |
| work_order_op | İş emri operasyonu; miktar, hedef tarih, öncelik | wo_id, op_id |
| schedule_allocation | Operasyonun kaynak ve zaman slotlarına atanması | allocation_id, wo_id, op_id |
Kısıtların temsili için iki yaklaşım vardır: kısıtı satır olarak saklamak (constraint as data) veya kısıtı kodla uygulamak (constraint as logic). Teknik ekip açısından sürdürülebilirlik, kısıtların mümkün olan kısmını veri olarak modellemeyi gerektirir. Örneğin “kaynak-yetenek eşleşmesi”, “ürün grubu için izinli kaynak listesi”, “setup matrisi (ürün A’dan B’ye geçiş süresi)” gibi bilgiler ayrı ilişki tablolarında tutulduğunda kapasite planlama veritabanı hem açıklanabilir olur hem de değişiklikler versiyonlanabilir.
Zaman Boyutu: Takvim, Slotlama ve Doğruluk Mühendisliği
Kapasite planlama veritabanı tasarımında zaman boyutu çoğu zaman performans sorunu gibi görülür; aslında doğruluk sorunudur. Kapasite tüketimi, bir operasyonun ne kadar süre aldığı kadar “hangi saatlerde çalışılabildiği” ile ilgilidir. Bu nedenle takvim modeli, vardiya başlangıç-bitişi, mola parçaları, planlı bakım pencereleri, istisna günler ve saatlik/dakikalık çözünürlük gibi unsurları formalize etmelidir.
Takvim verisini iki katmanda ele almak pratik bir yaklaşımdır:
- Kural katmanı: Vardiya şablonları, tekrarlayan çalışma günleri, standart molalar.
- İstisna katmanı: Tekil tarih/saat bazlı değişiklikler, planlı duruşlar, özel çalışma.
Bu iki katman birleştirilerek “kullanılabilir zaman aralıkları” türetilir. Teknik literatürde bu tür türetimler için versiyonlama önemlidir: aynı tarihe ait takvim kuralı değiştiğinde, geçmiş planların hangi takvim versiyonuna göre üretildiği izlenebilmelidir. Bu yüzden takvim tablolarında sürüm alanı (calendar_version), geçerlilik aralığı (valid_from, valid_to) ve yayın durumu gibi alanlar kapasite planlama veritabanı tasarımının parçası olmalıdır.
Zaman çözünürlüğü (slot uzunluğu) da veritabanı kararına dönüşür. Çok ince slotlama, schedule_allocation kayıt hacmini büyütür; çok kaba slotlama ise set-up ve kısa operasyonlarda hataya neden olur. Burada yaklaşım, slotlamayı “tek doğruluk kaynağı” yapmak yerine, operasyonun başlangıç/bitiş zamanını kesin alanlarla saklamak ve slotlamayı indeksleme/raporlama için türetilen bir yapı olarak kullanmaktır.
Veri Akışı: Kaynak Sistemler, Olay Kayıtları ve Versiyonlama
Kapasite planlama veritabanı yalnızca depolama katmanı değildir; veri akışının sözleşmesidir. Kurumsal entegrasyon prensiplerine göre, her gelen kayıt için kaynağı, işleme zamanını, iş anahtarını ve tekrar işlenebilirliği sağlayan bir iz (provenance) tutulmalıdır. Özellikle ERP’den gelen iş emri ve BOM/rota değişiklikleri ile üretimden veri toplama katmanından gelen gerçekleşen zamanlar aynı veri alanlarına yazıldığında, “hangisi baskın?” sorusu ortaya çıkar. Bu nedenle veri akışını katmanlamak gerekir.
Olay temelli model, planlama için güçlü bir çerçeve sağlar. Örneğin iş emri operasyonu için şu olay tipleri ayrı ayrı saklanabilir: yayınlandı, revize edildi, başlatıldı, durdu, tamamlandı, iptal edildi. Bu yaklaşımda “son durum” ayrıca bir özet tabloda tutulabilir; ancak denetim için olay günlüğü (event log) korunur. Böylece kapasite planlama veritabanı, hem anlık çizelgeyi hem de geriye dönük doğrulama ihtiyacını aynı anda karşılar.
Versiyonlama, sadece takvimde değil; rota ve süre modellerinde de gereklidir. Operasyon süreleri revize edildiğinde, eski planların hangi süre modeline göre oluşturulduğu izlenebilir olmalıdır. Bu amaçla aşağıdaki prensipler önerilir:
- Master data için geçerlilik aralığı ve sürüm numarası tutmak.
- Schedule kayıtlarında kullanılan sürüm referanslarını saklamak (calendar_version, time_model_version gibi).
- Değişiklikleri “üstüne yazma” yerine yeni sürüm olarak eklemek.
Entegrasyon katmanında idempotency (aynı mesajın tekrar gelmesi halinde tekil sonuç) kapasite planlama veritabanı için belirleyicidir. Bunun için doğal anahtarlarla (ör. source_system + source_id + source_revision) benzersiz indeksler kurgulanır; veritabanı tarafında tekrar kayıtlar engellenir ve güncelleme stratejisi netleştirilir.
Performans ve Ölçek: Sorgu Desenleri, Özet Katmanları ve Tutarlılık
Kapasite planlama veritabanı tasarımında performans, “kaç satır” meselesinden çok sorgu desenlerini doğru tahmin etme meselesidir. Planlama ekranları tipik olarak şu sorguları yoğun kullanır: belirli bir kaynak için zaman ekseninde yük grafiği, belirli bir iş emri için kaynak uygunluğu, belirli bir tarih aralığında darboğaz noktaları, ve çizelge değişikliği sonrası yeniden hesap gerektiren etki analizi.
Bu sorgular için ham olay verisi çoğu zaman yeterli değildir; özet katmanları (aggregation) gerekir. Ancak özet tabloların tek doğruluk kaynağı haline gelmesi, tutarsızlık riskini büyütür. Üretim yönetimi prensipleri çerçevesinde önerilen yaklaşım, özetleri deterministik olarak türetecek bir model kurmaktır:
- Ham kayıtlar değişmez (append-only) tutulur; düzeltmeler yeni olayla yapılır.
- Özet tablolar belirli anahtarlarla yeniden üretilebilir olacak şekilde tasarlanır.
- Özetin hangi “kesit” için üretildiği (tarih aralığı, kaynak grubu, takvim versiyonu) meta veriyle saklanır.
İndeks stratejisinde, zaman aralığı sorguları için (resource_id, start_time) ve (resource_id, end_time) bileşik indeksler; iş emri odaklı sorgular için (wo_id, op_id) indeksleri öne çıkar. Ayrıca schedule_allocation gibi büyük tabloların tarih bazlı bölümlenmesi (partition) düşünülür; burada amaç bakım kolaylığı ve sorgu kapsamını daraltmaktır. Tutarlılık açısından, çizelge güncellemelerinde yarış durumlarını engellemek için satır seviyesinde sürüm alanı (row_version) veya benzer bir eşzamanlılık kontrolü yaklaşımı kullanılabilir.
Yönetişim: Veri Kalitesi, Yetkilendirme ve Denetim İzleri
Kapasite planlama veritabanı, planın “neden böyle çıktığı” sorusuna yanıt üretebildiği ölçüde değerlidir. Bu da veri yönetişimi gerektirir. Teknik ekip açısından yönetişimin somut karşılığı; veri kalitesi kuralları, yetkilendirme matrisi ve denetim izleridir. Örneğin, negatif süre, çakışan vardiya aralıkları, geçerlilik aralığı boşlukları, kaynak-yetenek eşleşmesi olmayan atamalar gibi durumlar veritabanı seviyesinde kısıtlar (constraint), tetikleyiciler (trigger) veya yükleme doğrulama adımlarıyla yakalanmalıdır.
Yetkilendirme tarafında, kapasite planlama veritabanı “kim hangi kaynağın takvimini değiştirebilir?”, “kim süre modelini revize edebilir?”, “kim çizelgeyi yayınlayabilir?” sorularına rol tabanlı yanıt vermelidir. Denetim izi için asgari alan seti tipiktir: değişikliği yapan kimlik, değişiklik zamanı, değişiklik nedeni kodu, önceki değerlerin özeti. Bu alanlar, özellikle takvim ve süre modeli gibi planı doğrudan etkileyen tablolarda ayrı bir önem taşır.
Veri kalitesi metriklerini veritabanına “rapor” olarak değil “kural” olarak taşımak, kapasite planlama veritabanı tasarımının disiplinini artırır. Bu yaklaşım, planlama çıktılarının izlenebilirliğini güçlendirir ve entegrasyon akışındaki hataların erken yakalanmasına yardım eder.
Kapasite planlama veritabanı tasarımı ve veri akışı kurgusu; kavramsal model, zaman boyutu, kısıtların veri olarak temsili, olay günlüğü ve versiyonlama disiplinleriyle birlikte ele alındığında planlama hesaplarının denetlenebilirliğini ve sürdürülebilirliğini artırır. Kapasite planlama veritabanı odağında kendi veri sözleşmenizi netleştirmek, entegrasyon noktalarını tanımlamak ve zaman/takvim modelini doğru kurmak için MESPlus ile iletişime geçebilir, mevcut mimarinizi teknik prensipler üzerinden birlikte değerlendirebilirsiniz.
