Mustafa Bey, DepotMR Projesinde Geldiğimiz Nokta
Bu sayfa, DepotMR'nin fikir aşamasından çalışan frontend demoya kadar geldiği noktayı tek bakışta anlatmak için hazırlandı. Kurulan ekranları, modülleri, veri mantığını, mock data ile gösterilen ürün davranışını ve ürün ekibinin değerlendirmesi gereken karar başlıklarını özetliyoruz.
Çalışan ekranlar, akışlar ve kullanıcı deneyimi frontend tarafında gösterilebilir durumda.
Gerçek DB bağlantısı kurulmadan önce ürün kurgusunu göstermek için örnek depo/veri setleri kullanılıyor.
Sistem bu aşamada canlı operasyon verisine bağlı değil; backend ve DB entegrasyonu sonraki faz olarak planlanıyor.
Mock servis yapısı gerçek API'ye geçişi kolaylaştıracak şekilde organize edildi.
Ekranlar, modüller ve akışlar ürün ekibinin inceleyip geri bildirim verebileceği seviyede.
Sonraki geliştirmeye daha güvenli başlamak için kalite kontrolleri yapılmış durumda.
Mustafa Bey, bu proje artık sadece fikir veya pazarlama anlatımı seviyesinde değil. Depodaki operasyon görünürlüğü, iş yoğunluğu, personel görevlendirme, lokasyon verimliliği ve karar destek ihtiyacını anlatan çalışan bir frontend demo haline geldi.
Mock data sayesinde ekranlar boş bir tasarım gibi değil, anlamlı depo senaryoları üzerinden gezilebiliyor. Ürün ekibi artık modül isimlerini, ekran akışlarını, KPI mantığını, yönetici aksiyonlarını ve MVP kapsamını somut bir yazılım üzerinden değerlendirebilir.
DepotMR neyi çözmek için tasarlandı?
DepotMR, deponun anlık operasyon görünürlüğünü artırmak için tasarlandı. WMS'in yerine geçmeyi değil; WMS, RF, personel, görev, stok, ekipman ve lokasyon verisini yöneticiye karar desteği veren ekranlara dönüştürmeyi hedefler.
Şu anda oluşturduğumuz yazılım nedir?
Şu anki yapı frontend-first bir ürün simülasyonudur. Gerçek DB bağlantısı olmadan ekran ihtiyacını, modül ayrımını, veri ilişkilerini ve karar akışını test etmeye yarar; ileride Supabase/API/backend bağlantısına geçmeye uygun servis sınırlarıyla hazırlanmıştır.
| Alan | Durum |
|---|---|
| Frontend | Next.js üzerinde çalışan demo ekranları hazır; modüller route bazında gezilebiliyor. |
| Backend | Bu fazda canlı backend yok; API ve iş kuralları ürün kapsamı netleştikten sonra kurulacak. |
| Supabase | Henüz bağlı değil; PostgreSQL/Supabase şeması ürün modeli onaylandıktan sonra tasarlanacak. |
| Veri | Aktif veri kaynağı src/mock/seed altında; amaç ekran davranışını, veri ilişkilerini ve karar akışını test etmek. |
| Eski mocklar | Eski mocklar src/mock/archive altında tutuluyor; aktif demo düzenli seed kaynakları üzerinden ilerliyor. |
| Servis yapısı | Sayfalar mock veriyi doğrudan değil servis katmanından alıyor; gerçek API'ye geçişte bu sınır korunabilir. |
| Audit kontrolü | auditSeedRelations mevcut ve temiz; build/lint tarafı da temiz tutuluyor. |
| Ürün değerlendirmesi | Başlayabilir; modül adları, KPI'lar, akışlar ve MVP kapsamı artık somut ekranlar üzerinden tartışılabilir. |
Gerçek DB'ye geçmeden önce ürün modeli, ekran ihtiyaçları ve veri ilişkileri netleşmeli. Çünkü erken DB tasarımı; yanlış entity, yanlış alan ve yanlış ilişki kararlarını kalıcı hale getirebilir.
Bu yüzden mock data geçici bir hile gibi değil, ürün davranışını test eden bilinçli bir örnek veri katmanı olarak kullanılıyor. Ürün akışı, modüller, KPI anlamları ve rapor ihtiyaçları doğrulandıktan sonra Supabase/PostgreSQL şeması tasarlanacak ve mock servisler gerçek API servislerine dönüşecek.
Kurulan ana mimari
Bu projede kurulan yapı, bugün mock data ile çalışırken yarın Supabase, API ve backend servislerine taşınabilecek şekilde servis katmanı üzerinden ilerliyor.
Mock data ve veri modeli mantığı
Mock data, demo ekranlarını doldurmak için rastgele eklenmiş içerik değil; ürün davranışını, ekran ihtiyaçlarını ve veri ilişkilerini test etmek için kullanılan örnek veri yapısıdır. Gerçek DB'ye geçildiğinde depo, lokasyon, raf, iş emri, personel, ekipman, ürün, hareket, KPI ve olay/uyarı verileri bu modele bağlanacaktır.
Ne işe yarar: Şirket, depo ve müşteri/proje sınırlarını tanımlar; her ekranın hangi operasyon bağlamında çalıştığını belirler.
Hangi ekranları besler: Tüm modüllerin şirket, depo ve proje bağlamını besler; ileride yetki, rapor ve veri izolasyonu için ana referans olur.
Ürün ekibi neyi kontrol etmeli: Mustafa Bey, ürün ekibi müşteri/proje ayrımının gerçek operasyon yapısına ve raporlama ihtiyacına uygun olup olmadığını kontrol etmeli.
Ne işe yarar: Personel kimliği, yetkinlik, vardiya, devam, görev uygunluğu ve performans sinyallerini taşır.
Hangi ekranları besler: Personel Verimliliği, Workforce Optimizer, Control Tower, Dashboard ve rapor ekranlarını besler.
Ürün ekibi neyi kontrol etmeli: Personel verimliliğinde hangi metriklerin kullanılacağı, hangi bilginin hassas olduğu ve yöneticinin nasıl aksiyon alacağı netleşmeli.
Ne işe yarar: Deponun bina, kat, bölge, koridor, raf ve lokasyon kırılımını katman katman tarif eder.
Hangi ekranları besler: Depo Radar, Lokasyon Heatmap, Slotting Optimizer, Batching & Routing ve cep radar ekranlarını besler.
Ürün ekibi neyi kontrol etmeli: Raf, kat, koridor ve lokasyon adlarının sahadaki isimlendirmeyle uyumu; heatmap ve rota mantığının gerçek depo planına uyup uymadığı kontrol edilmeli.
Ne işe yarar: Ürün, barkod, stok bakiyesi, hareket geçmişi ve lokasyon bazlı stok anlamını temsil eder.
Hangi ekranları besler: Slotting Optimizer, Forecast & Replenish, KPI Merkezi, Raporlar ve ileride stok detay ekranlarını besler.
Ürün ekibi neyi kontrol etmeli: Ürün kırılımı, lokasyon doğruluğu, stok hareketi türleri ve ikmal kararlarında hangi verinin gerekli olduğu ürün ekibiyle doğrulanmalı.
Ne işe yarar: İş emrinden görev atamasına, saha oturumundan tarama/hareket olayına kadar operasyon akışını kurar.
Hangi ekranları besler: İş Emirleri, Event Stream, Control Tower, Operasyon MR, Dashboard ve Manuel İş & İstisna ekranlarını besler.
Ürün ekibi neyi kontrol etmeli: İş emri yaşam döngüsü, durum isimleri, SLA anlamı, manuel istisna süreci ve yönetici aksiyonları netleştirilmeli.
Ne işe yarar: Depoya sadece olanı değil; hangi yerleşim, görev, rota veya ikmal kararının daha doğru olabileceğini de gösterir.
Hangi ekranları besler: Slotting Optimizer, Workforce Optimizer, Batching & Routing, Forecast & Replenish ve Karar Önerileri ekranlarını besler.
Ürün ekibi neyi kontrol etmeli: Önerilerin hangi iş kurallarına göre üretileceği, hangi önerinin otomatik değil yönetici onaylı ilerleyeceği kararlaştırılmalı.
Ne işe yarar: Depodaki canlı görünüm, lokasyon durumu, görev işaretleri ve kritik uyarıları görselleştirir.
Hangi ekranları besler: Depo Radar, Depo Radar Cep, Control Tower ve Dijital İkiz için temel görsel dili besler.
Ürün ekibi neyi kontrol etmeli: Mock konumların görsel dili, uyarı öncelikleri, harita katmanları ve gerçek zaman beklentisi depo gerçekliğiyle karşılaştırılmalı.
Ne işe yarar: Operasyon verisini KPI, rapor, pilot izleme ve karar özetine dönüştürür.
Hangi ekranları besler: Dashboard, KPI Merkezi, Raporlar, ROI & Pilot İzleme ve yönetim ekranlarını besler.
Ürün ekibi neyi kontrol etmeli: KPI adları, formüller, hedef değerler, rapor sıklığı ve pilot başarı kriterleri ürün ekibi tarafından onaylanmalı.
Mevcut modüller ve ekranlar
Ürün ekibi bu ekranlara gerçek veri doğruluğu açısından değil; bu modül ne işe yarar, hangi kararı destekler, hangi veriyle beslenir ve MVP'de gerekli midir soruları açısından bakmalı.
| Modül | Amaç | Şu An Ne Gösteriyor? | Ürün Ekibi Ne Kontrol Etmeli? |
|---|---|---|---|
| Dashboard | Operasyonun genel sağlık durumunu tek bakışta gösterir; yöneticiye hedef, tamamlanan iş, risk ve öncelik sinyali verir. | Günlük hedefler, tamamlanan işler, throughput, risk kartları ve karar önerileri. | KPI adları, metrik anlamları ve yöneticinin bu ekrandan hangi kararı alacağı. |
| Depo Radar | Depodaki lokasyon, raf, personel, ekipman, görev ve riskleri görsel katmanlar halinde izlemek için tasarlanmıştır. | Zone, raf, personel, makine, görev ve uyarı katmanları mock konumlarla gösteriliyor. | Görsel temsilin depo gerçekliğine uyup uymadığı ve hangi katmanların MVP için öncelikli olduğu. |
| Depo Radar Cep | Radar bilgisini saha liderinin cep telefonunda hızlı okuyabileceği sade bir forma indirger. | Kompakt canlı durum, öncelikli uyarılar ve mobil görünüm. | Saha liderinin telefonda gerçekten ihtiyaç duyduğu ilk üç bilgi. |
| Operasyon MR | Depo süreçlerini sağlık kontrolünden geçirir; yoğunluk, gecikme ve kapasite sorunlarını operasyon diliyle görünür yapar. | Süreç bazlı sağlık sinyalleri, darboğaz bulguları ve aksiyon ihtiyacı. | Süreç adları, darboğaz tanımları ve hangi bulgunun yönetici aksiyonuna dönüşeceği. |
| Control Tower | Darboğaz, alarm, müdahale ve öncelik kararlarını tek yönetim ekranında toplar. | Süreç sağlık kartları, riskler, uyarılar ve operasyon önerileri. | Alarm seviyeleri, müdahale aksiyonları, eskalasyon dili ve sorumluluk kurgusu. |
| Event Stream | Depoda olan biteni zaman sırasıyla izlenebilir hale getirir; tarama, hareket, görev ve sistem olaylarını aynı akışta toplar. | Hareket, tarama, görev, uyarı ve sistem olayları. | Olay kategorileri, filtreler, önem derecesi isimleri ve olay detay ihtiyacı. |
| İş Emirleri | İş emirlerinin durumunu, gecikmesini, SLA riskini ve personel atamasını takip eder. | İş emri listesi, SLA riski, durum, öncelik ve personel ataması. | İş emri yaşam döngüsü, filtreler, detay ekranı ve aksiyon ihtiyacı. |
| Workforce Optimizer | Personeli doğru göreve yönlendirmek için uygunluk, mesafe, yetkinlik ve iş yükü sinyallerinden öneri üretir. | Uygunluk skoru, seyahat mesafesi, risk ve öneri gerekçesi. | Öneri mantığı, adalet kriteri, vardiya kuralları ve yönetici onay akışı. |
| Personel Verimliliği | Sahadaki personelin durumunu, rolünü, görev bağlamını ve verimlilik sinyallerini görünür yapar. | Personel kartları, rol, durum, lokasyon ve üretkenlik bilgisi. | Personel verilerinin kapsamı, hassasiyet seviyesi ve performans dilinin nasıl kurulacağı. |
| Manuel İş & İstisna | RF/WMS dışında kalan manuel işleri ve istisnai operasyon kayıtlarını görünür hale getirir. | Manuel aktivite listesi, onay durumu, açıklama ve istisna kayıtları. | Hangi manuel işlerin ölçüleceği, kanıt/onay süreci ve bu kayıtların KPI'a etkisi. |
| Batching & Routing | Toplama işlerini doğru gruplamak ve rota kararlarını iyileştirmek için mesafe, öncelik ve SLA riskini birlikte değerlendirir. | Batch metrikleri, rota skoru, SLA riski ve picker önerisi. | Batch kuralları, rota önceliği, gerçek operasyon kısıtları ve kabul edilebilir öneri dili. |
| Lokasyon Heatmap | Koridor, raf ve lokasyon bazında yoğunluk, bekleme ve tıkanıklık riskini ısı haritası mantığıyla gösterir. | Bölge yoğunluğu, lokasyon riski ve operasyon akışındaki sıkışma sinyalleri. | Heatmap katmanları, yoğunluk eşikleri ve gerçek depo planındaki anlamı. |
| Slotting Optimizer | Ürünlerin doğru lokasyona yerleşmesi için toplama sıklığı, mesafe ve operasyon etkisine göre öneri verir. | Mevcut/önerilen lokasyon, skor, mesafe ve kazanç tahmini. | Öneri kabul süreci, iş kuralları ve hangi ürün gruplarında öncelik verileceği. |
| Forecast & Replenish | Talep tahmini ve kritik stok/ikmal ihtiyacını önceden görünür kılmayı hedefler. | Kritik stok, ikmal uyarısı ve talep sinyali örnekleri. | Hangi veri kaynaklarının tahmine gireceği, ikmal eşiği ve uyarı öncelikleri. |
| Dock & Yard Sync | Gelen/giden araç, rıhtım kapısı ve saha bekleme süreçlerini depo operasyonuyla eşleştirir. | Randevu, kapı kullanımı, bekleme ve senkronizasyon sinyalleri. | Rıhtım süreçleri, araç statüleri ve hangi entegrasyonların gerekli olduğu. |
| Dijital İkiz | Gerçek veriler oturduğunda senaryo testi ve what-if analizi yapmak için planlanan simülasyon katmanıdır. | Mock senaryo fikri, operasyon etkisi ve karar simülasyonu çerçevesi. | Hangi senaryoların değerli olduğu ve bunun MVP sonrası hangi fazda ele alınacağı. |
| Deney Platformu | Yeni kural, ekran veya optimizasyon önerilerini pilot/AB test mantığıyla ölçmek için düşünülmüştür. | Deney kartları, metrik etkisi ve test durumu örnekleri. | Hangi değişikliklerin deney olarak izleneceği ve başarı kriterlerinin nasıl yazılacağı. |
| KPI Merkezi | Hız, kalite, verimlilik, SLA ve iş gücü metriklerini standart bir karar dili altında toplar. | Verimlilik, hız, kalite, iş gücü ve hedef KPI'ları. | Formüller, hedef değerler, veri kaynağı ve karar ilişkisi. |
| ROI & Pilot İzleme | Pilot depoda beklenen faydayı, maliyet etkisini ve canlıya geçiş hazırlığını izlemek için kullanılır. | Tasarruf tahmini, pilot fazları, değer alanları ve izleme başlıkları. | Pilot başarı kriterleri, ölçüm yöntemi ve raporlanacak finansal/operasyonel değerler. |
| Karar Önerileri | Kritik sorunları yönetici için anlaşılır aksiyon kartlarına dönüştürür. | Önceliklendirilmiş öneriler, gerekçe ve beklenen etki. | Öneri dili, aksiyon butonları, sorumluluk kurgusu ve onay mekanizması. |
| Raporlar | Yönetim, vardiya ve operasyon değerlendirmeleri için dışa aktarılabilir rapor başlıklarını kataloglar. | Rapor kartları, sıklık, beklenen çıktı ve kapsam bilgisi. | Rapor isimleri, dışa aktarım ihtiyacı, detay akışı ve dağıtım sıklığı. |
Depo Radar, projenin en görünür ekranlarından biridir; ancak tek başına ürün değildir. Arkasında personel, görev, lokasyon, stok, ekipman, olay ve karar destek verisi vardır.
Şu an konumlar simülasyon/mock datadır. Gerçek projede WMS, RF, IoT, ekipman takip sistemleri veya manuel operasyon kayıtlarıyla beslenecek; böylece yoğunluk, darboğaz ve gecikme tespiti canlı veriye yaklaşacaktır.
Depoyu anlık görmek
Yoğunluğu fark etmek
Personel/makine/görev konumlarını anlamak
Raf/lokasyon risklerini görmek
Uyarıları ve önerileri görsel hale getirmek
Karar desteğini sahaya yaklaştırmak
Ürün ekibinin bu projeye nasıl bakması gerekir?
Mustafa Bey, bu aşamada ürün ekibinden beklenen ana katkı verinin gerçekliğini değil ürünün doğruluğunu değerlendirmektir: modül isimleri, KPI'lar, operasyon akışı, MVP kapsamı, gerçek veri kaynakları ve yönetici için kritik aksiyonlar netleşmelidir.
| Kontrol Alanı | Ürün Ekibinin Sorusu |
|---|---|
| Terminoloji | Modül isimleri ve ekran içindeki terimler gerçek depo operasyonunda doğru mu? |
| KPI | KPI'lar karar almak için anlamlı mı; formül, hedef ve veri kaynağı belli mi? |
| Akış | Operasyon akışı gerçek depo mantığına uyuyor mu; kullanıcı bu ekranda hangi işi tamamlayacak? |
| Öncelik | Hangi ekranlar MVP'ye girmeli, hangileri sonraki faza kalmalı? |
| Veri | Hangi veriler WMS, ERP, RF, IoT veya manuel sistemlerden alınmalı? |
| Aksiyon | Yönetici için kritik aksiyonlar, filtreler, detaylar ve onay adımları eksiksiz mi? |
MVP için önerilen çekirdek
İlk ürün kapsamı; karar aldıran ana ekranları, temel operasyon görünürlüğünü ve sınırlı optimizasyon sinyallerini içermeli. Gelişmiş simülasyon, otomasyon ve canlı entegrasyonlar ürün doğrulandıktan sonra büyütülmeli.
| Modül | MVP Önerisi | Gerekçe |
|---|---|---|
| Dashboard | MVP'ye girsin | Yöneticiye genel sağlık, risk ve öncelik görünümü verir. |
| Depot Radar | MVP'ye girsin | Projenin görsel karar destek vitrini ve depo gerçekliğini anlatan ana ekranıdır. |
| İş Emirleri | MVP'ye girsin | Operasyonun iş emri bazlı takip edilmesi için çekirdek modüldür. |
| Personel Verimliliği | MVP'ye girsin | Personel kapasitesi ve görev bağlamı olmadan karar desteği eksik kalır. |
| Control Tower | MVP'ye girsin | Kritik riskleri ve müdahale kararlarını yönetilebilir hale getirir. |
| Event Stream | MVP'ye girsin | Olan bitenin izini ve sebep-sonuç okumasını sağlar. |
| KPI Merkezi | MVP'ye girsin | Ürün başarısının metrik dili burada netleşir. |
| Reports | MVP'ye girsin | Yönetim ve pilot değerlendirme çıktıları için gerekir. |
| Slotting Optimizer | Temel versiyon | Hızlı değer üretebilir; gelişmiş optimizasyon sonraki faza bırakılabilir. |
| Workforce Optimizer | Temel versiyon | Personel yönlendirme fikrini gösterir; tam karar motoru sonra derinleşir. |
| Dijital ikiz | Sonraki faz | Ürün modeli ve gerçek veri oturmadan tam değer üretmesi zordur. |
| Gelişmiş AI önerileri | Sonraki faz | Önce iş kuralları, KPI ve onay akışı kesinleşmeli. |
| Gerçek zamanlı IoT entegrasyonu | Sonraki faz | Donanım ve kaynak sistem entegrasyonları ayrıca planlanmalı. |
| Mobil personel uygulaması tüm kapsam | Sonraki faz | İlk MVP'de cep görünümü yeterli; tam saha uygulaması ayrı kapsamdır. |
Mustafa Bey, DepotMR projesinde mevcut frontend demo artık ürün ekibinin değerlendirebileceği seviyeye getirildi. Bu sürümde amaç gerçek operasyon verisiyle çalışmak değil; ekran akışını, modül yapısını, terminolojiyi, KPI anlamlarını, karar destek mantığını ve MVP kapsamını netleştirmektir.
Veriler gerçek değildir; sistem mock seed data ile çalışmaktadır. Bu yüzden değerlendirmeyi veri doğruluğu üzerinden değil, ürün mantığı, ekran kullanışlılığı, operasyon dili ve karar alma ihtiyacı üzerinden yapmanızı öneriyoruz.
Ürün ekibinden beklentimiz; ekran ekran geri bildirim vermesi, hangi modüllerin MVP'ye gireceğini belirlemesi ve her ekran için eksik aksiyon, filtre, detay, terminoloji ve KPI ihtiyaçlarını çıkarmasıdır.
Ürün Ekibi İçin Geri Bildirim Formatı
Geri bildirimlerin ekran ekran ve aynı formatta toplanması, MVP kapsamını ve sonraki geliştirme önceliklerini daha hızlı netleştirir.
| Sayfa / Modül | Doğru Bulduklarımız | Eksik / Hatalı Alan | İstenen Değişiklik | Öncelik | Not |
|---|---|---|---|---|---|
| Proje Detayı | Proje kapsamı ve mevcut durum net anlatılıyor. | Ürün ekibi kararları ayrıca işaretlenebilir. | Karar listesi üzerinden aksiyon sahipliği belirlenmeli. | Orta | |
| Dashboard | Genel operasyon sağlığı hızlı okunuyor. | KPI hedefleri ve formülleri doğrulanmalı. | Karar almak için gerekli KPI seti netleştirilmeli. | Yüksek | |
| Depot Radar | Depo görünürlüğü ve katman fikri güçlü. | Gerçek lokasyon veri seviyesi belirlenmeli. | MVP'de hangi radar katmanlarının zorunlu olduğu seçilmeli. | Kritik | |
| Depot Radar Cep | Saha lideri için kompakt görünüm sağlıyor. | Mobilde ilk görülecek öncelikli bilgiler kesinleşmeli. | Cep ekranı için sade aksiyon listesi çıkarılmalı. | Yüksek | |
| Work Orders | İş emri takibi operasyon çekirdeğini temsil ediyor. | Durum isimleri ve SLA anlamları doğrulanmalı. | Filtre, detay ve müdahale aksiyonları belirlenmeli. | Kritik | |
| Workers | Personel görünürlüğü ve görev bağlamı kurulmuş. | Performans dili ve hassas veri sınırı netleşmeli. | Rol, vardiya ve yetkinlik alanları ürün ekibiyle gözden geçirilmeli. | Yüksek | |
| Control Tower | Risk ve müdahale ekranı doğru konumlanıyor. | Alarm seviyeleri ve eskalasyon akışı detaylanmalı. | Kritik uyarıların sorumluluk ve aksiyon kurgusu yazılmalı. | Yüksek | |
| KPIs | Karar dili için merkezi metrik alanı var. | Formül, hedef ve veri kaynağı eşleşmeleri doğrulanmalı. | MVP KPI kataloğu onaylanmalı. | Kritik | |
| Reports | Pilot ve yönetim çıktıları için zemin sağlıyor. | Rapor sıklığı ve dışa aktarım ihtiyacı belirlenmeli. | Rapor şablonları ve alıcı grupları çıkarılmalı. | Orta | |
| Slotting | Yerleşim önerisi değer alanı net. | Terminoloji ve öneri kabul akışı doğrulanmalı. | Temel MVP kapsamı ile ileri optimizasyon ayrılmalı. | Orta | |
| Forecast | İkmal ve talep sinyali fikri görünür. | Gerçek tahmin verisi ve eşik değerleri belirlenmeli. | İlk faz için uyarı kriterleri sadeleştirilmeli. | Orta | |
| Dock/Yard | Rıhtım ve saha senkronizasyonu temsil ediliyor. | Araç statüleri ve entegrasyon ihtiyaçları netleşmeli. | Pilot depo için gerekli dock akışı yazılmalı. | Düşük | |
| Locations | Lokasyon yoğunluğu okunabilir hale geliyor. | Gerçek depo planı ve lokasyon hiyerarşisi doğrulanmalı. | Heatmap eşikleri ve filtreleri belirlenmeli. | Orta | |
| ROI | Pilot değer anlatımı için faydalı çerçeve var. | Finansal varsayımlar ve ölçüm yöntemi onaylanmalı. | Pilot başarı kriterleri ürün ve yönetim ekibiyle netleştirilmeli. | Yüksek | |
| Settings | Kaynak sistem ve yetki fikri gösteriliyor. | Gerçek rol, entegrasyon ve ortam bilgileri sonraki faza bırakılmalı. | Canlıya geçiş öncesi yönetim kapsamı ayrıca tasarlanmalı. | Düşük |
Mustafa Bey, artık somut ürün değerlendirmesi yapılabilir.
Bu demo, gerçek veri entegrasyonundan önce ürünün doğruluğunu konuşmak için hazırlandı. Ekranlar, modüller, veri omurgası, mock data mantığı ve servis yaklaşımı artık ürün ekibinin somut geri bildirim verebileceği kadar görünür durumda.