ერთი კომპანია, რამდენიმე დილერი: როლები, უფლებები და დამტკიცების წესი

მოკლე პასუხი: რამდენიმე დილერის შემთხვევაში უნდა გაიმიჯნოს ინფორმაციის ნახვა, ლოტის შერჩევა, ბიდის მომზადება, ლიმიტის შეცვლა, დამტკიცება და ისტორიის კონტროლი. აუქციონის ანგარიშზე დაშვება ამ შიდა როლებს ავტომატურად არ ქმნის. aiVIN-ის დღევანდელი დემო მხოლოდ სტატიკურ როლურ სცენარს აჩვენებს და ცოცხალ ანგარიშებს არ მართავს.

რატომ არ კმარა მომხმარებლის დამატება

ერთ კომპანიაში დილერები შეიძლება სხვადასხვა მიმართულებაზე, ქალაქზე ან მომხმარებელზე მუშაობდნენ. თუ ყველას ერთი და იგივე უფლება აქვს, კომპანიის წესები პრაქტიკაში ერთმანეთს ეჯახება. ერთ თანამშრომელს შეიძლება მხოლოდ კატალოგის დათვალიერება სჭირდებოდეს, მეორეს ბიდის მომზადება, მესამეს კი საბოლოო დამტკიცება. ამ განსხვავების გარეშე პასუხისმგებლობა ბუნდოვანი ხდება.

Copart-ის ოფიციალური გვერდები აღწერს ანგარიშისა და ბიდის მოქმედებებს. IAA-ის რეგისტრაციის გვერდი აჩვენებს, რომ მონაწილეობა ანგარიშის პროცესთან არის დაკავშირებული. Manheim-ის Simulcast Buyers Guide განმარტავს ონლაინ მყიდველის სამუშაოს. არც ერთი გარე პლატფორმის ანგარიში არ ადგენს, ვის რა უფლება აქვს თქვენს კომპანიაში. ეს უნდა ჩამოყალიბდეს შიდა პოლიტიკით.

როლების საბაზისო მატრიცა

მატრიცა დაიწყეთ იმ მოქმედებებით, რომლებიც თქვენთვის ფინანსურად ან ოპერაციულად განსხვავებულია. თითოეული მოქმედების გვერდით დაწერეთ ნახვა, მომზადება, დამტკიცება, შეცვლა ან გაუქმება. შემდეგ მიუთითეთ, არის ეს უფლება მუდმივი, ლოტზე მიბმული თუ დროებითი.

ცხრილი მხოლოდ მაგალითია. თქვენი კომპანია თავად წყვეტს, რომელი როლი არსებობს. მთავარი პრინციპია, რომ უფლება მოქმედებას ეკუთვნოდეს და არა მხოლოდ თანამშრომლის სახელს.

რა უნდა გაიმიჯნოს აუცილებლად

პირველი გამიჯვნაა დათვალიერება და მოქმედება. ლოტის ნახვა არ ნიშნავს, რომ თანამშრომელმა ბიდი მოამზადა. მეორეა ბიდის მომზადება და გაგზავნა. მესამეა კომპანიის თანხმობა და აუქციონის ანგარიშზე ტექნიკური დაშვება. მეოთხეა გარე სტატუსი და შიდა სტატუსი. ლოტი შეიძლება წყაროზე აქტიური ჩანდეს, მაგრამ კომპანიას მაინც ჰქონდეს გადაწყვეტილება „არ გავაგრძელოთ“.

როლების ჩანაწერში არ გამოიყენოთ მხოლოდ „წვდომა აქვს“. ჩაწერეთ, რისი გაკეთება შეუძლია, რომელ ლოტზე, რა ლიმიტამდე და ვისთან ესკალაციით. ასეთი ენა შემდეგ ამარტივებს როგორც პროგრამულ დიზაინს, ისე გუნდის სწავლებას.

დამტკიცების წესი რამდენიმე დილერისთვის

როცა დილერი ლიმიტის ფარგლებში მოქმედებს, სისტემა შეიძლება მოითხოვდეს მხოლოდ მოთხოვნის ჩანაწერს. ზღვარს ზემოთ კი უნდა გამოჩნდეს დამმტკიცებელი როლი და მიზეზი. თუ ერთ ლოტზე რამდენიმე დილერი მუშაობს, წინასწარ დაწერეთ რომელი მოთხოვნა ითვლება აქტიურად და ვის ეკუთვნის შემდეგი ნაბიჯი. საჭიროების შემთხვევაში ერთი ადამიანი უნდა იყოს კოორდინატორი, მაგრამ ეს არ ნიშნავს, რომ ის ყველა კომერციულ გადაწყვეტილებას იღებს.

დამტკიცებას უნდა ჰქონდეს ვადა და ფარგლები. ერთ კონკრეტულ ლოტზე მიცემული თანხმობა სხვა ლოტზე არ გადაიტანოთ. ასევე შეინახეთ უარყოფის მიზეზი, რათა დილერმა არ გაიმეოროს იგივე მოთხოვნა მხოლოდ სხვა სიტყვებით.

ცენტრალიზებული და დეცენტრალიზებული მოდელები

ცენტრალიზებულ მოდელში მენეჯერი ან მცირე ჯგუფი ამტკიცებს ყველა გამონაკლისს. კონტროლი მკაფიოა, მაგრამ პასუხი შეიძლება შენელდეს. დეცენტრალიზებულ მოდელში დილერებს მეტი დამოუკიდებლობა აქვთ წინასწარ განსაზღვრულ ჩარჩოში. ის სწრაფია, თუმცა ლიმიტები და აუდიტის ისტორია უფრო ყურადღებით უნდა კონტროლდებოდეს. შერეული მოდელი ხშირად ყოფს ყოველდღიურ მოქმედებას და გამონაკლისს.

არჩევანი არ უნდა გაკეთდეს მხოლოდ პროგრამული ფუნქციის მიხედვით. ჯერ განსაზღვრეთ ვის ეკისრება პასუხისმგებლობა, შემდეგ გადააქციეთ ეს წესი სისტემურ მოქმედებად. aiVIN-ის დემო ამ განსხვავების სტატიკურ ილუსტრაციას იძლევა.

ხშირი შეცდომები

ხშირია ერთი საერთო მომხმარებლის გამოყენება მთელი გუნდისთვის, რადგან ასე სწრაფად იწყებენ მუშაობას. ამ დროს ისტორია ვერ აჩვენებს რეალურ მოქმედ პირს. მეორე შეცდომაა ადმინისტრატორისთვის ყველა კომერციული უფლების მინიჭება. მესამეა როლის შეცვლა ძველი მოთხოვნების ისტორიის დაკარგვით. მეოთხეა დროებითი წვდომის მუდმივად დატოვება. მეხუთეა წყაროს ანგარიშის უფლების აღქმა როგორც თქვენი კომპანიის დამტკიცებად.

როგორ დაიწყოთ მცირე ნაბიჯით

აირჩიეთ ერთი აუქციონის პროცესი და ჩამოწერეთ ყველა მოქმედება ლოტის ნახვიდან საბოლოო შიდა გადაწყვეტილებამდე. თითოეულზე მიუთითეთ ერთადერთი პასუხისმგებელი როლი, საჭირო დამხმარე როლი და შეჩერების პირობა. შემდეგ სცადეთ სტატიკური სცენარი ორი დილერით: ერთი ამზადებს მოთხოვნას, მეორე ითხოვს გადაჭარბებას, მენეჯერი კი ამტკიცებს ან აბრუნებს. თუ გუნდი სხვადასხვა სიტყვებით აღწერს ერთსა და იმავე ნაბიჯს, ჯერ პოლიტიკა დააზუსტეთ.

aiVIN-ის დღევანდელი საზღვარი

aiVIN-ის მიმდინარე დემო არ ქმნის მომხმარებლებს, არ ანიჭებს აუქციონის ანგარიშის უფლებებს და არ ასრულებს ბიდს. როლების მატრიცა არის პროცესის დიზაინის მაგალითი და არა თქვენი კომპანიის უკვე მოქმედი პოლიტიკა. რეალური გამოყენებისთვის საჭიროა ანგარიშების, შიდა ავტორიზაციის, audit trail-ისა და პასუხისმგებელი პირების ცალკე დადასტურება.

მატრიცის შემოწმება გუნდთან

მატრიცა მხოლოდ მაშინ მუშაობს, თუ მას თითოეული როლის შემსრულებელი ერთნაირად კითხულობს. დილერს ჰკითხეთ, შეუძლია თუ არა მხოლოდ მოთხოვნის მომზადება და სად ჩერდება მისი მოქმედება. მენეჯერს ჰკითხეთ, რომელი მტკიცებულების ნახვა სჭირდება გამონაკლისის დასამტკიცებლად. ადმინისტრატორს ჰკითხეთ, როგორ ხედავს ცვლილებებს და როგორ აუქმებს დროებით წვდომას. თუ რომელიმე პასუხი სიტყვაზე „წვდომა“ ჩერდება, მოქმედება უფრო ზუსტად ჩამოწერეთ. კარგი შემოწმებაა ერთი სტატიკური ლოტის გავლა ყველა როლით და შემდეგ იმის აღწერა, ვინ რას ხედავდა, ვინ შეცვალა ჩანაწერი და ვინ დააფიქსირა საბოლოო გადაწყვეტილება.

იხილეთ სტატიკური როლების სცენარი და დაგვიკავშირდით aiVIN-ის ფორმით. ასევე გაეცანით მოქმედებების ისტორიას და გამონაკლისის დამტკიცებას.

ოფიციალური წყაროები

• Copart, ბიდისა და შეძენის წესები, Copart-ის ანგარიშისა და ყიდვის გზა.
• Copart, Place Bids, პლატფორმაზე ბიდის მოქმედების წყარო.
• IAA, რეგისტრაციის წესები, IAA-ის ანგარიშის რეგისტრაციის გვერდი.
• Manheim, Simulcast Buyers Guide, Manheim-ის მყიდველის სახელმძღვანელო.