BIM Satın Alma / 13 dk
BIM Danışmanlığı Nasıl Satın Alınır? Teknik Şartname, Teklif ve Kabul Rehberi
BIM danışmanlığı için RFP ve teknik şartname nasıl hazırlanır? Kapsam, teslimatlar, ISO 19650, IFC/IDS, entegrasyon, fiyatlandırma ve kabul kriterleri.
Danışmanlık, model üretimi ve yazılım lisansı ayrı kalemler olmalı
BIM danışmanlığı strateji, bilgi gereksinimleri, standartlar, kontrol ve kabul süreçlerini tasarlar. Model üretimi ise tanımlanmış kapsamda geometri ve bilgi oluşturur. Yazılım lisansı veya platform entegrasyonu farklı maliyet ve sorumluluklar içerir. Tek satırlık 'BIM çözümü' teklifi, hangi işin kime ait olduğunu belirsiz bırakabilir.
Teklif tablosunda bu iş paketlerini ayrı gösterin. Danışmanın aynı zamanda uygulayıcı olması durumunda bağımsız kalite kontrol ve çıkar çatışması yönetimini sözleşmede değerlendirin.
Şartnamenin ilk bölümü: Amaç, mevcut durum ve kapsam sınırları
Tesis türü, bina sayısı, yaklaşık alan, kritik ekipman sınıfları, mevcut CAD/BIM/CMMS/SCADA sistemleri, doküman durumu ve hedef kullanım senaryoları tarif edilmelidir. 'Tüm tesis BIM'e dönüştürülecek' ifadesi tek başına yeterli değildir.
Kapsam dışı alanları da açık yazın: örneğin detaylı yapısal analiz, bütün kabloların 3D modellenmesi, tüm sensörlere telemetri eklenmesi veya sahada ölçülemeyen kapalı alanların doğrulanması otomatik olarak kapsama dahil sayılmamalıdır.
Teslimatlar: Ölçülebilir doküman ve veri paketleri
Hazırlık değerlendirmesi ve boşluk analizi; BIM dönüşüm yol haritası; varlık bilgi gereksinimleri ve sınıflandırma matrisi; modelleme ve koordinat kuralları; CDE bilgi akışı; IFC/IDS kalite kuralları; entegrasyon mimarisi; pilot model ve varlık envanteri; kabul raporu; eğitim ve işletme prosedürleri ayrı teslimatlar olarak listelenebilir.
Her teslimat için dosya biçimi, sürüm, sorumlu, inceleme süresi, onay yetkisi ve revizyon döngüsü belirtilmelidir. Bir PDF raporu ile çalıştırılabilir veri doğrulama kuralı aynı kabul ölçütüne sahip değildir.
Teknik uygunluk: IFC, IDS, koordinatlar ve sistem entegrasyonu
Hedef IFC şeması, gerekli nesne sınıfları, özellikler, birimler, varlık kimlikleri ve mekânsal referanslar açıkça yazılmalıdır. IDS ile denetlenebilecek bilgi alanları ayrı; geometrik doğruluk ve saha uygunluğu için manuel veya özel testler ayrı tanımlanmalıdır.
CMMS/EAM, ERP, GIS, BMS ve SCADA bağlantılarında kaynak sistem, veri sahibi, arayüz, güvenlik, güncelleme sıklığı, hata yönetimi ve test sorumluluğu belirlenmelidir. 'API entegrasyonu dahil' gibi belirsiz ifadeler yerine örnek uçtan uca senaryolar istenmelidir.
Teklifleri nasıl karşılaştırmalı?
Danışmanlık ve saha keşfi için uzman-gün veya kapsam bazlı sabit bedel; varlık verisi ve modelleme için sınıf/adet; geometri için uygun alan veya karmaşıklık ölçüsü; entegrasyon için arayüz ve senaryo bazlı fiyatlandırma talep edilebilir. Böylece farklı tekliflerin hangi işleri içerdiği görülebilir.
Örnek değerlendirme matrisi oluşturun: yöntem ve teknik yaklaşım, benzer tesis deneyimi, ekip uzmanlığı, kalite ve kabul planı, takvim, toplam yaşam döngüsü maliyeti. Puan ağırlıkları kurumun satın alma politikasına göre önceden belirlenmeli; burada evrensel bir yüzde önerilmez.
Kabul kriteri örnekleri
Pilot kritik varlıkların tamamında benzersiz kimlik bulunması, zorunlu alanların belirlenen eşiklerde dolu olması, mükerrer kayıtların giderilmesi, örneklem saha doğrulamasının tamamlanması ve seçilen bakım senaryosunun modelden iş emrine izlenebilmesi gibi ölçülebilir kriterler kullanılabilir.
Eşikler sözleşme öncesinde tesisin riskine ve veri durumuna göre kararlaştırılmalıdır. Her koşulda yüzde yüz doluluk istemek, mevcut tesislerde erişilemeyen veya gerçekten bilinmeyen bilgiler için gerçekçi olmayabilir.
Sözleşme ve yönetişim riskleri
Model ve verinin kullanım hakları, kaynak dosyaların teslimi, üçüncü taraf lisansları, bilgi güvenliği, yedekleme, erişim, veri taşınabilirliği, değişiklik talepleri ve garanti/ayıp düzeltme süreleri netleştirilmelidir. Danışmanın teslim ettiği bilgi yönetimi yaklaşımının operasyonel sorumluluğu kimlere devredileceği de yazılmalıdır.
Octatus değerlendirmesinde platform, danışmanlık ve uygulama hizmetlerini ayrı iş paketleri olarak ele almak kapsamı şeffaflaştırır. Hizmetlerin ticari olarak sunulduğu ayrıca doğrulanmalıdır.
Sahadan örnek: karar anında hangi bilgi gerekir?
'BIM modeli teslim edilecektir' ifadesi denetlenebilir bir şartname değildir. Hangi varlıkların hangi kimlik ve özelliklerle, hangi IFC sürümünde ve hangi doğrulama yöntemiyle teslim edileceği yazılmalıdır.
Bir BIM danışmanlığı ihalesinde yalnızca LOD seviyesi istenmesi, işletme verisinin teslim edileceğini garanti etmez. Varlık sınıfları, zorunlu özellikler, örneklem doğrulaması, koordinat sistemi ve belge bağlantıları ayrıca tanımlanmalıdır. Belirsiz kapsam sonradan değişiklik taleplerine dönüşür.
Uygulama ve kabul kontrolü
Kabulde örnek varlık eşlemesi, IFC yeniden açma testi, eksik alan raporu, koordinat kontrolü, revizyon geçmişi ve düzeltme süresi ayrı maddeler olmalıdır.
Şartname pilotunda bir mekanik ekipman sınıfı için örnek teslim hazırlanır. İstekli firmanın sunduğu modelde kimlik, teknik alan, bakım belgesi ve sistem ilişkisi kontrol edilir. Kabul koşulu yalnızca dosyanın açılması değil zorunlu alanların doğrulanmasıdır.
Yatırım ve kapsam kararı nasıl verilir?
BIM danışmanlığı tekliflerinde toplam bedelin karşılaştırılabilmesi için saha keşfi, model üretimi, özellik doğrulaması ve işletmeye devir kalemleri ayrılmalıdır. Bir teklif IFC dosyası teslim ederken diğeri kimlik eşleme ve kabul testlerini de içeriyorsa doğrudan fiyat kıyaslaması yanıltıcı olur. Şartname örnek ekipman için zorunlu alanları ve kusur giderme yükümlülüğünü açıkça tanımlamalıdır. Teslim edilen verinin sonraki tedarikçi tarafından kullanılabilirliği de değerlendirilir.
Teklif karşılaştırmasında modelleme, saha ölçümü, entegrasyon ve eğitim kalemleri ayrı fiyatlandırılmalıdır. Kaynak dosya teslimi, kullanım hakları, revizyon süreci ve kusur giderme yükümlülüğü sözleşmede açık kalmalıdır. En düşük ilk fiyat en düşük yaşam döngüsü maliyeti olmayabilir.
Satın alma öncesi ihtiyaç tespiti ve iş hedefleri
BIM danışmanlığı alımında ilk adım bir yazılım markası veya model dosyası formatı seçmek değildir. Kurum hangi kararları iyileştirmek istediğini, hangi verilerin eksik olduğunu ve mevcut iş akışlarının nerede aksadığını açıklamalıdır. Bir kampüs işletmecisi kritik ekipmanların bakım belgelerine erişmek isterken yatırımcı tasarım koordinasyonunu ve yüklenici teslimatını önceliklendirebilir. Bu farklı amaçlar aynı şartnameyle yönetilmemelidir.
İhtiyaç tespitinde iş birimleri, bakım, mühendislik, BT, bilgi güvenliği ve satın alma birlikte çalışmalıdır. Mevcut model, as-built belge, varlık envanteri ve işletme sistemlerinden örnekler incelenmelidir. Çıktı kullanım senaryosu, veri boşluğu, sorumlu taraf ve başarı göstergesi içeren kısa bir ihtiyaç matrisi olmalıdır. Böylece danışmanlık işi belirsiz bir dönüşüm sloganı yerine ölçülebilir teslimatlara bağlanır.
Danışmanlık, uygulama ve lisans kalemlerini ayırmak
Tekliflerde strateji danışmanlığı, saha keşfi, veri temizliği, BIM modelleme, yazılım lisansı, entegrasyon, eğitim ve destek aynı fiyat altında toplandığında karşılaştırma güçleşir. Bir tedarikçi yalnızca danışmanlık verirken diğeri model üretimini ve platform kurulumunu da üstlenebilir. Aynı kapsamı satın almadan toplam fiyatı kıyaslamak yanlış karar doğurur. Her iş paketi için miktar, teslimat, kabul yöntemi ve varsayım ayrı istenmelidir.
Örneğin mevcut tesisin 500 kritik ekipmanı için kimlik doğrulaması ve veri sözlüğü hazırlanması, bütün binanın lazer taranmasından farklı maliyet kalemidir. Lisansın ilk yıl bedeliyle beş yıllık toplam sahip olma maliyeti de ayrılmalıdır. Değişiklik taleplerinin birim fiyatlandırma yöntemi sözleşme öncesinde belirlenmelidir. Böylece kapsam genişlemesi kontrol altında tutulabilir.
Bilgi gereksinimleri: OIR, AIR, PIR ve EIR
ISO 19650 yaklaşımında bilgi gereksinimleri kurumsal, varlık, proje ve bilgi alışverişi seviyelerinde ele alınabilir. OIR kurumsal kararları, AIR işletme varlık bilgisini, PIR proje kararlarını, EIR belirli bilgi alışverişi beklentilerini tanımlamaya yardımcı olur. Şartnameye bu kısaltmaları eklemek tek başına yeterli değildir. Her bilgi gereksinimi hangi karar için gerekli olduğunu ve nasıl doğrulanacağını göstermelidir.
Örneğin UPS varlığı için asset ID, kapasite, seri numarası, konum, bakım prosedürü ve besleme ilişkisi istenebilir. Ancak tasarım kapasitesi ile anlık ölçüm farklı kaynaklardan gelir. Şartname veri türünü, birimi, kaynak otoritesini, teslim zamanını ve doğrulama yöntemini açıklamalıdır. Gereksiz bilgi istemek maliyeti artırırken kritik alanları atlamak işletme değerini azaltır.
Kapsam sınırları ve hariç tutulan işler
İyi bir teknik şartname yalnızca yapılacak işleri değil yapılmayacak işleri de açıklar. Saha keşfi dahil mi, kritik bağlantılar fiziksel olarak doğrulanacak mı, nokta bulutu üretilecek mi, eski bakım belgeleri temizlenecek mi, mevcut CMMS ile bağlantı kurulacak mı gibi sorular yanıtlanmalıdır. Belirsiz sınırlar sonradan fiyat artışı ve sorumluluk tartışması doğurabilir.
Örneğin danışmanlık kapsamında veri sözlüğü ve entegrasyon mimarisi hazırlanıp yazılım geliştirme kapsam dışı bırakılabilir. Böyle bir durumda mimari teslimatın API sözleşmesi, örnek veri ve test senaryosu içermesi istenebilir. 'Gerekli tüm işler dahildir' gibi geniş ifadeler yerine somut iş paketleri ve değişiklik yönetimi kuralları kullanılmalıdır. Mevcut altyapı erişim izinleri de alım öncesinde netleştirilmelidir.
Teslimat listesi ve kabul edilebilir kanıt
Danışmanlık çıktıları yalnızca sunum dosyalarıyla sınırlı olmamalıdır. Kullanım senaryosu matrisi, bilgi gereksinimi sözlüğü, varlık sınıflandırması, kimlik stratejisi, CDE süreçleri, IFC eşleme raporu, entegrasyon mimarisi, güvenlik gereksinimleri ve kabul testleri somut teslimatlar olabilir. Her belgenin sahibi, revizyonu ve onay koşulu belirtilmelidir.
Örneğin veri sözlüğü için alan adı, açıklama, veri tipi, birim, zorunluluk, kaynak ve doğrulama kuralı istenebilir. Mimari teslimatta sistem sınırları, veri akışları, hata davranışı ve yetkilendirme açıklanmalıdır. Bir belgenin teslim edilmesi içerdiği bilgilerin kabul edildiği anlamına gelmez. Kabul, örnek kullanım senaryosu üzerinde doğrulanabilir olmalıdır.
IFC, IDS ve açık veri taşınabilirliği
Açık veri biçimi istemek tedarikçi bağımlılığını azaltabilir; ancak IFC dosyasının açılması veri bütünlüğünü garanti etmez. Kaynak modelden aktarım sırasında sınıflandırma, özel parametre, birim, koordinat ve sistem ilişkisi kaybı yaşanabilir. Teknik şartname kullanılacak IFC sürümünü ve hedef uygulama testlerini tanımlamalıdır. IDS gibi makine tarafından kontrol edilebilir gereksinimler uygun alanlarda kullanılabilir.
Kritik ekipman örneklerinde kaynak ve hedef varlık kimliği, kapasite, üretici, model, konum ve bağlantılar karşılaştırılmalıdır. Export ayarları, eşleme matrisi ve hata raporu teslim edilmelidir. Otomatik IDS doğrulaması saha gerçekliğini kanıtlamaz; fiziksel doğrulama ayrı süreçtir. Sözleşme sonunda verinin yeniden kullanılabilir biçimde dışa aktarımı test edilmelidir.
BIM–GIS koordinat ve mekânsal doğruluk şartları
Çok tesisli kampüslerde BIM modelinin harita üzerinde görünmesi yeterli doğruluk kanıtı değildir. Kaynak koordinat sistemi, hedef CRS, birimler, düşey datum, kuzey yönü ve dönüşüm parametreleri tanımlanmalıdır. Modelin elle sürüklenerek yaklaşık konuma yerleştirilmesi mühendislik ölçümüne eşdeğer değildir. Kullanım amacına göre kabul toleransları önceden kararlaştırılmalıdır.
Şartname kontrol noktaları, dönüşüm raporu, örnekleme yöntemi ve model revizyonundan sonra yeniden doğrulama sürecini içermelidir. GIS bina kimliği ile BIM bina nesnesi arasında kontrollü eşleme kurulmalıdır. Kazı ve altyapı müdahalesinde görsel konumlandırmanın tek başına güvenilir olmadığı belirtilmelidir. Ölçüm yetkinliği gereken işlerde uygun uzmanlık ve saha kanıtı istenmelidir.
CDE, revizyon ve onay iş akışları
Common Data Environment yalnızca ortak dosya depolama alanı olarak tarif edilmemelidir. Bilgi konteynerlerinin adlandırması, revizyonu, durumu, paylaşımı, yayın onayı ve arşivlenmesi süreç olarak tanımlanmalıdır. Taslak bir modelin onaylı uygulama belgesi gibi kullanılması ciddi yeniden iş riski yaratabilir. Erişim izni ile yayınlama yetkisi ayrı kontrol edilmelidir.
Kabul testinde farklı rollerle taslak yükleme, inceleme, onay, yayın ve geri çekme senaryoları çalıştırılabilir. Eski revizyonun yanlışlıkla güncel görünmemesi doğrulanmalıdır. Denetim izinin kullanıcı, zaman ve işlem ayrıntısı içermesi istenebilir. Sözleşme bitiminde bilgi konteynerleri ve revizyon geçmişinin nasıl teslim edileceği açıklanmalıdır.
Entegrasyon sözleşmeleri ve kaynak otoritesi
BIM platformunun ERP, CMMS, BMS, SCADA veya BT yönetim sistemiyle entegrasyonu yalnızca API bağlantısına indirgenmemelidir. Her veri alanının yetkili kaynağı, varlık kimliği eşlemesi, senkronizasyon sıklığı, hata davranışı ve güvenlik sınırı belirlenmelidir. Aynı fiziksel ekipman farklı sistemlerde farklı kodlarla bulunabilir. Belirsiz eşlemelerin otomatik birleştirilmesi yanlış bakım veya etki analizi üretir.
Octatus fiziksel varlık bağlamını, Enlogy enerji/OT ölçümünü, Argamos BT servis bağımlılıklarını ve Velocize mühendislik izini ilişkilendirebilecek uzman sistemler olarak düşünülebilir. Ancak gerçek entegrasyon yetenekleri proje bazında doğrulanmalıdır. Salt okunur veri erişimi ile kontrol komutu yetkisi ayrı tutulmalıdır. OT sistemlerinin operasyonel otoritesi görselleştirme platformuna kendiliğinden devredilmemelidir.
Bilgi güvenliği, tenant izolasyonu ve veri egemenliği
BIM verileri kritik altyapı konumları, güvenlik sistemleri ve tesis kapasitesi gibi hassas bilgiler içerebilir. Teknik şartname veri sınıflandırması, erişim matrisi, kimlik doğrulama, şifreleme, denetim izi, yedekleme ve kurtarma gereksinimlerini içermelidir. Çok kiracılı sistemlerde bir tenant kullanıcısının başka tenant verisini API veya arama üzerinden görmemesi test edilmelidir.
Kapalı ağ veya yerel barındırma gereksinimi varsa lisans doğrulama, harita servisleri, güncelleme, telemetri ve uzaktan destek dahil dış veri akışları incelenmelidir. Sadece 'veri ülkede tutulur' ifadesi bütün veri egemenliği sorularını çözmez. Alt yüklenici erişimleri ve olay bildirimi süreçleri sözleşmede açıklanmalıdır. Güvenlik testleri kabul aşamasına bırakılmadan tasarıma dahil edilmelidir.
Teklif puanlama matrisi nasıl kurulmalı?
Teklifleri karşılaştırırken yalnızca fiyatı puanlamak yerine teknik yaklaşım, ekip yetkinliği, teslimat kanıtı, veri taşınabilirliği, güvenlik, işletme desteği ve toplam sahip olma maliyeti değerlendirilmelidir. Ağırlıklar alımın amacına göre önceden ilan edilmeli ve teklif geldikten sonra keyfî değiştirilmemelidir. Bir tedarikçinin güçlü görsel demosu veri doğruluğu ve işletme sürdürülebilirliği yerine geçmez.
Örnek bir değerlendirmede teknik uygunluk, benzer proje kanıtı, kabul metodolojisi, güvenlik ve beş yıllık maliyet ayrı başlıklar olabilir. Kesin yüzdeler kurumun satın alma kurallarına göre belirlenmelidir. Her puan somut teklif maddesine veya örnek teslimata dayanmalıdır. Eksik kritik gereksinimlerin yüksek fiyat puanıyla telafi edilip edilemeyeceği alım öncesinde açıklanmalıdır.
Pilot kabulü için negatif test senaryoları
Kabul testleri yalnızca sistemin doğru veriyle çalıştığı örnekleri içermemelidir. Yanlış seri numarası, mükerrer varlık, eski belge revizyonu, yanlış koordinat, eksik besleme ilişkisi, gecikmiş sensör verisi ve yetkisiz kullanıcı erişimi gibi durumlar denenmelidir. Her senaryo için beklenen davranış ve hata sınıfı yazılmalıdır. Kritik hata açıkken toplam tamamlanma yüzdesi yüksek olsa bile kabul ertelenebilir.
Örneğin UPS kaydının beslediği pano belirsizse sistem kesin etki listesi üretmemelidir. Bir kullanıcı yetkisi olmayan tesisin dokümanını arama sonuçlarında görmemelidir. İletişimi kesilen sensörün son ölçümü canlı değer gibi sunulmamalıdır. Düzeltme sonrası yeniden test raporu ve kanıt bağlantısı istenmelidir.
Ödeme kilometre taşlarını bilgi kalitesine bağlamak
Ödeme planı yalnızca çalıştay yapıldı, rapor teslim edildi veya model dosyası yüklendi gibi faaliyetlere bağlanırsa sonuç kalitesi ikinci planda kalabilir. Kilometre taşları kabul edilmiş veri sözlüğü, doğrulanmış pilot varlık kümesi, başarılı IFC aktarım testi ve tamamlanmış eğitim gibi çıktılara dayanabilir. Bununla birlikte kabul kriterleri gerçekçi ve ölçülebilir olmalıdır.
Örneğin pilot için belirlenen kritik alanların doğruluk oranı ve hata düzeltme süresi sözleşmede tanımlanabilir. Ancak bu oranlar keşif yapılmadan rastgele vaat edilmemelidir. Saha erişimi ve üçüncü taraf veri kalitesi gibi bağımlılıklar açıkça belirtilmelidir. Uyuşmazlık çözümü ve yeniden teslim süreci ödeme planıyla tutarlı olmalıdır.
Fikri mülkiyet, veri sahipliği ve çıkış planı
BIM danışmanlığı sonunda üretilen bilgi sözlüğü, model, eşleme tabloları, test senaryoları ve dokümantasyonun kullanım hakları açıkça düzenlenmelidir. Kurumun kendi varlık verisine erişimi belirli bir tedarikçinin lisansına veya kapalı dosya biçimine bağımlı kalmamalıdır. Sözleşmede kaynak dosyalar, açık dışa aktarım ve teslim sonrası destek koşulları tanımlanmalıdır.
Örneğin yeni bir danışmanla çalışmaya geçildiğinde mevcut kimlik eşleme tablosu ve veri kalite raporları yeniden üretmek zorunda kalınmamalıdır. Kullanılan üçüncü taraf kütüphane ve veri lisansları ayrıca incelenmelidir. Gizlilik ve veri silme yükümlülükleri çıkış planına dahil edilmelidir. Sözleşme sona erdiğinde erişimlerin kapatılması ve teslim edilen verinin doğrulanması planlanmalıdır.
İşletme sonrası güncelleme ve eğitim kapsamı
Danışmanlık teslimi sonrasında ekipman değişimleri, proje revizyonları ve bakım kayıtları güncellenmeye devam eder. Bu güncellemeleri kimin başlatacağı, kimin doğrulayacağı ve hangi sürede yayınlayacağı tanımlanmazsa modelin doğruluğu düşer. Eğitim yalnızca yazılım menülerini göstermemeli; kimlik eşleme, veri kalite kontrolü, belge revizyonu ve hata bildirme süreçlerini de kapsamalıdır.
Örneğin yeni pompa montajında eski fiziksel cihazın geçmişi korunur, yeni seri numarası ve test belgesiyle yeni kayıt oluşturulur. Kurumsal asset ID ve fonksiyonel pozisyon ilişkisi güncellenir. Bu senaryo kullanıcı kabul eğitiminde çalıştırılabilir. Kurumun yeni personeli kendi başına eğitebilmesi için rol bazlı dokümantasyon ve örnekler teslim edilmelidir.
Aşamalı ihale ve 90 günlük pilot
Büyük portföyü tek seferde kapsayan belirsiz sözleşme yerine keşif, pilot, entegrasyon ve yaygınlaştırma fazları planlanabilir. İlk ay paydaş ihtiyaçları ve veri olgunluğu incelenir; ikinci ay sınırlı kritik varlık grubunda bilgi modeli ve eşleme kurulur; üçüncü ay gerçek kullanıcı görevleri ve negatif testler çalıştırılır. Takvim örnektir ve saha koşullarına göre değişebilir.
Pilot sonunda doğrulanmış varlık oranı, yanlış eşleme sayısı, kullanıcı görev süresi, güvenlik bulguları ve genişleme birim maliyeti raporlanmalıdır. Devam kararı ölçülebilir kabul sonuçlarına dayanmalıdır. Kimlik veya veri kalitesi sorunu çözülmediyse yeni bina eklemek yerine temel süreç düzeltilmelidir. Bu yaklaşım hatalı yöntemin tüm portföye yayılmasını önleyebilir.
Teklif değerlendirme toplantısında sorulacak sorular
Tedarikçiye benzer projelerde veri uyuşmazlıklarını nasıl yönettiği, IFC aktarımında hangi alanları test ettiği ve yanlış sistem ilişkilerini nasıl doğruladığı sorulmalıdır. Örnek teslimat, anonimleştirilmiş kalite raporu ve negatif test senaryosu istenebilir. Sadece sertifika veya ürün ortaklığı gerçek işletme başarısını kanıtlamaz. Teklifin varsayımları ve kapsam dışı işler ayrıntılı incelenmelidir.
Ayrıca kapalı ağda çalışma, veri dışa aktarımı, lisans artışı, bakım sorumluluğu, personel değişimi ve alt yüklenici erişimi açıklanmalıdır. Pilotun başarısız olması halinde hangi düzeltmelerin hangi bedelle yapılacağı sorulmalıdır. Tedarikçi değerlendirmesi pazarlama vaatlerinden doğrulanabilir teknik ve sözleşmesel kanıtlara taşınmalıdır.
Not: Teknik standartlara ilişkin açıklamalar bilgilendirme amaçlıdır. Ürün yetenekleri ve entegrasyon kapsamı proje bazında doğrulanmalıdır.