dışarıdan bakıldığının aksine çok çok kapsamlı teknik ve lojistik altyapıya sahip olması gereken sistem. kısa olarak yapısını modelleyelim bakalım bu sistemin tamamıyla çalışmasının. örnek bir alışveriş işleminden yola çıkıyor, ana işlem prosesleri yanında aklıma geldikçe o aşamada dallanıp yan proseslere de göz atıyorum.
müşteri siparişi gelmeden önce vitrinde sergilenecek ürünler için çok sağlam bir lojistik yapı olması gerekiyor çünkü muhtemelen kendi ürettiğimiz ürünleri satmıyoruz ve burdaki tüm ürünleri de stoklamıyoruz. bu şunu gerektiriyor: bir ödeme alındığında stokta bulunmayan ürünü anında tedarik etmeliyiz, yoksa ne olur? sözlükte gelip kötülerler.
müşterimiz geldi, muhteşem güzellikte ve kolay kullanımlı sitemizden o anda tedarik edebileceğimiz ürünü seçti ben bunu alıyorum dedi. en önemli işlemlerden biri burda ödemenin tahsilatı. burda genelde türkiye'de yaygın iki yöntem var: havale ve kredi kartı. türkiye'de ne yazık ki teknoloji halen daha sniffer'la kredi kartı çaldığımız zamanlarda sanıldığı için bazı insanlar kulaklarını tersten gösterip online kredi kartı işlemlerine güvenmeyerek havale yapıyor ve tahsilat sürecini uzatıyorlar. şimdi iki seçeneği teker teker inceleyelim:
- kredi kartı yönteminde tüm ameleliği banka yapıyor. bankalardan yıllık oldukça yüklü ücrete kiralanacak
sanal pos sayesinde tahsilat işlemi kolayca halledilebiliyor. burda da iki seçenek var
1. server'ınızda halihazırda
ssl sertifikası yüklüyse tüm transaction'ları müşterinin ruhu duymadan ve daha muhteşem bir profesyonellikle halledebilirsiniz. burda bankanın kullandığınız platforma göre (php, asp, dot net, jsp etc.) vereceği kodlarla tüm işlem halloluyor. ana prensip kredi kartı giriş interface'ini hazırlıyorsunuz, kredi kartı girişi yapıldığında arka planda bankaya bağlanıp ordan gerekli yanıtı alıyor transaction'un başarı durumuna göre gerekli yanıtı ziyaretçiye veriyorsunuz. işlemi yarıda kesme veya siparişe devam gibiç
2.
taci tırsak yöntemi diyebileceğim ikinci yöntemdeyse profesyonellik tabanda diyebiliriz. ssl sertifikası yüklü olmayan server'ınız varsa, yani müşteri kredi kartı numarasını sizin server'ınıza güvenli bir kanaldan gönderemiyorsa siz sisteminiz içinden bankanın hazırlamış olduğu standart kredi kartı kabul sistemine bağlanıyor ve müşterinin kredi kartı numarasını burdan gönderip gerekli onayı almasını sağlıyorsunuz. örnek olarak baskuda bazı bankalarda bu sistemi kullanıyor ve doğabilecek en ufak hatada ödemenin boşa gitmesini ve geri almak için uğraşmanızı gerektiren bir sistemle kredi kartını kabul ediyor. yani oldukça hıyarca.
kredi kartı transaction'u tamamlandı diyelim. bankadan gerekli response geldi, ödeme alındı dendi. yine bazı hıyar sistemler (yine baskuda'yı örnek veriyorum) bu aşamada ödemenin manual yolla onaylanmasını isteyebiliyor. bu da fazladan yaklaşık 1 güne patlıyor.
- kredi kartı kullanmayan bir müşterimiz var. bu insan ne yapacak? vereceğimiz banka hesabına ücretini yatıracak. burda sistem biraz modifiye oluyor. siparişi kaydediyoruz fakat onaylamıyoruz. siparişin bir kodu var ve müşteriye bu kodu kullanarak havale yapmasını söylüyoruz. yaklaşık 3 gün gibi bir süre veriyor bu süre boyunca belli periyodlarda arka planda banka hesaplarımızı kontrol ediyoruz. eğer gereken ücret yatırılmışsa onay veriyoruz siparişe
bir şekilde ödeme alındı, sipariş onaylandı. bundan sonra heyecanlı süreçler bekliyor hepimizi. öncelikle bir adet mail'le müşteriye siparişiniz onaylandı bilgisi veriyor ve ürünün satın alındığı mağazanın sorumlusunun ekranına bir adet daha bekleyen sipariş kaydı geliyor. bu andan itibaren sorumlunun görevi ürünün o an stokta olup olmadığını sorgulamak. database'cilik ilminin bir artısı olarak stok sorumlularının o anda stokta olan ürünleri tuttuğu tablodan bir relational query'le otomatik olarak mağaza sorumlusuna sistem diyor ki stokta var bu ürün veya tedarikçiden ürünü iste.
bazı sistemlerde bu stoktan ürün isteme veya tedarikçiden talep etme durumu manual olsa bile ideal bir sistem bunu da otomasyona bağlamalı. burda sistem duruma göre yine insanoğlu onayı isteyerek ya stok departmanına ürünün kargoya hazırlanması üzerine talimat vermeli veya tedarikçilerden istenecekler listesine bu ürünü eklemeli ve siparişi idle konumuna almalı. iki durumu da ele alalım
- stoktan kargoya gidecekler listesine bir kayıt girdiği an stok sorumlusuna hemen bir uyarıyla işlemi yapması bildirilir. ordan ürün allanır pullanır "sevke hazır" flagı işaretlenip kargo departmanına yollanır.
- tedarikçiden istenecekler listesine ürün kaydedilir. bu işten sorumlu kişinin periyodik olarak bu listeyi takip ettiği düşünülürse bu listeye gelecek ürünleri teker teker gerekli yerlerden sipariş eder ve stoğa girmesini sağlar. stoğa gelen ürünlerin kayıtları girilirken de tedarik tablosundan bu ürün artık tedarik edildiği için silinir. sonra otomatik olarak yine bu gelen ürünün kargoya hazırlanması gerektiği bildirilir ve yine ürün kargoya gider. bu esnada mağaza sorumlusu yani siparişten temel olarak sorumlu kişi bunlardan haberdar olur.
tüm bu işlemler sürerken en güzeli her kişinin kendi işiyle ilgilenmesidir. yani tedarikten sorumlu kişinin stokta ne olup bittiğini siklememesi en güzelidir. her şeyi sql bilir. şüphesiz sql her şeyi bilsin diye yaratıldı.
ürün kargo departmanından çıkış yaptığı an müşteriye bir bildirim gider ve kargolanmış ürünler hanesine bir record daha girilir. bunun sebebi kargo şirketiyle bütünleşik olarak teslimat durumunu inceleme amaçlıdır. periyodik olarak kargonun durumu kontrol edilir ve teslimat başarılıysa alkışlanır, sevinilir. ayrıca müşterinin "kargom elime geçmedi" gibi bir şikayeti de burdaki kayıtlar sayesinde çözülebilir.
yine satış sonrası doğacak arıza durumlarında kargoyla gelen ürünler arıza departmanında değerlendirilir, burdan gerekirse tedarikçiye geri gönderilir benzer işlemler sonrası müşteriye dönülür ve esas olan her işlemin teker teker kayıtlarının tutulmasıdır. bu işle uğraşıldığında her kaydın ne kadar işe yaradığını göreceksiniz.
tabi burada anlatılan sistem değişiklik gösterse bile en genel haliyle budur. en azından bu işe girsem bu tür bir modellemeye giderdim.