Yazılım satışı için önce hedef firmalar belirleniyor, sonra bu firmalardaki “teknoloji severler” belirleniyor. Ortada hiçbir resmi talep olmamasına rağmen bunlara yaklaşıyorlar, entelektüel paylaşım başlıyor. Günün birinde bu konu açıldığında bu kişilerin kafasında bir asgari gereksinim hazır olacak ve bu da zaten yazılımcının çözümüyle aynı olacak. Başka bir ifadeyle satış ihtimali ortaya çıktığında yazılımcının işi büyük ölçüde hazır olacak.
Wall Street firma değerlendirmesinde beklentilerin ticareti var. Firmalar kabaca yıllık karlarının 10 – 25 katı kadar değerli görülüyor. Sıra dışı firmalarda bu çarpanlar 40 a kadar yükselebiliyor. Burada diğer bir unsur sektör ortalamasıdır, rakipler de aynı oranlarda büyüyorsa bu sektörel bir standarttır ve sizi “sıradan” yapar.
· Yazılımda programlama işi artık globaldir, fiziki olarak ürün veya malzeme sevkini gerektirmediği için ve prensip olarak İngilizce ortak paydada buluşulduğu için kolayca Hindistan gibi ucuz – nitelikli – İngilizce coğrafyalara yayılabilir. Ne kadar global ve ortak sistem tabanlı olursa o kadar kolay – ucuz şekilde 7/24 servis verilebilir.
· Yazılım dünyasında sorunlara cevap verilme süresi arandıktan cevap verene kadar geçen süre değildir, arandıktan sorun giderilene kadar geçen süredir.
· ERP sistemleri karmaşıklaşıyor, müşterilere özel yapılandırmalar artıyor, ilave modüller ortaya çıkıyor, tecrübeli ve eskisi gibi tüm yazılımı A dan Z ye bilen veya bilebilen mühendisler de artık bulunamıyor. Dolayısıyla cevaplar yetersizleşiyor, süreler uzuyor, umulmadık yan etkiler ortaya çıkabiliyor.
· Yazılımcının ikilemi : Daha hızlı ve iyi servis için sistemi sadeleştir ama müşteri memnuniyeti için sistemi “kişiselleştirerek” karmaşık hale getir…
· Suçlayacak birini bulmak sorunu çözmeye yetmiyor.
· Yazılımcıların ERP pazarının bel kemiği büyük firmalardır, ancak bunların çoğunda bir sistem zaten kuruludur, yenisini kurmak veya değiştirmek hem pahalı hem uzun süreli bir çabadır. Dolayısıyla pazarın doğal bir sınırı vardır.
· Yazılımcıların ERP ürününü orta ölçekli firmalara uygun bir fayda/maliyet ile uyarlamaları gerekir.
· Yazılımlar genellikle kullanıcı sayısı (lisans sayısı) üzerinden fiyatlanır, dolayısıyla mevcut müşterilerde sistemin yaygınlığı artırılabilirse ilave gelir elde edilebilir.
· Rekabet opsiyon zenginliğinde değil, uygulama kolaylığı / hızı / finansal tabloda görünür sonuç elde edilebilmesindedir.
· Görünebilirliğin sağlanması, veri entegrasyonu, … gibi sonuçlar kulağa hoş gelir ama finansal tablolarda fark edilmezler.
· TOC dağıtım çözümünün yazılıma çevrilmesi halinde gerçek zamanlı satışlara göre üretim / satın alma yapılabilir, aşırı stoklar azalır, yok satarlar azalır, stoklar azalır, satışlar artar ve bunların hepsi finansal tablolarda kolayca görünür.
· Yazılım jargonu (görünebilirlik, entegrasyon, veri doğruluğu,..) ile yönetim jargonu (maliyet, kar, satış, stok,..) farklıdır.
· Yazılım ne kadar sadeyse ve hızlı sonuç üretebilirse o kadar iyidir.
· Yazılım uygulaması sadece bilgisayar işi değildir, kültürel değişim gerektirir, tecrübeli ve TOC bilgili bir ekiple yürütülmesi gerekir.
· Yazılımcının genel prensibi müşterinin önce yeni sistemi kullanması sonra değişiklik talep etmesidir. Müşteriler her zaman haklıdırlar ama yine de müşterilerdir (gelir yaratmalıdırlar).
· Bugünün sorunlarıyla ilgilenmezsek endişe edecek bir geleceğimiz olmayabilir.
· Yazılımın ve temsil ettiği sistemin olası faydalar satın almanın azalması, stokların azalması, yok satarların azalması, akış süresinin kısalması ve satışların artmasıdır.
· Müşteri ancak bundan para kazanabilecekse yazılıma yatırım yapmaya istekli olabilir.
· MRP tarzında bir yazılım malzeme eksiklerini önlemede başarılı olabilir ancak sınırsız kapasite ve “itme” prensipli olduğu için stokları ve akış süresini artırır. DBR (Kısıt-Tampon-Bağ) sistemleri iç stokları kontrol eder, sınırlı kapasiteye göre çalışır, termin önceliklidir. Kısalan akış süresi “ekspres sipariş” olarak tedarikçi açısından ilave gelir yaratabilir.
· Tüm verinin hazır olması ve doğru olması gerekmez, sadece kısıttakinin hazır olması yeterlidir. İlgili ve gerekli bilginin, data yığınından seçilebilmesi gerekir.
· Sıralama değişikliklerinin terminlere etkisi görülebilmelidir. Acil işlere öncelik verebilmek için Tampon Yönetimi gerekir. Çok sık sıralama değişikliği işletme içinde sıkıntı yaratır, sisteme olan güveni zedeler. Her siparişe daha uzun emniyet payları verilirse terminler tutabilir ama hem akış süreleri çok uzar hem de işletme içinde boşluklar oluşur.
· Artan kapasite nedeniyle kimsenin işinden olmaması için firmaya daha çok sipariş getirilmelidir. Lokal optimalardan vaz geçilmelidir.
· ERP sisteminin en hızlı sonuç alacak ve en çok işe yarayacak kısımları sınırlı kapasiteye göre kısıtta çizelgeleme yapmak ve tampon yönetmektir. Bunlar için mevcut bilgi sisteminin değiştirilmesi gerekmez, yama olarak eklenebilir. Her durumda sadece yazılımın değişmesi yetmez, kültür de değişmelidir.
· Bugün yazılım firmalarının her yeni modülü kendilerinin hazırlaması şart değildir, işe yarar ve yerel olarak kabul görmüş bir ürünü olan herhangi bir yazılım firması satın alınabilir.
· İdeal kurulum : Firma üst yönetimi doğrudan talep eder, iflas etmemek için tek çıkış yolu olarak bu projeye tutunurlar, fabrika müdürleri ilgili eğitimleri bizzat verir, kısa bir terminde görünür sonuç almak için ciddi baskı vardır. Bu şartlarda neredeyse hiçbir dirençle karşılaşılmaz. Eskiye dönüş hissi verecek değişimler istenmez. Dikkat dağılmaz. Yalın prensipleri kolaylıkla gereken noktalara uygulanabilir.
· Yazılımcı açısından en büyük Pazar üretimdir, ancak proje yönetimi (mühendislik, tasarım,..) de oldukça bakir bir alandır.
· Proje yönetiminde Kısıtlar Teorisi çözümü Kritik zincir Proje Yönetimidir (CCPM).
· Tahminler özünde hatalıdır, tahmine göre tedarik yanıltır. Bunun yerine fiili satışlara göre dinamik olarak güncellenen stok tamponları önerilir.
· Kısıtlar Teorisinin dağıtım çözümünde ürünler merkezi depoya toplanır, satış noktalarına günlük sevkiyat yapılır, merkezi stokta tamponlar dinamik güncellenir ve dolu tutulur.
· Firma içinde veya tedarik zinciri boyunca doğru performans ölçüleri geç kalmanın bedeli olarak TDD (Çıktı-gün-TL) ve erken yapmanın bedeli olarak IDD (Stok-gün-TL) şeklindedir.
· Tedarik zincirini bir bütün haline getirmek için “son tüketiciye satılana kadar satış yapılmış sayılmaz” prensibi gerekir.
o Akış süresi kısaldığında ticari teamüle uygun vadeler normalleşir
o Son tüketiciye yapılan satışa göre zincir boyunca geriye doğru hammadde tutarı kadar ödeme yapılır
o Firmaların hepsi birbirlerinin TDD ve IDD performanslarını görür, kötü performans gösterenler zincirden uzaklaştırılabilir.
· Yazılımcının doğru seçimi firmaları BT yatırımına zorlamadan (buluttan erişim) ve yaratılacak gelire oranlı (cirodan % olarak fiyatlanan, kader ortağı, lisans sayısı sormayan) bir tekliftir.
Hiç yorum yok:
Yorum Gönder