შეუძლია თუ არა AI-ს აღმოაჩინოს, როგორ მუშაობს საწარმო? დიახ. მაგრამ აღმოჩენა არ არის იგივე, რაც საოპერაციო ჭეშმარიტება.

 

საწარმოო AI-ის გარშემო ძლიერი ნარატივი ყალიბდება:

 

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

 

სინამდვილეში, ამაში მნიშვნელოვანი სიმართლეა.

 

პროცესების მაინინგი, task mining, object-centric process mining, საწარმოო ონტოლოგიები და აგენტური AI ისეთ ტრადიციულ Business Process Management (BPM)-სა და Robotic Process Automation (RPA)-ს სრულიად ახალ დონეზე აჰყავს.

 

თუმცა, არსებობს მნიშვნელოვანი არქიტექტურული განსხვავება, რომელიც AI-ის ნარატივმა ადვილად შეიძლება დაკარგოს:

 

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

 

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

 

1. როგორ „აკვირდება“ AI სინამდვილეში საწარმოს?

 

პირველ რიგში, AI-ს არ შეუძლია ჯადოსნურად გაიგოს, რა ხდება კომპანიის შიგნით.

 

სამაგიეროდ, მას მტკიცებულება სჭირდება.

 

პრაქტიკაში, ამ მტკიცებულების ერთ-ერთი ყველაზე მნიშვნელოვანი წყარო არის event log, რომელიც საოპერაციო სისტემების მიერ იქმნება.

 

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

 

ტრადიციული პროცესების მაინინგის event ჩვეულებრივ მოითხოვს მინიმუმ:

 

Case ID + Activity + Timestamp

 

მაგალითად:

 

PO-1057 → Purchase Requisition Created → 09:02 PO-1057 → Requisition Approved → 11:43 PO-1057 → Purchase Order Issued → 15:21 PO-1057 → Material Received → three weeks later PO-1057 → Invoice Approved → four weeks later

 

ამ მოვლენების მილიონობით ერთეულის შეგროვებით, ალგორითმებს შეუძლიათ შემდეგ აღადგინონ ის რეალური პროცესი, რომელსაც ორგანიზაცია მიჰყვებოდა.

 

ეს არის Process Mining.

 

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

 

შემდეგ მას შეუძლია გამოავლინოს:

 

• პროცესის ვარიაციები;
• ჩახერგვები;
• ციკლები და ხელახალი დამუშავება;
• უჩვეულო მიმდევრობები;
• დამტკიცების დაგვიანებები;
• შესაბამისობის გადახრები;
• დუბლირებული აქტივობები;
• და ავტომატიზაციის პოტენციური შესაძლებლობები.

 

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

 

2. მაგრამ რა ხდება ERP-ს გარეთ?

 

სწორედ აქ ავრცელებს სურათს Task Mining.

 

ბოლოს და ბოლოს, ყველა ბიზნესაქტივობა არ ქმნის სუფთა ERP მოვლენას.

 

მაგალითად, თანამშრომელმა შეიძლება:

 

გახსნას ელფოსტა → ჩამოტვირთოს Excel ფაილი → დააკოპიროს რაოდენობა → გახსნას SAP → მოძებნოს PO → გადაერთოს სხვა აპლიკაციაზე → დააკოპიროს მნიშვნელობა → დაბრუნდეს Excel-ში → გაგზავნოს დასამტკიცებელი ელფოსტა.

 

Task-mining ტექნოლოგიას, თავის მხრივ, შეუძლია ამ დესკტოპ აქტივობის ელემენტების აღბეჭდვა.

 

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

 

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

 

იმის ნაცვლად, რომ უბრალოდ აღმოაჩინოს:

 

Purchase Order Created → Purchase Order Approved

 

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

 

მოკლედ, აქედან მოდის პოპულარული იდეა იმის შესახებ, რომ AI „უყურებს, როგორ მუშაობს კომპანია“.

 

თუმცა, ეს ჯადოსნობა არ არის.

 

სინამდვილეში, ეს არსებითად არის:

 

Digital Events + User Interaction Telemetry + Context + Statistical/ML Analysis → Process Reconstruction

 

3. პროცესის მაინინგიდან ობიექტზე ორიენტირებულ პროცესის მაინინგამდე

 

თუმცა, ტრადიციულ პროცესის მაინინგს მნიშვნელოვანი შეზღუდვა აქვს.

 

პრაქტიკაში, რეალური საწარმოები არ მუშაობენ ერთი იზოლირებული „ქეისის“ გარშემო.

 

მაგალითად, შესყიდვის ორდერი შეიძლება ერთდროულად უკავშირდებოდეს:

 

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

 

თანამედროვე Object-Centric Process Mining (OCPM) ცდილობს შეინარჩუნოს ეს ურთიერთობები.

 

ერთი Case ID-ის გარშემო მხოლოდ ხაზოვანი თანმიმდევრობის აღდგენის ნაცვლად, ის მოდელირებს ურთიერთქმედებებს მრავალ ბიზნესობიექტს შორის.

 

შედეგად, მოდელი უფრო ახლოს მოდის:

 

Supplier ↔ PO ↔ Material ↔ Invoice ↔ Delivery ↔ Project

 

ეს მნიშვნელოვანი განვითარებაა, რადგან საწარმოს რეალობა რელაციურია და არა უბრალოდ თანმიმდევრული.

 

4. შემდეგ მოდის სემანტიკური ან ონტოლოგიური ფენა

 

შემდეგ ისეთი პლატფორმები, როგორიცაა Palantir, კიდევ ერთ ნაბიჯს დგამენ.

 

ისინი შეუძლიათ ERP, CRM, MES, SCM, მონაცემთა ბაზებიდან, დოკუმენტებიდან და გარე სისტემებიდან მიღებული მონაცემების გარდაქმნა საწარმოს ობიექტებად.

 

შედეგად, მონაცემთა ბაზის ჩანაწერი ხდება რაღაც მნიშვნელობიანი:

 

• Supplier
• Purchase Order
• Employee
• Machine
• Project
• Invoice

 

შემდეგ პლატფორმა ამ ობიექტებს შორის ურთიერთობებს ამყარებს.

 

მაგალითად:

 

• Supplier → supplies → Material
• Material → required by → Project
• შესყიდვის შეკვეთა → გაიცემა → მომწოდებელზე
• Invoice → references → Purchase Order
• Machine → allocated to → Project

 

ამ გზით პლატფორმა ქმნის საწარმოს მანქანით წაკითხვად წარმოდგენას.

 

შემდეგი ფენა ამატებს:

 

• Data + Logic + Actions + Security

 

შესაბამისად, AI აგენტი აღარ მხოლოდ მონაცემთა ბაზის ჩანაწერს იღებს.

 

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

 

ეს უაღრესად ძლიერია.

 

მაგრამ ერთი მნიშვნელოვანი რამ უნდა შევამჩნიოთ:

 

საიდან წარმოიშვა ამ საწარმოო ობიექტებისა და ტრანზაქციების უმეტესობა?

 

ხშირად ERP, CRM, SCM, MES, HR, პროექტების მართვის და სხვა ოპერაციული სისტემებიდან.

 

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

 

თუმცა, ეს სულაც არ გამორიცხავს იმ სისტემებს, რომლებიც ამ რეალობას ქმნიან.

 

5. როგორ მოწმდება მონაცემები?

 

ალბათ ეს დისკუსიის ყველაზე მნიშვნელოვანი ნაწილია.

 

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

 

ამიტომ მონაცემთა ინჟინერიის pipeline-ები იყენებენ ისეთ მექანიზმებს, როგორიცაა:

 

• Schema validation — შემომავალ მონაცემს აქვს მოსალოდნელი სტრუქტურა?
• Type validation — რაოდენობა რიცხვითია, თარიღი ნამდვილად თარიღია, ვალუტა სწორად არის წარმოდგენილი?
• Completeness checks — აკლია სავალდებულო ველები?
• Uniqueness checks — ჩნდება დუბლირებული ობიექტები?
• Referential checks — ნამდვილად არსებობს ეს მომწოდებელი, PO, თანამშრომელი ან პროექტი?
• Transformation rules — როგორ უნდა მოახდინოს pipeline-მა სხვადასხვა წყაროს სისტემის ფორმატების ნორმალიზება?
• Data lineage — საიდან წარმოიშვა ეს მნიშვნელობა და რომელმა გარდაქმნებმა შექმნა ის?
• Health checks — შეწყდა თუ არა მონაცემების შემოსვლა, შეიცვალა თუ არა მოულოდნელად ან დაარღვია თუ არა განსაზღვრული მოლოდინები?

 

პროცესის დონეზე გუნდები იყენებენ კიდევ ერთ მნიშვნელოვან ტექნიკას:

 

Conformance Checking

 

აქ პლატფორმა ადარებს აღმოჩენილ პროცესს მოსალოდნელ ან დამტკიცებულ პროცესის მოდელს.

 

მაგალითად:

 

Expected

 

• Requisition → Approval → PO → Receipt → Invoice → Payment

 

Observed

 

Requisition → PO → Receipt → Invoice → Approval → Payment

 

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

 

ცხადია, ეს უაღრესად სასარგებლოა.

 

თუმცა, ეს მნიშვნელოვან ფილოსოფიურ საკითხს აჩენს.

 

საიდან მოდის „სწორი“ პროცესის განსაზღვრება?

 

საბოლოოდ, ვინმემ უნდა განსაზღვროს ბიზნესწესი.

 

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

 

მაგრამ სიხშირე არ ადგენს სისწორეს.

 

თუ 5,000 თანამშრომელი განმეორებით ასრულებს ერთსა და იმავე workaround-ს, AI შესაძლოა წარმატებით აღმოაჩინოს დომინანტური პროცესი.

 

ამ შემთხვევაში, მას აღმოუჩენია ორგანიზაციული ქცევა.

 

თუმცა, მას სულაც არ აღმოუჩენია ორგანიზაციული პოლიტიკა.

 

6. ეს არის გადამწყვეტი განსხვავება დაკვირვებასა და ტრანზაქციის გენერირებას შორის

 

მაგალითად, განვიხილოთ შესყიდვები.

 

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

 

Material Request → Approval → RFQ → Evaluation → PO → Delivery → Invoice

 

მაგრამ ოპერაციულმა პლატფორმამ რეალურად უნდა შექმნას და გააკონტროლოს:

 

• Material ID
• Requested Quantity
• Approved Quantity
• Budget Availability
• Supplier
• Currency
• Unit Price
• Tax
• Contract Terms
• Approval Authority
• Committed Cost
• Inventory Movement
• Accounting Posting

 

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

 

ამის ნაცვლად, ისინი უნდა შეესაბამებოდეს წინასწარ განსაზღვრულ წესებს, უფლებებს, master data-ს, ბიუჯეტებს და ბუღალტრულ სტრუქტურებს.

 

ამ მიზეზით, საწარმოს სისტემები განზრახ დეტერმინისტულია.

 

კონტროლირებადი ტრანზაქციისთვის:

 

Validated Input + Approved Business Rules = Predictable Transaction

 

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

 

ეს არის კონტროლის მექანიზმი.

 

7. შესაბამისად, AI ქმნის ახალ ფენას და არა აუცილებლად ჩანაცვლების ფენას

 

მარტივი სიტყვებით, ახალი საწარმოო არქიტექტურა დაახლოებით ასე გამოიყურება:

 

ჩანაწერების სისტემები ERP | CRM | SCM | MES | HR | პროექტის სისტემები

 

↓

 

Operational Transactions & Event Logs

↓

 

Integration / Data Fabric

 

↓

 

Process & Task Mining

 

↓

 

Semantic / Ontology Layer

 

↓

 

AI Reasoning & Prediction

 

↓

 

AI Agents & Orchestration

 

↓

 

Controlled Action

 

↓

 

Operational Systems

 

შედეგად, ეს ქმნის დახურულ ინტელექტუალურ ციკლს.

 

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

 

ამიტომ საწარმოში AI რევოლუცია უბრალოდ არ ნიშნავს:

 

AI ცვლის ERP-ს.

 

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

 

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

 

8. მაშ, რა არის განსხვავებული ProjectVIEW ERP-ში?

 

ProjectVIEW პრობლემას საპირისპირო მიმართულებიდან უდგება.

 

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

 

კერძოდ, მისი ფუნდამენტური არქიტექტურა აერთიანებს:

 

BoQ ↔ WBS ↔ Cost Codes

 

ეს წარმოადგენს პროექტის რეალობის სამ განსხვავებულ განზომილებას:

 

BoQ = Scope / Commercial Structure

 

რისი აშენება გვაქვს კონტრაქტით ნაკისრი და რა რაოდენობებსა და ღირებულებებს მოიცავს იგი?

 

WBS = Time / Execution Structure

 

როდის და რომელი აქტივობებით ავაშენებთ მას?

 

Cost Codes = Cost / Resource Structure

 

რომელი რესურსები და ხარჯები იხარჯება მისი მიწოდებისთვის?

 

მნიშვნელოვანია, რომ კონტრაქტორი ურთიერთობებს შესრულებამდე განსაზღვრავს.

 

შემდეგ შესრულებისას გენერირებული ტრანზაქციები ამ პროექტულ კონტექსტს იძენს.

 

ამიტომ მასალების ტრანზაქცია არ არის მხოლოდ:

 

20 tonnes of steel consumed.

 

ამის ნაცვლად, ის შეიძლება გახდეს:

 

20 tonnes steel → Project X → BoQ Item Y → WBS Activity Z → Cost Code C

 

ეს განსხვავება ფუნდამენტურია.

 

9. ProjectVIEW ქმნის სტრუქტურირებულ ოპერაციულ მონაცემებს წყაროშივე

 

განვიხილოთ განსხვავება.

 

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

 

თანამშრომელმა A მოითხოვა ფოლადი.

 

შემდეგ თანამშრომელმა B რაღაც დაამტკიცა.

 

შესყიდვებმა გამოუშვა PO.

 

შემდეგ საწყობმა დააფიქსირა მიწოდება.

 

საიტის ინჟინერმა დააფიქსირა მოხმარება.

 

შემდეგ ფინანსებმა დააფიქსირა ხარჯი.

 

AI/მონაცემთა ფენამ შემდეგ უნდა დააკავშიროს ეს მოვლენები და დაამყაროს მათ შორის ურთიერთობები.

 

საპირისპიროდ, ProjectVIEW-ის არქიტექტურა ამ ურთიერთობებს ოპერაციული ტრანზაქციის ნაწილად აქცევს.

 

პროექტის სტრუქტურა არ არის უბრალოდ შემდგომში დასკვნადი.

 

ის წინასწარ არის კოდირებული.

 

სწორედ ამიტომ ProjectVIEW-ის დოკუმენტაცია აღწერს პროექტის ბიუჯეტს და BoQ-WBS-Cost Code ასოციაციას, როგორც სტრუქტურულ საფუძველს შემდგომი შესყიდვებისთვის, სამშენებლო ოპერაციებისთვის, რესურსების განაწილებისთვის, ხარჯების კონტროლისთვის და ბუღალტრული აღრიცხვისთვის.

 

შედეგად, საიტის ტრანზაქციას შეუძლია შემდგომი ხარჯებისა და შესრულების ანალიზში BoQ, WBS და Cost Code ასოციაცია თან გაიტანოს.

 

10. ეს არ აქცევს Palantir-ს, ServiceNow-ს ან პროცესის მაინინგს ERP-ის კონკურენტებად

 

სინამდვილეში, საპირისპირო დასკვნა შეიძლება უფრო საინტერესო იყოს.

 

ამის ნაცვლად, ისინი შეიძლება იყოს კომპლემენტარული.

 

მაგალითად, საწარმოს შეიძლება ჰქონდეს:

 

• SAP or Oracle კორპორაციული ფინანსების მართვისთვის,
• ProjectVIEW დეტალური პროექტული შესრულებისა და ხარჯების კონტროლის მართვისთვის,
• Primavera P6 გრაფიკის მართვისთვის,
• BIM ფიზიკური აქტივის წარმოდგენისთვის,

 

და AI/Ontology/Process Intelligence platform, რომელიც ყველა მათგანს შორის მსჯელობს.

 

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

 

შესაბამისად, ეს მნიშვნელოვან პრინციპამდე მიგვიყვანს:

 

AI ინტელექტი ნაწილობრივ ოპერაციული მონაცემების ხარისხის ფუნქციაა.

 

ან უფრო ფორმალურად:

 

უკეთესი ოპერაციული სტრუქტურა → უკეთესი კონტექსტი → უკეთესი AI მსჯელობა → უფრო უსაფრთხო ავტომატიზაცია

 

11. ამიტომ ProjectVIEW-ის უპირატესობა არ არის „ERP AI-ის ნაცვლად“

 

ბოლოს და ბოლოს, ეს არასწორი პოზიციონირება იქნებოდა.

 

ამის ნაცვლად, უფრო ძლიერი წინადადებაა:

 

ProjectVIEW უზრუნველყოფს დეტერმინისტულ, ინდუსტრიაზე მორგებულ ოპერაციულ საფუძველს, რომელზეც AI-ს შეუძლია მსჯელობა.

 

ProjectVIEW-ის დოკუმენტირებული არქიტექტურა ბიუჯეტის დონეზე აყალიბებს BoQ, WBS და Cost Code ურთიერთობას და ამ სტრუქტურას ავრცელებს შემდგომ ტრანზაქციებზე. შესაბამისად, შესყიდვები, სამშენებლო მართვა, HR, მანქანა-დანადგარები, ქვემომარაგება და ფინანსები შეიძლება ურთიერთქმედებდნენ საერთო პროექტულ სტრუქტურებზე დაყრდნობით. მათ არ სჭირდებათ ამ ურთიერთობების შემდეგ აღდგენა.

 

და ProjectVIEW AI-ს შეუძლია ProjectVIEW ტრანზაქციებს მიღმაც გავიდეს: DANAOS-ის მიმდინარე დიზაინი ცალსახად ითვალისწინებს გარე პროექტულ მონაცემებს, მათ შორის დოკუმენტებს, EDMS ინფორმაციას, Primavera P6-ს, საიტის ჩანაწერებს, ხარისხის სისტემებს და მიმოწერას, ხოლო ProjectVIEW ERP-დან მემკვიდრეობით მიღებულ სამშენებლო სპეციფიკურ ოპერაციულ ლოგიკას ინარჩუნებს.

 

ეს ქმნის პოტენციურად მნიშვნელოვან არქიტექტურულ განსხვავებას:

 

Generic Enterprise AI

 

Observe → Extract → Correlate → Model → Infer → Recommend → Act

 

Domain ERP + AI

 

Structure → Transact → Validate → Observe → Reason → Predict → Optimize → Act

 

ორივე მიდგომა შეიძლება თანაარსებობდეს.

 

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

 

12. მომავალი არ არის ERP წინააღმდეგ AI

 

ამიტომ შეიძლება არასწორ კითხვას ვსვამდეთ, როცა ვკითხულობთ:

 

“Will AI replace ERP?”

 

AI უდავოდ შეითვისებს ბევრ შესაძლებლობას, რომლებიც ისტორიულად BPM-ს, RPA-ს, ანალიტიკას, ინტეგრაციასა და მომხმარებლის ინტერფეისებს უკავშირდებოდა.

 

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

 

შედეგად, პროცესები უფრო დინამიკური გახდება.

 

ბუნებრივი ენა შეიძლება ჩაანაცვლოს ბევრი ტრადიციული ეკრანი.

 

და AI სულ უფრო მეტად ავტომატურად აღმოაჩენს და გადააწყობს სამუშაო ნაკადებს.

 

მაგრამ ამ ინტელექტის ქვემოთ საწარმოებს კვლავ სჭირდებათ კონტროლირებადი წარმოდგენები:

 

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

 

ეს მოითხოვს იდენტობას, ურთიერთობებს, უფლებებს, ვალიდაციას, referential integrity-ს, ტრანზაქციის მთლიანობას და აუდიტირებადობას.

 

ამიტომ მომავლის საწარმოო არქიტექტურა უფრო ნაკლებად ჰგავს:

 

AI instead of ERP

 

და უფრო მეტად ჰგავს:

 

ოპერაციული სისტემები + Data Fabric + AI + აგენტები = ინტელექტუალური საწარმო

 

ProjectVIEW-სთვის ამას კიდევ უფრო კონკრეტულად ასე გამოვხატავდით:

 

დეტერმინისტული პროექტის ERP + ჩაშენებული AI + აგენტური ორკესტრირება = ოპერაციული სისტემა პროექტებზე დაფუძნებული ინდუსტრიებისთვის

 

AI-ს შეუძლია აღმოაჩინოს, როგორ მუშაობს ორგანიზაცია.

 

მას ასევე შეუძლია დაეხმაროს იმის განსაზღვრაში, როგორ შეიძლება ორგანიზაცია უკეთ მუშაობდეს.

 

სულ უფრო მეტად, AI-ს ასევე შეუძლია ორკესტრირება გაუწიოს იმას, თუ როგორ ასრულებენ გუნდები სამუშაოს.

 

მაგრამ ოპერაციული პლატფორმა კვლავ პასუხისმგებელია ფუნდამენტურად განსხვავებულ რამეზე:

 

იმ მართული ბიზნესრეალობის განსაზღვრაზე, გენერირებასა და შენარჩუნებაზე, რომელზეც ეს ინტელექტი დამოკიდებულია.

 

AI-ს არ უნდა უწევდეს ყოველ დილას იმის დასკვნა, რაც საწარმომ უკვე იცის.