თავი 10 · ProjectVIEW ERP-ის ძირითადი SaaS ჩარჩო-დოკუმენტი
თავი 10 არეგულირებს, რა ხდება მაშინ, როდესაც ProjectVIEW ERP-ის ვერსიის სასიცოცხლო ციკლი სრულდება: შეტყობინება მინიმუმ 12 თვით ადრე, მიგრაციის მომსახურება, ინტეგრაციებისა და ინდივიდუალური მორგებების ადაპტაცია, ხელახალი ტრენინგი და ცვლილებების მართვა. მიუხედავად იმისა, გადადის თუ არა დამკვეთი მომდევნო ვერსიაზე თუ წყვეტს გამოწერას, მონაცემები ბრუნდება წერილობითი მოთხოვნიდან 2 სამუშაო დღის ვადაში (SQL სარეზერვო ასლი, CSV, JSON ან XML), ხოლო გარემო ექსპლუატაციიდან გამოიყვანება განსაზღვრული პროცესის შესაბამისად — „არცერთი დამკვეთი უყურადღებოდ არ რჩება“.
- 12 თვეEOL-ის შეტყობინების მინიმალური ვადა
- 2 ს.დ.მონაცემთა დაბრუნება წერილობითი მოთხოვნის შემდეგ
- .bak · CSV · JSON · XMLექსპორტის ფორმატები
10.1 მიმოხილვა და მიზანი
წინამდებარე თავი ადგენს ყოვლისმომცველ ჩარჩოს, რომელიც არეგულირებს ProjectVIEW ERP პლატფორმის სასიცოცხლო ციკლის დასრულების (EOL) პროცესს, მათ შორის ძირითად ვერსიებზე გადასვლას, მიგრაციის მომსახურებას, ხელახალი ტრენინგის ვალდებულებებს, ინტეგრაციებისა და ინდივიდუალური მორგებების ადაპტაციას, მონაცემთა დაბრუნების უფლებებს და გამოწერის შეწყვეტის პროცედურებს. იგი ჩანაცვლებს და აფართოებს თავი 4-ის §4.7.4-ის შეჯამებით დებულებებს.
მიმწოდებლის EOL ჩარჩო ეყრდნობა წამყვანი საწარმოს SaaS და ERP მიმწოდებლების — მათ შორის SAP S/4HANA, Oracle Fusion Cloud, IFS Cloud და Infor CloudSuite — ვერსიებზე გადასვლის დახვეწილ პრაქტიკას, რომელიც ადაპტირებულია მიმწოდებლის გამოყოფილი კერძო სუვერენული განთავსების მოდელსა და დამკვეთის მონაცემებზე სრული საკუთროების უფლებას (თავი 9, §9.9).
ძირითადი საპროექტო პრინციპია „არცერთი დამკვეთი უყურადღებოდ არ რჩება“: თითოეული დამკვეთი მიიღებს განსაზღვრულ შეტყობინებას, მიგრაციის ყოვლისმომცველ მხარდაჭერას, ხელახალ ტრენინგსა და მონაცემთა დაბრუნების მომსახურებას, იმისდა მიუხედავად, აირჩევს იგი მომდევნო ვერსიაზე გადასვლას თუ გამოწერის შეწყვეტას.
10.2 მოქმედების სფერო
წინამდებარე თავი მოიცავს:
- (a) ვერსიის სასიცოცხლო ციკლის ფაზებს: საყოველთაო ხელმისაწვდომობა (GA), ძირითადი მხარდაჭერა, გაფართოებული მხარდაჭერა, შემუშავების დასრულება (EOE) და სასიცოცხლო ციკლის დასრულება (EOL) პლატფორმის თითოეული ძირითადი ვერსიისთვის.
- (b) მიგრაციის მომსახურებას: მიმწოდებლის ხელმძღვანელობით წარმართულ მონაცემთა მიგრაციას, სქემის ტრანსფორმაციას, გარემოს უზრუნველყოფას და გადართვის დაგეგმვას მომდევნო ვერსიაზე გადამსვლელი დამკვეთებისთვის.
- (c) ხელახალ ტრენინგსა და ცვლილებების მართვას: სავალდებულო სატრენინგო პროგრამებს, ჩემპიონების ხელახალ სერტიფიცირებას, მომხმარებლის ადაპტაციის სამუშაო შეხვედრებს და ცოდნის ბაზის განახლებებს, რომლებიც აუცილებელია ვერსიაზე წარმატებული გადასვლისთვის.
- (d) ინტეგრაციებისა და ინდივიდუალური მორგებების ადაპტაციას: დამკვეთისთვის სპეციფიკური ინტეგრაციების, ინდივიდუალური მორგებებისა და კონფიგურაციების შეფასებას, ხელახალ შემუშავებას და ვალიდაციას მომდევნო ვერსიაზე.
- (e) მონაცემთა დაბრუნებას დამკვეთებისთვის, რომლებიც არ გადადიან ახალ ვერსიაზე: მონაცემთა ექსპორტის ვალდებულებებს, ფორმატის სპეციფიკაციებს, მიწოდების ვადებს და შენახვის ჯაჭვის (chain-of-custody) დოკუმენტაციას იმ დამკვეთებისთვის, რომლებიც გადასვლაზე უარს აცხადებენ.
- (f) გამოწერის შეწყვეტას: მომსახურების ეტაპობრივი დასრულების, გარემოს ექსპლუატაციიდან გამოყვანისა და სახელშეკრულებო ურთიერთობის შეწყვეტის ოფიციალურ პროცედურებს.
- (g) როლებსა და პასუხისმგებლობებს: ყველა EOL საქმიანობისთვის RACI-ს განაწილებას მიმწოდებლისა და დამკვეთის ორგანიზაციებს შორის. წინამდებარე თავი არ მოიცავს ძირითადი ვერსიის ფარგლებში ინკრემენტულ რელიზებს/განახლებებს (იხ. თავი 4, §4.7.1) ან ძირითადი მხარდაჭერის პერიოდში შესრულებულ COTS პლატფორმის განახლებებს (იხ. თავი 4, §4.7.3).
10.3 ვერსიის სასიცოცხლო ციკლის ფაზები
პლატფორმის თითოეული ძირითადი ვერსია (მაგ., v11, v12) გადის განსაზღვრულ სასიცოცხლო ციკლს. მიმწოდებლის სასიცოცხლო ციკლის მოდელი ეყრდნობა SAP-ის (Maintenance Strategy), Oracle-ის (Sustaining Support), IFS-ის (Mainstream/Extended Maintenance) და Infor-ის (Product Lifecycle Policy) მიერ გამოქვეყნებულ ვერსიების მხარდაჭერის ჩარჩოებს და ადაპტირებულია მიმწოდებლის მხოლოდ SaaS მიწოდების მოდელზე:
| ფაზა | ხანგრძლივობა | რას იღებს დამკვეთი | მიმწოდებლის ვალდებულებები |
|---|---|---|---|
| საყოველთაო ხელმისაწვდომობა (GA) | მომდევნო ვერსიის GA-მდე | სრული წვდომა პლატფორმის ყველა ფუნქციაზე, მოდულსა და API-ზე. ინკრემენტული რელიზები (v11.01, v11.02…) მოწოდებულია Agile სპრინტების მეშვეობით (§4.7.1). | აქტიური შემუშავება, ფუნქციების გაუმჯობესება, შეცდომების გამოსწორება, უსაფრთხოების პატჩები, COTS კომპონენტების აქტუალურობის შენარჩუნება. |
| EOL-ის გამოცხადება | T− 12 თვე | ოფიციალური წერილობითი შეტყობინება იმის შესახებ, რომ მიმდინარე ძირითადი ვერსიის სასიცოცხლო ციკლი სრულდება. შეტყობინება მიუთითებს მომდევნო ვერსიას, მიგრაციის სავარაუდო ვადებს და გადასვლის ხელმისაწვდომ მომსახურებებს. | EOL-ის გამოცხადების გამოქვეყნება. თითოეული დამკვეთისთვის მომდევნო ვერსიაზე გადასვლისთვის მზადობის შეფასების დაწყება. |
| გადასვლის პერიოდი | T− 12 თვიდან T− 30 დღემდე | მიგრაციის დაგეგმვა, მონაცემთა მიგრაციის შესრულება, ხელახალი ტრენინგი, ინტეგრაციების ხელახალი შემუშავება, UAT მომდევნო ვერსიაზე და პარალელური ექსპლუატაცია (არჩევის შემთხვევაში). | მიგრაციის მომსახურების, ტრენინგისა და ინტეგრაციების ადაპტაციის მიწოდება, როგორც ეს განსაზღვრულია §10.5– §10.7-ში. |
| შემუშავების დასრულება (EOE) | T− 30 დღე | ახალი ცვლილების მოთხოვნები აღარ მიიღება. ტექნიკური მხარდაჭერა გრძელდება (მხოლოდ ინციდენტების გადაწყვეტა + უსაფრთხოების პატჩები). | უსაფრთხოების პატჩების მიწოდებისა და P1/P2 ინციდენტების გადაწყვეტის გაგრძელება ძველი ვერსიისთვის. |
| სასიცოცხლო ციკლის დასრულება (EOL) | T = 0 (გამოცხადებიდან 12 თვის შემდეგ) | ძველი ვერსიის ყველა სახის მხარდაჭერა წყდება. დამკვეთი უკვე უნდა მუშაობდეს მომდევნო ვერსიაზე ან არჩეული ჰქონდეს გამოწერის შეწყვეტა. | ძველი გარემოს ექსპლუატაციიდან გამოყვანა. მონაცემთა დაბრუნება, თუ დამკვეთმა შეწყვეტა აირჩია (§10.9). |
| გაფართოებული მხარდაჭერა (ნებაყოფილი) | EOL-ის შემდეგ არაუმეტეს 12 თვისა | ხელმისაწვდომია წერილობითი მოთხოვნის საფუძველზე და ექვემდებარება დამატებით საფასურს. მოიცავს მხოლოდ P1/P2 ინციდენტების გადაწყვეტას და უსაფრთხოების კრიტიკულ პატჩებს. ფუნქციების შემუშავება არ ხორციელდება. | გაფართოებული მხარდაჭერის მიწოდება კომერციული ხელშეკრულების ცალკე დანართის (Extended Support Addendum) საფუძველზე. |
ძირითადი ვალდებულება: მიმწოდებელი უზრუნველყოფს მინიმუმ თორმეტი (12) თვის პერიოდს EOL-ის გამოცხადებასა და EOL-ის თარიღს შორის. არცერთ დამკვეთს არ მოეთხოვება გადასვლა ოფიციალური წერილობითი შეტყობინების თარიღიდან 12 თვეზე ნაკლებ ვადაში. ეს შეესაბამება SAP-ის, Oracle-ის, IFS-ისა და Infor-ის სასიცოცხლო ციკლის პოლიტიკებში დაფიქსირებულ საუკეთესო პრაქტიკას.
10.4 EOL-ის გამოცხადება და დამკვეთთან კომუნიკაცია
მიმწოდებელი EOL-ის პროცესს თითოეულ დამკვეთს აცნობებს შემდეგი სტრუქტურირებული პროგრამის მეშვეობით:
| კომუნიკაცია | ვადა | არხი | შინაარსი |
|---|---|---|---|
| EOL-ის გამოცხადების წერილი | T− 12 თვე (მინიმუმ) | წერილობითი შეტყობინება დამკვეთის დანიშნულ საკონტაქტო პირს + ანგარიშის მენეჯერის ელ.ფოსტა | EOL-ის ოფიციალური თარიღი, მომდევნო ვერსიის იდენტიფიკაცია, მიგრაციის მომსახურების შეჯამება, სავარაუდო გრაფიკი და დამკვეთისგან საჭირო ქმედებები. |
| მიგრაციისთვის მზადობის შეფასება | T− 11 თვე | ერთობლივი სამუშაო შეხვედრა (დისტანციურად ან ადგილზე) | დამკვეთისთვის სპეციფიკური ინტეგრაციების, ინდივიდუალური მორგებებისა და მონაცემთა მოცულობის ზეგავლენის შეფასება. მიგრაციის წინასწარი გეგმა და რესურსების მოთხოვნები. |
| გადასვლის სტატუსის კვარტალური ანგარიშები | T−‒9, T−6, T−3 თვე | მომსახურების მიმოხილვის შეხვედრა + წერილობითი ანგარიში | მიგრაციის პროგრესი, შეუსრულებელი ქმედებები, რისკების რეესტრი, ტრენინგების გრაფიკი და გადართვის სავარაუდო თარიღი. |
| EOE-ის შეტყობინება | T− 30 დღე | წერილობითი შეტყობინება + ბანერი აპლიკაციაში | დადასტურება იმისა, რომ ძველი ვერსიისთვის ახალი ცვლილების მოთხოვნები აღარ მიიღება. შეტყობინება მხარდაჭერის ფარგლების შემცირების შესახებ. |
| მიგრაციის საბოლოო დადასტურება | T− 14 დღე | წერილობითი შეტყობინება | დასრულებული მიგრაციის (ან დამკვეთის მიერ შეწყვეტის + მონაცემთა დაბრუნების არჩევის) დადასტურება. გადართვის საბოლოო ლოგისტიკა. |
| EOL-ის დადასტურება | T = 0 | წერილობითი შეტყობინება | ძველი ვერსია გამოყვანილია ექსპლუატაციიდან. მომდევნო ვერსია ერთადერთი მხარდაჭერილი ვერსიაა. დადასტურებულია გაფართოებული მხარდაჭერის ხელმისაწვდომობა (საჭიროების შემთხვევაში). |
10.5 მიგრაციის მომსახურება
მიმწოდებელი მომდევნო ვერსიაზე გადამსვლელ თითოეულ დამკვეთს სტრუქტურირებულ მიგრაციის პროგრამას მიაწოდებს. ქვემოთ განსაზღვრული სტანდარტული მიგრაციის ფარგლებში მიგრაციის მომსახურება შედის გამოწერაში დამატებითი ღირებულების გარეშე. გაფართოებული მიგრაციის მომსახურება (მაგ., ძველი სისტემებიდან მონაცემთა ჩატვირთვა, რთული ETL ტრანსფორმაციები, პარალელური ექსპლუატაცია სტანდარტულ პერიოდზე მეტი ხანით) ხელმისაწვდომია ცალკე განსაზღვრული ფარგლების მქონე პროექტების სახით.
10.5.1 სტანდარტული მიგრაციის ფარგლები
- (a) გარემოს უზრუნველყოფა: მიმწოდებელი დამკვეთის გამოყოფილ კერძო სუვერენულ Azure ტენანტში უზრუნველყოფს მომდევნო ვერსიის გარემოს, რომელიც კონფიგურირებულია იგივე უსაფრთხოების კონტროლებით, ქსელური პარამეტრებით და შესაბამისობის პარამეტრებით, როგორიც აქვს მოქმედ საწარმოო (production) გარემოს.
- (b) მონაცემთა მიგრაცია: დამკვეთის ყველა მონაცემის სრული მიგრაცია ძველი ვერსიის მონაცემთა ბაზიდან მომდევნო ვერსიის მონაცემთა ბაზაში, მათ შორის ძირითადი (master) მონაცემების, ტრანზაქციული მონაცემების, კონფიგურაციული მონაცემებისა და აუდიტის კვალის. მიმწოდებელი იყენებს სქემის ტრანსფორმაციის ავტომატიზებულ სკრიპტებს, რომლებიც ვალიდირებულია დამკვეთის მონაცემთა პროფილის მიმართ.
- (c) საკონსულტაციო მხარდაჭერა მონაცემთა გასუფთავებისთვის: Oracle Fusion-ისა და Infor CloudSuite-ის საუკეთესო პრაქტიკის შესაბამისად, მიმწოდებელი მიგრაციამდე დამკვეთს უწევს კონსულტაციას მონაცემთა გასუფთავების შესაძლებლობებზე. რეკომენდებული მიდგომაა აქტიური ტრანზაქციული მონაცემების არაუმეტეს სამი (3) წლის მიგრაცია, ხოლო ისტორიული მონაცემების დაარქივება მხოლოდ წაკითხვის ფორმატში, რომელიც ხელმისაწვდომი იქნება ანგარიშგებობისა და შესაბამისობის მიზნებისთვის.
- (d) კონფიგურაციის მიგრაცია: დამკვეთისთვის სპეციფიკური ყველა კონფიგურაცია (როლები, სამუშაო ნაკადები, დამტკიცების ჯაჭვები, შეტყობინებების წესები, ანგარიშების შაბლონები, საინფორმაციო დაფები) მომდევნო ვერსიაზე გადაიტანება მიმწოდებლის კონფიგურაციის ექსპორტის/იმპორტის ინსტრუმენტების გამოყენებით.
- (e) მიგრაციის ტესტირება: საწარმოო გადართვამდე წინასწარი (Staging) გარემოში სრულდება მიგრაციის მინიმუმ ორი (2) სრული საცდელი გაშვება. თითოეული საცდელი გაშვება მოიცავს მონაცემთა მთლიანობის შემოწმებას (რეფერენციული, გამოთვლითი, დროითი), აპლიკაციის დონეზე სწრაფ ტესტირებას (smoke testing) და წარმადობის შედარებით შეფასებას.
- (f) გადართვის შესრულება: მომდევნო ვერსიაზე საწარმოო გადართვა წინასწარ შეთანხმებულ ტექნიკური მომსახურების ფანჯარაში, მათ შორის DNS/ქსელის გადართვა, მონაცემთა ბაზის გადართვა, გადართვის შემდგომი შემოწმება და უკუსვლის (rollback) მზადყოფნა.
- (g) გაძლიერებული მხარდაჭერის (hypercare) პერიოდი: მიგრაციის შემდგომი გაძლიერებული მხარდაჭერა მინიმუმ ოცდაათი (30) კალენდარული დღის განმავლობაში, რომლის ფარგლებშიც მიმწოდებელი ნიშნავს მიგრაციის ხელმძღვანელს და გამოყოფს სამხარდაჭერო რესურსებს პრიორიტეტული ინციდენტების გადაწყვეტისა და სტაბილიზაციისთვის.
10.5.2 მონაცემთა მიგრაციის მთლიანობის უზრუნველყოფა
მიმწოდებელი მიგრაციის მთელი პროცესის განმავლობაში იყენებს მონაცემთა მთლიანობის შემდეგ კონტროლებს, თავში 5 (პროგრამული უზრუნველყოფის ხარისხი და ტესტირება) განსაზღვრული AI-ით გაძლიერებული ტესტირების ჩარჩოს შესაბამისად:
- (a) მიგრაციამდე საბაზისო მდგომარეობა: მიგრაციის დაწყებამდე უშუალოდ ფიქსირდება მთლიანი მონაცემთა ბაზის კრიპტოგრაფიული ჰეში (SHA-256) და ჩანაწერების რაოდენობის ინვენტარიზაცია, რითაც დადგენილი ხდება მონაცემთა მთლიანობის საბაზისო მდგომარეობა.
- (b) მიგრაციის შემდგომი შედარება: მომდევნო ვერსიის მონაცემთა ბაზაზე სრულდება ჩანაწერების რაოდენობის შედარება, რეფერენციული მთლიანობის შემოწმები და გამოთვლითი მთლიანობის შემოწმები. მიგრაციის შემდგომი ჰეში დარებდება მიგრაციამდე საბაზისო მდგომარეობას.
- (c) AI აგენტით ვალიდაცია (ნებაყოფილი): თუ დამკვეთმა აირჩია AI-ით გაძლიერებული ტესტირების მომსახურება (თავი 5), მიმწოდებელი მომდევნო ვერსიის გარემოში ამუშავებს AI აგენტებს თავიდან ბოლომდე (end-to-end) სიმულაციური სცენარების შესასრულებლად, მონაცემთა ნაკადების, ბიზნეს წესებისა და ინტეგრაციის წერტილების ვალიდაციისთვის.
- (d) მიგრაციის დამტკიცება: დამკვეთი ატარებს UAT-ს მომდევნო ვერსიის გარემოში. საწარმოო გადართვამდე საჭიროა დამკვეთის წერილობითი დამტკიცება, თავი 5-ის §5.8-ში განსაზღვრული UAT მოთხოვნების შესაბამისად.
10.6 ინტეგრაციებისა და ინდივიდუალური მორგებების ადაპტაცია
ძირითად ვერსიებზე გადასვლამ შესაძლოა გავლენა მოახდინოს დამკვეთისთვის სპეციფიკურ ინტეგრაციებზე, ინდივიდუალურ მორგებებსა და მესამე მხარის გაფართოებებზე. მიმწოდებელი ამ გადასვლას მართავს ადაპტაციის სტრუქტურირებული პროგრამის მეშვეობით:
10.6.1 ინტეგრაციებზე ზეგავლენის შეფასება
EOL-ის გამოცხადებიდან ოცდაათი (30) კალენდარული დღის ვადაში მიმწოდებელი დამკვეთს წარუდგენს ინტეგრაციებზე ზეგავლენის შეფასებას, რომელიც მოიცავს:
- (a) API-ების თავსებადობის ანალიზს: ძველ ვერსიაში გამოყენებული დამკვეთისთვის ხელმისაწვდომი ყველა API-ს შესაბამისობას მომდევნო ვერსიის ეკვივალენტებთან, რაც ავლენს თავსებადობის დამრღვევ ცვლილებებს, მოძველებულ წერტილებს (endpoints) და ახალ შესაძლებლობებს.
- (b) მესამე მხარის ინტეგრაციების ინვენტარიზაციას: ყველა აქტიური ინტეგრაციის (შუალედური პროგრამული უზრუნველყოფა, B2G კონექტორები, სატრანსპორტო API-ები, საბანკო ინტერფეისები, მესამე მხარის ანგარიშგების ინსტრუმენტები) კატალოგს მომდევნო ვერსიასთან თავსებადობის სტატუსის მითითებით.
- (c) ინდივიდუალური მორგებების რეესტრს: დამკვეთისთვის სპეციფიკური ინდივიდუალური მორგებების (კომპილირებული DLL-ები, სპეციალური SQL ფუნქციები, ინდივიდუალური ანგარიშები, სამუშაო ნაკადების გაფართოებები) სრულ ინვენტარიზაციას მიგრაციის გზის კლასიფიკაციით: (i) თავსებადია მომდევნო ვერსიასთან, (ii) საჭიროებს ხელახალ შემუშავებას, (iii) მოძველებულია / ხელმისაწვდომია ჩანაცვლება.
- (d) სამუშაო მოცულობის შეფასებას და გრაფიკს: შეუთავსებელი ინტეგრაციებისა და ინდივიდუალური მორგებების ხელახალი შემუშავების სავარაუდო სამუშაო მოცულობა (კაც-დღეები) და გრაფიკი, სტანდარტული ფარგლების (შედის ფასში) და გაფართოებული ფარგლების (ცალკე ფასდება) გამიჯვნით.
10.6.2 ხელახალი შემუშავება და ვალიდაცია
„საჭიროებს ხელახალ შემუშავებას“ კატეგორიის ინტეგრაციებისა და ინდივიდუალური მორგებებისთვის:
- (a) მიმწოდებლის მიერ მართული ხელახალი შემუშავება: თუ ინდივიდუალური მორგება თავდაპირველად მიმწოდებლის მიერ შეიქმნა (დაფიქსირებულია Git რეპოზიტორიაში დამკვეთის კლიენტის ტოტში — Client Branch), მიმწოდებელი კომპონენტს ხელახლა შეიმუშავებს და გატესტავს დამატებითი ღირებულების გარეშე, სტანდარტული მიგრაციის ფარგლებში.
- (b) დამკვეთის ან მესამე მხარის მიერ მართული ინტეგრაციები: თუ ინტეგრაცია დამკვეთის ან მესამე მხარის მიერ შეიქმნა, მიმწოდებელი (i) წარადგენს მომდევნო ვერსიის API-ის ტექნიკურ დოკუმენტაციას, (ii) ტესტირებისთვის ხელმისაწვდომს გახდის წინასწარ (Staging) გარემოს და (iii) სთავაზობს ნებაყოფილ პროფესიულ დახმარებას დროისა და მასალების (time-and-materials) საფუძველზე.
- (c) ინტეგრაციების რეგრესიული ტესტირება: ყველა მიგრირებული ინტეგრაცია საწარმოო გადართვამდე გადის ავტომატიზებულ რეგრესიულ ტესტირებას წინასწარ (Staging) გარემოში, AI აგენტების ჩარჩოს (თავი 5) ან შეთანხმებისამებრ ხელით შესასრულებელი ტესტირების სკრიპტების გამოყენებით.
10.7 ხელახალი ტრენინგი და ცვლილებების მართვა
ძირითად ვერსიაზე გადასვლა წარმოადგენს პლატფორმის მნიშვნელოვან ცვლილებას და იწვევს ხელახალი ტრენინგის სავალდებულო ვალდებულებებს თავი 6-ის (ტრენინგი და ცოდნის გადაცემა) შესაბამისად. მიმწოდებელი ახორციელებს მორგებულ გადასვლის სატრენინგო პროგრამას, რომელიც მოიცავს:
10.7.1 სატრენინგო საჭიროებების ხელახალი შეფასება
EOL-ის გამოცხადებიდან სამოცი (60) კალენდარული დღის ვადაში მიმწოდებელი ატარებს სატრენინგო საჭიროებების ხელახალ შეფასებას (TNRA) შემდეგის გამოსავლენად:
- (a) მომდევნო ვერსიაში ახალი ან შეცვლილი UI ელემენტები, სამუშაო ნაკადები და ნავიგაციის სტრუქტურა.
- (b) მოძველებული ფუნქციები და მათი ჩანაცვლებები.
- (c) მომდევნო ვერსიით უზრუნველყოფილი ახალი შესაძლებლობები (საჭიროების შემთხვევაში AI-ზე დაფუძნებული ფუნქციების ჩათვლით).
- (d) როლების მიხედვით სატრენინგო მოთხოვნები დამკვეთის აქტიური მოდულების კონფიგურაციისა და ორგანიზაციული სტრუქტურის საფუძველზე. TNRA-ს შედეგია გადასვლის სატრენინგო გეგმა, რომელიც ერთვის მიგრაციის გეგმას დანართის სახით და განსაზღვრავს სესიებს, ხანგრძლივობას, ჩატარების მეთოდებს და სამიზნე აუდიტორიას.
10.7.2 გადასვლის სატრენინგო პროგრამა
| ტრენინგის კომპონენტი | აუდიტორია | ფორმატი | ვადა | ხანგრძლივობა |
|---|---|---|---|---|
| ბრიფინგი „რა არის ახალი“ | ყველა ავტორიზებული მომხმარებელი | ვებინარი (ჩაწერილი + AI-ით ტრანსკრიფციით) | T−6 თვე | 90 წუთი |
| პრაქტიკული სამუშაო შეხვედრა: ძირითადი ცვლილებები | სუპერ-მომხმარებლები + ჩემპიონები | ინსტრუქტორის მიერ წარმართული (ონლაინ ან ადგილზე) | T−5-დან T−4 თვემდე | 2–3 დღე მოდულების თითოეულ ჯგუფზე |
| ჩემპიონების ხელახალი სერტიფიცირება | DANAOS ProjectVIEW ERP-ის ჩემპიონები | ინსტრუქტორის მიერ წარმართული + გამოცდა | T−4-დან T−3 თვემდე | 1 დღე თითოეულ ჩემპიონზე |
| ინტეგრაციისა და API-ს სამუშაო შეხვედრა | დამკვეთის IT / ინტეგრაციის გუნდი | ტექნიკური სამუშაო შეხვედრა (ონლაინ) | T−4 თვე | 1 დღე |
| UAT-ის საორიენტაციო სესია | UAT-ის მონაწილეები | ინსტრუქტორის მიერ წარმართული ბრიფინგი | T−2 თვე | ნახევარი დღე |
| გაშვებისთვის (Go-Live) მზადყოფნის შემოწმება | ჩემპიონები + დამკვეთის IT ხელმძღვანელი | საკონტროლო შეხვედრა | T−14 დღე | 2 საათი |
| მიგრაციის შემდგომი ღია კონსულტაციები | ყველა ავტორიზებული მომხმარებელი | ონლაინ კითხვა-პასუხი (ორ კვირაში ერთხელ) | T + 0-დან T + 90 დღემდე | 1 საათი თითოეულ სესიაზე |
გადასვლის ყველა სატრენინგო სესია იწერება და იშიფრება AI-ის მეშვეობით თავი 6-ის §6.4.4-ის შესაბამისად. ჩანაწერები და ტრანსკრიფციები ქვეყნდება დამკვეთის კლიენტის სატრენინგო ვიკიში (https://docs.projectview.wiki/[client]) თითოეული სესიიდან ხუთი (5) სამუშაო დღის ვადაში.
10.7.3 ცოდნის ბაზის განახლება
მომდევნო ვერსიაზე საწარმოო გადართვამდე მიმწოდებელი ახლებს შემდეგ საცნობარო რესურსებს:
- (a) კლიენტის სატრენინგო ვიკი: ყველა მოდულის გვერდი, პროცესების სახელმძღვანელო და FAQ სტატია იახლება მომდევნო ვერსიის UI-ს, სამუშაო ნაკადებისა და ტერმინოლოგიის ასასახად.
- (b) პლატფორმის რელიზების ცენტრი: მომდევნო ვერსიის რელიზის ჩანაწერები, განთავსების სახელმძღვანელოები და კონფიგურაციის ცნობარები ქვეყნდება რელიზების ცენტრში.
- (c) აპლიკაციის შიდა მითითებები: კონტექსტური მინიშნებები (tooltips), დახმარების ბმულები და AI-ის მხარდაჭერით მოწოდებული მითითებები იახლება მომდევნო ვერსიის ფუნქციონალს დასაყრდნობად.
10.8 დამკვეთის გადაწყვეტილება: გადასვლა ან შეწყვეტა
EOL-ის თარიღამდე არაუგვიანეს ექვსი (6) თვით ადრე (ანუ T−6 თვე), დამკვეთი ოფიციალურად აცნობებს მიმწოდებელს თავის არჩევანს შემდეგ ვარიანტებს შორის:
- (a) ვარიანტი A — გადასვლა: მომდევნო ვერსიაზე მიგრაციის გაგრძელება. მიმწოდებელი ახორციელებს მიგრაციის მომსახურებას (§10.5), ინტეგრაციების ადაპტაციას (§10.6) და ხელახალ ტრენინგს (§10.7). გამოწერა უწყვეტად გრძელდება მომდევნო ვერსიაზე მოქმედი კომერციული პირობებით (თუ ისინი ურთიერთი წერილობითი შეთანხმებით არ შეიცვლება).
- (b) ვარიანტი B — გამოწერის შეწყვეტა: გადასვლაზე უარის თქმა. მიმწოდებელი იწყებს გამოწერის შეწყვეტის პროცესს (§10.9), მათ შორის მონაცემთა დაბრუნებას (§10.10), გარემოს ექსპლუატაციიდან გამოყვანას (§10.11) და სახელშეკრულებო ურთიერთობის შეწყვეტას (§10.12). გამოწერა წყდება EOL-ის თარიღში (ან გაფართოებული მხარდაჭერის ვადის გასვლის თარიღში, თუ ის არჩეულია). თუ დამკვეთი T−6 ვადის გასვლამდე არ წარადგენს წერილობით შეტყობინებას, მიმწოდებელი უგზავნის შემხსენებელ შეტყობინებას. თუ დამატებითი ოცდაათი (30) კალენდარული დღის განმავლობაში პასუხი არ იქნება მიღებული, მიმწოდებელი მიიჩნევს, რომ დამკვეთმა აირჩია ვარიანტი A (გადასვლა), და მიგრაციის მომსახურება გაგრძელდება.
10.9 გამოწერის შეწყვეტის პროცესი
თუ დამკვეთი ირჩევს ვარიანტ B-ს (გამოწერის შეწყვეტა), გამოიყენება შემდეგი პროცესი:
| ფაზა | ვადა | საქმიანობა | პასუხისმგებელი |
|---|---|---|---|
| 1. შეწყვეტის შეტყობინება | T−6 თვე (დამკვეთის არჩევანი) | დამკვეთი წერილობით აცნობებს გადასვლაზე უარის თქმის გადაწყვეტილებას. მიმწოდებელი მიღებას ადასტურებს 2 სამუშაო დღის ვადაში. | დამკვეთი → ანგარიშის მენეჯერი |
| 2. შეწყვეტის დაგეგმვა | T−6-დან T−5 თვემდე | მიმწოდებელი და დამკვეთი ათანხმებენ შეწყვეტის გეგმას, რომელიც მოიცავს: მონაცემთა ექსპორტის ფორმატ(ებ)ს, გრაფიკს, საკონტაქტო პირების გადაცემას, ღია მოთხოვნების (tickets) გადაწყვეტას და გარემოს ეტაპობრივი გათიშვის გრაფიკს. | ანგარიშის მენეჯერი + Cloud Ops-ის ხელმძღვანელი |
| 3. მონაცემთა ექსპორტი და დაბრუნება | T−5-დან T−2 თვემდე | მიმწოდებელი დამკვეთის ყველა მონაცემს აექსპორტებს შეთანხმებულ ფორმატ(ებ)ში თითოეული საფუძვლიანი მოთხოვნიდან 2 სამუშაო დღის ვადაში (§10.10). დაშვებულია ექსპორტის რამდენიმე მოთხოვნა. | DBA + Cloud Ops |
| 4. დამკვეთის მიერ ვალიდაცია | T−2-დან T−1 თვემდე | დამკვეთი ამოწმებს ექსპორტირებული მონაცემების სისრულესა და მთლიანობას. მონაცემთა სისრულესთან დაკავშირებულ პრეტენზიებს (ასეთის არსებობის შემთხვევაში) წარადგენს მიღებიდან 14 კალენდარული დღის ვადაში. | დამკვეთის IT ხელმძღვანელი |
| 5. ღია მოთხოვნების გადაწყვეტა | T−3 თვიდან T−30 დღემდე | მიმწოდებელი წყვეტს ყველა ღია P1/P2 ინციდენტს. უფრო დაბალი პრიორიტეტის მოთხოვნები იხურება დამკვეთთან შეთანხმებით ან დოკუმენტირდება როგორც გადაუწყვეტელი. | Cloud Ops + ანგარიშის მენეჯერი |
| 6. გარემოს ექსპლუატაციიდან გამოყვანა | T = EOL-ის თარიღი | ძველი გარემო გამოიყვანება ექსპლუატაციიდან: VM-ების გათიშვა, მონაცემთა ბაზის წაშლა, საცავის ანგარიშის (storage account) გასუფთავება, დაშიფვრის გასაღებების განადგურება (§10.11). | Cloud Ops + DBA |
| 7. ექსპლუატაციიდან გამოყვანის სერტიფიკატი | T + 14 დღე | მიმწოდებელი გასცემს ექსპლუატაციიდან გამოყვანის სერტიფიკატს, რომელიც ადასტურებს, რომ დამკვეთის ყველა მონაცემი უსაფრთხოდ განადგურდა NIST SP 800-88-ის შესაბამისად. | CTO → დამკვეთი |
| 8. სახელშეკრულებო ურთიერთობის შეწყვეტა | T + 30 დღე | შეთანხმება ოფიციალურად წყდება. ძალაში დარჩენილი დებულებები (კონფიდენციალურობა, ინტელექტუალური საკუთრება, პასუხისმგებლობის შეზღუდვა, მონაცემთა დაცვის ნარჩენი ვალდებულებები) გრძელდება §10.12-ის შესაბამისად. | იურიდიული სამსახური / ანგარიშის მენეჯერი |
10.10 მონაცემთა დაბრუნება
დამკვეთი ყოველთვის ინარჩუნებს დამკვეთის ყველა მონაცემზე ერთადერთ და განსაკუთრებულ საკუთროებას (თავი 9, §9.9). გამოწერის შეწყვეტისას მიმწოდებლის ვალდებულებები მონაცემთა დაბრუნებასთან დაკავშირებით შემდეგია:
10.10.1 ექსპორტის ფორმატები და მიწოდება
- (a) სტანდარტული ექსპორტის ფორმატები: SQL Server-ის სარეზერვო ფაილი (.bak), CSV, JSON და/ან XML. დამკვეთს შეუძლია მოითხოვოს ფორმატების ნებისმიერი კომბინაცია.
- (b) მიწოდების ვადა: დამკვეთისგან საფუძვლიანი წერილობითი მოთხოვნის მიღებიდან ორი (2) სამუშაო დღის ვადაში.
- (c) მიწოდების მეთოდი: დაშიფრული უსაფრთხო გადაცემა დამკვეთის მიერ დასახელებული SFTP წერტილის, Azure Blob Storage SAS ტოკენის ან დაშიფრული ფიზიკური მატარებლის მეშვეობით (კურიერით მიწოდებული, შენახვის ჯაჭვის დოკუმენტაციის თანხლებით).
- (d) ექსპორტის ფარგლები: დამკვეთის ყველა მონაცემი, მათ შორის: ძირითადი (master) მონაცემები, ტრანზაქციული მონაცემები, კონფიგურაციული მონაცემები, აუდიტის კვალი, ცვლილებების აღრიცხვის ჩანაწერები, დოკუმენტების დანართები (blob საცავი) და აპლიკაციის მიერ გენერირებული ანგარიშები.
- (e) მრავალჯერადი ექსპორტი: დამკვეთს შეუძლია შეწყვეტის პერიოდში მოითხოვოს მრავალჯერადი ექსპორტი. თითოეული მოთხოვნა სრულდება 2 სამუშაო დღის ვადაში.
10.10.2 დაბრუნებული მონაცემების ვალიდაცია
მონაცემთა თითოეული ექსპორტის შემდეგ:
- (a) მთლიანობის ჰეში: მიმწოდებელი თითოეული ექსპორტირებული მონაცემთა კრებულისთვის წარადგენს SHA-256 კრიპტოგრაფიულ ჰეშს, რაც დამკვეთს საშუალებას აძლევს, მიღებისას გადაამოწმოს მონაცემთა მთლიანობა.
- (b) ჩანაწერების რაოდენობის სერტიფიკატი: მიმწოდებელი წარადგენს სერტიფიკატს, რომელშიც მითითებულია ჩანაწერების რაოდენობა ექსპორტის თითოეული ცხრილის/ობიექტისთვის და შედარებულია საწარმოო მონაცემთა ბაზასთან ექსპორტის მომენტის მდგომარეობით.
- (c) ვალიდაციის პერიოდი: დამკვეთს მიღებიდან თოთხმეტი (14) კალენდარული დღე აქვს მონაცემთა სისრულესთან ან მთლიანობასთან დაკავშირებით პრეტენზიის წასაყენებლად. მიმწოდებელი საფუძვლიანი პრეტენზიიდან ორი (2) სამუშაო დღის ვადაში აღმოფხვრის ხარვეზს და ხელახლა აექსპორტებს მონაცემებს.
- (d) მიღებულად მიჩნევა: თუ დამკვეთი 14-დღიანი ვალიდაციის პერიოდში პრეტენზიას არ წარადგენს, ექსპორტი მიღებულად ითვლება.
10.10.3 მონაცემთა დაბრუნების ღირებულება
მონაცემთა დაბრუნება სტანდარტულ ფარგლებში (ექსპორტი სტანდარტულ ფორმატებში უსაფრთხო ციფრული გადაცემის გზით) შედის გამოწერაში დამატებითი ღირებულების გარეშე. შემდეგი მომსახურება ხელმისაწვდომია დამატებით საფასურად, დროისა და მასალების (time-and-materials) საფუძველზე:
- (a) ექსპორტირებული მონაცემების ტრანსფორმაცია არასტანდარტულ ფორმატებში (მაგ., სამიზნე სისტემისთვის სპეციფიკური სქემის ტრანსფორმაციები მომდევნო ERP-ში ჩასატვირთად).
- (b) ფიზიკური მატარებლის მომზადება და კურიერით მიწოდება.
- (c) მონაცემთა ექსპორტის გახანგრძლივებული პერიოდი შეწყვეტის სტანდარტულ ვადებზე მეტი ხანით.
- (d) ტექნიკური კონსულტაცია მონაცემთა შესაბამისობის (mapping), მიგრაციის სკრიპტების ან ETL-ის დიზაინის შესახებ დამკვეთის მომდევნო სისტემისთვის.
10.11 გარემოს ექსპლუატაციიდან გამოყვანა
მონაცემთა დაბრუნების დასრულებისა და დამკვეთის ვალიდაციის პერიოდის ამოწურვის შემდეგ მიმწოდებელი ექსპლუატაციიდან გამოიყვანს დამკვეთის გამოყოფილ კერძო სუვერენულ გარემოს:
- (a) ვირტუალური მანქანების გათიშვა: დამკვეთის ყველა VM (საწარმოო და წინასწარი) ჩერდება, დისკის ასლები იშლება და გამოთვლითი რესურსები თავისუფლდება.
- (b) მონაცემთა ბაზების განადგურება: SQL Server-ის ყველა მონაცემთა ბაზა (საწარმოო, წინასწარი, სარეზერვო ასლები) სამუდამოდ იშლება. Azure Backup Vault-ში ტრანზაქციების ჟურნალები და სარეზერვო ფაილები სუფთავდება.
- (c) საცავის ანგარიშების გასუფთავება: დამკვეთთან დაკავშირებული ყველა Azure Blob Storage კონტეინერი, ფაილების საერთო რესურსი და ცხრილების საცავი სამუდამოდ იშლება, მათ შორის GRS-ით რეპლიცირებული ასლები მეორად რეგიონში.
- (d) დაშიფვრის გასაღებების განადგურება: Azure Key Vault-ში დამკვეთისთვის სპეციფიკური ყველა დაშიფვრის გასაღები, საიდუმლო მნიშვნელობა და სერტიფიკატი სუფთავდება (გასუფთავებისგან დაცვის გაუქმება ავტორიზებულია CTO-ს მიერ).
- (e) ქსელის გასუფთავება: დამკვეთთან დაკავშირებული ვირტუალური ქსელები, NSG-ები, საჯარო IP მისამართები, DNS ჩანაწერები და SSL/TLS სერტიფიკატები გამოიყვანება და უქმდება.
- (f) CMDB-ს განახლება: დამკვეთთან დაკავშირებული ყველა კონფიგურაციული ელემენტი მიმწოდებლის CMDB-ში აღინიშნება როგორც ექსპლუატაციიდან გამოყვანილი.
- (g) მონაცემთა უსაფრთხო განადგურება: მონაცემთა განადგურება მთლიანად ხორციელდება NIST SP 800-88-ის (მედია-მატარებლების გასუფთავების სახელმძღვანელო) შესაბამისად. Azure-ის კრიპტოგრაფიული წაშლა უზრუნველყოფს, რომ ექსპლუატაციიდან გამოყვანილ საცავზე არსებული მონაცემების აღდგენა შეუძლებელია.
NIST SP 800-88 Rev. 1: მედია-მატარებლების გასუფთავების სახელმძღვანელო (Guidelines for Media Sanitization) Azure: მონაცემთა განადგურება
10.12 ძალაში დარჩენილი ვალდებულებები
შემდეგი ვალდებულებები ძალაში რჩება ჩარჩო-დოკუმენტის შეწყვეტის ან ვადის ამოწურვის შემდეგაც და ინარჩუნებს სრულ იურიდიულ ძალას:
- (a) კონფიდენციალურობა: კონფიდენციალურობის ორმხრივი ვალდებულებები ძალაში რჩება შეწყვეტის თარიღიდან ხუთი (5) წლის განმავლობაში (თავი 8, §8.11).
- (b) ინტელექტუალური საკუთრება: ინტელექტუალური საკუთრების ყველა უფლება და სალიცენზიო შეზღუდვები ძალაში რჩება ვადის გარეშე.
- (c) მონაცემთა დაცვის ნარჩენი ვალდებულებები: თავი 7-ით გათვალისწინებული კერძო ცხოვრების დაცვის ვალდებულებები ძალაში რჩება როგორც ეს ეხება სამართლებრივი ან რეგულაციური ვალდებულების შესაბამისად მიმწოდებლის მიერ შენახულ ნებისმიერ პერსონალურ მონაცემს (თავი 7, §7.13).
- (d) პასუხისმგებლობის შეზღუდვა: პასუხისმგებლობის ზღვრები და გამონაკლისები კვლავ ვრცელდება გამოწერის ვადის განმავლობაში მომხდარი მოვლენებიდან წარმოშობილ მოთხოვნებზე.
- (e) დავების გადაწყვეტა: მოქმედი სამართალი და დავების გადაწყვეტის დებულებები კვლავ ვრცელდება ჩარჩო-დოკუმენტიდან ან მასთან დაკავშირებით წარმოშობილ ნებისმიერ მოთხოვნაზე.
- (f) აუდიტის უფლებები: დამკვეთის უფლება, ჩაატაროს მონაცემთა განადგურების შესაბამისობის აუდიტი, ძალაში რჩება ექსპლუატაციიდან გამოყვანის სერტიფიკატის თარიღიდან თორმეტი (12) თვის განმავლობაში.
10.13 გაფართოებული მხარდაჭერის ვარიანტი
SAP-ის (Extended Maintenance), Oracle-ის (Sustaining Support), IFS-ის (Extended Maintenance) და Infor-ის (Extended Maintenance) გაფართოებული მხარდაჭერის მოდელების შესაბამისად, მიმწოდებელი იმ დამკვეთებს, რომლებსაც გადასვლის დასასრულებლად დამატებითი დრო სჭირდებათ, სთავაზობს ნებაყოფილი გაფართოებული მხარდაჭერის პერიოდს:
(a) ხელმისაწვდომობა: გაფართოებული მხარდაჭერა წერილობით უნდა მოითხოვოთ EOL-ის თარიღამდე არაუგვიანეს სამოცი (60) კალენდარული დღით ადრე. (b) ხანგრძლივობა: EOL-ის თარიღის შემდეგ არაუმეტეს თორმეტი (12) თვისა, კვარტლის ბიჯით. (c) ფარგლები: მხოლოდ P1 და P2 ინციდენტების გადაწყვეტა და უსაფრთხოების კრიტიკული პატჩები. ფუნქციების შემუშავება, ახალი ცვლილების მოთხოვნები და ახალი მოდულების აქტივაცია არ გადაიწყვეტა. (d) ფასი: გაფართოებული მხარდაჭერა ისახურება მოცემულ მომენტში მოქმედ ARR-ზე ოცი პროცენტით (20%) მაღალი ტარიფით, რომელიც იგადახდება კვარტლურად, წინასწარ. (e) შეწყვეტა: გაფართოებული მხარდაჭერა ავტომატურად წყდება არჩეული პერიოდის ბოლოს. გაფართოებული მხარდაჭერის ვადის ამოწურვისას გამოიყენება გამოწერის შეწყვეტის ყველა დებულება (§10.9–§10.12).
10.14 როლები და პასუხისმგებლობები (RACI მატრიცა)
შემდეგი RACI მატრიცა ანაწილებს პასუხისმგებლობებს EOL-ის ძირითადი საქმიანობებისთვის მიმწოდებლისა და დამკვეთის როლებს შორის:
| საქმიანობა | CTO | Cloud Ops-ის ხელმძღვანელი | ანგარიშის მენეჯერი | DBA-ს ხელმძღვანელი | დამკვეთის IT ხელმძღვანელი | დამკვეთის ჩემპიონები |
|---|---|---|---|---|---|---|
| EOL-ის გამოცხადების გამოქვეყნება | A | I | R | I | I | I |
| მიგრაციისთვის მზადობის შეფასება | A | R | C | R | C | I |
| ინტეგრაციებზე ზეგავლენის შეფასება | I | R | C | C | R | I |
| მონაცემთა მიგრაციის შესრულება | I | R | I | R | C | I |
| მონაცემთა მიგრაციის მთლიანობის შემოწმება | I | R | I | R | C | I |
| გადასვლის სატრენინგო პროგრამის ჩატარება | I | C | R | I | C | R |
| ჩემპიონების ხელახალი სერტიფიცირება | I | I | R | I | C | R |
| ცოდნის ბაზის განახლება | I | R | C | I | I | C |
| ინტეგრაციების ხელახალი შემუშავება | I | R | I | C | R | I |
| UAT მომდევნო ვერსიაზე | I | C | C | C | R | R |
| გადართვის დაგეგმვა და შესრულება | A | R | C | R | C | I |
| დამკვეთის გადაწყვეტილება (გადასვლა / შეწყვეტა) | I | I | C | I | R | I |
| მონაცემთა ექსპორტის შესრულება | I | R | C | R | R | I |
| დაბრუნებული მონაცემების ვალიდაცია | I | I | I | I | R | I |
| გარემოს ექსპლუატაციიდან გამოყვანა | A | R | I | R | I | I |
| ექსპლუატაციიდან გამოყვანის სერტიფიკატის გაცემა | R | C | I | C | I | I |
| გაფართოებული მხარდაჭერის მართვა | A | R | C | R | I | I |
ლეგენდა: R = შემსრულებელი (Responsible) · A = ანგარიშვალდებული (Accountable) · C = კონსულტანტი (Consulted) · I = ინფორმირებული (Informed).
10.15 პროცესების რეესტრი
შემდეგი პროცესების რეესტრი აერთიანებს წინამდებარე თავში განსაზღვრულ ყველა ოფიციალურ პროცესს.
| პროცესის ID | პროცესის დასახელება | ინიცირების საფუძველი | შემსრულებელი | დამტკიცებელი | შედეგი | პუნქტი |
|---|---|---|---|---|---|---|
| P-10.01 | EOL-ის გამოცხადება | პროდუქტის საგზაო რუკის გადაწყვეტილება ძირითადი ვერსიის სასიცოცხლო ციკლის დასრულების შესახებ | ანგარიშის მენეჯერი | CTO | EOL-ის წერილობითი გამოცხადება მიწოდებულია ყველა დაინტერესებულ დამკვეთზე EOL-ის თარიღამდე ≥ 12 თვით ადრე. | §10.4 |
| P-10.02 | მიგრაციისთვის მზადობის შეფასება | EOL-ის გამოცხადება გამოქვეყნებულია (T−11 თვე) | Cloud Ops + DBA | CTO | დამკვეთისთვის სპეციფიკური ზეგავლენის შეფასება და მიგრაციის წინასწარი გეგმა მიწოდებულია. | §10.4 |
| P-10.03 | ინტეგრაციებზე ზეგავლენის შეფასება | EOL-ის გამოცხადება გამოქვეყნებულია (30 დღის ვადაში) | Cloud Ops-ის ხელმძღვანელი | CTO | მიწოდებულია API-ების თავსებადობის ანალიზი, ინტეგრაციების ინვენტარიზაცია, ინდივიდუალური მორგებების რეესტრი და სამუშაო მოცულობის შეფასება. | §10.6.1 |
| P-10.04 | სატრენინგო საჭიროებების ხელახალი შეფასება | EOL-ის გამოცხადება გამოქვეყნებულია (60 დღის ვადაში) | ანგარიშის მენეჯერი | CTO | გადასვლის სატრენინგო გეგმა დართულია მიგრაციის გეგმას. | §10.7.1 |
| P-10.05 | მონაცემთა მიგრაციის შესრულება | მიგრაციის გეგმა დამტკიცებულია და წინასწარი (Staging) გარემო უზრუნველყოფილია | DBA + Cloud Ops | Cloud Ops-ის ხელმძღვანელი | დამკვეთის მონაცემები მიგრირებულია; მთლიანობა შემოწმებულია; საცდელი გაშვება(ები) დასრულებულია. | §10.5.1 |
| P-10.06 | მიგრაციის მთლიანობის შემოწმება | დასრულებულია მონაცემთა მიგრაციის საცდელი გაშვება ან საწარმოო გადართვა | DBA + Cloud Ops | Cloud Ops-ის ხელმძღვანელი | მიგრაციამდე/შემდგომი ჰეშების შედარება წარმატებულია; ჩანაწერების რაოდენობის შედარება დასრულებულია; მთლიანობის ანგარიში გაცემულია. | §10.5.2 |
| P-10.07 | ინტეგრაციის ხელახალი შემუშავება | ზეგავლენის შეფასებისას ინტეგრაცია კლასიფიცირებულია როგორც „საჭიროებს ხელახალ შემუშავებას“ | Cloud Ops | Cloud Ops-ის ხელმძღვანელი | ინტეგრაცია განახლებული, ტესტირებული და ვალიდირებულია მომდევნო ვერსიაზე. | §10.6.2 |
| P-10.08 | გადასვლის ტრენინგების ჩატარება | გადასვლის სატრენინგო გეგმა დამტკიცებულია | ანგარიშის მენეჯერი + ტრენერები | Cloud Ops-ის ხელმძღვანელი | ყველა დაგეგმილი სატრენინგო სესია ჩატარებულია; ჩანაწერები გამოქვეყნებულია ვიკიში. | §10.7.2 |
| P-10.09 | ჩემპიონების ხელახალი სერტიფიცირება | გადასვლის სატრენინგო პროგრამა დაგეგმილია | ანგარიშის მენეჯერი | CTO | ჩემპიონებმა ჩააბარეს მომდევნო ვერსიის გამოცდა; სერტიფიკატები გაცემულია. | §10.7.2 |
| P-10.10 | UAT მომდევნო ვერსიაზე | მიგრაციის საცდელი გაშვება წარმატებულია; ტრენინგი დასრულებულია | დამკვეთის IT ხელმძღვანელი + ჩემპიონები | დამკვეთი | მიღებულია დამკვეთის წერილობითი დამტკიცება მომდევნო ვერსიაზე. | §10.5.2 |
| P-10.11 | საწარმოო გადართვა | UAT-ის დამტკიცება მიღებულია; გადართვის ფანჯარა შეთანხმებულია | Cloud Ops + DBA | CTO | საწარმოო გარემო მუშაობს მომდევნო ვერსიაზე; უკუსვლა (rollback) ხელმისაწვდომია 72 საათის განმავლობაში. | §10.5.1 |
| P-10.12 | გაძლიერებული მხარდაჭერა (hypercare) | საწარმოო გადართვა დასრულებულია | Cloud Ops + DBA | ანგარიშის მენეჯერი | 30-დღიანი გაძლიერებული მხარდაჭერის პერიოდი უზრუნველყოფილია; სტაბილიზაცია დადასტურებულია. | §10.5.1 |
| P-10.13 | დამკვეთის მიერ შეწყვეტის არჩევა | დამკვეთის წერილობითი შეტყობინება გადასვლაზე უარის თქმის შესახებ | ანგარიშის მენეჯერი | CTO | შეწყვეტის გეგმა შეთანხმებულია; მონაცემთა ექსპორტის გრაფიკი დადასტურებულია. | §10.8 |
| P-10.14 | მონაცემთა ექსპორტი და დაბრუნება | დამკვეთის საფუძვლიანი წერილობითი მოთხოვნა შეწყვეტის პერიოდში | DBA + Cloud Ops | ანგარიშის მენეჯერი | დამკვეთის მონაცემები ექსპორტირებულია შეთანხმებულ ფორმატში 2 სამუშაო დღის ვადაში. | §10.10 |
| P-10.15 | დაბრუნებული მონაცემების ვალიდაცია | მონაცემთა ექსპორტი მიწოდებულია დამკვეთზე | დამკვეთის IT ხელმძღვანელი | დამკვეთი | დამკვეთი ადასტურებს სისრულეს 14-დღიანი ვალიდაციის პერიოდში (ან ექსპორტი მიღებულად ითვლება). | §10.10.2 |
| P-10.16 | გარემოს ექსპლუატაციიდან გამოყვანა | დაბრუნებული მონაცემების ვალიდაციის პერიოდი ამოწურულია; დადგა EOL-ის თარიღი | Cloud Ops + DBA | CTO | დამკვეთის ყველა რესურსი განადგურებულია NIST SP 800-88-ის შესაბამისად; CMDB განახლებულია. | §10.11 |
| P-10.17 | ექსპლუატაციიდან გამოყვანის სერტიფიკატი | გარემოს ექსპლუატაციიდან გამოყვანა დასრულებულია | CTO | CTO | ექსპლუატაციიდან გამოყვანის სერტიფიკატი დამკვეთს გაეცემა 14 დღის ვადაში. | §10.11 |
| P-10.18 | გაფართოებული მხარდაჭერის აქტივაცია | დამკვეთის წერილობითი მოთხოვნა EOL-ის თარიღამდე ≥60 დღით ადრე | Cloud Ops-ის ხელმძღვანელი | CTO | გაფართოებული მხარდაჭერის დანართი ხელმოწერილია; P1/P2 მხარდაჭერა გაგრძელებულია არჩეული პერიოდის განმავლობაში. | §10.13 |
10.16 პროცესის ნაკადის სქემა
ქვემოთ მოცემული ცხრაეტაპიანი სასიცოცხლო ციკლი აჩვენებს ვერსიაზე გადასვლისა და გამოწერის შეწყვეტის სრულ ნაკადს:
① EOL-ის გამოცხადება და კომუნიკაცია → ② მზადობისა და ზეგავლენის შეფასება → ③ დამკვეთის
გადაწყვეტილება (გადასვლა / შეწყვეტა)
↓
გადასვლის გზა: ④ მიგრაცია და ხელახალი შემუშავება → ⑤ ხელახალი ტრენინგი და ცვლილებების მართვა → ⑥
UAT და საწარმოო გადართვა
↓
შეწყვეტის გზა: ⑦ მონაცემთა ექსპორტი და დაბრუნება → ⑧ გარემოს ექსპლუატაციიდან გამოყვანა → ⑨ სახელშეკრულებო
ურთიერთობის შეწყვეტა
ეტაპი ① EOL-ის გამოცხადება და კომუნიკაცია: მიმწოდებელი EOL-ის ოფიციალურ გამოცხადებას აქვეყნებს EOL-ის თარიღამდე ≥12 თვით ადრე და იწყებს კომუნიკაციის სტრუქტურირებულ პროგრამას (§10.4). ყველა დამკვეთი იღებს წერილობით შეტყობინებას, ხოლო ანგარიშის მენეჯერი გეგმავს მიგრაციისთვის მზადობის შეფასებას (P-10.01).
ეტაპი ② მზადობისა და ზეგავლენის შეფასება: მიმწოდებელი EOL-ის გამოცხადებიდან 60 დღის ვადაში წარადგენს მიგრაციისთვის მზადობის შეფასებას, ინტეგრაციებზე ზეგავლენის შეფასებასა და სატრენინგო საჭიროებების ხელახალ შეფასებას (P-10.02, P-10.03, P-10.04).
ეტაპი ③ დამკვეთის გადაწყვეტილება: T−6 თვეზე დამკვეთი ოფიციალურად ირჩევს გადასვლას (ვარიანტი A) ან შეწყვეტას (ვარიანტი B). თუ შემხსენებიდან 30 დღის ვადაში პასუხი არ იქნება მიღებული, ნაგულისხმევი ვარიანტია გადასვლა (P-10.13).
ეტაპი ④ მიგრაცია და ხელახალი შემუშავება (გადასვლის გზა): მონაცემთა მიგრაცია, კონფიგურაციის მიგრაცია და ინტეგრაციების ხელახალი შემუშავება სრულდება წინასწარ (Staging) გარემოში ≥2 საცდელი გაშვებით (P-10.05, P-10.06, P-10.07).
ეტაპი ⑤ ხელახალი ტრენინგი და ცვლილებების მართვა (გადასვლის გზა): სრულდება გადასვლის სატრენინგო პროგრამა: „რა არის ახალი“ ბრიფინგები, პრაქტიკული სამუშაო შეხვედრები, ჩემპიონების ხელახალი სერტიფიცირება და ცოდნის ბაზის განახლება (P-10.08, P-10.09).
ეტაპი ⑥ UAT და საწარმოო გადართვა (გადასვლის გზა): დამკვეთი ატარებს UAT-ს მომდევნო ვერსიაზე. წერილობითი დამტკიცება იწვევს საწარმოო გადართვას, რომელსაც მოყვება 30-დღიანი გაძლიერებული მხარდაჭერის (hypercare) პერიოდი (P-10.10, P-10.11, P-10.12).
ეტაპი ⑦ მონაცემთა ექსპორტი და დაბრუნება (შეწყვეტის გზა): მიმწოდებელი დამკვეთის ყველა მონაცემს აექსპორტებს თითოეული საფუძვლიანი მოთხოვნიდან 2 სამუშაო დღის ვადაში. დაშვებულია მრავალჯერადი ექსპორტი. თითოეულ ექსპორტს თან ახლავს მთლიანობის ჰეში და ჩანაწერების რაოდენობის სერტიფიკატი (P-10.14, P-10.15).
ეტაპი ⑧ გარემოს ექსპლუატაციიდან გამოყვანა (შეწყვეტის გზა): ვალიდაციის პერიოდის ამოწურვისა და EOL-ის თარიღის დადგომისას მიმწოდებელი ანადგურებს დამკვეთის ყველა რესურსს NIST SP 800-88-ის შესაბამისად და გასცემს ექსპლუატაციიდან გამოყვანის სერტიფიკატს (P-10.16, P-10.17).
ეტაპი ⑨ სახელშეკრულებო ურთიერთობის შეწყვეტა (შეწყვეტის გზა): ჩარჩო-დოკუმენტი ოფიციალურად წყდება ექსპლუატაციიდან გამოყვანიდან 30 დღის შემდეგ. ძალაში დარჩენილი ვალდებულებები (კონფიდენციალურობა, ინტელექტუალური საკუთრება, მონაცემთა დაცვა, პასუხისმგებლობა, აუდიტის უფლებები) გრძელდება §10.12-ის შესაბამისად (P-10.18, თუ გაფართოებული მხარდაჭერა აქტიური იყო).