Tedarikçi iflas ederse ne olur? Çıkış stratejisi

ESL yatırımı, beş ila sekiz yıllık bir ilişkidir ve bu sürede tedarikçi tarafında değişiklikler olabilir: firma el değiştirir, Türkiye temsilciliği sona erer, üretici modeli bırakır ya da firma faaliyetini durdurur.

Bu senaryolar düşük olasılıklıdır ama sonuçları ağırdır. Satın alma anında bir miktar hazırlık yapmak, sonradan yapılacak her şeyden ucuzdur.

Sistem ne kadar çalışmaya devam eder?

İyi haber: tedarikçi ortadan kalksa bile sistem bir süre çalışmaya devam eder.

Etiketler çalışır; son gösterdikleri fiyatı gösterirler ve sistemden gelen güncellemeleri almaya devam ederler.

Yerel sunucu kurulumunda yazılım çalışmaya devam eder; lisans süreye bağlıysa süre dolana kadar.

Bulut kurulumunda durum kritiktir: hizmet kapanırsa sistem durur. Bu, bulut modelinin en ciddi riskidir (bulut mu yerel sunucu mu).

Yani asıl kırılma noktası, yazılımın nerede çalıştığıdır.

Ne zaman çalışmayı durdurur?

Üç tetikleyici:

1. Lisans süresi dolar ve yenilenemez.
2. Bulut hizmeti kapanır.
3. Donanım arızalanır ve yedek parça bulunamaz.

Üçüncüsü kademelidir: sistem bir anda durmaz, yavaşça erir. Arızalanan etiketler yerine yenisi konamaz, park küçülür.

Satın alma anında alınacak dört önlem

1. Veri dışa aktarım garantisi

Eşleştirme tablosu, şablonlar, yapılandırma ve fiyat geçmişi standart bir formatta dışa aktarılabilmelidir.

Bu, hem tedarikçi değişimi hem felaket kurtarma için gereklidir ve aynı maddeyle karşılanır (ESL'de yedekleme ve felaket kurtarma).

2. Yerel çalışma seçeneği

Bulut modelinde bile, hizmet sona ererse yerel bir kuruluma geçiş hakkı sözleşmeye yazılabilir. Bu, yazılımın yerel kurulabilir bir sürümünün bulunmasını gerektirir.

Her üründe mümkün değildir ama sorulmalıdır.

3. Yedek parça stoku

Tedarikçiye bağımlılığı azaltmanın en somut yolu, kendi yedek stokunuzu tutmaktır. Kritik modellerden bir-iki yıllık ihtiyaç bulundurmak, tedarik kesintisine karşı tampon sağlar (yedek etiket oranı ne olmalı).

4. Standart protokol tercihi

Tescilli protokol, çıkışı fiilen imkânsız kılar. Bluetooth LE gibi standart protokoller teorik olarak başka bir yazılımla çalışabilme imkânı sunar.

Pratikte bu geçiş yine de kolay değildir ama tescilli sisteme göre bir seçenek fazlası vardır (Sub-1 GHz ile 2,4 GHz farkı).

Kaynak kodu emaneti işe yarar mı?

Büyük projelerde bazen kaynak kodu emaneti (escrow) talep edilir: tedarikçi iflas ederse kod bağımsız bir emanetçiden alınır.

ESL'de bu maddenin faydası sınırlıdır, çünkü sorun yazılımın kaynağı değil donanımın tescilli protokolüdür. Koda sahip olmak, protokolü çözmeyi kolaylaştırmaz.

Daha işlevsel olan, veri dışa aktarımı ve yerel çalışma garantisidir.

Türkiye temsilciliği değişirse

Daha sık karşılaşılan senaryo budur: üretici devam eder ama Türkiye'deki çözüm ortağı değişir.

Bu durumda donanım ve yazılım çalışmaya devam eder; değişen şey servis ve tedarik kanalıdır. Geçiş dönemi sancılı olabilir: yedek parça temini yavaşlar, destek bilgisi kaybolur.

Hazırlık: sistem dokümantasyonunun ve yapılandırma kayıtlarının sizde bulunması. Yeni ortak bunları sizden öğrenir (personel eğitimi ve devir teslim).

Türkiye'deki çözüm ortaklarının kapsamı servis ağı haritasında ve marka temsilcileri sayfasında kayıtlı.

Model üretimden kalkarsa

En sık karşılaşılan ve en yönetilebilir senaryo. Tedarikçi devam eder ama satın aldığınız model üretilmez.

Hazırlık: satın alma sırasında "bu model kaç yıl daha üretilecek ve yedek parça kaç yıl temin edilecek" sorusunun sorulması ve cevabın sözleşmeye yazılması (elektronik etiketin ömrü, tedarikçi seçerken sorulacak 20 soru).

Tedarikçi sağlamlığını değerlendirmek

Satın alma öncesinde bakılabilecek işaretler: firmanın kaç yıldır faaliyette olduğu, Türkiye'de kaç kurulumu bulunduğu, kaç kişilik teknik ekibi olduğu, referanslarının sürekliliği.

Ayrıca bir üreticinin bağımsız bir platforma veri doğrulaması yapıp yapmadığı, kurumsal şeffaflığı hakkında bir sinyal taşır (veri talepleri sicili, Şeffaflık Ligi).

Hiçbiri garanti vermez ama birlikte bir tablo oluşturur (referans ziyareti nasıl yapılır).

Risk seviyesini belirleyen tek soru

Bütün bu senaryolar içinde, riskin büyüklüğünü belirleyen tek bir soru var: yazılım nerede çalışıyor?

Yerel kurulumda, tedarikçi ortadan kalksa bile sistem çalışmaya devam eder. Güncelleme yapılır, etiketler basılır, operasyon sürer. Zamanla yedek parça sorunu büyür ama bu yıllar alır.

Bulut kurulumunda ise hizmet kapandığı gün sistem durur. Etiketler son hâllerini gösterir ama bir daha güncellenemez.

Bu fark, bulut mu yerel sunucu mu kararının en az konuşulan ama en ağır sonucudur.

Geçiş planı bir kez yazılmalı

Çıkış senaryosu için ayrıntılı bir plan hazırlamak gereksizdir; ama tek sayfalık bir not değerlidir:

1. Yazılım nerede çalışıyor, lisans ne zaman bitiyor?
2. Dışa aktarılabilir veriler neler, nasıl alınır?
3. Yedek stok ne kadar, kaç ay yeter?
4. Aynı protokolü kullanan başka tedarikçi var mı?

Bu dört sorunun cevabı, kurulum tamamlandığında bir kez yazılır ve yılda bir gözden geçirilir. Gerektiğinde sıfırdan araştırma yapmaktan çok daha hızlıdır.