Prosedürü olmayan kurumsal şirket neredeyse yok. Uygulananı ise az. Aradaki mesafenin sebebi metnin kendisinde.
İki ayrı gerçeklik
Çoğu şirkette satın alma prosedürü bir kez yazılıyor. Genelde bir belgelendirme sürecinde ya da bir denetim öncesinde.
Metin hazırlanıyor, imzalanıyor, doküman numarası alıyor, ortak sürücüye konuyor. Denetimde soruluyor, gösteriliyor, geçiliyor.
Sonra gerçek süreç kendi yoluna devam ediyor. Talepler telefonla geliyor, onaylar e-postayla veriliyor, acil alımlar sonradan kaydediliyor.
Aradan iki yıl geçtiğinde iki ayrı gerçeklik oluşuyor: yazılı olan ve olan. İkisi arasında bir bağ kalmıyor ve prosedürü okuyan yeni bir çalışan, şirketin nasıl çalıştığını öğrenmiş olmuyor.
Metnin uygulanmama sebepleri
Prosedürler dört tipik hatayla yazılıyor ve dördü de uygulanmamayı garantiliyor.
İdeal süreci tarif ediyor, gerçeği değil. Yazan kişi “olması gereken”i yazıyor. Sahadaki kısıtlar, aciliyetler ve istisnalar metne girmiyor. Metin ilk gerçek durumda kırılıyor.
İstisnaya yer bırakmıyor. Acil alım için bir yol tanımlanmamışsa acil alım prosedürün dışında yapılıyor. Bir kez dışarı çıkan iş kolay kolay geri dönmüyor.
Sorumluyu unvanla değil kişiyle tanımlıyor. O kişi ayrıldığında maddenin karşılığı kalmıyor.
Ölçüsü yok. “Talepler ivedilikle değerlendirilir” cümlesi hiçbir şey söylemiyor. Kimse bu maddeye uyup uymadığını bilemiyor.
Beşinci ve en yaygın sebep ise şu: prosedür süreci hızlandırmıyor, yavaşlatıyor. İnsanlar kurala değil yavaşlığa direniyor. Yazılı yol telefondan yavaşsa telefon kazanıyor, her seferinde.
İyi bir prosedürün taşıdığı şeyler
İşe yarayan metinlerde ortak olan birkaç şey var.
Kim, ne zaman, neyi yapıyor. Unvan bazında sorumluluk. Kişi adı değil.
Eşikler yazılı. Hangi tutarın üstünde ne gerekiyor: kaç teklif, kaç onay, hangi kademe. Rakam yoksa uygulama kişiye göre değişiyor.
İstisna tanımlı. Acil alım, tek kaynaklı alım, sözleşmeli alım. Her birinin ne zaman geçerli olduğu ve nasıl kayda geçeceği yazılı.
Süre var. Onayın kaç gün içinde verilmesi beklendiği. Süresiz bir onay adımı, süreci belirsiz süre bekletiyor.
Kayıt yeri belli. Hangi adımda hangi kaydın nerede tutulacağı. Kaydın yeri belirtilmemişse kayıt tutulmuyor.
Bir de şu var: prosedür kısa olmalı. Kırk sayfalık bir metin okunmuyor. Süreci gerçekten yürüten kurallar birkaç sayfaya sığıyor.
Prosedürü yazılım nasıl değiştiriyor
Yazılım prosedürü kendiliğinden uygulatmıyor. Yaptığı şey daha dolaylı ama daha etkili: akışın dışına çıkmayı zorlaştırıyor.
Kural metinde yazılıyken uymak bir tercih. Kural sistemin içine gömüldüğünde uymak varsayılan davranış oluyor.
Onay eşiği sistemde tanımlıysa, o tutarın üstündeki talep ilgili kademeye kendiliğinden gidiyor. Kimsenin prosedürü hatırlaması gerekmiyor.
Malzeme listeden seçiliyorsa, “malzeme tanımı standart olmalı” maddesi kendiliğinden uygulanıyor.
Teklif isteği sistemden çıkıyorsa, kaç tedarikçiye gittiği kayıt altına alınıyor ve üç teklif kuralı ölçülebilir hale geliyor.
Buradaki asıl kazanç ölçülebilirlik. Prosedüre uyulup uyulmadığı artık bir kanaat değil, bir rakam. Kaç talep sistemden açıldı, kaç alım süreç dışında yapıldı sorularının cevabı elde oluyor.
Sıra önemli: önce süreç mi, önce yazılım mı
Yaygın bir tartışma ve pratik cevabı şu: ikisi birlikte yürüyor.
Prosedürü tamamen bitirip sonra yazılıma geçmek işe yaramıyor, çünkü kağıt üzerinde tasarlanan sürecin bir kısmı uygulamada tutmuyor.
Yazılımı kurup prosedürü sonra yazmak da eksik kalıyor, çünkü sistemde tanımlanacak eşikler ve yetkiler bir karara dayanmak zorunda.
İşleyen sıra genelde şu: mevcut sürecin gerçek hali yazılıyor, ideal hali değil. Sonra bunun üzerinde düzeltmeler yapılıyor. Düzeltilmiş akış sisteme kuruluyor. Birkaç ay kullanıldıktan sonra prosedür metni son haline getiriliyor.
Bu sırada prosedür, sistemin tarifi haline geliyor. İkisi arasında fark kalmıyor ve metin güncel kalmaya başlıyor.
Prosedürde üç imza vardı, uygulamada bir tane
Not: Aşağıdaki örnek gerçek bir müşteriye ait değildir; sahada sık karşılaşılan durumlardan oluşturulmuş bir senaryodur.
İki gerçekliğin nasıl ayrıştığını gösteren bir örnek.
Bir gıda üreticisinin satın alma prosedürü on dört sayfaydı ve altı yıl önce yazılmıştı. Belirli tutarın üzerindeki alımlar için üç imza öngörüyordu: talep eden birim yöneticisi, satın alma müdürü ve genel müdür.
Uygulamada ne olduğu incelendiğinde şu çıktı. Talep eden birim yöneticisi imzalıyordu. Satın alma müdürü imzalıyordu. Genel müdür imzası ise ayda bir, toplu halde atılıyordu; o ay yapılmış alımlar bir dosyada önüne konuyor, hepsi birden imzalanıyordu.
Yani üçüncü onay, alım gerçekleştikten sonra veriliyordu. Bir kontrol adımı değil, arşiv işlemiydi.
Sebep de anlaşılırdı: genel müdür sahada ve seyahatteydi, her alım için imza beklemek işi durduruyordu. Prosedür bu gerçeği hiç tanımıyordu; yedek onaycı tanımlı değildi.
Prosedür yeniden yazılırken iki şey değişti. Onay eşiği yükseltildi, yani gerçekten genel müdüre çıkması gereken alımlar azaldı. Ve yedek onaycı tanımlandı.
Sonuç şu oldu: genel müdüre çıkan alım sayısı düştü ama çıkanların hepsi gerçekten önceden onaylandı.
Prosedür kısaldı ve ilk kez uygulanmaya başladı. Metin gerçekliğe uydurulduğunda gerçeklik de metne uydu.
Codigno tarafında
Talep yönetimi tarafında onay hiyerarşisi proje ya da departman bazında tanımlanıyor ve gelişmiş yetkilendirme ile kimin ne talep edebileceği ve kimin onaylayacağı belirleniyor. Prosedürdeki yetki ve eşik maddeleri bu tanımlarla sistemin içine giriyor.
Versiyon kontrolü sayesinde talep üzerindeki değişiklikler izleniyor; prosedürün istediği izlenebilirlik kendiliğinden oluşuyor.
Malzeme ve hizmet ağacı, tanım standardını kural olmaktan çıkarıp varsayılan davranışa dönüştürüyor.
Belgelendirme tarafı: ISO 9001 tedarikçi değerlendirmesi. Zincirin bütünü: satın alma yönetimi rehberi.
Sık sorulan sorular
Satın alma prosedürü zorunlu mu?
Kanuni bir zorunluluk değil. Kalite yönetim sistemi belgelendirmelerinde süreçlerin tanımlı ve kayıtlı olması bekleniyor; prosedür metni bunun en yaygın karşılanma biçimi.
Prosedür ne kadar ayrıntılı olmalı?
Süreci gerçekten yürüten kurallar genelde birkaç sayfaya sığıyor. Uzun metinler okunmuyor ve güncellenmiyor.
Prosedürde acil alıma yer verilmeli mi?
Verilmesi gerekiyor. Acil alım için yol tanımlanmayan prosedürlerde o alım süreç dışında yapılıyor ve hiç kaydedilmiyor.
Prosedür ne sıklıkta güncellenmeli?
Süreç değiştiğinde. Takvime bağlı güncelleme, metni gerçeklikten kopmuş haliyle bir yıl daha yürürlükte bırakıyor.
Prosedüre uyulup uyulmadığı nasıl ölçülür?
Süreç sistemde yürüyorsa doğrudan ölçülebiliyor: sistemden açılan talep oranı, süreç dışı yapılan alım sayısı, ortalama onay süresi. Metin tek başına ölçüm imkanı vermiyor.
Önce prosedür mü yazılmalı, önce yazılım mı kurulmalı?
İkisi birlikte yürüyor. Mevcut sürecin gerçek hali yazılıp düzeltilerek sisteme kuruluyor; metin son halini birkaç ay kullanımdan sonra alıyor.
Geçen ay yapılan alımların kaçı prosedürde yazan akıştan geçti? Mevcut prosedürünüzdeki onay eşiklerini paylaşın; bunların sisteme nasıl kurulacağını ve uyumun nasıl ölçüleceğini gösterelim.
