Birinci bölümde satın alma döngüsünü talepten ödemeye yedi istasyon olarak haritalandırdık ve basit bir alıştırma önerdik: ödenmiş son on tedarikçi faturanızı alın ve her birini talebine, onayına, satın alma siparişine ve mal kabul kaydına kadar geriye doğru izleyin. Bu alıştırmada aradığınız ilk belge satın alma talebiydi. Bazı faturaların hiç talebi yoksa işe buradan başlıyoruz, çünkü ondan sonraki her belgenin dayanacağı bir şeye ihtiyacı vardır.

Bu bölüm ilk iki istasyonu birlikte ele alıyor: ihtiyacı kayda geçiren talep ve şirketin bu ihtiyaç için harcama yapacağına karar veren onay. Kulağa idari gibi gelen ama aslında operasyonel olan bir soruyu yanıtlıyor: kim neyi, hangi limite kadar onaylar, onaylayan kişi yokken onun yerine kim onay verir ve ihtiyaç bekleyemediğinde ne olur.

Satın alma talebi: sonraki her şeyin dayandığı belge

Satın alma talebi işin üstüne eklenen bir evrak işi değildir. Bir ihtiyacın telefon görüşmesindeki bir cümle olmaktan çıkıp numaralı bir kayda dönüştüğü andır. O olmadan satın alma siparişinin dayanacağı bir şey yoktur, şantiyede teslim alan kişi ne bekleyeceğini bilmez ve muhasebeci neden ödeme yaptığını bilmez. İyi bir talep beş temel soruyu yanıtlar:

  • Kimin ihtiyacı var? Mesajı ileten kişinin değil, talep edenin adı ve görevi: şantiye mühendisi, üretim hattı vardiya amiri, otelin bakım sorumlusu.
  • Tam olarak ne? Kalem, şartnamesi, miktarı ve birimi. "Sıhhi tesisat malzemesi" gibi bir satır referans değildir, çünkü daha sonra kimse gelen malı onunla karşılaştıramaz.
  • Hangi proje, şantiye ya da mülk için? Maliyeti ait olduğu yere gönderen bu alandır. Hiçbir projeye ait olmayan bir alım, kimsenin izini süremeyeceği genel bir gidere dönüşür.
  • Neden? Tek satır yeterlidir: metraj cetvelindeki bir kalem, duran bir makine için yedek parça, gelecek sezon için sarf malzemesi. Bu satır, onaylayan kişiyi sormak için telefon açmaktan kurtarır.
  • Ne zamana kadar? Her talebin üzerindeki "acil" kelimesi değil, gerçekten ihtiyaç duyduğunuz tarih. Satın alma birimi tedarikçilerin teslim sürelerini bu tarihle karşılaştırır.

Talebin, kaba da olsa tahmini bir değere de ihtiyacı vardır, çünkü tutara göre onay vermek için bir tutar gerekir. Talep eden bu değeri bilmiyorsa, satın alma birimi talep onaya gitmeden önce ekler. Ardından talep bir numara alır ve sistemde sonraki her belge bu numaraya bağlanır: onay, satın alma siparişi, mal kabul kaydı ve tedarikçi faturası. Bu, iş emirleri ve maliyetlerin bağlandığı talep numarası yazısında ortaya koyduğumuz mantığın aynısıdır: her belge aynı numaraya bağlandığında, zincirin herhangi bir noktasından başlayıp kimseye sormadan başına ulaşabilirsiniz.

Onay matrisi: tek başına tutar yetmez

Onay matrisi tek bir soruyu yanıtlayan bir tablodur: Bu talebe kim evet diyebilir? En basit matris tek bir eksen üzerine kurulur, o da tutardır: bir limite kadar bölüm müdürü onaylar, onun üzerinde finans müdürü, daha da üzerinde işletme sahibi. Tutar geçerli bir eksendir, ancak satın alma türü onaylayanın yanıtladığı soruyu değiştirir:

  • Stok malzemeleri. Bir şantiye için demir ve çimento, bir üretim hattı için hammadde, bir otel için temizlik malzemesi. Buradaki soru, bu miktara gerçekten ihtiyacınız olup olmadığı ve satın almadan önce başka bir depoda ya da başka bir şantiyede zaten bulunup bulunmadığıdır. Bu yüzden onaylayanın onay anında kalemin stok durumunu görmesi işe yarar.
  • Hizmetler ve taşeronlar. Asansör bakımı, bir taşeronun yaptığı yalıtım işi, bir temizlik sözleşmesi. Burada kapsam fiyattan daha önemlidir: tam olarak ne yapılacak ve bittiğini nasıl anlayacağız. Bu yüzden talebin iki farklı soru için onaylayana ihtiyacı vardır: teknik bilgiye sahip kişi kapsamı onaylar, matrisin o tutar için belirlediği kişi de harcamayı onaylar.
  • Sabit kıymetler. Ekipman, bir araç, bir jeneratör, üretim hattı için bir makine. Bu, yıllarca süren ve beraberinde işletme ve bakım maliyetleri getiren bir taahhüttür; dolayısıyla yalnızca tutarının gerektireceğinden daha üst bir kademeye gitmesi makuldür.
  • Acil alımlar. Bunların aşağıda ele aldığımız kendi yolları vardır, çünkü insanlar acil durumları hesaba katmayan bir matrisi, ilk acil durum yaşandığında hemen dolanır.

Rakamların kendisini, yani bir talebin bir kademeden diğerine geçtiği limitleri, işletme sahibi ya da varsa yönetim kurulu belirler, çünkü bunlar şirketin büyüklüğünü, kâr marjlarını ve sahibin bizzat ne kadarını görmek istediğini yansıtır. Her şirkete uyan, genel olarak doğru bir limit yoktur; başka bir şirketten ödünç alınan bir limit fazla dar olup işi durdurabilir ya da fazla geniş olup hiçbir şeyi kontrol etmeyebilir.

Her tür için iki kural geçerlidir. Birincisi, kimse kendi talebini onaylamaz; bir onaylayanın kendi talebi bir üst kademeye gider. İkincisi, onay yetkisi kişiye değil göreve aittir; böylece bir şantiye şefi başka bir şantiyeye geçtiğinde, yetki birinin onu değiştirmeyi hatırlamasını beklemek yerine yeni görevle birlikte taşınır. Bu ilkeyi yetkiler: veriler dosyadan çıktığında kim neyi görür yazısında ayrıntılı olarak açıkladık; onay matrisi, aynı ilkenin paraya uygulanmış hâlidir.

Peki onaylayan kişi seyahatteyken kim onay verir? İşte devamsızlığı hiç planlamamış bir matris burada çöker ve boşluk "benim yerime sen onayla" diyen bir mesajla ya da iki kişinin paylaştığı bir şifreyle doldurulur. Çözüm, sistemde önceden tanımlanmış bir yetki devridir: kime, ne kadar süreyle ve hangi limitler içinde. Vekilin onayı kendi adıyla, asıl onaylayan adına verildiği işaretlenerek görünür, yetki devri tarihi geldiğinde otomatik olarak sona erer ve onaylayan döndüğünde kendisi yokken nelerin onaylandığını görür. Bir talep, işletme sahibinin belirlediği bir sürenin ötesinde kararsız kalırsa, izindeki birinin gelen kutusunda beklemek yerine bir üst kademeye aktarılır.

Bir sistemin kapatması gereken iki kestirme yol

Ne kadar iyi tasarlanmış olursa olsun her matrisin etrafında iki kestirme yol açık kalır. Bu yollara sapmak için kötü niyet gerekmez; onayın yavaş olması ve işin beklememesi yeterlidir. Bu yüzden bir sistem onları iki taraftan kapatır: kestirme yolu engelleyen bir kontrolle ve kimsenin kestirmeye ihtiyaç duymayacağı kadar hızlı bir onayla.

  • Talebi bölmek. Şantiye şefinin limitini aşan bir talep, birkaç gün içinde aynı tedarikçiden aynı kalem için, limitin altında kalan iki ya da üç talebe bölünür. Her talep tek başına sorunsuzdur; birlikte ise o tutar için yetkisi olan kişiye hiç ulaşmadan limiti aşarlar. Sistem bunu tek tek taleplere değil toplama bakarak kapatır: aynı projede, işletme sahibinin belirlediği bir dönem içinde aynı kalemi ya da aynı tedarikçiyi paylaşan talepler toplanır ve toplam limiti aşarsa, onu onaylayabilecek kademeye gider.
  • WhatsApp üzerinden onay. Yönetici, onlarca başka mesajın bulunduğu bir grupta bir teklifin fotoğrafına "Tamam" diye yanıt verdi. Onay gerçekti, ama neyin onayıydı? Teklifin hangi sürümü, hangi miktar, hangi proje? İki ay sonra mesaj binlercesinin altında kaybolmuştur ya da o zamandan beri değiştirilmiş bir telefonda durmaktadır. Bu arada KDV'ye tabi bir işletme için, bu onaya dayanarak ödenen fatura, KDV Uygulama Yönetmeliği'nin 66. maddesi uyarınca ilgili olduğu vergi döneminin sonundan itibaren en az altı yıl saklanmalıdır; oysa satın almanın arkasındaki onayın nerede olacağını kimse bilmez.

Çözüm kâğıda ve kalemle atılan imzalara geri dönmek anlamına gelmez. Elektronik İşlemler Kanunu, belirlediği koşullara tabi olarak elektronik işlemlere, kayıtlara ve imzalara bağlayıcı etki tanır (madde 5) ve bir elektronik işlemin delil değerini tartarken, kaydı oluşturmak, saklamak ya da iletmek için kullanılan yöntemin ne kadar güvenilir olduğunu ve kaydın değiştirilip değiştirilemeyeceğini dikkate alır (madde 9(4)). WhatsApp onayının sorunu elektronik olması değil, onayladığı talepten kopuk olmasıdır. Bu yüzden onay, sistemin içinde talebin kendisi üzerinde, onaylayanın adı, saat, tutar ve onaylanan sürümle birlikte verilir; talep daha sonra miktar ya da tutar bakımından değişirse yeniden onaya döner. WhatsApp bildirim kanalı olarak kalır: onaylayan, talebe giden bir bağlantıyla birlikte bildirim alır ve dizüstü bilgisayar açmadan telefonundan onaylar; böylece yavaş onay, onu dolanmak için bir gerekçe olmaktan çıkar.

Acil alımlar: kestirme yol yerine ilan edilmiş bir yol

Misafirler gelmeden önce bir otel odasındaki su sızıntısı, üretim hattında duran bir pompa, hâlihazırda devam eden bir beton dökümünü bitirmek için malzeme bekleyen bir şantiye. Böyle anlarda kimse tam bir onay döngüsünü beklemez, beklememelidir de. Bu gerçeği görmezden gelen bir matris acil alımları durdurmaz; onları sistemin dışına iter, böylece kalem nakit olarak ya da bir çalışanın kendi cebinden alınır ve iki hafta sonra talepsiz ve onaysız olarak muhasebede ortaya çıkar.

Dürüst yaklaşım, acil durumların var olduğunu kabul eden ve onlara açık koşulları olan ilan edilmiş bir yol veren bir sistemdir:

  • Kimin başlatabileceği. Her çalışan değil, şantiye şefi ya da nöbetçi bakım sorumlusu gibi belirli görevler.
  • Neyin acil sayıldığı. Bir his değil, yazılı bir tanım: bir güvenlik riski, duran bir operasyon ya da gecikmeyle yayılan bir hasar. Bu, bildirimden kapanışa: bakım taleplerini yönetmek yazısında bakım talepleri için önerdiğimiz mantığın aynısıdır.
  • Asgari bilgi. Ne olduğu, neden acil olduğu ve mümkünse bir fotoğraf; tam bir form yerine şantiyede telefondan girilir.
  • Bir harcama tavanı. Acil yolla nelerin alınabileceğine işletme sahibinin koyduğu bir limit; bu limitin üzerinde onaylayan, satın almadan önce telefonundan talebin kendisi üzerinde onay verir.
  • Süreli, sonradan onay. Satın alma hemen yapılır ve onayı, işletme sahibinin belirlediği süre içinde tamamlanır. Süre onaysız geçerse talep, sahibin bizzat gördüğü bir listede belirir.

Ardından acil taleplerin toplam içindeki payını izleyin. Gerçek acil durumlar yaşanır, ancak belirli bir bölümde ya da şantiyede acil yol normal yol hâline geldiğinde, bu insanların yetersizliği değildir; oradaki planlamanın gözden geçirilmesi gerektiğinin ya da normal onayın işin kaldırabileceğinden daha yavaş olduğunun işaretidir.

Origami'nin bakışı

Bir şirket için satın alma iş akışı kurarken, politika el kitabında yazdığı hâliyle değil, gerçekte işlediği hâliyle mevcut matrisinden yola çıkarız: bugün kim onaylıyor, onay nerede takılıyor, insanlar onu nerede ve neden dolanıyor. Bir ekibin kullandığı kestirme yol, bize kontrolün nerede sıkılaştırılması gerektiğini söylemeden önce tasarımın nerede değişmesi gerektiğini söyler.

Ardından matrisi sistemin uyguladığı bir tabloya dönüştürürüz: işletme sahibinin belirlediği limitler, satın alma türü, yetki devri ve üst kademeye aktarma ve süresiyle birlikte acil yol; onay, onaylayanın telefonuna ulaşır ve talebin kendisi üzerinde kayda geçer. Bunu, yapı değiştiğinde işletme sahibinin bir programcıya ihtiyaç duymadan limitleri değiştirebileceği şekilde tasarlarız. Bu, hizmetlerimiz sayfasında anlatılan, kurduğumuz özel sistemlerin bir parçasıdır.

Bu haftaya bir alıştırma: matrisinizi tek sayfaya çizin

Herhangi bir sistemden önce, şirketinizin bugün çalıştığı matrisi, hiç yazılmamış olsa bile yazıya dökün. İşletme sahibi bunu operasyon müdürü ve finans müdürüyle bir ya da iki oturumda yapabilir:

  • Satın alma türlerinizi sütunlara yazın: stok malzemeleri, hizmetler ve taşeronlar, sabit kıymetler ve acil alımlar. Şirketiniz bu dördünden hiçbirine uymayan bir şey satın alıyorsa bir tür ekleyin.
  • Tutar kademelerini, şirketiniz için doğru gördüğünüz limitlerle satırlara yerleştirin ve her hücreye bir kişinin adını değil, onay veren görevi yazın.
  • Her onaylayan için, o yokken onay verecek bir vekil belirleyin ve bir talebin bir üst kademeye aktarılacağı süreyi saptayın.
  • Acil durumu yazılı olarak tanımlayın; kimin başlatabileceğine, harcama tavanına ve onayının tamamlanması için gereken süreye karar verin.
  • Birinci bölümdeki alıştırmanın on faturasına geri dönün ve her biri için sorun: Bu matris yürürlükte olsaydı onu kim onaylardı? Ve o kişi gerçekten onayladı mı?

Bu son sorudaki sayfa ile gerçek arasındaki fark, sistemin kapatması gereken açıklıktır. Fark bulursanız, önce onaylayanın o anda sadece ulaşılamaz olup olmadığını kontrol edin, çünkü o zaman çözüm daha sıkı bir kontrol değil, net bir yetki devridir.

Bir sonraki bölümde

İhtiyacın artık numaralı bir talebi, kararın da sahibi bilinen bir onayı var. Bir sonraki bölüm sonraki iki istasyona geçiyor: tedarikçi ve teklif, ardından satın alma siparişi. Bir kez girilen ve tedarikçi eklenirken kontrol edilen bir tedarikçi kaydıyla başlıyor, ardından teklifleri tek bir temelde karşılaştırıyor, sonra da seçilen teklifi fiyatı, miktarı ve koşulları taşıyan ve talebine bağlanan bir satın alma siparişine dönüştürüyoruz; böylece sipariş, herhangi bir fatura gelmeden önce işletme sahibinin görebileceği bir taahhüde dönüşüyor.

Kaynaklar