Microsoft გაზარდეთ თქვენი კომპანია ERP სისტემის SMART დანერგვით, რომელიც მორგებულია თქვენი ბიზნესის საჭიროებებზე. Dynamics 365 Finance and Operations Applications

1. 1. მასშტაბი,
   2.  სამუშაო,
   3. ხანგრძლივობა,
   4. რელიზის გეგმა,
   5. ღირებულება,
   6. პროექტის ლიცენზირების ნაწილი,
   7. გუნდი,
   8. დაშვებები და შეზღუდვები.

პროექტის შეფასების პროცესის აქტივობები ხორციელდება მომხმარებელსა და კონტრაქტორს შორის მჭიდრო თანამშრომლობით და შეიძლება შეფასდეს შემდეგნაირად:

• მაღალი დონის სქოუფის განსაზღვრა – ERP სისტემის ფუნქციების მოთხოვნების განსაზღვრა მომხმარებლის ოფიციალური ან არაფორმალური მოთხოვნის საფუძველზე. ეს დავალება შეიძლება შესრულდეს განმეორებით და, როგორც წესი, მოითხოვს მოთხოვნების ფორმალიზაციას და კლასიფიკაციას. ამ მიზნით გამოიყენება სტანდარტული ბიზნეს პროცესების კლასიფიკატორი.
• მოთხოვნების დახვეწა – მომხმარებლის მოთხოვნების დაზუსტება შეხვედრების ჩატარებით, შესაძლოა ERP სისტემის ზოგიერთი ფუნქციის დემონსტრირებით, რათა განისაზღვროს ძირითადი საკითხები/შეზღუდვები/პროცესები/მოლოდინები და სხვა ატრიბუტები, რომლებიც განსაზღვრავენ პროექტის მართვის ძირითად ფაქტორებს (იხილეთ ზემოთ). ეს ოპერაცია გამოიყენება დაბალი სირთულის პროექტებისთვის.
• Discovery პროექტის განხორციელება – ეს ოპერაცია არსებითად ქვეპროექტია, რომელიც მკაცრად რეკომენდებულია მთავარი იმპლემენტაციის პროექტის მაღალი ხარისხის გეგმის მისაღებად. ეს ქვეპროექტი არ ცვლის ანალიზის ფაზას მთავარ პროექტში (იხილეთ სტატია „D365FO ERP განხორციელების მეთოდოლოგია მნიშვნელოვანია“), მაგრამ საშუალებას გაძლევთ საკმარისად ზუსტად შეიმუშავოთ საშუალო და მაღალი სირთულის ERP განხორციელების მთავარი პროექტის შეფასება და დაგეგმვა. აღმოჩენის ფარგლებში სამუშაოს შესრულება, როგორც წესი, 3-დან 6 კვირამდე გრძელდება და ანაზღაურებადია, ასევე შესაძლებელია Microsoft-ის დაფინანსება. Discovery ქვეპროექტის ძირითადი შედეგები:
  • პროექტის სქოუფი – პროცესები/ქვეპროცესები, სისტემის მოდულები,
  • რელიზის გეგმა – კონტენტის დაჯგუფება ამ პროცესების ექსპლუატაციაში თანდათანობითი გაშვების მიზნით:
    • პროცესების მიხედვით,
    • იურიდიული პირების მიხედვით,
    • გეოგრაფიული ლოკაციის მიხედვით.
  • თითოეული რელიზისთვის სამუშაო ქვეპროცესების დონემდე დაყოფით,
  • ხანგრძლივობა,
  • ღირებულება,
  • პროექტის გუნდი,
  • სისტემის ლანდშაფტი – ERP სისტემის მოდულებისა და სისტემების ურთიერთქმედების დიაგრამა, რომლებიც ქმნიან მომავალი გადაწყვეტილების საერთო არქიტექტურას, მათ შორის მონაცემთა ნაკადები და ინტეგრაციის მეთოდები,
  • Fit&Gap –მომხმარებლის მოთხოვნების დაფარვის პროცენტული მაჩვენებელი სისტემის სტანდარტული ფუნქციონალით,
  • პროექტის ძირითადი რისკები და მათი მართვის მეთოდები,
  • პროექტის შეფასების ძირითადი ვარაუდები,
  • პროექტის შეზღუდვები.

• პროექტის შეფასება – შეაფასეთ შრომის ხარჯები, გუნდის ხარისხობრივი და რაოდენობრივი შემადგენლობა, ასევე პროექტის ხანგრძლივობა — პროცესებისა და პროექტის ეტაპების მიხედვით დაყოფით, შეფასების ფაილის ფორმატში.
• შეფასების შეთანხმება – გამართეთ შეხვედრები შეფასების მონაცემების წარსადგენად, განსახილველად და გასარკვევად, რათა გათვალისწინებული იყოს ყველა მოთხოვნა, შეზღუდვა, მოლოდინი და შეფასება ასევე გასაგები იყოს მომხმარებლისთვის.
• კომერციული წინადადების შექმნა/შეთანხმება – შეიმუშავეთ დოკუმენტი, რომელიც შეაჯამებს წინა ეტაპზე შესრულებულ სამუშაოს შედეგებს (სურვილის შემთხვევაში, ERP სისტემის დანერგვის პროექტის გეგმას MS Project ფორმატში) და ასევე შეიცავს ინფორმაციას როგორც პროექტისა და სისტემის ღირებულებაზე, ასევე იმ ელემენტებზე, რისგანაც შედგება ეს ღირებულება, და მის ფორმირების პრინციპებზე. ეს დოკუმენტი წარმოადგენს ოფიციალურ წინადადებას და, მომხმარებლის მიერ მისი მიღების შემთხვევაში, საფუძვლად გამოიყენება შესაბამისი ხელშეკრულებების მომზადების, შეთანხმებისა და გაფორმებისთვის.

ERP-ის იმპლემენტაციის პროექტის ღირებულება

საკუთრების მთლიანი ღირებულება (TCO) განისაზღვრება სისტემის გამოყენების მთელი სასიცოცხლო ციკლისთვის და შემდეგი ელემენტებისგან შედგება:

1. Microsoft Dynamics 365-ის ფინანსური და ოპერაციული აპლიკაციების პროგრამული პროდუქტის ლიცენზიების ღირებულება,
2. იმ გარემოების ღირებულება, რომლებიც საჭიროა პროგრამული უზრუნველყოფის გადატანასა და ოპერირებისთვის, თუკი ისინი არ შედის ERP სისტემასთან ერთად სტანდარტულად მიწოდებულ კომპლექტში.
3. დამატებითი პროგრამული პროდუქტების ღირებულება (მაგალითად, Office 365, გარე Power BI და სხვ.), თუკი მათი გამოყენება გათვალისწინებულია ბიზნეს პროცესების ფარგლებში, ასევე დამატებითი მოდულებისა და სერვისების ღირებულება (მაგალითად, ლოკალიზაციის პაკეტები კონკრეტული ქვეყნებისთვის),
4. ERP სისტემის დანერგვის პროექტის ღირებულება იმ პროცესებისა და ფუნქციონალის ჭრილში, რაც პროექტის ფარგლებში ხორციელდება,
5. სისტემის პროექტის შემდგომი მხარდაჭერის ღირებულება.

• კომპლექსური პროექტი (ერთ ან რამდენიმე რელიზში), რომლის ფარგლებშიც შესაძლებელია სამუშაოების მოცულობის (Scope) დაგეგმვა პროექტის დაწყებამდე;
• ეტაპობრივი (release-by-release) პროექტი, სადაც სამუშაოების მოცულობა განისაზღვრება ყოველი შემდეგი რელიზის დაწყებამდე.

1. ლიცენზიების ღირებულება Microsoft Dynamics 365 Finance and Operations-ის პროგრამული უზრუნველყოფისთვის:
   • სისტემაში არსებობს ოთხი ძირითადი პროგრამული პროდუქტი, რომლებიც ცალ-ცალკე შეგიძლიათ შეიძნოთ, და ასევე დამატებითი მოდულები კონკრეტული ფუნქციონალისთვის: Microsoft Dynamics 365 Finance, Microsoft Dynamics 365 Supply Chain Management, Microsoft Dynamics 365 Commerce and Microsoft Dynamics 365 Human Resources.
   • ლიცენზირებული მომხმარებლები სახელობითად ინიშნება და იყოფიან ოთხ კატეგორიად:
     • Premium,
     • Operations – Activity,
     • Standard,
     • Team Member.

• SCM Premium,
• SCM,
• Operations – Activity,
• Team Member.

2. საოპერაციო გარემოს ღირებულება: პროდუქტის საბაზისო პაკეტი მოიცავს ორ გარემოს – სატესტო (sandbox) და საოპერაციო (production). დამატებითი გარემოების საჭიროება დამოკიდებულია:

• პროექტის ფარგლებში რაიმე სახის დეველოპმენტის აუცილებლობაზე. თუ პროექტის ფარგლებში აუცილებელია სისტემის მოდიფიკაცია ან დეველოპმენტი (coding), საჭირო გარემოების რაოდენობა განისაზღვრება არქიტექტურული მიდგომით და დამოკიდებულია იმაზე, რამდენი ცალკე დველოპმენტის ან ტესტირების ეტაპია გასათვალისწინებელი;
• ერთდროულად რამდენიმე გარემოს პარალელურად გამოყენების საჭიროებაზე, მაგალითად მაშინ, როცა სისტემა ეტაპობრივად (release-by-release) ამოქმედდება, შეიძლება საჭირო გახდეს რამდენიმე სატესტო ან დამატებითი საოპერაციო გარემოს არსებობა, რათა უზრუნველყოფილ იქნეს სისტემის შეუფერხებელი ფუნქციონირება და მისი თანმიმდევრული დანერგვა სხვადასხვა რელიზის ფარგლებში.

3. დამატებითი პროგრამული უზრუნველყოფის ღირებულება. თუ სისტემის დიზაინის ეტაპზე გაირკვა, რომ ბიზნეს-პროცესებისთვის აუცილებელია დამატებითი პროგრამების გამოყენება (მაგალითად, Office 365, Power BI, ლოკალიზაციის პაკეტები), უნდა გაითვალისწინოთ მათი ლიცენზიების შესყიდვაც.

4. ERP სისტემის დანერგვის პროექტის ღირებულება: ეს ღირებულება ორი ძირითადი პარამეტრით განისაზღვრება:

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

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

• ა. იმ პერსონალის რაოდენობა და კვალიფიკაცია, რომელიც დამკვეთის მხარეს მუშაობს და უზრუნველყოფს სისტემის მხარდაჭერას,
• პროცესებისა და მომხმარებლების რაოდენობაზე ERP სისტემაში,
• სისტემის ტესტირების ხარისხზე Go-Live-მდე,
• საბოლოო მომხმარებლების გადამზადების ხარისხსა და მათ კვალიფიკაციაზე,
• არასტანდარტული და დაუგეგმავი ოპერაციების რაოდენობაზე, რომლებიც პროექტით განსაზღვრული ჩარჩოს გარეთ შეიძლება წარმოიშვას,
• მონაცემთა (საქაღალდეების და სხვა ინფორმაციის) ხარისხზე,
• ERP სისტემის გარე სისტემებთან ინტეგრაციების რაოდენობასა და სპეციფიკაზე,
• ცვლილებების ინიცირებაზე — მათ შორის ახალი მოთხოვნები ან კონფიგურირებული პროცესების ცვლილებები.

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

ვლად ბერიოზინი

Business Development Manager, SMART business

ERP იმპლემენტაციის ნაბიჯები (ეტაპები)

1. პროექტის დაწყება
2. პროცესის მოდელირება და ანალიზი
3. სისტემის კონფიგურაცია
4. სისტემის ტესტირება
5. სისტემის გადატანა
6. გაშვება/მხარდაჭერა

I. პროექტის დაწყება

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

II. პროცესის მოდელირება და ანალიზი

• მიმდინარე პროცესების, არქიტექტურისა და მონაცემთა ნაკადების (As Is Model) ანალიზს ინტერვიუების სახით და მათი შედეგების დოკუმენტირებას ტექსტური აღწერის სახით ამასთანავე პროცესის დიაგრამების შემუშავებას.
• პროცესების, მონაცემთა ნაკადებისა და ინფორმაციის წარდგენის ფორმების მოთხოვნებისა და შეზღუდვების შეგროვებას და მათ დოკუმენტირებას შესაბამისი ფორმით.
• სისტემის მოდელირებას პროცესების, მონაცემთა ნაკადებისა და ინფორმაციის წარდგენის ფორმების მოთხოვნების დასაფარად.
• სასურველი პროცესების, მონაცემთა ნაკადებისა და ინფორმაციის წარდგენის ფორმების მოთხოვნების ფორმალიზებას ფუნქციური მოთხოვნების დოკუმენტის (FRD) სახით. ეს დოკუმენტი შეიცავს ბიზნეს პროცესების დიაგრამებს (პროცესების რუკები), ამ დიაგრამების ტექსტურ აღწერას, ასევე სხვა ინფორმაციას.
• მოთხოვნების დაგროვების განსაზღვრას და სისტემის კონფიგურაციაზე შესაბამის სამუშაოებს, მოთხოვნების პრიორიტეტებსა და მათ სპეციფიკას Fit&Gap დოკუმენტის სახით, სადაც:
  • Fits წარმოადგენს სისტემის კონფიგურაციაზე მუშაობად
  • Gaps კი -ახალი ფუნქციონალის შემუშავებაზე მუშაობას ან არსებულის გაფართოებას.
• ERP სისტემის მესამე მხარის პროდუქტებთან ინტეგრაციის წერტილების განსაზღვრას, მონაცემთა ნაკადების და ინფორმაციის გაცვლის ტექნიკური პარამეტრების აღწერას,
• გადაწყვეტილების ზოგადი არქიტექტურის განსაზღვრას და ფორმალიზაციას, ERP სისტემის და მისი ადგილის ჩვენებას გადაწყვეტილების ზოგად სტრუქტურაში, გადაწყვეტილებაში ინტეგრაციის წერტილებისა და მონაცემთა ნაკადების მითითებას,
• FRD და Fit&Gap დოკუმენტების დადასტურებას სისტემის კონფიგურაციის ტექნიკურ დავალებაში,
• Baseline-ის დაზუსტებას ტექნიკური დავალების მონაცემებზე დაყრდნობით შესაძლო კორექტირებით და, საჭიროების შემთხვევაში, პროექტის საბაზისო ხაზის მოდიფიკაციას და ხელახლა დადასტურებას.

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

III. სისტემის კონფიგურაცია

• კონგიგურაციების შესრულებას. (Fits).
• დეველოპმენტის შესრულებას (Gaps) –ფუნქციების, ველების, ფილტრების დამატება/შეცვლას, ანგარიშების, პირველადი ფორმების და ა.შ. დეველოპმენტს ჩაშენებული სისტემური ინსტრუმენტების გამოყენებით:
  • დეველოპმენტის სპეციფიკაციების მომზადება,
  • დეველოპმენტი,
  • ტესტირება.
• მონაცემთა წყაროების, სამუშაო პროცესების, მონაცემთა პარამეტრების, ანგარიშების კონფიგურაციას ჩაშენებული სისტემური ინსტრუმენტების გამოყენებით.
• რჩეული პროცესებისთვის სისტემის პროტოტიპის დემონსტრირებას.
• დეველოპმენტის ძირითადი სპეციფიკაციების განხილვას და დადასტურებას.
• სატესტო სკრიპტების მომზადებას:
  • ფუნქციონალის ტესტის სკრიპტები,
  • ინტეგრაციის ტესტის სკრიპტები.
• შიდა ფუნქციონალის ტესტირებას – სისტემა იტესტება პროექტის გუნდის რესურსებით.

IV. სისტემის ტესტირება

• ინდივიდუალური პროცესები, ინტეგრაციები ან პროცესების ჯგუფები (ფუნქციონალის ტესტირება) – User Acceptance Testing:
  • ტესტირების მონაცემების მომზადება,
  • სისტემის მუშაობის დემონსტრირება სატესტო სკრიპტების ფარგლებში და ძირითადი მომხმარებლების ტრენინგი,
  • სისტემა იტესტება ძირითადი მომხმარებლების მიერ პროექტის გუნდის მხარდაჭერით,
  • სისტემის და შესაბამისი სატესტო სკრიპტების კორექტირება.
• სრულმასშტაბიანი ტესტირება (End-to-End Testing):
  • შიდა ინტეგრაციის ტესტირება – სისტემა,
  • გარე ინტეგრაციის ტესტირება – სისტემის ტესტირება ძირითადი მომხმარებლების მიერ პროექტის გუნდის მხარდაჭერით,
  • სისტემის და შესაბამისი სატესტო სკრიპტების კორექტირება.
• დატვირთვის ტესტირება – გამოიყენება მხოლოდ ოპერაციების და/ან მომხმარებლების დიდი რაოდენობის შემთხვევაში.

V. სისტემის გადატანა

• მომხმარებლის ტრენინგი (ძირითადი და საბოლოო მომხმარებლები). ძირითადი მომხმარებლების ძირითადი ტრენინგი ტარდება ტესტირების ეტაპზე, მაგრამ დამატებითი ტრენინგი შეიძლება საჭირო გახდეს სისტემის გადატანის ეტაპზეც. საბოლოო მომხმარებლის ტრენინგს ახორციელებენ ძირითადი მომხმარებლები. გამონაკლის შემთხვევებში, შეიძლება ჩაერთონ კონტრაქტორის სპეციალისტები.
• მონაცემთა მიგრაციის შაბლონების მომზადება.
• მონაცემთა მიგრაცია (ძველი სისტემიდან და მანუალურად) და მათი სისწორის შემოწმება. ამ სამუშაოს ასრულებენ მომხმარებლის სპეციალისტები. ასევე გასათვალისწინებელია, რომ ეს ამოცანა შეიძლება დაკავშირებული იყოს მნიშვნელოვან ძალისხმევასთან და დიდ დროს მოითხოვდეს. არასწორი მონაცემები ერთ-ერთი ყველაზე გავრცელებული პრობლემაა გაშვების/ Go-Live-ის დროს.
• სისტემის მონაცემებზე წვდომის უფლებების კონფიგურაციას ასრულებს მომხმარებლის სპეციალისტი შესაბამისი ტრენინგის შემდეგ.
• სისტემის ფროდაქშენის გარემოს მომზადება.
• სისტემის გაშვების გეგმის მომზადება. ეს გეგმა შემუშავებულია წარმატებული Go-Live-ზე მიმართული ქმედებების ეტაპობრივად აღსაწერად. ეს ქმედებები შეიძლება იყოს მოსამზადებელი ან აღწერდეს სისტემის მუშაობის დაწყების თანმიმდევრობას კალენდართან დაკავშირებული დეპარტამენტების/პროცესებისთვის.
• სისტემის გაშვების გეგმის იმპლემენტაცია.
• როლებზე დაფუძნებული მომხმარებლის ინსტრუქციების მომზადება - შესრულებულია მომხმარებლის სპეციალისტის მიერ დასრულებული ფუნქციონალის ტესტირების სკრიპტების საფუძველზე.

VI. Go Live/მხარდაჭერა

• Go-Live გემის იმპლემენტაცია.
• მომხმარებლების მხარდაჭერა.
• შეცდომების აღმოფხვრა.
• ცვლილებების შეტანა.

ცვლილების კონტროლი

• ცვლილების მოთხოვნის (CR) ინიცირება და აღწერა:
  • საჭიროების აღწერა,
  • პრიორიტეტი.
• მოთხოვნის ანალიზი სფეროზე პასუხისმგებელი სპეციალისტის მიერ:
  • მოთხოვნის არსი,
  • განხორციელებადობა,
  • ცვლილების გავლენის სფეროები.
• მოთხოვნის ანალიზის განხილვა პროექტის მენეჯმენტის მიერ.
• შეფასების მოთხოვნა სფეროზე პასუხისმგებელი სპეციალისტის მიერ:
  • ძალისხმევა,
  • ღირებულება,
  • ხანგრძლივობა.
• შეფასების განხილვა ცვლილების ინიციატორის, პროექტის მართვის ჯგუფის წევრის მიერ და გადაწყვეტილების მიღება:
  • მიღება,
  • უარყოფა,
  • გადადება.
• ცვლილების დანერგვა მისი დადასტურებისთანავე:
  • Project Baseline-ის გეგმაში ჩართვა და კორექტირება,
  • სამუშაოს შესრულება,
  • · ტესტირება:
    • შიდა,
    • გარე.
• სისტემის მუშაობის დემონსტრირება ცვლილების დანერგვის შემდეგ.
• ცვლილებების გადატანა.

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

ERP პროექტების იმპლემენტაციის მიდგომა დაფუძნებულია Dynamics 365-ის ფინანსურ და ოპერაციულ აპლიკაციებზე, რომლებსაც SMART business იყენებს, ის კი თავის მხრივ დაფუძებულია, Microsoft Sure Step (Success by Design) მეთოდოლოგიაზე, რომელიც წარმოადგენს პროცესების, დოკუმენტებისა და პროცედურების კომპლექსურ ლოგიკურ ერთობლიობას. იმპლემენტაციის პროექტებში ამ მიდგომის დაცვა სასიცოცხლოდ მნიშვნელოვანი ელემენტია ნებისმიერი სირთულის ERP სისტემის დანერგვის პროექტის წარმატებით განხორციელებისთვის.

ვლად ბერიოზინი

Business Development Manager, SMART business