საწარმოს რესურსების დაგეგმვის (ERP) სისტემების დანერგვის პროექტები შედარებით რთულია ტექნოლოგიური და ორგანიზაციული რისკების, ასევე ავტომატიზაციის საჭირო მრავალი ურთიერთდაკავშირებული პროცესის თვალსაზრისით. ხშირად, ERP პროექტის იმპლემენტაციის პროცესში დადგენილი პროცესები იცვლება. ასეთი პროექტის იმპლემენტაციისადმი მიდგომა და მისი შემუშავება, მეთოდოლოგიაში გათვალისწინებული პროცედურებისა და პროცესების ფრთხილად დაცვა პროექტის წარმატების კრიტიკული ფაქტორებია.
სქემურად, SMART business მიერ გამოყენებული Microsoft Dynamics 365-ის ფინანსური და ოპერაციული აპლიკაციების ERP სისტემის დანერგვის პროექტი შეიძლება შემდეგნაირად იყოს წარმოდგენილი:
ERP იმპლემენტაციის ნაბიჯები (ეტაპები)
- პროექტის დაწყება
- პროცესის მოდელირება და ანალიზი
- სისტემის კონფიგურაცია
- სისტემის ტესტირება
- სისტემის გადატანა
- გაშვება/მხარდაჭერა
მოდით, უფრო დეტალურად განვიხილოთ. Microsoft D365FO Apps ERP სისტემის დანერგვის პროექტის ფარგლებში წარმოდგენილია ERP-ის დანერგვის შემდეგი ეტაპები (ეტაპები/ფაზები). პროექტის სპეციფიკიდან გამომდინარე, ეს ფაზები შეიძლება იყოს მკაცრად თანმიმდევრული ან ნაწილობრივ პარალელურად შესრულებული:
I. პროექტის დაწყება
ამ ეტაპზე სამუშაო ხორციელდება პროექტის დაწყებისა და შემდგომი ნაბიჯების განსახორციელებლად საჭირო ინფორმაციისა და გეგმების მოპოვების მიზნით. ამ ეტაპის ძირითადი შედეგებია:
- პროექტის საბაზისო გეგმა
ეს გეგმა ეფუძნება პროექტის შეფასების მონაცემებს (იხილეთ სტატია „ERP სისტემის დანერგვის შეფასების პროცესი“), თუმცა აქ ის ადაპტირებულია რეალურ რესურსებზე, მათ კალენდრებზე და კონტრაქტულ პირობებზე. დადასტურებული პროექტის გეგმა წარმოადგენს საბაზისო მონახაზს, რომლის მიხედვითაც მომავალში განხორციელდება ფაქტობრივი მაჩვენებლების შედარება დაგეგმილთან (სამუშაოს მოცულობა, ხანგრძლივობა, ღირებულება, რესურსები, ძალისხმევა, განრიგის მონაცემები). - პროექტის ორგანიზაციული სტრუქტურა და როლები
(ამ მონაცემების საწყისი განსაზღვრა შესაძლებელია განხორციელდეს წინასაპროექტო აქტივობების ფარგლებში (იხილეთ სტატია „ERP სისტემის დანერგვის შეფასების პროცესი“), თუმცა საბოლოო დადასტურება ამ ეტაპზე ხორციელდება.
ქვემოთ მოცემულია დიაგრამა „პროექტის დაწყების“ ეტაპისთვის:
II. პროცესის მოდელირება და ანალიზი
ეს ეტაპი მოიცავს:
- მიმდინარე პროცესების, არქიტექტურისა და მონაცემთა ნაკადების (As Is Model) ანალიზს ინტერვიუების სახით და მათი შედეგების დოკუმენტირებას ტექსტური აღწერის სახით ამასთანავე პროცესის დიაგრამების შემუშავებას.
- პროცესების, მონაცემთა ნაკადებისა და ინფორმაციის წარდგენის ფორმების მოთხოვნებისა და შეზღუდვების შეგროვებას და მათ დოკუმენტირებას შესაბამისი ფორმით.
- სისტემის მოდელირებას პროცესების, მონაცემთა ნაკადებისა და ინფორმაციის წარდგენის ფორმების მოთხოვნების დასაფარად.
- სასურველი პროცესების, მონაცემთა ნაკადებისა და ინფორმაციის წარდგენის ფორმების მოთხოვნების ფორმალიზებას ფუნქციური მოთხოვნების დოკუმენტის (FRD) სახით. ეს დოკუმენტი შეიცავს ბიზნეს პროცესების დიაგრამებს (პროცესების რუკები), ამ დიაგრამების ტექსტურ აღწერას, ასევე სხვა ინფორმაციას.
- მოთხოვნების დაგროვების განსაზღვრას და სისტემის კონფიგურაციაზე შესაბამის სამუშაოებს, მოთხოვნების პრიორიტეტებსა და მათ სპეციფიკას Fit&Gap დოკუმენტის სახით, სადაც:
- Fits წარმოადგენს სისტემის კონფიგურაციაზე მუშაობად
- Gaps კი -ახალი ფუნქციონალის შემუშავებაზე მუშაობას ან არსებულის გაფართოებას.
- ERP სისტემის მესამე მხარის პროდუქტებთან ინტეგრაციის წერტილების განსაზღვრას, მონაცემთა ნაკადების და ინფორმაციის გაცვლის ტექნიკური პარამეტრების აღწერას,
- გადაწყვეტილების ზოგადი არქიტექტურის განსაზღვრას და ფორმალიზაციას, ERP სისტემის და მისი ადგილის ჩვენებას გადაწყვეტილების ზოგად სტრუქტურაში, გადაწყვეტილებაში ინტეგრაციის წერტილებისა და მონაცემთა ნაკადების მითითებას,
- FRD და Fit&Gap დოკუმენტების დადასტურებას სისტემის კონფიგურაციის ტექნიკურ დავალებაში,
- Baseline-ის დაზუსტებას ტექნიკური დავალების მონაცემებზე დაყრდნობით შესაძლო კორექტირებით და, საჭიროების შემთხვევაში, პროექტის საბაზისო ხაზის მოდიფიკაციას და ხელახლა დადასტურებას.
სისტემის დანერგვისთვის გამოყენებული მიდგომის (სტანდარტული თუ პროტოტიპზე დაფუძნებული) და პროექტის სირთულის მიხედვით, „ანალიზისა და მოდელირების“ ეტაპზე მუშაობა შეიძლება განსხვავდებოდეს როგორც მოცულობით და შრომის ხარჯებით, ასევე შინაარსით. ამრიგად, FRD არ არის შემუშავებული მარტივი პროცესებისა და პროექტებისთვის, ასევე პროტოტიპის მოდელის გამოყენებით განხორციელებული პროექტებისთვის, ანუ პროექტამდე წინასწარ კონფიგურირებული სისტემის ფუნქციონალის საფუძველზე. ასევე, მსგავსი პროექტებისთვის გამოიყენება მომხმარებლის მიმდინარე პროცესების ანალიზის გამარტივებული და შემცირებული მოცულობითი ვერსია. ამრიგად, ანალიზისა და მოდელირების ეტაპზე სამუშაოს მოცულობა, ძალისხმევა, ღირებულება და ხანგრძლივობა პირდაპირ დამოკიდებულია:
- იმპლემენტაციის ტიპზე (სტანდარტული ან პროტოტიპზე დაფუძნებული მიდგომა),
- კონკრეტული ბიზნეს პროცესის სირთულეზე,
- პროექტის სირთულეზე მთლიანობაში,
- სისტემური მოთხოვნების რაოდენობასა და სპეციფიკაზე,
- ინტეგრაციის წერტილების რაოდენობასა და სპეციფიკაზე,
- სხვა ფაქტორებზე.
„პროცესების მოდელირებისა და ანალიზის“ ეტაპის დიაგრამა მოცემულია ქვემოთ:
III. სისტემის კონფიგურაცია
ERP-ის დანერგვის ეს ეტაპი მოიცავს:
- კონგიგურაციების შესრულებას. (Fits).
- დეველოპმენტის შესრულებას (Gaps) –ფუნქციების, ველების, ფილტრების დამატება/შეცვლას, ანგარიშების, პირველადი ფორმების და ა.შ. დეველოპმენტს ჩაშენებული სისტემური ინსტრუმენტების გამოყენებით:
- დეველოპმენტის სპეციფიკაციების მომზადება,
- დეველოპმენტი,
- ტესტირება.
- მონაცემთა წყაროების, სამუშაო პროცესების, მონაცემთა პარამეტრების, ანგარიშების კონფიგურაციას ჩაშენებული სისტემური ინსტრუმენტების გამოყენებით.
- რჩეული პროცესებისთვის სისტემის პროტოტიპის დემონსტრირებას.
- დეველოპმენტის ძირითადი სპეციფიკაციების განხილვას და დადასტურებას.
- სატესტო სკრიპტების მომზადებას:
- ფუნქციონალის ტესტის სკრიპტები,
- ინტეგრაციის ტესტის სკრიპტები.
- შიდა ფუნქციონალის ტესტირებას – სისტემა იტესტება პროექტის გუნდის რესურსებით.
„კონფიგურაციის“ ეტაპის დიაგრამა მოცემულია ქვემოთ:
IV. სისტემის ტესტირება
ეს ეტაპი მოიცავს სისტემის კომპლექსურ ტესტირებას შემდეგი ჩარჩოების ფარგლებში:
- ინდივიდუალური პროცესები, ინტეგრაციები ან პროცესების ჯგუფები (ფუნქციონალის ტესტირება) – User Acceptance Testing:
- ტესტირების მონაცემების მომზადება,
- სისტემის მუშაობის დემონსტრირება სატესტო სკრიპტების ფარგლებში და ძირითადი მომხმარებლების ტრენინგი,
- სისტემა იტესტება ძირითადი მომხმარებლების მიერ პროექტის გუნდის მხარდაჭერით,
- სისტემის და შესაბამისი სატესტო სკრიპტების კორექტირება.
- სრულმასშტაბიანი ტესტირება (End-to-End Testing):
- შიდა ინტეგრაციის ტესტირება – სისტემა,
- გარე ინტეგრაციის ტესტირება – სისტემის ტესტირება ძირითადი მომხმარებლების მიერ პროექტის გუნდის მხარდაჭერით,
- სისტემის და შესაბამისი სატესტო სკრიპტების კორექტირება.
- დატვირთვის ტესტირება – გამოიყენება მხოლოდ ოპერაციების და/ან მომხმარებლების დიდი რაოდენობის შემთხვევაში.
„სისტემის ტესტირების“ ეტაპის დიაგრამა მოცემულია ქვემოთ:
V. სისტემის გადატანა
ERP-ის დანერგვის ამ ეტაპზე სისტემა მზად არის გაშვებისთვის (Go-Live-ისთვის):
- მომხმარებლის ტრენინგი (ძირითადი და საბოლოო მომხმარებლები). ძირითადი მომხმარებლების ძირითადი ტრენინგი ტარდება ტესტირების ეტაპზე, მაგრამ დამატებითი ტრენინგი შეიძლება საჭირო გახდეს სისტემის გადატანის ეტაპზეც. საბოლოო მომხმარებლის ტრენინგს ახორციელებენ ძირითადი მომხმარებლები. გამონაკლის შემთხვევებში, შეიძლება ჩაერთონ კონტრაქტორის სპეციალისტები.
- მონაცემთა მიგრაციის შაბლონების მომზადება.
- მონაცემთა მიგრაცია (ძველი სისტემიდან და მანუალურად) და მათი სისწორის შემოწმება. ამ სამუშაოს ასრულებენ მომხმარებლის სპეციალისტები. ასევე გასათვალისწინებელია, რომ ეს ამოცანა შეიძლება დაკავშირებული იყოს მნიშვნელოვან ძალისხმევასთან და დიდ დროს მოითხოვდეს. არასწორი მონაცემები ერთ-ერთი ყველაზე გავრცელებული პრობლემაა გაშვების/ Go-Live-ის დროს.
- სისტემის მონაცემებზე წვდომის უფლებების კონფიგურაციას ასრულებს მომხმარებლის სპეციალისტი შესაბამისი ტრენინგის შემდეგ.
- სისტემის ფროდაქშენის გარემოს მომზადება.
- სისტემის გაშვების გეგმის მომზადება. ეს გეგმა შემუშავებულია წარმატებული Go-Live-ზე მიმართული ქმედებების ეტაპობრივად აღსაწერად. ეს ქმედებები შეიძლება იყოს მოსამზადებელი ან აღწერდეს სისტემის მუშაობის დაწყების თანმიმდევრობას კალენდართან დაკავშირებული დეპარტამენტების/პროცესებისთვის.
- სისტემის გაშვების გეგმის იმპლემენტაცია.
- როლებზე დაფუძნებული მომხმარებლის ინსტრუქციების მომზადება – შესრულებულია მომხმარებლის სპეციალისტის მიერ დასრულებული ფუნქციონალის ტესტირების სკრიპტების საფუძველზე.
„სისტემის გადატანის“ ეტაპის დიაგრამა მოცემულია ქვემოთ:
VI. Go Live/მხარდაჭერა
ეს ეტაპი პროექტის/პროექტის რელიზის ბოლო ეტაპია და წარმოადგენს სისტემის გაშვების გეგმის შესაბამისად გაშვებისკენ მიმართულ ქმედებებს, რაც გულისხმობს მომხმარებლების მხარდაჭერას სისტემაში ოპერაციულ მუშაობაში, შეცდომების აღმოფხვრასა და ცვლილებების შეტანას. ეს ეტაპი დროში შეზღუდულია, რაც დამოკიდებულია ხელშეკრულების პირობებზე. ამ ეტაპზე შესრულებული სამუშაო არის შემდეგი:
- Go-Live გემის იმპლემენტაცია.
- მომხმარებლების მხარდაჭერა.
- შეცდომების აღმოფხვრა.
- ცვლილებების შეტანა.
ERP-ის დანერგვის ამ ეტაპის დასრულების შემდეგ, პროექტი/გამოშვება დასრულებულად ითვლება და სისტემა გადადის პროექტის შემდგომ მხარდაჭერის რეჟიმში.
„გაშვების“ ეტაპის დიაგრამა მოცემულია ქვემოთ:
ცვლილების კონტროლი
ცვლილებების კონტროლი არის მიდგომების, დოკუმენტებისა და პროცედურების ერთობლიობა, რომელიც მიზნად ისახავს სისტემასა და პროექტის გეგმაში ცვლილებების კონტროლირებად შეტანას. ცვლილებები დადასტურებულია პროექტის დოკუმენტებში (FRD, F&G, არქიტექტურა, ინტეგრაციის წერტილები, პროექტის საბაზისო ხაზი, ყველა ტიპის სატესტო სკრიპტი, მონაცემთა იმპორტის შაბლონები და ა.შ.) შეტანილი ნებისმიერი კორექტირება. ცვლილებების მართვის პროცედურა შემდეგ ეტაპებს მოიცავს:
- ცვლილების მოთხოვნის (CR) ინიცირება და აღწერა:
- საჭიროების აღწერა,
- პრიორიტეტი.
- მოთხოვნის ანალიზი სფეროზე პასუხისმგებელი სპეციალისტის მიერ:
- მოთხოვნის არსი,
- განხორციელებადობა,
- ცვლილების გავლენის სფეროები.
- მოთხოვნის ანალიზის განხილვა პროექტის მენეჯმენტის მიერ.
- შეფასების მოთხოვნა სფეროზე პასუხისმგებელი სპეციალისტის მიერ:
- ძალისხმევა,
- ღირებულება,
- ხანგრძლივობა.
- შეფასების განხილვა ცვლილების ინიციატორის, პროექტის მართვის ჯგუფის წევრის მიერ და გადაწყვეტილების მიღება:
- მიღება,
- უარყოფა,
- გადადება.
- ცვლილების დანერგვა მისი დადასტურებისთანავე:
- Project Baseline-ის გეგმაში ჩართვა და კორექტირება,
- სამუშაოს შესრულება,
- · ტესტირება:
- შიდა,
- გარე.
- სისტემის მუშაობის დემონსტრირება ცვლილების დანერგვის შემდეგ.
- ცვლილებების გადატანა.
გასათვალისწინებელია შემდეგი:
- ცვლილებები წარმოადგენს პროექტის ხანგრძლივობისა და ღირებულების ზრდის ერთ-ერთ ყველაზე გავრცელებულ მიზეზს.
- კომპლექსური ცვლილებების განხორციელება შესაძლებელია განმეორებით.
- ზემოთ აღნიშნული ცვლილებების მართვის პროცედურის იგნორირებამ შეიძლება გამოიწვიოს არაპროგნოზირებადი შედეგები სისტემის ფუნქციონირებაზე.
- ცვლილებების რაოდენობა პირდაპირ დამოკიდებულია ანალიზისა და მოდელირების ეტაპზე სამუშაოს ხარისხზე და შესაბამის პროექტის დოკუმენტებზე.
- შესაძლო ცვლილებების განსახორციელებლად საჭირო ძალისხმევის ზუსტად დაგეგმვა, როგორც წესი, შეუძლებელია. ამ მიზნით, რეზერვები შედის საბაზისო ხაზში. შესაძლო ცვლილებების განსახორციელებლად საჭირო ძალისხმევის ზუსტად დაგეგმვა, როგორც წესი, შეუძლებელია. ამ მიზნით, baseline-ში გათვალისწინებულია რეზერვები.
„ცვლილებების კონტროლის“ პროცესის დიაგრამა მოცემულია ქვემოთ:
ERP პროექტების იმპლემენტაციის მიდგომა დაფუძნებულია Dynamics 365-ის ფინანსურ და ოპერაციულ აპლიკაციებზე, რომლებსაც SMART business იყენებს, ის კი თავის მხრივ დაფუძებულია, Microsoft Sure Step (Success by Design) მეთოდოლოგიაზე, რომელიც წარმოადგენს პროცესების, დოკუმენტებისა და პროცედურების კომპლექსურ ლოგიკურ ერთობლიობას. იმპლემენტაციის პროექტებში ამ მიდგომის დაცვა სასიცოცხლოდ მნიშვნელოვანი ელემენტია ნებისმიერი სირთულის ERP სისტემის დანერგვის პროექტის წარმატებით განხორციელებისთვის.
20+ წლიანი გამოცდილება ბიზნესის, პროექტებისა და გაყიდვების მენეჯმენტის სფეროში. 2007 წლიდან 2012 წლამდე იყო პროექტების მართვის ინსტიტუტის (PMI) პრეზიდენტი, კიევის ფილიალში. აქვს პრაქტიკული გამოცდილება პროექტების განხორციელების სფეროში საწარმოს რესურსების დაგეგმვის (ERP), ადამიანური რესურსების (HR), მარკეტინგის, ორგანიზაციების, EPM, PPM, BPMS და ბიზნეს პროცესების (BP) მიმართულებით.
