Proje Doğru da Olsa, Beklentiler Önemli!

Projeler kusursuz tamamlansa dahi, öngörülemeyen, şirketlerin ya da müşterilerin kolay adapte olamadığı yeni açılımlardan dolayı gizli riskler söz konusudur.

Müşteri ile “el sıkışılan” kapsam, projede belirtilen zaman ve maliyet aşılmadan, kalite kabul kriterleri çerçevesinde gerçekleştirilmiş olması,  o projenin başarılı olacağı anlamına maalesef gelmeyecektir. Bu noktadan hareketle proje ekibinin başarısız olarak nitelendirilmesi de doğru olmayacaktır.

2005 yılında eczacılar için geliştirdiğimiz bir projede; eczacıların çok daha hızlı sipariş verebilmesini sağlayan, stoklarında meydana gelen kaçakları en aza, hatta sıfıra indiren bir sistem üzerinde çalışmıştık, tüm eczaneler kullandıkları ecza programlarına depolardan yaptıkları alışları e-fatura yöntemi  sistemlerine aktarabiliyor. B2B altyapısını kullanarak sipariş verebiliyordu.

Bu çalışmanın en büyük nedeni, eczanelerdeki yanlış stok yönetimi yüzünden, ecza depolarında acil sipariş yükünün çok ciddi boyutlara ulaşmasıydı. Öyle ki günde 20 kez motosikletli kurye ile acil sipariş veren eczaneler vardır. (bu sayı artmıştır muhtemelen)  Bu da şirket için ekstra maliyet anlamına geliyordu. Kar marjlarının çok düşük olduğu bu sektörde farklılık yaratmak şart olmuştu. Çünkü herkes aşağı yukarı aynı fiyattan satıyordu ilaçları.

Kabaca projeyi anlatmak gerekirse;

1.       Depolardan yapılan alımlar e-fatura ile eczanelere gönderilecek, eczaneler bu faturaları tek bir tuşla masaüstü programlarına işleyecek

2.       Eczane programları üzerinden tüm ilaçlar için bir kereye mahsus minimum stok seviyesi girilecek (bu programlar geçmişe yönelik detaylı raporlar verebiliyordu)

3.       Yapılan tüm satışlar barkod cihazları ile yapılacak, dolayısıyla stoklardan düşürülmesi sağlanacak,

4.       Tek bir tuşla sipariş oluşturularak, depo’nun B2B platformuna, XML web servisleri ile aktarılacak, sipariş oluşturulacaktı.

Mevcut durumda; eczaneler ilaçlarının bittiğini çok geç fark edip, “hastayı” (müşteri demek oldum olası içimden gelmez) oyalayarak acil ilaç siparişi verirler. Bu durumda depo, en yakın depo ya da cep deposundan motosikletli bir kurye ile ilacı takribi 10 dakika içerisinde eczaneye ulaştırır. (depoya olan maliyetinden bahsetmeye gerek yok sanırım)

Eczanelerin geleneksel sipariş yönetiminde telefon yolu ile olduğunu düşündüğünüzde; eksik, yanlış verilen siparişler. Operatör tarafından hatalı girilen siparişler vb. bahsetmeye de gerek yok,

Bu birkaç paragraf bile yukarıda çok dar anlamıyla anlattığım projenin önce eczaneler, sonrasında da depo için ne kadar verimli bir proje olduğunu kanıtlıyor.

Gelin görün ki projenin “çözümlenmesi” ve “planlama” aşamalarında konuştuğumuz. Bu iş yapış şeklini çok beğenen eczacıların büyük bir çoğunlu bile, alışılageldik iş yapış şeklini değiştirmek istemedi. Çünkü 20 yıldır bu şekilde çalışıyordu.

Bir diğer durum bazı eczanelerde siparişleri kalfaların veriyor olması. Kalfaların bu  sisteme sıcak bakmaması gerçeğiydi. Eczacı ne kadar bu sistemi kullanmak isterse istesin, kalfası bir gün kullanmadığında sistem hata veriyordu. Oysa biz görüşürken kalfalar ile değil, eczacılar ile görüşmüştük, hiçbirisi de benim eczanemde siparişleri kalfalar verir dememişti.

Proje ile ilgili Trabzon, Eskişehir ve birkaç ilde daha birçok eczacı ile görüştüm. Özellikle yeni eczacılardan çok olumlu geri bildirimler aldım. İlk kez bu sistem ile çalışmaya başladıkları için, çok kolay ve hızlı adapte olabiliyorlardı.

İşin özü, yeni eczacılar sistemi çok hızlı benimseseler de, nispeten eski eczanelerde aynı sonucu alamamamıştık, hatta bu verileri bir şekilde kendi sisteminize mi aktaracaksınız sorularıyla da muhatap olmuştuk, Projenin şu anki durumunu bilmiyorum. Fakat merak etmiyor da değilim.

İş yapış şekillerinin değiştirilmesi ile ilgili bir iki yazı yazmıştım, bunlardan birini örneklemek istedim.

“Proje Doğru da Olsa, Beklentiler Önemli!” için bir yorum

  1. çevik yazılım geliştirme manifestosunu yapıştırıyorum aşağıya:

    * Bireyler ve onlar arasındaki etkileşimi süreç ve araca tercih etmek
    * Çalışan bir yazılımı detaylı bir dokümantasyona tercih etmek
    * Müşteri ile işbirliğini, anlaşma görüşmelerine tercih etmek
    * Değişikliklere istenildiği anda cevap verebilmeyi sınırları belirli bir plana tercih etmek

    bu ilkeler temelinde geliştirilen projelerde kısa (hafta bazında) periyodlarla çalışan uygulamalar sunulur ve kullanıcıdan devamlı geri bildirim alınır. bu şekilde kullanıcının sisteme tepksini daha projenin başında ölçebilir ve buna göre devam edebilirsiniz.

    klasik proje yönetimi teknikleri ile hem müşteri hem de geliştiriciler tarafında yanlış seçilebilecek analistler sebebi ile, sunulan ürün ile istenen arasındaki fark çok geç anlaşılmaktadır.

    tabii ki bazı projeler geleneksel yöntemlere daha uygun olabilirler ama çevik proje yönetimi kesinlikle göz önüne alınması gereken bir yöntem bence.

    http://enveraltin.com/sunumlar/ adresindeki değişimikucaklamak.pdf dosyasındaki sunumdan giriş yapılabilir.

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir