Hesap çıktısı teklife nasıl dönüşür?

Hesap çıktısının teklif kalemine dönüşmesi, mühendislik hesabının seçtiği ürünün kendi girdisiyle birlikte ticari kayda geçmesidir. Bu dönüşümü mümkün kılan karar, kayıtlar doğarken veriliyor; sepet kalemi doğduğu anda hangi projeye ait olduğunu taşıyor. Zincirin kurulamadığı yer de belli: hesap yöntemi kurumda standartlaşmamışsa koda gömülecek tek bir hesap yoktur ve ilk iş yöntemi sabitlemektir.

Teklifi yazan kişi hesabı yapan kişi değil

Resterm elektrikli ısıtıcı üretiyor. Bu ürün grubunda doğru cihaza karar vermek bir mühendislik hesabı gerektiriyor. Belirleyici olan hesabın kimde durduğu. Teklifi hazırlayan kişi çoğunlukla hesabı yapan kişi değil. Satış tarafı bir teklif çıkaracağı zaman hesabı bilen kişiye sıra bekliyor.

Bu bekleme bir iletişim aksaklığı gibi görünür. Değildir. Bilginin tek bir kişide durmasının doğrudan sonucudur. Uzman izne çıktığında, aynı gün birden çok teklif istendiğinde ya da masasında başka bir iş olduğunda satış durmuyor; yavaşlıyor. Yavaşlarken de rakamın kalitesi düşüyor, çünkü aceleyle verilen değer sonradan düzeltiliyor.

Yavaşlamanın ikinci bir yüzü daha var: hangi tekliflerin hiç çıkmadığı. Sıra beklemek uzadıkça küçük işler öne alınmıyor, sessizce düşüyor. Kimse bunu kayıp saymıyor, çünkü düşen teklif hiçbir yerde görünmüyor.

Kurumların bu noktada denediği ilk yol genellikle eğitim oluyor. Satış ekibine hesabın mantığı anlatılıyor, bir kılavuz yazılıyor. Kılavuz bir süre işe yarıyor. Ürün gamı genişlediğinde ya da hesap yöntemi güncellendiğinde kılavuzun kendisi ikinci bir bakım kalemi hâline geliyor. Yazılı doküman uzmana bağımlılığı kırmıyor; güncellenmesi gereken ikinci bir nesne ekliyor.

Bağımlılığı kıran şey hesabın yazılıma taşınması oldu. Kullanıcı ısıtma ihtiyacını giriyor; mühendislik hesabını yapan ve uygun elektrikli ısıtıcıyı seçen, yazılımın kendisi. Uzmanın rolü ortadan kalkmıyor, yer değiştiriyor. Uzman artık her teklifte değil, hesabın kuralı değiştiğinde devrede oluyor.

Karşı durum burada net yazılmalı. Hesap yöntemi kurumda standartlaşmamışsa, yani her mühendis kendi yaklaşımıyla çalışıyorsa, yazılıma gömülecek tek bir hesap yoktur. O durumda ilk iş yazılım değil, yöntemin sabitlenmesi. Yazılım standart üretmez; mevcut standardı çoğaltır. Standardı olmayan bir hesabı koda gömmek, bir kişinin yöntemini kurumun yöntemi ilan etmek olur.

Üç kayıt üç ayrı ortamda yaşayınca

Yazılımdan önceki düzende zincirin halkaları birbirine bakmıyordu. Mühendislik hesabı bir hesap tablosunda tutuluyordu. Ürün bilgisi ayrı bir belgede duruyordu. Teklif ise üçüncü bir ortamda hazırlanıyordu. Üç kayıt yeri de kendi başına düzgün çalışıyordu; kimse dosyaların içinde hata aramıyordu.

Kopukluğun mekanizması dosyaların sayısı değil, aralarında referans olmaması. Üç kayıt birbirinin varlığından habersiz. Bir teklif satırının arkasında hangi hesabın durduğu, belge kapandığı anda görünmez oluyor. Kayıtlar arasında bağ olmadığı için aranacak bir alan da yok.

Bedel revizyonda ödeniyor. Müşteri kapasiteyi büyütmek ya da kapsamı daraltmak istediğinde teklifin hangi girdiden çıktığı bilinmediği için hesap yeniden yapılıyor. Yani ikinci teklif birincinin üzerine değil, sıfırın üzerine kuruluyor. Revizyon sayısı arttıkça bu maliyet katlanarak artıyor; her tur kendi hesabını yeniden gerektiriyor.

İkinci bedel doğrulamada. Müşteri bir rakamın dayanağını sorduğunda cevabı verecek olan kayıt değil, o hesabı yapmış kişi oluyor. Cevap doğru olsa bile kurum bunu gösteremiyor. Gösterilemeyen dayanak, pazarlıkta her zaman zayıf taraf.

Bu düzenin en sinsi yanı, gündelik işleyişte sorun çıkarmaması. Hesabı yapan kişi masasındayken zincir görünmez biçimde tamamlanıyor; eksik olan halka o kişinin kendisi. Sistem çalışıyor gibi görünüyor, çünkü bir insan boşluğu her gün elle kapatıyor. Boşluk ancak o insan yerinde olmadığında ortaya çıkıyor ve o an genellikle en kötü an oluyor.

Kuruluş hedefi tek cümleyle yazılabilir: mühendislik hesabını, ürün seçimini ve teklif kaydını tek zincirde tutmak. Bu bir entegrasyon işi değil, kuruluş kararı. Entegrasyon üç ayrı sistemi birbirine bağlar ve her bağ kendi bakımını ister; bağlardan biri sessizce koptuğunda kimse fark etmez. Kuruluş kararı ise üç kaydı baştan aynı yerde oluşturur. Kopacak bir bağ yoktur, çünkü ayrı yaşayan bir kayıt yoktur.

Zincir, girdi bir ihtiyaç olduğunda başlar

Bir satış yazılımının ilk sorusu, kullanıcıdan ne istediğidir. Klasik kurgu ürün kodu ya da model adı ister. Bu isteğin gizli bir varsayımı var: kullanıcı ne alacağını zaten biliyor. Mühendislik ürünlerinde bu varsayım çoğu zaman yanlış. Kullanıcı ne alacağını bilmiyor; neye ihtiyacı olduğunu biliyor.

Isıtma ihtiyacından ısıtıcı seçen Resterm yazılımında zincirin ilk halkası ihtiyacın kendisi olarak kayda geçiyor. Kullanıcı bir kod yazmıyor; ısıtma ihtiyacını giriyor. Yazılım bu girdiden mühendislik hesabını yapıyor ve uygun elektrikli ısıtıcıyı seçiyor. Katalogda arama adımı akıştan tamamen kalkıyor.

Bu tersine çevirmenin kataloğa etkisi de var. Katalog artık bir arama yüzeyi değil, hesabın üzerinde seçim yaptığı veri kaynağı. Kullanıcı ürünü bulmuyor; yazılım ürünü türetiyor. Aradaki fark sorumluluğun yerini de değiştiriyor: yanlış ürün seçildiğinde hata kuralda aranıyor. Kural da düzeltilebilir bir nesne.

Bunun bedeli, yazılımın üreticinin ürün yapısını gerçekten tanıması. Yazılımı Resterm’in kendi ürün yapısı üzerine kurduk; hesap o yapının üzerinde çalışıyor. Sunucu tarafı Laravel’de, arayüz Vue’da, kayıtlar MySQL’de duruyor. Yığın küçük tutuldu, çünkü işin zorluğu ölçekte değil, hesabın ürün yapısına doğru oturmasında.

Bu tercihin bir de kullanıcıya bakan yüzü var. Katalogda arama adımı kalktığında satış görüşmesinin şekli değişiyor. Konuşma “hangi modeli istersiniz” ile değil, “ne kadar alana ne kadar ısı” ile başlıyor. Müşteri kendi bilmediği bir kodu telaffuz etmek zorunda kalmıyor; kendi bildiği şeyi söylüyor. Yazılımın ürün adını en sona bırakması, satışın konusunu ürün olmaktan çıkarıp ihtiyaç yapıyor.

Karşı durum bu bölümde özellikle önemli. Ürün seçiminde belirleyici olan hesap değil beğeniyse, yani renk, koku ya da tasarımsa, ihtiyaç girdili zincir kurulamaz. Orada girdi zaten ürünün kendisidir; kullanıcı ne istediğini görünce anlar. Böyle bir katalogda hesap adımı aramak, olmayan bir soruya motor yazmak olur.

Seçim sepete, sepet projeye, proje müşteriye bağlanır

Hesabın bir ürün seçmesi zincirin yarısı. Diğer yarısı, o seçimin ticari kayda nasıl geçtiği. Resterm yazılımında hesabın seçtiği ısıtıcı sepete düşüyor; sepet bir projeye, proje de o projenin müşterisine bağlanıyor. Kayıtlar MySQL’de tek zincirde duruyor.

Buradaki kritik ayrıntı bağın ne zaman kurulduğu. Bağ sonradan yapılan bir eşleştirme değil, kaydın baştan taşıdığı adres. Sepet kalemi, hangi projeye ait olduğunu bilmeden var olmuyor. Sonradan eşleştirme kurulan sistemlerde her zaman eşleşmemiş kayıtlar birikir ve o yığın bir gün elle temizlenir. Bağ kayıt oluşurken kuruluyorsa böyle bir yığın oluşmuyor.

Bağın yönü de önemli. Sepet kalemi projeye bağlanıyor, proje sepete değil. Yön tersine kurulsaydı bir projenin hangi kalemleri taşıdığı ancak bütün sepetler taranarak bulunurdu. Kaydın kime ait olduğunu kaydın kendisi taşıdığında, teklif ekranı listeyi taramadan çıkıyor.

Sonucu iki yönde okunabiliyor. İleri yönde: teknik seçim ile ticari kalem arasında elle veri taşınmıyor, hesabın çıktısı doğrudan teklif kalemine dönüşüyor. Geri yönde: bir teklifin hangi ısıtma ihtiyacı girdisinden çıktığı okunabiliyor. İkinci yön birincisinden daha değerli, çünkü şikâyet, revizyon ve fiyat itirazı hep geriye doğru okuma ister.

Bu ilkenin satış dışında da karşılığı var. İş emri, tüketilen parça ve faturayı tek zincirde tutan AlgoCar’da parça iş emrine yazıldığı anda stoktan düşüyor ve fatura aynı kayıttan kesiliyor; depo hareketi ayrı bir ekranda ikinci kez girilmiyor. AlgoCar bizim kendi ürünümüz. Sektörler farklı, işleyen kural aynı: operasyonel kayıt elle taşınmadan ticari kaleme dönüyor.

Bu bağların nerede duracağı bir veri modeli kararı. Teklif, proje ve müşteri kayıtlarını tek çekirdekte taşıyan ERP çalışmalarımızda ilk yazdığımız şey de ekran olmuyor; hangi kaydın hangi kaydın altında oluştuğunu yazıyoruz. Ekran sonradan değişir, bağ değişmez.

Fiyatı seçim belirlediğinde akış neyi taşır

Bazı ürünlerde fiyat bir kayıtta durmaz. Seçim yapıldığında hesaplanır. Otomotiv bunun en görünür örneği: satılan şey bir stok kalemi değil, bir yapılandırma sonucu.

Donanım ve renk seçiminin fiyatı belirlediği KGM SsangYong online satış kanalında her seçim fiyatı ve görseli aynı ekranda birlikte değiştiriyor. Ziyaretçi bir seçimi değiştirdiğinde fiyat ve ekrandaki aracın görseli aynı anda güncelleniyor.

Akış tasarımı açısından asıl soru şu: bir adımdan diğerine ne taşınıyor? Ürün kodu taşınırsa bilgi eksik gider. Kod, hangi birleşimin seçildiğini ve fiyatın neden o fiyat olduğunu anlatmaz. Bu yüzden akışın taşıdığı şey seçimin kaydı oluyor. Seçilen birleşim kendi satış koşuluyla kayda geçiyor ve sonraki adıma o kayıt gidiyor.

Bu ayrım fiyatın nerede saklandığını da değiştiriyor. Fiyat tek bir ürün satırında durmuyor; birleşimin kaydında duruyor. Bu yüzden bir birleşimin satış koşulu değiştiğinde dokunulan yer ürün kartı değil, o birleşimin kendi kaydı oluyor. Kayıt hangi seviyede tutuluyorsa değişiklik de o seviyede yapılıyor; aksi hâlde tek bir koşul değişikliği kataloğun tamamına dokunmayı gerektirirdi.

Bunun pratik karşılığı fiyat itirazında görünüyor. Ziyaretçi ödeme adımında beklediğinden farklı bir rakam gördüğünde farkın nereden geldiği kayıttan okunabiliyor. Fiyat yalnız bir sayı olarak taşınsaydı, aradaki farkı açıklamak yine bir insana kalırdı.

Karşı uç aynı portföyde duruyor. Parfüm perakendesinde fiyat ve stok, satılabilir birimin kendi kaydında durur; satın alma sırasında ne hesap ne yapılandırma adımı vardır. Müşteri hacmi seçer ve fiyat o hacmin kaydından gelir. Aynı akış kurgusunu buraya taşımak, olmayan bir adım için ekran açmak olurdu.

Konfigüratör ile ödeme tek akışın iki adımı

Zincirin en pahalı kopma noktası, seçim ile ödeme arasındaki geçiş. Ziyaretçi burada zaten karar vermiştir; kaybedilen her şey karar verilmiş bir satıştır.

SsangYong satış kanalında ödeme, konfigüratörün devamı olarak açılıyor. Ziyaretçi yapılandırdığı aracı bırakmadan satın alma adımına geçiyor ve seçim bilgisi aynı oturumda kalıyor. İki sistem arasında el sıkışma yok; tek akışın iki adımı var.

Kopukluk olsaydı ne olacağını tarif etmek gerekiyor, çünkü çalışan bir akışta bu risk görünmez. Konfigürasyon bir yerde, ödeme başka bir yerde dursaydı ziyaretçi seçtiği aracı ödeme tarafında baştan kurardı. Tekrar veri girişi burada bir konfor sorunu değil, satış kaybı mekanizması. İkinci kez seçim yapan kişi çoğu zaman ikinci kez aynı kararı vermiyor; ya vazgeçiyor ya da erteliyor.

Bu bütünlüğün sınırı da var. Ödeme adımı bankanın ve ödeme sağlayıcısının kurallarına tabi; o tarafı biz belirlemiyoruz. Tek akış demek, ödeme adımını kendi içimize almak değil; ziyaretçinin kurduğu yapılandırmanın o adıma eksiksiz taşınması demek. Sınır, verinin nerede durduğu değil, nerede yeniden istendiği.

Teknik tarafta bu bütünlüğün bir bedeli olmadı. Satış kanalı, markanın kurumsal sitesiyle aynı Laravel, MySQL ve Redis setinde çalışıyor. İki sistemin bakımı tek yetkinlik alanında toplanıyor; ikinci bir yığın öğrenmek, ayrı bir dağıtım hattı kurmak gerekmiyor. Proje başına yeni yığın seçmek yerine yıllarca bakılabilecek tek yığın seçmenin somut karşılığı bu.

Sepet ve ödeme akışlarını e-ticaret işlerimizde hep bu sırayla kuruyoruz: önce bir adımdan diğerine hangi kaydın taşındığını yazıyoruz, ekranı sonra çiziyoruz. Ters sıra denendiğinde ekranlar tek tek doğru çalışıyor, aralarındaki geçişte bilgi eksiliyor.

Genel teklif aracı nereye kadar yeter

Buraya kadarki her bölüm özel yazılmış bir akışı anlatıyor. Soru haklı: hazır bir teklif aracına katalog eklemek aynı sonucu vermez mi?

Vermiyor, çünkü katalog yüklemek ürün listesini taşır, ürün yapısını taşımaz. Jenerik bir araçta katalog bir listedir ve hesap adımı aracın dışında kalır. Hesap dışarıda kaldığı anda zincir de dışarıda kalıyor: kullanıcı yine bir tabloda hesap yapıp sonucu araca yazıyor. Araç değişti, elle taşıma sürüyor. Resterm yazılımını bu yüzden üreticinin ürün yapısı üzerine kurduk.

Aynı sınır e-ticaret tarafında da göründü. Hazır sepetler donanım ve renk kırılımını taşımıyor; fiyat tek bir ürün kaydına bağlı kalıyor. Hazır aracın varsayımı açık: fiyat ürün kaydında durur. Fiyat seçimden çıktığında bu varsayım kırılıyor ve kırılan varsayımın etrafından dolaşmak, aracı kullanmaktan pahalı hâle geliyor.

Karşı durum da aynı netlikte. Katalog küçükse, fiyat satılabilir birimin kaydındaysa ve hesap adımı yoksa hazır araç yeterli. Hacmi ayrı satılabilir birim sayan Kokudankokuya mağazasında kataloğun ölçeği ayrı bir arama ya da önbellek katmanı gerektirmedi; mağaza Laravel ve MySQL üzerinde duruyor. İki bileşene indirilmiş bir yığın, bu ölçekte doğru cevabın küçük olduğunun kanıtı.

Aşağıdaki tablo dört işi aynı üç soruyla yan yana koyuyor: tutar nereden çıkıyor, satış kaydı neye geriye okunuyor ve zincir hangi tekrar veri girişini kaldırıyor.

Tablonun son sütunu kasten yazıldı. Bir zincirin değeri ancak kaldırdığı tekrarla ölçülebiliyor. Kendi işinizde bu sütuna yazacak bir şey bulamıyorsanız zincire ihtiyacınız yok demektir. Bulabiliyorsanız, o tekrar bugün birinin gününden çıkıyor.