Satın Alma Talebi, Politika ve Onay Süreci Nasıl Kurulur?
Ders 2 / 10 · 30 dakika okuma · İleri
Satın alma talebinin hangi bilgileri içermesi gerektiğini, politika kontrollerinin nasıl uygulanacağını ve tutar, kategori, bütçe, risk ve organizasyon yapısına göre ölçeklenebilir onay akışlarının nasıl kurulacağını öğrenin.
Bu Derste Öğrenecekleriniz
- ✓Satın alma talebinde zorunlu ve kategoriye bağlı veri alanlarını belirlemek
- ✓Talep kalitesini teknik şartname ve ticari gereksinim açısından değerlendirmek
- ✓Satın alma politikasını sistem kurallarına dönüştürmek
- ✓Tutar, kategori, bütçe ve risk bazlı onay matrisi oluşturmak
- ✓Parçalı satın alma ve onay limitini aşma girişimlerini tespit etmek
- ✓Acil, tek kaynak ve bütçe dışı talepler için kontrollü istisna akışı tasarlamak
- ✓Onay süresini ve bekleyen talepleri KPI'larla yönetmek
Satın alma sürecinin kalitesi, talebin kalitesiyle başlar. '10 adet bilgisayar lazım' ifadesi işlem başlatabilir ancak satın alma kararı vermek için yeterli değildir. Kullanım amacı, teknik gereksinim, ihtiyaç tarihi, teslimat yeri, bütçe, kategori ve gerekiyorsa mevcut sözleşme veya tercih gerekçesi gibi bilgiler satın alma ekibinin doğru yöntem seçmesini sağlar.
1. Talep formunu veri toplama ekranı değil karar girdisi olarak tasarlayın
Her alanın bir kullanım amacı olmalıdır. Satın alma veya onay kararında kullanılmayan onlarca zorunlu alan kullanıcıyı yorar; eksik kritik alanlar ise satın alma ekibinin talep sahibine tekrar dönmesine neden olur.
| Alan | Neden gerekli? | Her talepte zorunlu mu? |
|---|---|---|
| Talep başlığı/açıklaması | İhtiyacı anlaşılır tanımlamak | Genellikle evet |
| Kategori | Politika, onay ve sourcing yöntemini belirlemek | Evet |
| Miktar/birim | Hacmi ve ticari kapsamı belirlemek | Ürün alımlarında evet |
| İhtiyaç tarihi | Termin ve aciliyeti değerlendirmek | Evet |
| Teslimat/lokasyon | Lojistik ve vergi/operasyon etkisi | Gerektiğinde |
| Maliyet merkezi/proje | Bütçe ve muhasebe sınıflandırması | Politikaya göre |
| Teknik şartname | Karşılaştırılabilir teklif almak | Kategoriye göre |
| Önerilen tedarikçi | Pazar bilgisi sağlamak | Varsa; bağlayıcı olmamalı |
| Gerekçe | İhtiyacın iş değerini açıklamak | Belirli tutar/kategorilerde |
İpucu — Dinamik form kullanın
2. Teknik şartnameyi marka talebinden ayırın
Talep sahibi çoğu zaman ihtiyacı belirli bir marka veya ürün adıyla ifade eder. Satın alma açısından asıl soru, bu tercihin zorunlu teknik gereksinim mi yoksa alışkanlık mı olduğudur. Gereksiz marka bağımlılığı rekabeti azaltabilir; yetersiz şartname ise karşılaştırılamayan teklifler üretir.
Örnek — Karşılaştırılamayan teklif sorunu
3. Satın alma politikasını uygulanabilir kurallara dönüştürün
Politika yalnız '5.000 TL üzerindeki alımlar onaya tabidir' gibi tek bir eşikten oluşmaz. Hangi kategoride kaç teklif gerektiği, kimlerin tedarikçi açabileceği, hangi tutarda hangi onayların gerektiği, tek kaynak alımının nasıl gerekçelendirileceği, acil satın almanın nasıl yönetileceği ve sözleşme gerektiren durumlar açık olmalıdır.
| Politika alanı | Örnek sistem kuralı |
|---|---|
| Teklif sayısı | Kategori/tutar eşiğine göre minimum geçerli teklif |
| Yetki | Talep sahibi kendi talebini tek başına nihai onaylayamaz |
| Bütçe | Maliyet merkezi bütçesi kontrol edilir veya bütçe dışı onaya yönlenir |
| Tedarikçi | Yalnız uygun/onaylı tedarikçiye sipariş açılır |
| Tek kaynak | Gerekçe + yetkili onay zorunlu |
| Sözleşme | Belirli kategori/tutar/sürelerde hukuk veya sözleşme kontrolü |
| Acil alım | Acil gerekçesi ve sonradan denetim izi |
Uyarı — Politika ile prosedürü karıştırmayın
4. Onay matrisini yalnız tutara göre kurmayın
Tutar önemli bir kriterdir ancak tek başına riskin tamamını göstermez. Düşük tutarlı bir kişisel veri işleme hizmeti bilgi güvenliği açısından kritik olabilir; yüksek tutarlı fakat mevcut sözleşme kapsamında standart hammadde siparişi farklı kontrol gerektirebilir.
- Talep tutarı
- Kategori
- Maliyet merkezi veya bütçe sahibi
- Proje
- Sözleşme gereksinimi
- Bilgi güvenliği/veri erişimi
- Tek kaynak durumu
- Yeni tedarikçi kullanımı
- Ödeme koşulu veya avans
- Acil satın alma
- Yurt dışı veya dövizli satın alma
Örnek — Çok boyutlu onay örneği
5. Onay limitlerinin bölünerek aşılmasını engelleyin
Bir ihtiyacın onay limitinin altında kalmak için birden fazla talep veya siparişe bölünmesi kontrol sistemini etkisizleştirir. Sistem benzer tedarikçi, kategori, talep sahibi, proje ve yakın tarihli işlemleri işaretleyerek inceleme sinyali üretebilir.
Uyarı — Her bölünmüş sipariş ihlal değildir
6. Bütçe kontrolünün hangi anda yapılacağını belirleyin
Bütçe yalnız fatura aşamasında kontrol edilirse işletme çoktan ticari taahhüt altına girmiş olabilir. Talep, onay veya sipariş aşamasında bütçe kontrolü ve gerekiyorsa rezervasyon yapılması; kullanılabilir bütçenin daha doğru görülmesini sağlar.
| Yaklaşım | Avantaj | Risk/Dikkat |
|---|---|---|
| Talepte kontrol | Erken uyarı | Tahmini tutar değişebilir |
| Onayda rezervasyon | Bütçeyi taahhüt öncesi korur | İptal/ret durumunda rezervasyon çözülmeli |
| Siparişte kesinleştirme | Ticari tutara yaklaşır | Önceki aşamalarda görünürlük gerekebilir |
7. Ret ve revizyon akışlarını da tasarlayın
Onay sistemi yalnız 'onayla' düğmesinden oluşmamalıdır. Onaylayan kişi talebi reddedebilmeli veya açıklamayla revizyona gönderebilmelidir. Revizyon sonrasında hangi onayların tekrar gerektiği, hangi değişikliklerin mevcut onayı geçersiz kıldığı belirlenmelidir.
Örnek — Onayı geçersiz kılan değişiklik
8. Acil ve tek kaynak satın almayı görünmez kaçış yoluna dönüştürmeyin
Gerçek acil durumlar ve tek kaynak gereksinimleri olabilir. Bu senaryolar normal süreci gizlice atlamak yerine ayrı istisna türü olarak tanımlanmalı; gerekçe, yetkili onay, süre ve sonradan gözden geçirme bilgileri tutulmalıdır.
| İstisna | Zorunlu kayıt örneği | Sonraki kontrol |
|---|---|---|
| Acil satın alma | Acil gerekçesi, ihtiyaç tarihi, onaylayan | Acil durum kök nedeni ve tekrar sıklığı |
| Tek kaynak | Neden alternatif olmadığı, teknik/ticari gerekçe | Pazar/tedarikçi bağımlılığı değerlendirmesi |
| Bütçe dışı | İş gerekçesi ve finans/yönetim onayı | Bütçe etkisi |
| Politika dışı ödeme | Avans/özel vade gerekçesi | Finansal risk |
9. Onay süresini ölçün; kontrolü hızın düşmanı yapmayın
Kontrol için tasarlanan onay zinciri gereksiz adımlarla uzarsa kullanıcılar sistemi aşmanın yollarını arar. Hangi onay seviyesinde ne kadar bekleme olduğu, kimlerin sürekli darboğaz oluşturduğu ve düşük riskli taleplerin gereğinden fazla kontrolden geçip geçmediği ölçülmelidir.
| KPI | Ne gösterir? | Olası aksiyon |
|---|---|---|
| Talep → ilk onay süresi | İlk karar gecikmesi | Bildirim/delege/yetki düzenleme |
| Toplam onay çevrim süresi | Onay zincirinin toplam hızı | Gereksiz adım ve eşik analizi |
| Revizyona dönen talep oranı | Talep kalitesi | Form, eğitim ve şartname iyileştirmesi |
| Politika istisna oranı | Standart sürecin uygunluğu | Kural veya davranış kök neden analizi |
| Bekleyen talep yaşlandırması | Operasyon kuyruğu | SLA ve eskalasyon |
İlgili çözüm: Satın Alma ve Tedarikçi Portalı
Şimdi Uygulayın
Uygulama Görevi — Satın Alma Talep ve Onay Matrisi
İşletmenizde en sık satın alınan en az beş kategori seçin. Her kategori için talepte gerekli bilgileri, tutar eşiklerini, bütçe kontrolünü, gerekli teklif sayısını, onay rollerini ve istisna koşullarını tanımlayın. Ardından düşük riskli standart alımlarda hangi kontrollerin otomatikleştirilebileceğini belirleyin.
| Kategori/Tutar | Talep verisi | Teklif kuralı | Onay | Bütçe | İstisna |
|---|---|---|---|---|---|
| … | … | … | … | … | … |
| … | … | … | … | … | … |
| … | … | … | … | … | … |
İpucu — Kabul testi
Bu Derste Ne Öğrendik?
- ✓Kaliteli satın alma, kaliteli taleple başlar.
- ✓Talep formu ihtiyacın ne olduğunu, neden gerektiğini, ne zaman gerektiğini, hangi bütçe ve kategoriye ait olduğunu karar verilebilir düzeyde açıklamalıdır.
- ✓Satın alma politikası dokümanda kalmamalı; tutar, kategori, bütçe, risk ve görev ayrılığı kuralları sistemde uygulanmalıdır.
- ✓Onay akışı kontrol sağlarken gereksiz adımlarla süreci kilitlememeli; istisnalar gerekçe, yetki ve audit iziyle yönetilmelidir.