საწარმოს ERP-ის შერჩევა ორ გადაწყვეტილებას მოითხოვს: ბიზნესისთვის შესაფერისი პლატფორმის არჩევას და ისეთი პარტნიორის არჩევას, რომელსაც შეუძლია მისი დანერგვა, მხარდაჭერა და გაუმჯობესება. პროექტზე დაფუძნებული ორგანიზაციებისთვის ეს ნიშნავს ინდუსტრიული ექსპერტიზის, ურთიერთდაკავშირებული პროექტის კონტროლის, დანერგვაზე პასუხისმგებლობის, მომხმარებელთა ადაპტაციის, ინტეგრაციისა და გრძელვადიანი მომსახურების უწყვეტობის შეფასებას. ფუნქციების ჩამონათვალი სასარგებლოა, თუმცა ის ვერ აჩვენებს, როგორ იმუშავებს სისტემა — და მის უკან მდგომი ადამიანები — როცა პროექტი იცვლება, ინტეგრაცია წყდება ან სამშენებლო მოედნის გუნდებს მხარდაჭერა სჭირდებათ.
ERP-ის დემონსტრაციამ შეიძლება აჩვენოს, რომ სისტემა ქმნის შესყიდვის შეკვეთებს, აღრიცხავს ხარჯებს და აგენერირებს დაფებს.
ის სულაც არ აჩვენებს, დააკავშირებს თუ არა შემოთავაზებული გადაწყვეტა მოედნიდან მოსულ მოთხოვნას სწორ სამუშაო მოცულობასთან, ბიუჯეტთან, დაგეგმილ აქტივობასთან, დამტკიცების უფლებამოსილებასთან და ფინანსურ შედეგთან.
არც იმას ადგენს, ვინ აიღებს პასუხისმგებლობას, როცა ეს კავშირი არ იმუშავებს.
სწორედ ამიტომ მიმაჩნია, რომ საწარმოს ERP-ის შეფასებამ ორ კითხვას უნდა უპასუხოს:
ესმის თუ არა ამ პლატფორმას, როგორ მუშაობს ჩვენი ბიზნესი?
შეუძლია თუ არა ამ მომწოდებელს დაგვეხმაროს მის დანერგვაში, ექსპლუატაციასა და მუდმივ გაუმჯობესებაში?
სასიცოცხლო ციკლის ეს პერსპექტივა ასახულია Microsoft-ის Dynamics 365-ის დანერგვის სახელმძღვანელოში, რომელიც სტრატეგიიდან და დანერგვიდან მომზადებამდე და მიმდინარე ექსპლუატაციამდე ვრცელდება. საწარმოს აპლიკაციის გზა გაშვებით არ მთავრდება.
ამიტომ კონტრაქტორებისა და პროექტზე დაფუძნებული სხვა საწარმოებისთვის შეფასება მოდულების შედარებას უნდა გასცდეს და გაცილებით მომთხოვნ ტესტად იქცეს: ოპერაციული შესაბამისობა, რომელიც რეალური ბიზნეს-პროცესებით დასტურდება და მკაფიო პასუხისმგებლობით არის გამყარებული.
1. ინდუსტრიული ექსპერტიზა ბიზნეს-ლოგიკით უნდა დადასტურდეს
ERP-ის მომწოდებელს სამშენებლო კომპანიაში გამოყენებულ ტერმინოლოგიაზე მეტი უნდა ესმოდეს.
უფრო მეტიც, მას უნდა ესმოდეს კავშირები კომპანიის კომერციულ ვალდებულებებს, საწარმოო პროცესებს, რესურსებსა და ფინანსურ შედეგებს შორის.
განვიხილოთ პროექტის სამი განსხვავებული სტრუქტურა.
- სამუშაოთა მოცულობების უწყისი — BoQ — განსაზღვრავს გაზომვად სამუშაო პოზიციებსა და მოცულობებს. შემდეგ, ამ პოზიციების მიხედვით რესურსების ანალიზი კონტრაქტორის შიდა ხარჯთაღრიცხვას ეყრდნობა. დამკვეთისთვის განკუთვნილი გასაყიდი ფასი და შიდა შესრულების ხარჯი ავტომატურად ერთი და იგივე არ არის.
- სამუშაოთა დეკომპოზიციის სტრუქტურა — WBS — პროექტის სამუშაო მოცულობას მართვად კომპონენტებად აწესრიგებს. ამავდროულად, მასთან დაკავშირებული განრიგი შემოაქვს აქტივობებს, დამოკიდებულებებს, ხანგრძლივობებსა და თარიღებს. თუმცა თავად WBS არ უნდა აგვერიოს სრულ განრიგში.
- საბოლოოდ, ხარჯების კოდები უზრუნველყოფს შიდა კლასიფიკაციას, რომლის მეშვეობითაც ხდება დანახარჯებისა და რესურსების ხარჯების დაგროვება, ანალიზი და შეჯერება.
პროექტების მართვის ინსტიტუტის (Project Management Institute) სამუშაოთა დეკომპოზიციის სტრუქტურების პრაქტიკული სტანდარტი WBS-ს აღწერს, როგორც პროექტის სრული სამუშაო მოცულობის ორგანიზების სტრუქტურას. ეს განსხვავება მნიშვნელოვანია, როცა აფასებთ, ნამდვილად ესმის თუ არა მომწოდებელს პროექტის კონტროლი, თუ უბრალოდ ნაცნობ აბრევიატურებს იყენებს.
DANAOS-ის ანალიტიკა ამ განზომილებებს შორის კავშირს განიხილავს სტატიაში პროექტის შესრულების საბაზისო ხაზების დადგენა, სადაც ერთმანეთს უკავშირდება BoQ, WBS, ხარჯების კლასიფიკაცია, რესურსების დაგეგმვა და სამუშაოს ავტორიზაცია.
პრაქტიკული ტესტი მარტივია:
შეუძლია თუ არა მომწოდებელს ახსნას, როგორ მოქმედებს მოცულობის ცვლილება რესურსებზე მოთხოვნაზე, შესყიდვებზე, შესრულებაზე, ხარჯსა და პროგნოზზე — და არა მხოლოდ ის, როგორ შეიტანოს ეს ცვლილება სისტემაში?
ეს არ ამართლებს მტკიცებას, რომ საწარმოს ზოგად პლატფორმებს პროექტის ფუნქციონალი აკლიათ. მაგალითად, Oracle აღწერს Primavera Unifier-ის ტრანზაქციებს, რომლებიც CBS და WBS კოდებს ერთდროულად შეიცავს. ეს ფუნქციონალი რეალურია. თუმცა თავისთავად ის არ ადასტურებს, უზრუნველყოფს თუ არა კონკრეტული დანერგვა BoQ-ზე დაფუძნებულ სრულ ოპერაციულ სამუშაო პროცესს, რომელიც კონტრაქტორს სჭირდება.
შეაფასეთ შემოთავაზებული კონფიგურაცია და პროცესი — და არა სტერეოტიპი მომწოდებლის შესახებ.
2. ჩაანაცვლეთ ფრაგმენტული დემონსტრაციები პროექტის სრული ციკლის ტესტით
ჩემი რეკომენდაციაა, საბოლოო სიაში მოხვედრილ მომწოდებლებს მისცეთ პროექტის ერთი წარმომადგენლობითი სცენარი და სთხოვოთ, აჩვენონ სრული თანმიმდევრობა.
მაგალითად, განვიხილოთ საილუსტრაციო საძირკვლის სამუშაოების პაკეტი. ეს შეფასების სცენარია და არა კლიენტის შემთხვევის ანალიზი.
პირველ რიგში, დაიწყეთ გაზომილი სამუშაო მოცულობითა და რესურსებზე დაფუძნებული ხარჯთაღრიცხვით. შემდეგ დაადგინეთ დამტკიცებული ბიუჯეტი, დაუკავშირეთ სამუშაო პროექტის განრიგს და განსაზღვრეთ შესაბამისი ხარჯების კოდები.
შემდეგ სთხოვეთ მომწოდებელს აჩვენოს, როგორ ემსახურება იგივე ინფორმაცია შემდეგს:
მოედნიდან მოთხოვნა, დამტკიცება, შესყიდვის შეკვეთა, მიწოდება, მასალის ხარჯვა, სამუშაო ძალისა და ტექნიკის ჩანაწერები, გაზომილი პროგრესი, ქვეკონტრაქტორის სერტიფიკატი და შედეგად მიღებული ხარჯების მდგომარეობა.
შემდეგ შეიტანეთ ცვლილება.
გაზარდეთ მოცულობა. დააყოვნეთ მიწოდება. ინსპექციის შემდეგ უარყავით სამუშაოს ნაწილი. აღრიცხეთ ტექნიკის დამატებითი მოცდენა. წარადგინეთ ცვლილება, რომელიც ჯერ არ არის დამტკიცებული.
ახლა შეამოწმეთ, ინარჩუნებს თუ არა სისტემა იმ განსხვავებებს, რომლებსაც მნიშვნელობა აქვს:
მაგალითად, მიღებული მასალა აუცილებლად არ ნიშნავს დახარჯულ მასალას.
ანალოგიურად, დახარჯული მასალა აუცილებლად არ ნიშნავს მიღებულ ფიზიკურ პროგრესს.
გაწეული ხარჯი აუცილებლად არ ნიშნავს დამკვეთის მიერ დამტკიცებულ ცვლილებას.
განახლებულმა პროგნოზმა ჩუმად არ უნდა გადაწეროს თავდაპირველი დამტკიცებული საბაზისო ხაზი.
ყოველ ეტაპზე იკითხეთ: ვინ აღრიცხავს მოვლენას, ვინ ამტკიცებს მას, რა იცვლება შემდგომ ეტაპებზე და რა მტკიცებულება რჩება?
Microsoft-ის ERP-ის ტესტირების სტრატეგიის სახელმძღვანელო ხაზს უსვამს ბიზნეს-მოთხოვნებს, ტესტირების დოკუმენტირებულ შედეგებს, საწარმოო გარემოსთვის მზადყოფნას და ბიზნეს-მომხმარებლების ხელმოწერით დადასტურებას. ეს მიღებისთვის უფრო მყარი საფუძველია, ვიდრე მხოლოდ დახვეწილი დემონსტრაცია.
მიზანი დემონსტრაციის გართულება არ არის.
მიზანია გაირკვეს, რჩება თუ არა შემოთავაზებული გადაწყვეტა თანმიმდევრული, როცა პროექტი რთულდება.
3. დანერგვის შესაძლებლობა იმის ნაწილია, რასაც ყიდულობთ
თუმცა ძლიერი პლატფორმა თავისით არ ერგება ორგანიზაციას.
ამიტომ დანერგვამ უნდა განსაზღვროს, როგორ იმუშავებენ ერთად კომპანიები, პროექტები, მომხმარებლები, რესურსები, მომწოდებლები, ბიუჯეტები, უფლებები და სამუშაო პროცესები.
Microsoft-ის დანერგვის სტრატეგიის სახელმძღვანელო პირდაპირ ეხება ბიზნეს-მიზნებს, წარმატების საზომებს, კლიენტისა და პარტნიორის პასუხისმგებლობებს, მეთოდოლოგიას, უკუკავშირსა და ადაპტაციას. სხვა სიტყვებით, ის დანერგვას განიხილავს, როგორც ბიზნესისა და ტექნოლოგიის კოორდინირებულ ინიციატივას.
საწარმოს მყიდველებისთვის ამას სამ მოთხოვნად ვთარგმნიდი.
- პირველი: გაიცანით შესრულების გუნდი — და არა მხოლოდ გაყიდვების გუნდი. იკითხეთ, ვინ უხელმძღვანელებს პროცესების დიზაინს, მონაცემთა მიგრაციას, ინტეგრაციას, ტრენინგსა და გაშვების შემდგომ მხარდაჭერას. ასევე შეისწავლეთ მათი შესაბამისი გამოცდილება და რეალური ხელმისაწვდომობა.
- მეორე: დაახარისხეთ ყველა მნიშვნელოვანი მოთხოვნა. ხელმისაწვდომია სტანდარტულ პროდუქტში, მიიღწევა კონფიგურაციით, დამოკიდებულია ინტეგრაციაზე, საჭიროებს ინდივიდუალურ შემუშავებას თუ ჯერ კიდევ სამომავლო გეგმაშია?
- მესამე: განსაზღვრეთ მიღების კრიტერიუმები შემუშავების დაწყებამდე. შეთანხმდით მოსალოდნელ ქცევაზე, სატესტო მონაცემებზე, პასუხისმგებელ მომხმარებლებსა და დადასტურებისთვის საჭირო მტკიცებულებაზე.
„ჩვენ ამის მხარდაჭერა შეგვიძლია“ საკმარისად ზუსტი არ არის.
მყიდველმა უნდა იცოდეს, როგორ, ვის მიერ, რა ღირებულებით, რა დამოკიდებულებებით და რა მიღების კრიტერიუმების მიხედვით.
DANAOS ინდუსტრიული ცოდნის, დანერგვისა და უწყვეტი მხარდაჭერის თავის კომბინაციას აღწერს ინტეგრირებული ციფრული მიწოდების მეშვეობით. მყიდველებმა ნებისმიერი ასეთი შეთავაზება — ჩვენი ჩათვლით — კონკრეტულ, შეთანხმებულ დანერგვის გეგმად უნდა აქციონ.
სანდო პარტნიორმა ეს განსხვავებები უფრო ნათელი უნდა გახადოს და არა ბუნდოვანი.
4. ინტეგრაციამ მნიშვნელობა უნდა შეინარჩუნოს და არა უბრალოდ მონაცემები გადაიტანოს
ინტერფეისმა შეიძლება წარმატებით გადაიტანოს ტრანზაქცია და ამავდროულად ბიზნეს-პროცესი სუსტად კონტროლირებადი დატოვოს.
მაგალითად, შესყიდვის შეკვეთა შეიძლება კორპორაციულ ERP-ს მიაღწიოს, თუმცა მიმღებმა სისტემამ შეიძლება ვერ შეინარჩუნოს პროექტზე მიკუთვნება, დამტკიცების სტატუსი ან კავშირი საბაზისო ბიუჯეტთან.
სწორედ ამიტომ ინტეგრაციის შეფასება მხოლოდ კავშირის არსებობით არ უნდა შემოიფარგლოს.
იკითხეთ, რომელი სისტემა ფლობს თითოეულ ძირითად ჩანაწერს. დაადგინეთ გაცვლის მიმართულება და სიხშირე. განსაზღვრეთ, როგორ სწორდება უარყოფილი ტრანზაქციები, როგორ ხდება დუბლიკატების პრევენცია და როგორ სრულდება შეჯერება.
რაც მთავარია, დაადგინეთ, ვინ არის პასუხისმგებელი, როცა პროცესი ორ სისტემას შორის საზღვარს კვეთს.
Microsoft-ის ინტეგრაციის სტრატეგიისა და მმართველობის საკონტროლო სია გვირჩევს ინტეგრაციების რეალისტურ პირობებში ტესტირებას და მათი წინა და შემდგომი ეფექტების შესწავლას.
DANAOS-ის ანალიტიკა პროექტსა და ფინანსებს შორის კავშირს განიხილავს სტატიაში ხარჯების კოდები ProjectVIEW ERP-ში: ინტეგრაცია Oracle Fusion-თან და SAP-თან. გამოქვეყნებული მიდგომა ხარჯების კოდების შესაბამისობას იყენებს პროექტის ოპერაციების საწარმოს ანგარიშგებასთან დასაკავშირებლად.
ეს მნიშვნელოვან არქიტექტურულ არჩევანს ქმნის.
კონტრაქტორს შეუძლია მთელ ოპერაციებში ინტეგრირებული სამშენებლო ERP დანერგოს, ან შეინარჩუნოს კორპორაციული პლატფორმა და მას მშენებლობისთვის სპეციალიზებული ოპერაციული სისტემა დაუკავშიროს. DANAOS-ის მესამე მხარის ERP-თან ინტეგრაციის მიმოხილვა აღწერს ProjectVIEW ERP-ის როგორც დამატებით, ისე ჩამნაცვლებელ როლს. შესაბამისი მოცულობა მაინც უნდა დაპროექტდეს და დადასტურდეს კონკრეტული ორგანიზაციისთვის.
სანდო პარტნიორმა უნდა გირჩიოთ ბიზნესისთვის შესაფერისი არქიტექტურა — და არა ავტომატურად ყველაზე მასშტაბური ჩანაცვლების პროგრამა.
5. მომხმარებელთა ადაპტაცია პროცესის შედეგია და არა შესვლების რაოდენობა
ERP-ში შესვლა არ ადასტურებს, რომ ადამიანი მას ეფექტიანად იყენებს.
მოედნის ინჟინრისთვის ადაპტაცია შეიძლება ნიშნავდეს პროგრესის აღრიცხვას სწორი სამუშაო პაკეტის მიხედვით, მასალის მოთხოვნების წარდგენას დამტკიცებული პროცესით და განხილვისთვის საჭირო მტკიცებულების დართვას.
შესყიდვებისთვის ეს შეიძლება ნიშნავდეს მოთხოვნების დამუშავებას ისე, რომ ინფორმაცია სხვა ცხრილში თავიდან არ შეიქმნას.
ფინანსებისთვის ეს შეიძლება ნიშნავდეს ხარჯის მიკვლევას იმ ოპერაციულ ტრანზაქციამდე, რომელმაც ის წარმოშვა.
ამიტომ ადაპტაციას ბიზნეს-პროცესების ხარისხითა და დასრულებით გავზომავდი და არა უბრალოდ აქტიური ანგარიშების რაოდენობით.
სასარგებლო მაჩვენებლებია: სისტემაში დასრულებული სავალდებულო ტრანზაქციების წილი, დაყოვნება მოედანზე მომხდარ მოვლენასა და მის აღრიცხვას შორის, უარყოფილი წარდგენების სიხშირე და ჯერ კიდევ საჭირო ხელით შეჯერების მოცულობა.
Microsoft-ის ცვლილებების მართვის საკონტროლო სია მოიცავს ყოველდღიური სამუშაო სცენარების ტესტირებას, ტრენინგზე უკუკავშირს, ცოდნის გადაცემას და ადაპტაციისა და გამოყენების გაზომვას.
DANAOS-ის სტატია მოსწავლე ორგანიზაცია: როგორ აჩქარებს ProjectVIEW ERP ციფრულ ტრანსფორმაციას ავითარებს კავშირს სტანდარტიზებულ პროცესებს, ცოდნის შენარჩუნებასა და უწყვეტ ოპერაციულ სწავლებას შორის.
მისი გამოქვეყნებული ProjectVIEW ERP-ის ჩართვისა და ტრენინგის მიდგომა მოიცავს სტრუქტურირებულ სესიებს, კლიენტის მხარეს ჩემპიონებს, ჩაწერილ მასალებსა და შემდგომ მხარდაჭერას. ეს კონკრეტული ელემენტებია, რომელთა შემოწმებაც მყიდველებს ადაპტაციის გეგმის შეფასებისას შეუძლიათ.
ამრიგად, მიზანი არ უნდა იყოს თანამშრომლების მომწოდებელზე დამოკიდებულება ყოველი რუტინული ქმედებისთვის.
პირიქით, მიზანი უნდა იყოს ორგანიზაციის მზარდი უნარი, სისტემა კარგად მართოს.
6. ძლიერი პარტნიორი ვერ ჩაანაცვლებს ჩართულ ხელმძღვანელობას
მომწოდებელს აქვს პასუხისმგებლობები. ასევე აქვს კლიენტსაც.
მომწოდებელმა უნდა მიაწოდოს შეთანხმებული ფუნქციონალი, განმარტოს შეზღუდვები, მხარი დაუჭიროს მომხმარებლებს და მართოს თავისი მიწოდების ვალდებულებები.
ამავდროულად, კლიენტმა უნდა დანიშნოს პროცესების მფლობელები, მიაწოდოს და გადაამოწმოს მონაცემები, გამოყოს მომხმარებლების დრო, გადაჭრას შიდა უთანხმოებები და განსაზღვროს დამტკიცების უფლებამოსილება.
ვერცერთი პროგრამული უზრუნველყოფის მომწოდებელი ვერ გადაწყვეტს კონტრაქტორის ნაცვლად, რომელ დეპარტამენტს უნდა ეკუთვნოდეს სადავო ბიზნეს-პროცესი ან რომელ აღმასრულებელს აქვს განსაკუთრებული ვალდებულების დამტკიცების უფლება.
DANAOS-ის ანალიტიკა ამ საკითხს განიხილავს სტატიაში იზოლაციის დაძლევა: რატომ არის ხელმძღვანელობის ჩართულობა გადამწყვეტი ERP-ის წარმატებისთვის მშენებლობაში, სადაც ხაზგასმულია სპონსორობა, რესურსების გამოყოფა და ხელმძღვანელობის უწყვეტი მონაწილეობა.
Microsoft ასევე რეკომენდაციას უწევს ორგანიზაციული რისკისა და სირთულის პროპორციულ ცვლილებების მართვას, ნაცვლად იმისა, რომ ის დანერგვის ბოლოს დამატებულ ზოგად აქტივობად განიხილებოდეს.
ჩემი აზრით, სანდო ERP პარტნიორი მზად უნდა იყოს, კლიენტს კონსტრუქციულად შეეპაექროს.
ეს შეიძლება ნიშნავდეს ხარჯების არათანმიმდევრული კლასიფიკაციის, ბუნდოვანი პასუხისმგებლობების ან ისეთი შემოთავაზებული ინდივიდუალური შემუშავების გამოვლენას, რომელიც უბრალოდ არაეფექტიან პროცესს იმეორებს.
მოკლედ, ყველა მოთხოვნასთან დათანხმება არ ნიშნავს კლიენტის ინტერესებით მოქმედებას.
7. განსაზღვრეთ ბიზნეს-შედეგები, სანამ დანერგილ მოდულებს დათვლით
დანერგვის ეტაპი ხელმძღვანელობას ეუბნება, რა არის დაინსტალირებული.
თუმცა თავისთავად ის არ აჩვენებს, რა გაუმჯობესდა.
ამიტომ გაშვებამდე მცირე რაოდენობის ოპერაციულ საზომებს დავადგენდი, დასახელებული მფლობელითა და გაანგარიშების შეთანხმებული მეთოდით.
კომერციული და ხარჯების ხილვადობა: შეუძლია თუ არა გუნდს ორმაგი აღრიცხვის გარეშე განსაზღვროს მიმდინარე ბიუჯეტი, ფაქტობრივი ხარჯები, დაუფარავი ვალდებულებები და დარჩენილი პროგნოზი? რამდენად სწრაფად შეუძლია ცვლილების ეფექტის შეფასება?
შესრულება და პროდუქტიულობა: შესაძლებელია თუ არა აღრიცხული სამუშაო საათების, ტექნიკის გამოყენებისა და მასალის ხარჯვის დაკავშირება შესაბამის ფიზიკურ შედეგთან? ხდება თუ არა შედარება თანმიმდევრული სამუშაო მოცულობის, ერთეულებისა და გაზომვის წესების მიხედვით?
პროცესების საიმედოობა: რამდენი დროა საჭირო მოთხოვნის დასამტკიცებლად, მონაცემთა გამონაკლისის გადასაჭრელად ან პროექტისა და კორპორაციული ჩანაწერების შესაჯერებლად? რომელი შემოვლითი გზები რჩება?
ეს შეფასების შემოთავაზებული საზომებია და არა გარანტირებული გაუმჯობესების პროცენტის შესახებ განცხადებები.
გაერთიანებული სამეფოს მთავრობის ციფრული ტექნოლოგიების, მონაცემებისა და ტექნოლოგიების სახელმძღვანელო (Digital, Data and Technology Playbook) სასარგებლო შესყიდვების პრინციპს გვთავაზობს: ფოკუსირება მომხმარებლის საჭიროებებზე, შედეგებსა და სასიცოცხლო ციკლის სრულ ღირებულებაზე, ნაცვლად იმისა, რომ გადაწყვეტის საწყისი შეძენა მთელ გადაწყვეტილებად განიხილებოდეს. სახელმძღვანელო სახელმწიფო შესყიდვებისთვისაა დაწერილი; შეფასების ზოგადი პრინციპი კი სასარგებლოა საწარმოს მყიდველებისთვისაც.
ERP-ის ბიზნეს-კეისმა მოსალოდნელი გაუმჯობესება გადამოწმებადი უნდა გახადოს.
8. გრძელვადიანი მხარდაჭერა ოპერაციულად კონკრეტული უნდა იყოს
„მხარდაჭერა შედის“ — ეს ძალიან ბევრ კითხვას პასუხგაუცემელს ტოვებს.
რომელ მომხმარებლებს ეწევა მხარდაჭერა? რომელ საათებში და რომელ ენებზე? ვინ აგვარებს შეფერხებულ ინტეგრაციას? როგორ ხდება გადაუდებელი ინციდენტების ესკალაცია? ვინ ტესტავს განახლებას, სანამ ის საწარმოო გარემოში მოხვდება?
Microsoft-ის მხარდაჭერის სტრატეგიის სახელმძღვანელო ერთმანეთისგან მიჯნავს მხარდაჭერის მოცულობას, გუნდსა და ოპერაციებს. ის ასევე ეხება მომსახურების საათებს, გეოგრაფიას, ენას, პრიორიტეტებსა და ესკალაციას.
კონტრაქტორისთვის მომსახურების ამ მოდელს პრაქტიკული სიტუაციით შევამოწმებდი:
მოედანი ვერ აგზავნის გადაუდებელ მოთხოვნას, დამტკიცება დაბლოკილია, პასუხისმგებელი გუნდი კი სხვა დროის სარტყელშია. რა ხდება შემდეგ?
პასუხმა უნდა განსაზღვროს შეტყობინების არხი, ინციდენტის მფლობელი, ესკალაციის გზა, ბიზნესის დროებითი გამოსავალი და კომუნიკაციის პროცესი.
მომსახურების დონის შეთანხმებამ ასევე უნდა გამიჯნოს რეაგირება, აღდგენა და საბოლოო გადაჭრა. ამასთან, ბილეთის მიღების დადასტურება არ ნიშნავს დაზიანებული პროცესის აღდგენას.
DANAOS-ის გამოქვეყნებული ProjectVIEW ERP-ის მხარდაჭერის მოდელი აღწერს ბილეთების სისტემას, პრობლემების მართვასა და ესკალაციას მომსახურების დონის მოთხოვნების მიხედვით. ზუსტი ვალდებულებები კლიენტთან შეთანხმებული მომსახურების მოცულობის მიხედვით უნდა გადამოწმდეს.
ურთიერთობის ხარისხი მაშინ ჩანს, როცა რაღაც არასწორად მიდის — და არა მხოლოდ მაშინ, როცა ყველაფერი ჩვეულებრივ მუშაობს.
9. ნდობა მოიცავს გამჭვირვალობას უწყვეტობის, ღირებულებისა და გასვლის შესახებ
გრძელვადიანი ურთიერთობა არ უნდა ეფუძნებოდეს იმას, რომ წასვლა პრაქტიკულად შეუძლებელი იყოს.
ჩემი რეკომენდაციაა, უწყვეტობისა და გასვლის პირობები ხელმოწერამდე შეაფასოთ, დანერგვასა და მხარდაჭერასთან ერთად.
იკითხეთ, როგორ შეუძლია ორგანიზაციას თავისი მონაცემების, დოკუმენტების, ტრანზაქციების ისტორიისა და შესაბამისი კონფიგურაციის ინფორმაციის დაბრუნება. ასევე დაადგინეთ ფორმატები, პასუხისმგებლობები და დაკავშირებული ხარჯები.
შეისწავლეთ მომწოდებლის მიწოდების შესაძლებლობები, პროდუქტის განვითარების მიმართულება და ცალკეულ პირებზე დამოკიდებულება. შეამოწმეთ შემოთავაზებული დანერგვის შესაბამისი უსაფრთხოებისა და აღდგენის მტკიცებულებები.
შემდეგ შეაფასეთ სრული კომერციული სურათი: დანერგვა, გამოწერები, ინტეგრაცია, ინდივიდუალური შემუშავება, ტრენინგი, განახლებები, შიდა პერსონალის ძალისხმევა და საბოლოო გადასვლა.
გაერთიანებული სამეფოს ციფრული ტექნოლოგიების, მონაცემებისა და ტექნოლოგიების სახელმძღვანელოს მომწოდებლის სათანადო შემოწმებისა და გასვლის დაგეგმვის თავები პირდაპირ ეხება მომწოდებლის ფინანსურ მდგომარეობას, უწყვეტობას და ცოდნისა და მონაცემების გადაცემის ადრეულ დაგეგმვას.
ზოგადად, სანდო პარტნიორს ამ საკითხების განხილვა არ უნდა უჭირდეს.
ნდობა უფრო მყარია, როცა პასუხისმგებლობები ნათელია და კლიენტი საკუთარ ბიზნეს-ინფორმაციაზე კონტროლს ინარჩუნებს.
10. AI დისციპლინირებულ ERP-ის შერჩევას უფრო მნიშვნელოვანს ხდის — და არა ნაკლებად
AI-ის დემონსტრაციამ არ უნდა გააუქმოს ბიზნეს-ლოგიკის, წვდომის უფლებებისა და პასუხისმგებლობის შეფასების საჭიროება.
ყოველი შემოთავაზებული AI შესაძლებლობისთვის იკითხეთ, რომელ მონაცემებზე აქვს მას წვდომა, როგორ მოწმდება მისი შედეგი, რა ქმედებების შესრულება შეუძლია და სად რჩება აუცილებელი ადამიანის დამტკიცება.
ასევე მკაფიოდ გამიჯნეთ დღეს ხელმისაწვდომი ფუნქციონალი, კონტროლირებადი პილოტი და სამომავლო გეგმა.
NIST-ის AI რისკების მართვის ჩარჩო (AI Risk Management Framework) აღიარებულ საფუძველს იძლევა სანდოობისა და რისკების მართვის ინტეგრირებისთვის AI სისტემების დიზაინში, შემუშავებაში, გამოყენებასა და შეფასებაში.
DANAOS-ის ProjectVIEW AI ეკოსისტემა წარმოადგენს არსებულ საინფორმაციო დახმარებისა და ცოდნის რესურსებს, AI აგენტებისა და ინტელექტუალური ოპერაციების უფრო ფართო მიმართულებასთან ერთად. მყიდველებმა თითოეული შემოთავაზებული გამოყენების შემთხვევის ხელმისაწვდომობა და დანერგვის მოთხოვნები უნდა გადაამოწმონ, ნაცვლად იმისა, რომ საერთო ხედვა დასრულებული ფუნქციების ჩამონათვლად აღიქვან.
DANAOS Projects-ის პოზიციით, AI უნდა მოქმედებდეს კონტროლირებადი პროექტის მონაცემებისა და ბიზნეს-პროცესების გარშემო.
შესაბამისი კითხვა უბრალოდ ეს არ არის: „მოიცავს თუ არა ეს ERP AI-ს?“
კითხვაა: „შეგვიძლია თუ არა გავიგოთ, ვმართოთ და გადავამოწმოთ, რას აკეთებს მისი AI?“
როგორ ერგება ProjectVIEW ERP ამ შეფასებას
ProjectVIEW ERP-ის გამოქვეყნებული არქიტექტურა აგებულია BoQ-ის, WBS-ისა და ხარჯების კოდების დაკავშირებაზე კომერციულ, ოპერაციულ და ფინანსურ პროცესებში.
DANAOS-ის ანალიტიკა ამ მიდგომას განმარტავს სტატიაში როგორ აღწევს ProjectVIEW ERP ხარჯების რეალურ კონტროლს: ინტეგრირებული მოდულური არქიტექტურის სიღრმისეული ანალიზი. სტატია აღწერს, როგორ უწყობს ხელს ხარჯთაღრიცხვა, შესყიდვები, მოედნის ტრანზაქციები, ქვეკონტრაქტორებთან მუშაობა და ფინანსური ინფორმაცია პროექტის კონტროლის საერთო სტრუქტურას.
ორგანიზაციებისთვის, რომლებიც აფასებენ
, შესაბამისი შეთავაზება, შესაბამისად, არის პროექტზე მორგებული ფუნქციონალისა და მისი ამოქმედებისთვის საჭირო მომსახურებების ერთობლიობა.
თუმცა შეფასების იგივე დისციპლინა უნდა გავრცელდეს ProjectVIEW-ზე, როგორც ნებისმიერ სხვა შერჩეულ პლატფორმაზე.
გვთხოვეთ, თქვენი პროცესების დემონსტრირება. შეისწავლეთ შემოთავაზებული ინტეგრაციები. გაიცანით დანერგვის გუნდი. შეათანხმეთ მიღების კრიტერიუმები. გადახედეთ ადაპტაციის გეგმასა და მხარდაჭერის პასუხისმგებლობებს.
პარტნიორობის შეთავაზებას აზრი მხოლოდ მაშინ აქვს, როცა მისი შემოწმება შეიძლება.
დასკვნითი მოსაზრება
საწარმოს ERP-ის მყიდველები პროგრამულ უზრუნველყოფაზე მეტს ირჩევენ.
ისინი ირჩევენ ბიზნეს-ლოგიკას, მიწოდების შესაძლებლობას, ოპერაციულ პასუხისმგებლობებს და ურთიერთობას, რომელიც გაშვების შემდეგაც უნდა გაგრძელდეს.
სწორი პლატფორმა ვერ აანაზღაურებს არაეფექტიან დანერგვას.
ანალოგიურად, სწორი პარტნიორი ვერ აანაზღაურებს პროდუქტის ფუნდამენტურ შეუსაბამობას.
და ვერცერთი მათგანი ვერ აანაზღაურებს ორგანიზაციას, რომელიც არ არის მზად, საკუთარ პროცესებსა და გადაწყვეტილებებზე პასუხისმგებლობა აიღოს.
ამიტომ ERP-ის ყველაზე ძლიერი შერჩევა ერთ მომთხოვნ კითხვას პასუხობს:
რომელ პლატფორმასა და პარტნიორს შეუძლია აჩვენოს, როგორ იმუშავებს ჩვენი ბიზნესი უკეთ — და დარჩეს პასუხისმგებელი ამის მიღწევაში საკუთარ წილზე?
ეს უფრო სასარგებლო კითხვაა, ვიდრე ის, თუ რომელ სისტემას აქვს ფუნქციების ყველაზე გრძელი ჩამონათვალი.
