Dahili satın alma talebi sistemi: darboğazlardan kaçının

Satın alma talepleri neden takılıp kalır?

Satın alma gecikmelerinin çoğu, birinin talebi onaylamasından veya reddetmesinden önce başlar. Bir çalışan dizüstü bilgisayar isteğini e-postayla gönderir, sohbet kanalında bir fiyat paylaşır, ardından finans ekibi için bir elektronik tablo satırı ekler. Talebin bir bölümü her yerde kalır. Sonra satın alma sorumlusunun tedarikçiyi, maliyeti, iş gerekçesini, bütçe sahibini ve son tarihi bir araya getirmesi gerekir.

Bu durum tekrarlanan işler yaratır. Yönetici, çalışanın daha önce finansa gönderdiği ayrıntıları yeniden ister. Finans bütçeyi kontrol eder, ancak departman yöneticisinin ihtiyacı onaylayıp onaylamadığını göremez. Çalışan da talebin nerede olduğunu veya sıradaki işlemi kimin yapması gerektiğini anlayamaz.

Eksik bilgiler gecikmelere yol açar

Talep, sürece dahil olan herkesin ihtiyaç duyduğu bilgileri içermediğinde satın alma onay iş akışı yavaşlar. Yaygın eksikler şunlardır:

• Ürün açıklaması, miktar veya tedarikçi teklifi yoktur
• Departman, maliyet merkezi veya bütçe tutarı yoktur
• İş gerekçesi veya istenen teslim tarihi yoktur
• Onay sorumlusu veya satın alma sorumlusu belirtilmemiştir
• Yorumların, değişikliklerin veya önceki kararların kaydı yoktur

Tek bir eksik bile talebi başlangıca döndürebilir. Ekip lideri 1.200 dolarlık bir yazılım yenilemesini onaylar, ancak finans daha sonra bütçenin kime ait olduğunun belirtilmediğini fark eder. Sipariş vermek yerine ekip, harcamadan sorumlu kişiyi bulmak için günler harcar.

Tek kayıt ve net sorumluluk

Dahili satın alma talebi sistemi, gönderimden satın alma siparişine devre kadar talebin tamamını tek yerde tutar. Talep sahibi ihtiyacı bir kez girer. Yöneticiler, finans çalışanları ve satın alma ekibi aynı ayrıntıları görür, aynı kayda yorum ekler ve görünür bir karar geçmişi bırakır.

Net durum etiketleri gereksiz takip mesajlarını azaltır. Bir talep, bütçe incelemesine mi, yönetici onayına mı, satın alma işlemi yapılmasına mı yoksa tedarikçi bilgisine mi ihtiyaç duyduğunu gösterebilir. Her aşama için adı belirlenmiş bir kişi veya rol ve yokluk durumları için bir yedek kural gerekir.

Kodsuz satın alma uygulaması, operasyon ekiplerinin form ve elektronik tabloları ayrı ayrı yönetmesine gerek bırakmadan bunu mümkün kılar. AppMaster, talepleri, bütçe alanlarını, onay mantığını ve satın alma kuyruğunu tek bir uygulamada destekleyebilir. Her talebin tek bir merkezi, güncel bir sorumlusu ve siparişe ilerlemesini sağlayacak kadar ayrıntısı olmalıdır.

Her talebe hangi bilgilerin eklenmesi gerektiğine karar verin

Bir talep formu, yöneticilere ve satın alma ekibine hızlı karar vermeleri için yeterli bilgi sağlamalıdır. Çalışanlar temel bilgileri takip mesajlarında açıklamak zorunda kalıyorsa form fazla yetersizdir. Çalışanların bilemeyeceği finansal ayrıntılar isteniyorsa insanlar tahminde bulunur veya vazgeçer.

Her talepte ürün adı, miktar, tedarikçi, tahmini birim maliyet, toplam maliyet ve iş gerekçesi bulunmalıdır. Bu ayrıntılar bütçeyi veya teslimatı etkiliyorsa departmanı, maliyet merkezini, talep sahibini ve ihtiyaç tarihini de ekleyin. Çalışan giriş yaptıktan sonra sistem adını ve departmanını otomatik olarak doldurabilir.

Kısa bir gerekçe, büyük ve boş bir metin kutusundan daha iyi çalışır. Örneğin: «Yeni akşam vardiyası için beş ek müşteri destek koltuğu.» Bu ifade onaylayana pratik bir gerekçe, miktar ve mevcut işle bağlantı sunar.

İki talep türü kullanın

Katalog satın alımları ile tek seferlik satın alımlar farklı formlara ihtiyaç duyar. Katalog ürününün onaylanmış bir açıklaması, tedarikçisi, fiyatı ve bazen sözleşme referansı zaten vardır. Çalışan ürünü seçer, miktarı girer ve ihtiyacı açıklar. Böylece sık kullanılan talepler tutarlı kalır.

Tek seferlik satın alımda daha fazla bağlam gerekir, çünkü satın alma ekibi sipariş vermeden önce ürünü değerlendirmelidir. Ürün veya hizmet açıklamasını, biliniyorsa tercih edilen tedarikçiyi ve iletişim bilgilerini, teklifi veya tahmini maliyeti, miktarı ve faturalandırma sıklığını, iş gerekçesini ve istenen teslim tarihini isteyin.

Bir şeyi talep edebilmek için çalışanları tedarikçi bulmaya zorlamayın. Şirket kurallarına uygun hangi satıcının olduğunu bilmeden ayakta çalışmaya uygun bir masa istemeleri mümkündür. Satın alma ekibi bu kısmı daha sonra tamamlayabilir.

Zorunlu alanları gerçekten gerekli olduklarında kullanın

Bir alanı yalnızca birinin talebi onaylamak, bütçelemek veya satın almak için ona ihtiyacı varsa zorunlu yapın. Ürün, miktar, tahmini maliyet, maliyet merkezi ve gerekçe genellikle bu gruba girer. Ekleri yalnızca belirli bir harcama limitinin üzerindeki taleplerde veya yazılım aboneliği gibi kategorilerde zorunlu tutun.

Koşullu alanlar formu daha kullanışlı tutar. Bir yazılım talebinde kullanıcı sayısı, yenileme tarihi ve müşteri verilerinin işlenip işlenmeyeceği sorulabilir. Fiziksel bir üründe ise bunun yerine teslimat adresi istenebilir. Her satın alma onay iş akışı, tüm çalışanları uzun bir formdan geçirmeden ihtiyaç duyduğu bilgileri alır.

Kullanıma açmadan önce üç test talebi gönderin: bir katalog ürünü, yeni tedarikçi satın alımı ve tekrarlanan bir hizmet. Onaylayan kişi hâlâ bariz bir soru soruyorsa bir alan ekleyin veya mevcut alanı daha anlaşılır hale getirin.

Talepleri hızlandıran bir katalog oluşturun

Katalog, tekrarlanan işleri ortadan kaldırır. Her çalışandan dizüstü bilgisayarı, yazılım lisansını veya ofis sandalyesini baştan açıklamasını istemek yerine onaylanmış seçeneklerden oluşan kısa bir liste sunun.

Her katalog ürününde anlaşılır bir açıklama, normal birim fiyat ve tercih edilen tedarikçi bulunmalıdır. Takip mesajlarını önleyecek ürün kodu, sözleşme süresi, mevcut boyutlar veya yöneticinin ihtiyacı onaylaması gerekip gerekmediği gibi ayrıntıları da ekleyin.

Örneğin «Standart dizüstü bilgisayar» kaydında model, onaylanmış tedarikçi, 1.200 dolarlık fiyat ve üç yıllık garanti bulunabilir. Talep sahibi miktarı seçer ve ürünü kimin kullanacağını açıklar. Satın alma ekibi her seferinde aynı yararlı bilgileri alır.

Seçenekleri basit tutun

Kataloğu her tedarikçi web sitesinin kopyasına dönüştürmeyin. Çalışanların sık sipariş ettiği ürünlerle başlayın, ardından aynı serbest metin talebi tekrar tekrar geldiğinde yeni kayıtlar ekleyin. Uzun ve düzensiz bir katalog yeni bir gecikme yaratır.

Ürünleri yazılım, ekipman, ofis malzemeleri ve profesyonel hizmetler gibi bilinen kategorilerde gruplandırın. Çalışanların ürün açıklaması yazmaya başlamadan önce ürünü bulabilmesi için arama özelliği ve kısa adlar kullanın.

Bir katalog kaydında genellikle ürün adı, açıklama, birim fiyat veya beklenen aralık, tercih edilen tedarikçi, faturalandırma birimi ve kısıtlamalar bulunur. Örneğin bir abonelik «kullanıcı başına, aylık» şeklinde gösterilebilir ve yönetici onayı gerektiği belirtilebilir.

İstisnalara yer bırakın

Çalışanların listede olmayan bir şeye ihtiyaç duyduğu durumlar olacaktır. Serbest metin seçeneğini koruyun, ancak sonraki adımı mümkün kılacak kadar bilgi isteyin: ihtiyaç, tahmini maliyet, biliniyorsa tedarikçi ve iş gerekçesi.

Serbest metin taleplerini katalog hatası olarak değil, inceleme kuyruğu olarak değerlendirin. Satın alma ekibi teklifleri karşılaştırabilir, tedarikçiyi onaylayabilir veya gelecekteki talepler için ürünü kataloğa eklemeye karar verebilir.

AppMaster ile oluşturulmuş bir kodsuz satın alma uygulamasında katalog ürünü seçildiğinde fiyat, tedarikçi ve talep alanları otomatik doldurulabilir. Bu, bütçe onay süreci için daha temiz veriler sağlar ve satın alma siparişine devirden önceki düzeltme işlerini azaltır.

Onaydan önce bütçe kontrolleri ekleyin

Bir talep, onay görevi başlamadan önce finansal bağlamını göstermelidir. Talep sahibinden bir departman ve maliyet merkezi seçmesini isteyin, ardından tutarı ve para birimini kaydedin. Sistem bu alanları kullanarak ilgili bütçeyi bulabilir.

Talep sahipleri için kontrolü basit tutun. Talep toplamını, kullanılabilir bütçeyi ve onaydan sonra kalacak tutarı görebilmelidirler. «Bu talep kalan bütçeyi 420 dolar aşıyor» gibi bir mesaj, yöneticinin sorunu daha sonra bir e-posta zincirinde fark etmesini önler.

Bütçe rakamlarının sorumluluğu finansta olmalıdır. Çalışanlar her dönemin başında departman veya maliyet merkezi için onaylanmış tutarı güncelleyebilir, planlar değiştiğinde revize edebilir. Dahili satın alma talebi sistemi, henüz faturaya dönüşmemiş onaylı talepleri de izlemelidir. Aksi halde bir ekip, bu fonları daha önce taahhüt etmiş olmasına rağmen elinde hâlâ para varmış gibi görünebilir.

Talebin tamamını kontrol edin

Satın alma ekibinin gerçekte ödeyeceği tutarı hesaplayın. Uygun olduğunda miktarları, birim fiyatları, vergileri, kargoyu, kurulum ücretlerini ve tekrarlanan ödemeleri dahil edin. 900 dolarlık bir yazılım aboneliği ile 150 dolarlık kurulum ücreti toplam 1.050 dolarlık bir taleptir.

Talep sahibi formu gönderdiğinde, sistem onaylayana iletmeden önce bütçe onay sürecini çalıştırın. Böylece boşa inceleme yapılmaz ve talep sahibi maliyet merkezini düzeltebilir, siparişi küçültebilir veya istisnayı açıklayabilir.

Kodsuz bir satın alma uygulamasında bu, görsel bir kural olabilir: seçilen maliyet merkezini okuyun, talep toplamını kalan bütçeyle karşılaştırın ve sonucu talebin üzerine kaydedin. AppMaster talep verilerini modelleyebilir, mantığı Business Process Editor'da oluşturabilir ve sonucu dahili bir formda gösterebilir.

Bütçeyi aşan taleplerin nasıl ilerleyeceğine karar verin

Bütçeyi aşan bir talebi belirsiz bir durumda bırakmayın. Harcama politikasına uygun belirli bir yol tanımlayın. Talebi fark gösterilerek talep sahibine geri gönderebilir, istisna için bütçe sahibine iletebilir, acil ihtiyacı finansa gönderebilir veya tarih ve gerekçeyle bir sonraki bütçe dönemine kadar bekletebilirsiniz.

Bütçe sonucunu ve varsa istisna kararını kaydedin. Satın alma ekibi siparişi başlattığında çalışanlar harcamanın ilk bütçeye uyup uymadığını ve ek tutarı kimin onayladığını görebilir. Finans da bir maliyet merkezinin planı neden aştığını açıklayabilir.

İnsanların takip edebileceği onay rotaları belirleyin

Bir dahili satın alma talebi sisteminde, herhangi biri talep göndermeden önce yönlendirme kuralları hazır olmalıdır. Talepleri ara sıra kontrol edilen genel bir gelen kutusuna göndermek yerine harcamayı değerlendirebilecek kişilere iletin.

Rotayı formda zaten toplanan bilgilere dayandırın. Departman, maliyet merkezi, satın alma kategorisi ve toplam tutar genellikle yeterli bağlamı sağlar. 40 dolarlık ofis malzemesi talebi yalnızca ekip yöneticisinin onayını gerektirebilir. Yeni bir yazılım sözleşmesi ise bütçe sahibinin, BT'nin, güvenliğin ve satın alma ekibinin onayını gerektirebilir.

Risk düşük olduğunda rotaları kısa tutun. «Her ihtimale karşı» onaylayanlar eklemek basit bir satın alma onay iş akışını gecikmeler zincirine dönüştürür. Her onaylayan kişinin onaylamak, reddetmek veya daha fazla bilgi istemek için açık bir nedeni olmalıdır.

Öngörülebilir kurallar kullanın

Çalışanlar talebi göndermeden önce nereye gideceğini bilmelidir. Öngörülebilir kurallar, talep takıldığında yaşanan anlaşmazlıkları da azaltır.

Örneğin bir şirket şu kuralları kullanabilir:

• 500 doların altındaki talepler departman yöneticisine gider.
• 500 ila 5.000 dolar arasındaki talepler yöneticiye ve maliyet merkezi sahibine gider.
• Yazılım ve bulut hizmeti talepleri ayrıca BT veya güvenlik ekibine gider.
• 5.000 doların üzerindeki talepler bütçe onayından sonra satın alma ekibine gider.
• Sermaye harcamaları tutardan bağımsız olarak finans sorumlusuna gider.

Kuralların tüm departmanlarda aynı olması gerekmez. Satış ekibi müşteriyle doğrudan ilgili araçlar için onay isteyebilir, operasyon ekibi ise ek bir ekipman kontrolüne ihtiyaç duyabilir. Çalışanların her seferinde süreci yeniden öğrenmemesi için şirket genelinde aynı temel mantığı kullanın.

Yoklukları planlayın ve kaydı eksiksiz tutun

Her onaylayanın bir yedeği olmalıdır. Yönetici izindeyse sistem yeni talepleri adı belirlenmiş bir vekile göndermeli veya yöneticinin bekleyen işleri yeniden atamasına izin vermelidir. Talep sahipleri e-posta veya sohbet üzerinden birini takip etmek zorunda kalmamalıdır.

Bir yanıt hedefi belirleyin. Örneğin iki iş gününden sonra onaylayana bildirim gönderin, beş gün sonra talebi yedeğe iletin. Eskalasyon, ilk rotayı ve karar geçmişini korurken talebi ilerletmelidir.

Her kararı talep kaydında tutun. Kimin onayladığını veya reddettiğini, ne zaman işlem yaptığını ve yorumlarını gösterin. «Yenileme tarihine kadar mevcut ekip lisansını kullanın» gibi bir ret gerekçesi, talep sahibine pratik bir sonraki adım, satın alma ekibine de sipariş için bağlam sağlar.

AppMaster ekiplerin talep alanlarını modellemesine, görsel bir iş sürecinde onay mantığı oluşturmasına ve talep sahiplerine güncel durumu göstermesine olanak tanır. Sorumluluk e-posta zincirlerinde kaybolmak yerine görünür kalır.

Talep akışını adım adım oluşturun

Net bir talep akışı, basit satın alımların e-postalar arasında kaybolmasını önler. Her durum mevcut aşamayı açıklamalı ve herkes ne zaman işlem yapması gerektiğini bilmelidir.

Küçük bir durum setiyle başlayın: Taslak, Gönderildi, Onaylandı, Reddedildi, Sipariş verildi ve Teslim alındı. «İnceleme bekliyor» ve «Onay bekliyor» gibi neredeyse aynı anlama gelen etiketlerden kaçının. İnsanlar bunları tutarsız kullanır ve raporlamanın güvenilirliği düşer.

Talep taslak olarak başlar. Talep sahibi onu kaydedebilir, ürünü veya miktarı değiştirebilir ya da silebilir. Sistem bu aşamada bildirim göndermemeli veya bütçe ayırmamalıdır.

Talep sahibi formu gönderdiğinde durum Gönderildi olur. Talep değişiklik için geri gönderilmediği sürece fiyatı, tedarikçi ayrıntılarını ve istenen tutarı kilitleyin. Onaylayan kişi talebi onaylayabilir, reddedebilir veya kısa bir yorumla geri gönderebilir.

Onaydan sonra talebi satın alma ekibine devredin. Çalışanlar yalnızca satın alma siparişini oluşturduktan veya verdikten sonra durumu Sipariş verildi olarak işaretlemelidir. Harcama izni, birinin ürünü satın aldığını kanıtlamaz.

Ürünler ulaştığında, hizmet erişimi başladığında veya abonelik doğrulandığında teslim alan kişi talebi Teslim alındı olarak işaretler. Böylece finans ve talep sahipleri gelen ürünler için güvenilir bir kayda sahip olur.

Her role açık işlemler verin

Basit bir dahili satın alma talebi sistemi, durum değişikliklerinin sorumluları olduğunda daha iyi çalışır. Her kullanıcının gönderilmiş her talebi düzenlemesine izin vermeyin.

• Talep sahipleri taslak oluşturur, talep gönderir ve geri gönderilen talepleri düzeltir.
• Yöneticiler ve bütçe sahipleri talepleri onaylar, reddeder veya gerekçeyle geri gönderir.
• Satın alma çalışanları tedarikçi bilgilerini, satın alma siparişi ayrıntılarını ve sipariş durumunu kaydeder.
• Teslim alan kişiler teslimatı doğrular ve talepleri Teslim alındı olarak işaretler.
• Finans çalışanları tüm geçmişi görür ve muhasebe referansı gibi sınırlı alanları düzeltir.

Yönetici, onaylayanın şirketten ayrılması veya yinelenen bir talep gibi istisnaları ele almalıdır. Her durum değişikliği için kimin, ne zaman ve hangi yorumla işlem yaptığını içeren bir denetim izi tutun.

İşlem yapması gereken kişilere bildirim gönderin

Gönderilmiş bir talep onaylayana ulaştığında bildirim gönderin. Talep başlığını, tutarı, departmanı ve verilmesi gereken kararı ekleyin. «Yeni bir göreviniz var» gibi belirsiz bir mesaj, insanların bağlamı aramasını gerektirdiği için işlemi geciktirir.

Birisi talebi onayladığında, reddettiğinde veya geri gönderdiğinde talep sahibine bildirim gönderin. Ret veya geri gönderme için yorum zorunlu olsun. «Bu çeyrekte bütçe kullanılamıyor» talep sahibine yol gösterir. «Hayır» göstermez.

Satın alma ekibi son onaydan sonra bildirim almalıdır. Satın alma ekibi talebi Sipariş verildi ve Teslim alındı olarak işaretlediğinde talep sahibine güncelleme gönderin. Belirlenen süre içinde kimse işlem yapmazsa mevcut sorumluya hatırlatma gönderin ve yedek onaylayanı bilgilendirin.

AppMaster ile kodsuz bir satın alma uygulaması, durumları Data Designer'da modelleyebilir ve izin verilen değişiklikleri Business Process Editor'da uygulayabilir. Her devir, birinin onu hatırlamasına bağlı kalmak yerine kaydın üzerinde tutulur.

Örnek: yazılım aboneliği talebi

Pazarlama yöneticisi Maya'nın bir sosyal medya planlama aracına 15 aboneliğe ihtiyacı vardır. Serbest metin talebi oluşturmak yerine dahili satın alma talebi sistemini açar ve aracı yazılım kataloğundan seçer.

Katalog kaydında tedarikçi, plan türü, kullanıcı başına fiyat, faturalandırma dönemi ve sözleşmenin sahibi olan ekip bulunur. Maya 15 lisans girer, Pazarlama maliyet merkezini seçer ve şu gerekçeyi ekler: ekibin kampanya gönderilerini ortaklaşa planlaması ve onaylaması gerekiyor.

Uygulama, Maya göndermeden önce yıllık maliyeti hesaplar. Pazarlama ekibinin yeterli yazılım bütçesi vardır, bu nedenle talep bütçe kontrolünden geçer. Bütçe yetersiz olsaydı uygulama talebi durdurabilir ve Maya'dan başka bir maliyet merkezi seçmesini veya ek fon istemesini isteyebilirdi. Bu, finansın ödeyemeyeceği bir satın alımın yönetici tarafından onaylanmasını önler.

Talep yöneticinin harcama limiti içinde olduğu için Maya'nın departman yöneticisine gider. Onay ekranında maliyet, kullanıcı sayısı, iş gerekçesi ve bütçe bakiyesi görünür. Yönetici talebi onaylar.

Satın alma ekibi tedarikçi ve planı, yıllık toplamı ve yenileme tarihini, maliyet merkezini ve bütçe sonucunu, Maya'nın gerekçesini ve yöneticinin zaman damgalı onayını içeren eksiksiz bir kayıt alır. Satın alma koordinatörü şirketin tedarikçiyle zaten bir anlaşması olup olmadığını kontrol eder. Anlaşma varsa kaydedilen bilgilerle satın alma siparişini oluşturur. Yoksa sipariş vermeden önce tedarikçi incelemesini başlatır.

Koordinatör satın alma siparişi numarasını kaydeder ve talebi Sipariş verildi olarak işaretler. Maya satın alma ekibine sormadan güncellemeyi görebilir. Tedarikçi 15 lisansı doğruladığında koordinatör talebi Teslim alındı olarak işaretler ve hesabı kimin yöneteceğini kaydeder.

Bu akış her kararı talebe bağlı tutar. Finans ekibi ekibin yazılımı neden aldığını, hangi bütçenin ödediğini ve harcamayı kimin onayladığını görebilir.

Satın alma sürecini yavaşlatan hatalar

Bir satın alma süreci akış şemasında basit görünüp kullanıcılarını yine de zorlayabilir. Sorunlar genellikle sistem her talebi sıra dışı kabul ettiğinde veya onaydan sonra değişikliklerin kontrolünü kaybettiğinde ortaya çıkar.

Her talebi üst yönetime göndermek

Birçok ekip her talebi tek bir üst düzey yöneticiye gönderir. Böylece yedek klavye, aylık yazılım yenilemesi veya düşük harcama limitinin altındaki malzemeler gibi rutin işler bu kişinin kuyruğunda birikir. Yönetici iki gün yoksa herkes bekler.

Onay rotalarını maliyete, departmana ve talep türüne göre eşleştirin. Ekip lideri belirli bir limitin altındaki standart katalog ürününü onaylayabilir. Departman sahibi daha büyük satın alımları inceleyebilir. Talep bütçeyi etkilediğinde veya limiti aştığında finans sürece katılabilir. Üst düzey yöneticilere sıradan talepler değil, istisnalar gitmelidir.

Onaylanmış taleplerin sessizce değişmesine izin vermek

Son onay belirli bir ürün, miktar, tedarikçi ve fiyat için geçerlidir. Birisi bu ayrıntıları daha sonra değiştirirse onay artık yapılan harcamayla örtüşmeyebilir.

Önemli düzenlemeler için kurallar belirleyin. 10 lisanstan 12 lisansa veya 500 dolardan 1.200 dolara yapılan değişiklik, talebi ilgili inceleyene geri göndermelidir. Teslimat sorumlusu gibi küçük notlar, satın alma onay iş akışını baştan başlatmadan düzenlenebilir kalabilir.

Kodsuz bir satın alma uygulaması düzenleme geçmişini tutabilir ve kontrollü alanlar değiştiğinde onayı yeniden açabilir. Böylece finans onaylanan tutarı faturayla karşılaştırırken sürprizlerle karşılaşmaz.

Talebi çok erken kapatmak

Onay, satın alma sürecinin sonu değildir. Satın alma ekibinin tedarikçiyi, satın alma siparişi numarasını, son fiyatı, sipariş tarihini ve teslimat durumunu da kaydetmesi gerekir. Bu ayrıntılar oluşmadan talep kapatılırsa çalışanlar daha sonra e-postaları ve elektronik tabloları aramak zorunda kalır.

Onaylandı, Sipariş verildi, Teslim alındı ve Kapatıldı gibi net durumlar kullanın. Talebi yalnızca satın alma ekibi sipariş ayrıntılarını kaydedip devri doğruladıktan sonra Kapatıldı durumuna taşıyın. Onaylanmış yıllık abonelik, satın alma sorumlusu tedarikçi siparişini veya yenileme referansını kaydedene kadar Onaylandı durumunda kalmalıdır.

Bu ayrım raporlamayı daha güvenilir hale getirir. Ekipler hangi onaylanmış taleplerin hâlâ işlem beklediğini, hangi siparişlerin teslimat beklediğini ve hangi satın alımların tamamlandığını görebilir.

Kullanıma açmadan önce hızlı kontroller

Kısa bir test çalışması, çalışanlar dahili satın alma talebi sistemine güvenmeye başlamadan önce sorunların çoğunu ortaya çıkarır. Küçük bir gruptan ofis malzemesi, yazılım yenilemesi ve hizmet sözleşmesi gibi gerçekçi talepler göndermesini isteyin. Talep sahiplerini, onaylayanları ve satın alma siparişi oluşturan çalışanları dahil edin.

Her talebin tek bir açık sorumlusu ve görünür bir durumu olmalıdır. Sorumluluk talep sahibinden yöneticiye veya satın alma sorumlusuna geçtiğinde sorumlu değişmelidir. Durum etiketleri Taslak, Gönderildi, Onaylandı, Reddedildi veya Satın almaya devredildi gibi ne olduğunu açıklamalıdır.

Uygulamayı herkese açmadan önce her talebin sorumlusunu, mevcut durumunu, tutarını ve sıradaki onaylayanını gösterdiğini doğrulayın. Onay kurallarını gerçek harcama limitleri ve departman kurallarıyla karşılaştırın. Satın alma ekibinin tedarikçiyi, teklif edilen fiyatı, onaylanan miktarı ve istenen teslim tarihini görebildiğini kontrol edin.

Bütçeyi aşan bir talebi test edin ve uygulamanın onu durdurduğunu veya doğru kişiye gönderdiğini doğrulayın. Başka bir talebi açık bir gerekçeyle reddedin, ardından talep sahibinin gerekçeyi aldığını ve formu güncelleyebildiğini kontrol edin.

Bütçe testlerinde gerçek rakamlar kullanın. Bir ekibin kalan aylık bütçesini 2.000 dolar olarak belirleyin ve 2.400 dolarlık bir talep gönderin. Sistemin talebi engellemesine, finansın onayını istemesine veya bütçe sahibinin fon aktarmasına izin vermesine karar verin. Sürece dahil herkes aynı sonucu görmelidir.

Onaydan sonraki değişiklikleri de test edin. Talep sahibi 10 monitörlük siparişi 15'e çıkarabilir veya tedarikçi teklif edilen fiyatı artırabilir. Satın alma onay iş akışı talebi yeniden onaya göndermeli veya yeniden inceleme gerektirmeyen değişiklikleri açıkça belirtmelidir. Sessiz değişiklikler daha sonra anlaşmazlık yaratır.

Son olarak satın alma siparişine devri test edin. Satın alma ekibi onaylanan ayrıntıları e-posta veya sohbetten yeniden yazmak yerine tek bir yerde almalıdır. AppMaster'da ekipler bu yolları örnek kayıtlarla test edebilir ve uygulamayı yayımlamadan önce görsel kuralları düzenleyebilir. Başarısız testlerin kısa bir kaydını tutun, her birinin arkasındaki kuralı düzeltin ve testi yeniden çalıştırın.

Sonraki adımlarınızı seçin

Tekrarlanan satın alımları ve yönetilebilir bir onay zinciri olan bir departmanla başlayın. BT yazılımları, ofis malzemeleri veya pazarlama abonelikleri pratik başlangıç noktalarıdır. Bu gruba yaygın ürünleri, tahmini fiyatları ve satın alma ekibinin ihtiyaç duyduğu bilgileri içeren kısa bir katalog sunun.

İlk sürümü odaklanmış tutun. Talep sahibi net bir ihtiyacı gönderebilmeli, onaylayan kişi maliyeti ve bütçe durumunu görebilmeli, satın alma ekibi de onaydan sonra eksiksiz bir talep alabilmelidir. Temel yol güvenilir biçimde çalıştıktan sonra sıra dışı talep türlerini ekleyin.

İlk birkaç haftadan sonra dahili satın alma talebi sisteminin her bölümünü kullanan kişilerden geri bildirim alın. Talep sahipleri kafa karıştıran alanları belirleyebilir. Onaylayanlar nerede daha fazla bağlama ihtiyaç duyduklarını açıklayabilir. Satın alma çalışanları eksik tedarikçi ayrıntılarını veya hâlâ uygulama dışından gelen talepleri gösterebilir.

Bu geri bildirimleri kullanarak kimsenin kullanmadığı alanları kaldırın, tekrarlanan satın alımlar için katalog kayıtları ekleyin, onay limitlerini netleştirin, sıradaki sorumlu kişiyi gösterin ve birinin talebi neden geri gönderdiğini veya reddettiğini kaydedin.

AppMaster, ekiplerin boş bir teknik projeyle başlamak zorunda kalmadan kodsuz bir satın alma uygulaması oluşturmasına yardımcı olabilir. Ekipler çalışan talep formları oluşturabilir, bütçe kontrolleri ve onay rotaları için Business Process Editor'ı kullanabilir, yöneticiler ve satın alma çalışanları için ayrı ekranlar hazırlayabilir. Data Designer, katalog ürünlerini, departmanları, tedarikçileri, bütçeleri ve talepleri tek bir yerde tutabilir.

Küçük bir pilot, pratik sorunları hızla ortaya çıkarır. Çalışanlar hâlâ talepleri e-postayla gönderiyorsa daha fazla kural eklemeden önce bunun nedenini bulun. İnsanların geçici çözümlerden daha net ve hızlı olduğu için tercih edeceği bir talep yolu oluşturun. Pilot sorunsuz çalışmaya başladığında yapıyı sonraki departmana uyarlayın, ancak kataloğunu ve onay kurallarını o ekibin harcama biçimine bağlı tutun.