Yeni tedarikçilerin devreye alınma gününü kaos olmadan nasıl yürütürsünüz

Zaten seçilmiş tedarikçilerin operasyonel olarak devreye alınması için pratik bir şema: filtre, istasyonlar, roller, istisna bankosu, hazır olma kararı ve devam paketi.

Tedarikçi zaten seçildi, anlaşmalar sağlandı, davetiyeler gönderildi. Sahada, erişim e-postasını yanlış çalışanın aldığı, muhasebenin fatura gerekliliklerini bilmediği, banka bilgilerinin doğrulama beklediği ve tüm karmaşık soruların tek bir kuyrukta durduğu ortaya çıkıyor. Ekip güzergâhı ve hazır olma kriterini önceden belirlemezse, yeni tedarikçilerin bağlantı günü kolayca bir danışma masasına dönüşür.

Biz Aventura'da böyle bir günü bir başka sunum değil, çalışır bir devreye alma olarak kurguluyoruz. Genel bölümü kısa tutuyoruz. Tedarikçiler zamanlarının çoğunu istasyonlarda geçiriyor: profili, belgeleri, erişimleri, sipariş alma kanalını ve fatura düzenleme usulünü teyit ediyorlar. Çözülmemiş durumlar hemen sahibi ve sonraki adımı belirlenmiş ayrı bir akışa aktarılıyor.

Bu format, karşı taraf seçildikten sonra başlar. Şirket hâlâ pazarı ve gelecekteki gereklilikleri inceliyorsa, önce tedarikçilerle ön ihale konferansı senaryosu gerekir. Görev daha genişse ve pazarın şirketi, kategorileri ve uzmanları tanımasını içeriyorsa, tedarikçi günü uygundur. Burada bir sonraki aşamayı ele alıyoruz: zaten seçilmiş şirketlerin operasyonel olarak devreye alınması.

Hangi sonuç tedarikçi katılımı olarak kabul edilmelidir?

Katılım, tedarikçi üzerinde anlaşılan ilk çalışma döngüsünü gerçekleştirebildiğinde veya başlatmayı şu anda hangi koşulların engellediğini tam olarak bildiğinde tamamlanmış olur. Oluşturulan hesap yalnızca tek bir adımı doğrular. Hazır olma durumu; doğrulanmış bir profil, zorunlu belgeler, uygun roller, çalışan bir sipariş alma kanalı ve anlaşılır bir fatura ve destek sürecini kapsar.

Oracle'ın resmi materyalleri şirket kaydını, profil doldurmayı, gerekli belgelerin yüklenmesini ve kullanıcı erişimlerinin oluşturulmasını birbirinden ayırır. Zorunlu yeterlilik gereklilikleri ve belge doğrulaması ayrı aşamalar olarak kalır. Bu nedenle yeşil "hesap oluşturuldu" işareti otomatik olarak "tedarikçi kabul edildi" anlamına dönüşmemelidir.

Hazır olma tanımını katılımcıları davet etmeden önce belirliyoruz. Bu tanım şu soruları yanıtlamalıdır:

1. Şirket ve çalışma iletişim bilgileri doğrulandı mı?
2. Zorunlu alanlar ve belgeler işleme alındı mı?
3. Kullanıcılar sisteme giriş yapabiliyor ve yalnızca gerekli işlevleri görebiliyor mu?
4. Tedarikçi, siparişin hangi tüzel kişilikten ve hangi kanaldan geleceğini anlıyor mu?
5. Muhasebe, fatura gerekliliklerini ve fatura durumunu nasıl kontrol edeceğini biliyor mu?
6. Kapatılmamış her madde için bir sorumlu ve bir sonraki adım atandı mı?

Bazı kontroller etkinlikten sonra da devam edebilir. Ekip bunu "tamamlandı" kelimesiyle gizlemediği sürece bu normal bir sonuçtur. Gün, her soruyu yerinde kapatma vaadi değil, doğrulanabilir bir durum sunmalıdır.

Davetten önceki ön filtre

Davetten önce, standart rotaya sahip tedarikçileri önceden ayrı bir çalışma oturumuna ihtiyaç duyan durumlardan ayırıyoruz. Filtre atlanırsa, entegrasyon projesi, yabancı tüzel kişilik ve sıradan hizmet tedarikçisi aynı akışa girer. İlk istasyon açılmadan önce bile kuyruk oluşur.

Satın alma biriminden her şirket için kısa bir pasaport doldurmasını istiyoruz. Bunda tam tedarikçi anketi yok. Yalnızca rotayı değiştiren işaretler gereklidir.

Etkinlikten önce tedarikçi belge listesini, dosya adlandırma kurallarını, sistem gereksinimlerini ve gerekli katılımcıların listesini alır. Ticari iletişim kişisi, portal yöneticisinin veya muhasebecinin yerini tutmaz. Kilit çalışan katılmıyorsa, kart önceden şu koşulu alır: bazı istasyonlardan geçilemez.

Ödemeden önce karşı taraf kontrolü ayrı bir görev olarak kalır. Bunu avans öncesi yüklenici kontrolü hakkındaki materyalimizle karşılaştırmak uygundur. Bağlantı gününün ön filtresi due diligence'i ortadan kaldırmaz ve hukuki kontrolü tekrarlamaz.

Tedarikçi Hazırlık Kartı

Tek bir kayıt sistemi, şirket için onaylanmış tek bir durum sürümünü saklar. Sunumlar, sohbetler ve e-postalar işe yardımcı olabilir, ancak kayıt sisteminin yerini tutmaz. Karar merkezi hangi aşamanın geçildiğini, engelin nerede ortaya çıktığını ve bir sonraki adımdan kimin sorumlu olduğunu görmelidir.

«Bilgi edinildi» ve «süreç içinde» gibi ifadeler neredeyse işe yaramaz. Bir eylemi başlatmazlar. Bunun yerine şöyle yazmak daha iyidir: «belgenin kopyası gerekli», «muhasebeci rolü kontrol ediliyor», «kontrol PO ulaşmadı», «yanıtı süreç sahibi verecek». Böylece kart, sözlü aktarım olmadan başka bir vardiyaya devredilebilir.

Karttaki roller ve kararların etkinlik sorumluluk matrisi ilkesine göre koordine edilmesi daha iyidir. Birden fazla birimin yer aldığı bir günde, tek bir soyadının «her şeyden sorumlu» olması yeterli değildir. Her aşamanın bir uygulayıcısı, bir karar sahibi ve net bir eskalasyonu olmalıdır.

İş akışlarını, kayıt süreçlerini ve sahadaki ekip çalışmasını nasıl düzenlediğimizi «Aventura» portfolyosunda görebilirsiniz. Belirli bir proje için aşamaların ve kartların yapısı, müşterinin sistemlerine ve kurallarına göre değişir.

Güzergâhta hangi istasyonlar gerekli?

İstasyon, tedarikçinin bir işlem yaptığı ve doğrulanabilir bir sonuç elde ettiği yerde gereklidir. Bir noktada yalnızca slaytlar okunuyorsa, bu genel girişin bir parçasıdır. Çalışma istasyonu girdi verilerini alır, kontrol yapar, kartın durumunu değiştirir ve gerekirse vakayı eskalasyona iletir.

Oracle, tedarikçi profilini şirket, iletişim, adres, sınıflandırma, banka hesabı ve kategori verileri kümesi olarak tanımlar. SAP, şirketin mevcut durumuna bağlı olarak farklı bağlantı yöntemlerine izin verir. Bu nedenle herkes için tek bir güzergâh yalnızca kâğıt üzerinde pratiktir. Sahada dallanması gerekir.

PO istasyonunda ekip, çalışma yolunun anlaşıldığını teyit eder. IBM, tedarikçi talimatlarında siparişlerin alınması ve yerine getirilmesini, faturaları ve durumlarını ayrıca ele alır. Fatura için tüzel kişilik, PO numarası ve satırı, para birimi, şirket bilgileri ve ekler belirli müşterinin kurallarına göre doğrulanmalıdır. Bir şirketin kurumsal kontrol listesi evrensel norm olarak aktarılamaz.

Gösterim amacıyla sahte bir finansal belge oluşturmak gerekmez. Test ortamı, sandbox veya mutabık kalınan bir kontrol vakası kullanın. Böyle bir ortam yoksa istasyon, gerçek fatura göndermeden güzergâhı ve verileri teyit edebilir.

Kuyruksuz güzergâh

Akışı dalgalar ve dallanmalar halinde kuruyoruz. Tedarikçilerin tüm istasyonları aynı sırayla geçmesi gerekmiyor. Hazırlık kartı gerekli noktaları gösterir, koordinatör ise şirketi durumu ve karmaşıklığı dikkate alarak boş güzergâha yönlendirir.

Şu hazırlık sırasını kullanıyoruz:

1. Tedarikçileri kayıt durumu, çalışma biçimi ve karmaşıklığa göre segmentlere ayırıyoruz.
2. Her segment için zorunlu istasyonları işaretliyoruz.
3. Güzergâh süresi benzer olan dalgaları oluşturuyoruz.
4. Sessizlik, belge veya teknik teşhis gerektiren istasyonları ayırıyoruz.
5. Yeniden kontrol için yedek slotlar bırakıyoruz.
6. Girişte bir koordinatör ve genel karargâh yöneticisi atıyoruz.
7. Operasyon ekranında istasyon yükünü ve açık engelleri gösteriyoruz.

Etkinlik katılımcılarının kaydını, şirketin vendor portal kaydından ayrı tasarlamak daha iyidir. İlki varış, erişim ve dalgalara dağıtımdan sorumludur. İkincisi tedarikçinin çalışma profiliyle ilgilidir. Giriş ve yedek senaryonun ortak mekaniğini etkinlik katılımcılarının kaydı makalesinde ele aldık.

Bu format için kapsamlı iş etkinlikleri organizasyonu uygundur: program, mekân, kayıt, yönlendirme, moderasyon ve karargâh tek bir akış haritasına göre çalışmalıdır. Yükleniciler yalnızca tek tek unsurlardan sorumluysa, tepki süresi ve eskalasyon sırasının etkinlik için yüklenici SLA'sı ile sabitlenmesi gerekir.

İş formatları ve akış yönetimi üzerine pratik notları Aventura'nın Telegram kanalında yayımlıyoruz.

İstisna masası genel akışı yavaşlatmaz

Ayrı bir nokta, standart zaman diliminde kapatılamayan durumları kabul eder. Bağlamı korur, bir sahip atar ve tedarikçiye anlaşılır bir sonraki adımı iletir. Ana akış bu sırada çalışmaya devam eder.

Masaya belirli bir belirtiyi içeren sorun kartı iletilir:

Masa koordinatörü finans, hukuk veya bilgi güvenliği adına kurallar uydurmaz. Soruyu yönlendirir ve durumunu takip eder. Yanıt genel süreci değiştiriyorsa, sahip etkilenen tüm tedarikçiler için onaylanmış talimatı günceller.

İstisna, sonuç tedarikçi tarafından doğrulandıktan sonra kapatılabilir. İç ekibin «talep tamamlandı» işareti, kullanıcının oturum açtığını, siparişi gördüğünü veya düzeltilmiş belgeyi gönderdiğini henüz kanıtlamaz.

Her adımda kararı kim veriyor?

Roller sunumlara göre değil, kararlara göre ayrılır. Satın alma ilişkileri ve siparişi yönetir, BT hesapları ve rolleri yönetir, finans bilgileri ve faturayı kontrol eder, uyum ve hukuk ekipleri zorunlu kontrolleri yürütür. Tedarikçi de bir ekiple gelmelidir; aksi halde sürecin bir kısmı sahipsiz kalır.

Oracle, erişimin gerekli ayrıcalıklar etrafında kurulmasını ve görüntüleme ile değiştirme haklarının ayrılmasını önerir. NIST daha genel bir ilke ortaya koyar: bir kullanıcının veya cihazın kuruluşa ait olması tek başına güven oluşturmaz. Kimlik doğrulama ve yetkilendirme, kaynakla oturum açılmadan önce gerçekleşir. Bağlantı günü için bu, adlandırılmış hesaplar, işleve göre roller ve yönetici değişimi için ayrı bir prosedür anlamına gelir.

"Muhasebe için" ortak bir giriş hesabı hızlı bir çözüm gibi görünse de işlem denetimini ve erişimin iptalini zorlaştırır. Kartta hemen birincil yöneticiyi, yedek kişiyi ve kullanıcı değiştirme prosedürünü belirtmek daha iyidir.

Bağlantı gününün senaryosu

Senaryo, genel kurallar sürümünden kişisel güzergâhlara, ardından karargâh kararına doğru ilerler. Evrensel dakikalar belirlemiyoruz: süre, sistem sayısına, kontrollerin kapsamına ve tedarikçilerin karmaşıklığına bağlıdır. Ana zaman çizelgesinde sıra ve geçiş koşulları daha önemlidir.

1. Ekip karargâhı açar ve istasyonların, listelerin ve yedek kanalların hazır olup olmadığını kontrol eder.
2. Koordinatörler tedarikçileri kabul eder, katılımı onaylar ve güzergâhı verir.
3. Genel oturumda müşteri günün amacını, sınırları, durumları ve eskalasyon düzenini açıklar.
4. İlk dalga çalışma istasyonlarına gider, geri kalanlar kendi programlarına göre başlar.
5. Koordinatörler kartları günceller ve katılımcıları genel bankoya geri dönmeden yönlendirir.
6. Karmaşık durumlar, bağlamla birlikte istisna bankosuna aktarılır.
7. Karargâh yükü, tekrarlanan engelleri ve sahiplerin kararlarını birkaç kez karşılaştırır.
8. Tedarikçi nihai durumu ve sonraki adımların listesini alır.
9. Akış kapandıktan sonra ekip, kayıt defterini devam sahiplerine teslim eder.

Hedef kitlenin bir kısmı çevrimiçi katılıyorsa, onlar için salonun köşesindeki bir kamera değil, ayrı bir moderatör gerekir. Materyaller önceden gönderilir, salondaki tüm konuşmalar mikrofondan geçer, altyazılar ve yedek kanal başlangıçtan önce kontrol edilir. Karmaşık bir hibrit için konferans, forum ve seminer düzenleme üretim şeması kullanılabilir.

Şirket içinde iş programları hazırlayanlar için Event-Skill sistemik materyalleri faydalı olacaktır. Bu makalede yalnızca belirli bir günün operasyonel şemasını bırakıyoruz.

Go, conditional go veya no-go kararı nasıl verilir?

Kararı, önceden mutabık kalınan kriterlere göre süreç sahibi verir. Etkinlik organizatörü, satın alma, finans, compliance veya bilgi güvenliği yerine tedarikçiyi kabul edilmiş ilan edemez. Karargâh kanıtları toplar ve sonucu kartta kaydeder.

Conditional go, belirsizliğin süslü bir adı olarak kullanılamaz. Sınırları olmalıdır. Örneğin: profil ve erişim hazır, ancak banka bilgileri doğrulanana kadar fatura gönderimi yasak. Ya da tedarikçi materyalleri alabilir, ancak gerekli rol atanana kadar siparişleri göremez.

Karar; gerekçe, sahip ve bir sonraki kontrol tarihiyle birlikte verilir. Belirli bir satın almanın kuralları ayrı bir onay gerektiriyorsa, etkinlikteki kart bunun yerine geçmez, ona girdi olur.

Hibrit yapı ve kişisel veriler

Hibrit format iki eşit rotayı gerektirir: yüz yüze ve uzaktan. Çevrimiçi katılımcı materyalleri görebilmeli, salondan gelen soruları duyabilmeli, kendi sorularını sorabilmeli ve aynı kart statüsünü almalıdır. Ayrı bir moderatör sohbeti, altyazıları, erişimi ve uzaktan katılımcının istasyonlar arasındaki geçişini takip eder.

W3C, erişilebilirlik ihtiyaçlarının önceden sorulmasını, materyallerin etkinlikten önce katılımcılara ve destek uzmanlarına iletilmesini, mikrofonların kullanılmasını ve altyazıların kontrol edilmesini önerir. Otomatik işlev, gerçek platformda ve gerçek sesle test edilmeden hazır sayılamaz.

Gün kayıt formu yalnızca katılım, erişim ve destek için gereken verileri toplar. Kişisel veriler kanunu, işlemeyi belirli ve meşru bir amaçla ilişkilendirmeyi, gereksiz veri toplamamayı ve kişiyi tanımlamaya imkân veren verileri gerekli süreden uzun saklamamayı şart koşar. Yurt dışı platform ve sınır ötesi aktarım için ayrı ve güncel bir hukuki inceleme gerekir. Makalede genel geçer bir hukuki talimat vermiyoruz.

Etkinlik sonrası paket

Etkinlik sonrası materyaller, tek seferlik bir günü anlaşılır bir devama dönüştürür. Tedarikçi onaylanmış iletişim bilgilerini, statüsünü ve kendi eylemlerini alır. Müşteri hazırlık kaydını, istisna kuyruğunu ve bir sonraki döngüde yapılması gereken değişikliklerin listesini alır.

Pakete şunları dahil ediyoruz:

1. Her tedarikçi için nihai hazırlık kartı.
2. Gerekçesiyle go, conditional go veya no-go kararı.
3. Sahipler ve kontrol noktalarıyla açık istisnalar kaydı.
4. Sorular sonucunda değişen onaylanmış talimatlar.
5. Destek iletişim bilgileri ve talep oluşturma kuralları.
6. Form, rol ve süreç sahipleri için tekrarlayan engelleyicilerin listesi.
7. Tamamlanmamış maddeler için yeniden kontrol planı.
8. Ekip için kısa bir değerlendirme: bir sonraki dalgaya kadar nelerin değiştirilmesi gerektiği.

Bir maddeyi e-posta gönderildikten sonra değil, sonuç onaylandıktan sonra kapatılmış sayıyoruz. Kendi göstergelerimizi kartın aşamalarına göre hesaplayabiliriz: kaç şirket kaydı tamamladı, rolleri aldı, PO'yu onayladı ve fatura kontrolünü geçti, kaç istisna açıldı ve kapatıldı. Bu veriler şirket içinde kalır. Bunları sektör normu olarak sunmaya gerek yok.

Kaynaklar

• Oracle: Tedarikçi Kayıt Süreci
• SAP: Tedarikçi Etkinleştirme Yöntemleri
• IBM: Buy@IBM tedarikçi kaynakları
• IBM: Küresel Satın Alma faturalandırma talimatları
• Oracle: Tedarikçi Portalı Kullanıcılarını Yapılandırma
• NIST: SP 800-207 Sıfır Güven Mimarisi
• Rusya Çalışma Bakanlığı: 152-FZ sayılı Federal Kanun «Kişisel Veriler Hakkında»
• W3C WAI: Etkinlikleri Erişilebilir Hale Getirme
• W3C: Uzaktan Toplantıların Erişilebilirliği