თავდაცვისა და კოსმოსის წარმოება უბრალოდ წარმოება არ არის. ეს არის პროექტის შესრულება, რომელშიც წარმოება ჩაშენებულია უფრო ფართო საკონტრაქტო, საინჟინრო და მიწოდების ფარგლებში.
რადარის მონტაჟი, მისიის მხარდაჭერის ობიექტი, სატელიტის ინტეგრაციის კონსტრუქცია, სპეციალიზებული მიწისზედა დამხმარე სისტემა ან საინჟინრო მოდული იშვიათად არის განმეორებადი საწარმოო ხაზის შედეგი, რომელიც პროექტისგან დამოუკიდებლად მუშაობს.
ის არსებობს იმიტომ, რომ კონკრეტულ პროექტს სჭირდება იგი.
ეს განსხვავება ERP ლოგიკას სრულიად ცვლის.
ტრადიციულ წარმოებაში მასალათა უწყისი (BoM) ჩვეულებრივ დომინანტური სტრუქტურაა: რა კომპონენტებია საჭირო პროდუქტის დასამზადებლად?
პროექტზე დაფუძნებულ წარმოებაში მის ზემოთ დგას კიდევ ერთი სტრუქტურა: საკონტრაქტო და პროექტის ფარგლები. კომერციული მოდელის მიხედვით, ეს შეიძლება წარმოდგენილი იყოს რაოდენობათა უწყისით (BoQ), ღირებულებათა განრიგით, კონტრაქტის პუნქტებით, სამუშაო პაკეტებით ან ფარგლების სხვა სტრუქტურირებული განსაზღვრებით.
სიმარტივისთვის ამ სტატიაში გამოყენებულია BoQ, როგორც ეს კომერციული/პროექტული საყრდენი.
ამიტომ კრიტიკული მოთხოვნა მხოლოდ BoM-ის მართვა არ არის.
ამის ნაცვლად, საჭიროა ციფრული ჯაჭვის შექმნა, რომელიც შეძლებს შემდეგის გარდაქმნას:
პროექტის მოთხოვნა → BoQ → WBS → დამზადებული პროდუქტი → BoM → წარმოების ოპერაციები → ხარისხი → აწყობა/მონტაჟი → ღირებულება → პროგრესი
ეს არის განსხვავება საწარმოო პროგრამულ უზრუნველყოფასა და ნამდვილ პროექტზე დაფუძნებულ წარმოების ERP-ს შორის.
DANAOS ProjectVIEW ERP უკვე მოდელირებს ამ ურთიერთობას თავისი პროექტზე დაფუძნებული წარმოების ERP არქიტექტურის მეშვეობით, სადაც მომხმარებლებს შეუძლიათ პროექტის BoQ გადაიყვანონ წარმოებისთვის მზად BoM-ებად და routing-ებად, რომლებიც დაკავშირებული რჩება WBS აქტივობებსა და cost codes-თან. danaos-projects.com
რა არის პროექტზე დაფუძნებული წარმოება თავდაცვისა და კოსმოსის სფეროში?
პროექტზე დაფუძნებული წარმოება არის საინჟინრო პროდუქტების დამზადება, რომლებიც კონკრეტულად საჭიროა პროექტის, კონტრაქტის ან მისიის ფარგლების შესასრულებლად და არა სტანდარტული, განმეორებადი პროდუქტების მარაგის შესავსებად.
პრაქტიკაში ეს ხშირად კვეთს engineer-to-order და დაბალი მოცულობის/მაღალი სირთულის წარმოებას.
თუმცა მნიშვნელოვანი განსხვავება ეკონომიკურიც არის და ტექნიკურიც.
სხვა სიტყვებით, დამზადებული ნივთი არ არსებობს როგორც იზოლირებული პროდუქტი.
ამის ნაცვლად, ის არსებობს იმ პროექტის ეკონომიკასა და გრაფიკში, რომელიც მას საჭიროებს.
NASA-ს Systems Engineering Handbook ასახავს კოსმოსური სექტორის უფრო ფართო სისტემური ინჟინერიის რეალობას: განვითარება და პროდუქტის რეალიზაცია არის განმეორებადი, მრავალდისციპლინური პროცესები, რომლებიც ვრცელდება პროექტის სიცოცხლის ციკლზე. გარდა ამისა, NASA კონკრეტულად უსვამს ხაზს Model-Based Systems Engineering-ს, როგორც მექანიზმს პროდუქტის განვითარებისა და მიწოდების გასაუმჯობესებლად. NASA
ანალოგიურად, ევროპული კოსმოსური პროგრამები მოქმედებს European Cooperation for Space Standardization-ის ჩარჩოში, რომელიც მკაფიოდ აერთიანებს პროექტის მართვას, ინჟინერიას, ინდუსტრიალიზაციას, წარმოებას, ტექნიკურ მომსახურებასა და პროდუქტის უზრუნველყოფას. მისი კონფიგურაციის მართვის სტანდარტი მოითხოვს პროდუქტის მახასიათებლებს, დამტკიცებულ მოთხოვნებსა და მზარდ as-built კონფიგურაციას შორის კავშირის შენარჩუნებას მთელი სიცოცხლის ციკლის განმავლობაში. ECSS
სწორედ ამიტომ ხდება ტრადიციული უწყებრივი დაყოფა პრობლემური.
ინჟინერიამ ვერ უნდა დაასრულოს თავისი საქმე და უბრალოდ „გადააგდოს BoM კედლის მეორე მხარეს“ წარმოებაში.
ანალოგიურად, წარმოება ვერ იფუნქციონირებს პროექტის ეტაპების გააზრების გარეშე.
შესყიდვებს ვერ ექნება მხოლოდ მარაგის მოთხოვნაზე დაფუძნებული ყიდვა.
ასევე, ხარისხი ვერ იმუშავებს კონფიგურაციისგან განცალკევებით.
და ფინანსები ვერ გაიგებს პროექტის ნამდვილ შესრულებას, თუ დამზადების ხარჯები განცალკევებით დგას იმ პროექტული შედეგისგან, რომელმაც ისინი წარმოშვა.
დაკარგული თარგმანი: BoQ → BoM
ეს არის არქიტექტურული პრობლემა, რომელიც მეტ ყურადღებას იმსახურებს.
მაგალითად, წარმოიდგინეთ, რომ პროექტის BoQ შეიცავს მოთხოვნას საინჟინრო აწყობაზე.
პროექტის პერსპექტივიდან, ეს აწყობა შეიძლება გამოჩნდეს როგორც ერთი მასალა ან პროდუქტი, რომელიც საჭიროა BoQ-ის ერთი საპროექტო ფარგლის შესასრულებლად.
მაგრამ შიგნით ეს „მასალა“ აუცილებელი არ არის კატალოგიდან შესაძენი რაღაც იყოს.
ის შეიძლება თავად იყოს პროექტზე დაფუძნებული წარმოებული პროდუქტი.
თავის მხრივ, ეს პროდუქტი იშლება საკუთარ BoM-ად, რომელიც შედგება მრავალი ნედლეულის, ნაყიდი კომპონენტის, სახარჯი მასალისა და ნახევრად მზა დეტალისგან.
- მას ასევე სჭირდება შრომა.
- გარდა ამისა, იგი მოიხმარს ტექნიკას, ხელსაწყოებსა და საწარმოო სიმძლავრეს.
- ის გადის წარმოების ოპერაციებს.
- და ბოლოს, ის გადის ინსპექციისა და ხარისხის საკონტროლო ეტაპებს.
ზოგიერთი პროცესი შეიძლება შიდა წესით განხორციელდეს.
სხვა ნაწილი შეიძლება გადავიდეს სპეციალიზებულ მომწოდებლებთან ან ქვემიმწოდებლებთან.
და ბოლოს, დასრულების შემდეგ, წარმოებული შედეგი ერთ იდენტიფიცირებად პროდუქტად კონსოლიდირდება, რომელსაც მშობელი პროექტის ფარგლები იყენებს აწყობის, აღმართვის, ინტეგრაციის ან მონტაჟის დროს.
ამას ჩაშენებულ პროექტულ წარმოებას ვუწოდებთ.
ProjectVIEW უკვე უჭერს მხარს ამ საბაზისო ლოგიკას BoQ-დან BoM-მდე წარმოების, წარმოების ფაზებისა და რესურსების განაწილების მეშვეობით და თავისი სპეციალური Materials & Production Management მოდულის საშუალებით. წარმოების ფაზები შეიძლება იყოს მიმდევრობითი ან პარალელური და განასხვავებდეს შეყვანებს, ნახევრად მზა პროდუქტებსა და შედეგებს. მათ ასევე შეუძლიათ შრომისა და ტექნიკის განაწილება, ქვემიმწოდებლების ჩართვა, საბოლოო წარმოების ერთეულის ღირებულების გამოთვლა და დაგეგმილი და ფაქტობრივი რესურსებისა და ხარჯების შედარება. Danaos Projects
ეს ქმნის ბევრად უფრო მდიდარ ურთიერთობას, ვიდრე:
პროდუქტი → BoM
ამის ნაცვლად, ის ხდება:
BoQ ფარგლები → WBS აქტივობა → დამზადებული პროდუქტი → BoM + Routing + რესურსები + ხარისხი → დასრულებული პროდუქტი → მშობელი BoQ
და თითოეული ფენა ეკონომიკურად მიეკუთვნება იმავე პროექტს.
დამზადებული პროდუქტი ასევე არის პროექტის რესურსი
ეს კონცეფცია განსაკუთრებით მნიშვნელოვანია.
დამზადებული აწყობა ერთდროულად შეიძლება იყოს:
ერთი წარმოების პროცესის შედეგი და სხვა პროექტული პროცესის შემომავალი რესურსი.
მაგალითად, განვიხილოთ თავდაცვის პროგრამისთვის დამზადებული საინჟინრო საყრდენი მოდული.
პროექტის დონეზე ის შეიძლება იყოს მასალა/რესურსი, რომელიც საჭიროა განსაზღვრული BoQ სამუშაო პაკეტისთვის.
თუმცა შიდა დონეზე ProjectVIEW-ს შეუძლია ეს პროდუქტი წარმოების BoM-ად დაშალოს.
თავის მხრივ, მის დამზადებას შეიძლება სჭირდებოდეს კონსტრუქციული მასალები, შეძენილი კომპონენტები, სპეციალისტთა შრომა, შედუღების ან დამუშავების აღჭურვილობა, ხარისხის შემოწმებები და, შესაძლოა, გარე დასრულების სამუშაოები ან სპეციალიზებული ტესტირება.
აწყობის მიღების შემდეგ, გუნდი მას აბრუნებს მშობელ პროექტში, როგორც კონტროლირებად, იდენტიფიცირებად რესურსს, რომელიც მზად არის მონტაჟისთვის.
მთავარი ის არის, რომ მისი ღირებულება არ გამქრალა ზოგად საწარმოო ზედნადებ ანგარიშში.
ამის ნაცვლად, მისი შრომის საათები, მანქანური დრო, მასალები, ქვეკონტრაქტით შესრულებული ოპერაციები და წარმოების პროგრესი კვლავ მიეკუთვნება იმ პროექტის მოთხოვნას, რომელმაც ის შექმნა.
ეს არის პროექტის ხარჯების კონტროლი, რომელიც წარმოებაში აღწევს.
თავდაცვის მაგალითი: ერთი BoQ მოთხოვნა, მის ქვეშ მთელი საწარმოო პროექტი
მაგალითად, განვიხილოთ თავდაცვის კონტრაქტორი, რომელიც აწვდის ინტეგრირებულ მისიის მხარდაჭერის ობიექტს.
ერთი საკონტრაქტო მოცულობის პუნქტი შეიძლება მოითხოვდეს საინჟინრო დანადგარის გარსაცმს ან კონსტრუქციულ მოდულს.
მშობელი პროექტის თვალსაზრისით, მენეჯმენტს სურს იცოდეს:
- მზად არის?
- როდის დაამონტაჟებს გუნდი მას?
- რა დაჯდა?
- გაიარა ინსპექტირება?
- იყენებს დამტკიცებულ კონფიგურაციას?
მაგრამ ამ ერთი შეხედვით მარტივი პუნქტის ქვეშ დგას მინი პროექტი.
- პირველ რიგში, ინჟინერია გამოყოფს ნახაზებს და სპეციფიკაციებს.
- შემდეგ სისტემა ქმნის ან უკავშირებს შესაბამის BoM-ს და მარშრუტიზაციას.
- შესყიდვები უზრუნველყოფს საჭირო კომპონენტებს.
- წარმოება ანაწილებს საამქროს სიმძლავრეს, შრომას და დანადგარებს.
- სპეციალიზებულ მომწოდებლებს შეუძლიათ აიღონ შერჩეული პროცესები.
- ხარისხი აფიქსირებს ინსპექტირებებს, შეუსაბამობებს და დამტკიცებებს.
- სისტემა ვერსიების კონტროლს უკეთებს კონფიგურაციის ცვლილებებს.
საბოლოოდ, გუნდი ასერიულებს ან სხვაგვარად იდენტიფიცირებს დასრულებულ ნივთს და გადასცემს მას საჭირო ეზოში ან ობიექტზე. შემდეგ მისი მშობელი მონტაჟის აქტივობა მას იყენებს.
სწორედ აქ ხდება ProjectVIEW-ის პრინციპი, რომელიც აერთიანებს BoQ ↔ WBS ↔ Cost Codes, განსაკუთრებით ძლევამოსილი: კომერციული მოთხოვნა, გრაფიკი, საწარმოო რესურსები და ფაქტობრივი ხარჯები არ არის სხვადასხვა რეალობა, რომელსაც სხვადასხვა დეპარტამენტი ინახავს.
ისინი ხდება ერთი და იმავე პროექტული რეალობის სხვადასხვა ხედები.
DANAOS დღეს მსგავს საწარმოო ლოგიკას იყენებს რთულ პროექტულ გარემოებში, როგორიცაა გემთმშენებლობა და გემთსარემონტო ოპერაციები, სადაც დამზადება, მასალები, შრომა, ქვეკონტრაქტორები, დიზაინის ინფორმაცია, წარმოება და ხარჯები უკვე ერთმანეთთან გადაჯაჭვულია. Danaos Projects
სივრცითი მაგალითი: წარმოება განუყოფელია კონფიგურაციისა და ხარისხისგან
ახლა განვიხილოთ სპეციალიზებული მიწისზედა მხარდაჭერის კონსტრუქცია ან ინტეგრაციის ჩარჩო, რომელიც მზადდება კოსმოსური პროგრამისთვის.
მის BoM-ში შეიძლება იყოს სტანდარტული საგნები, სპეციალურად დამზადებული კომპონენტები და ზუსტი დეტალები, მიღებული სპეციალისტი მომწოდებლებისგან.
- წარმოების ნაწილი ხორციელდება მწარმოებლის საამქროში.
- სხვა ოპერაციას შეიძლება ახორციელებდეს სპეციალისტი მომწოდებელი.
- საბოლოო აწყობა შეიძლება განხორციელდეს სხვა ობიექტზე.
- მიღება შეიძლება მოითხოვდეს ინსპექტირების ჩანაწერებს, სერტიფიკატებს, დამტკიცებულ ნახაზებს და ზუსტ as-built კონფიგურაციას.
ამიტომაც ხარისხი უბრალოდ ვერ იქნება Manufacturing-ის გვერდით მდგომი კიდევ ერთი ERP მოდული.
ამის ნაცვლად, ხარისხი წარმოების მდგომარეობის ნაწილია.
ევროპული კოსმოსური სტანდარტები ამ ურთიერთობას მკაფიოდ განსაზღვრავს: ECSS ინარჩუნებს გამოყოფილ მოთხოვნებს კოსმოსური პროდუქტის უზრუნველყოფისთვის, კოსმოსური პროექტების ხარისხის უზრუნველყოფისთვის და კონფიგურაციისა/ინფორმაციის მართვისთვის. ECSS
ამიტომ, ვერავინ სანდოდ ვერ განაცხადებს, რომ წარმოებული ნივთი „დასრულებულია“ მხოლოდ იმიტომ, რომ საწარმოო ოპერაციებმა 100%-ს მიაღწია.
- მაგალითად, ის შეიძლება იყოს ფიზიკურად დასრულებული, მაგრამ ინსპექტირების გარეშე.
- ინსპექტირებულია, მაგრამ შეუსაბამობა აქვს.
- მიღებულია, მაგრამ არ არის გათავისუფლებული.
- გათავისუფლებულია, მაგრამ არ არის გადატანილი.
- მიწოდებულია, მაგრამ არ არის ინტეგრირებული.
- ინტეგრირებულია, მაგრამ საბოლოო ვერიფიკაციას ელოდება.
თითოეული მდგომარეობა სხვადასხვა რამეს ნიშნავს Production-ისთვის, Quality-ისთვის, Planning-ისთვის, Commercial Management-ისთვის და მომხმარებლისთვის.
ამიტომ სერიოზულ ERP-ს ეს განსხვავებები უნდა ესმოდეს.
თავდაცვასა და კოსმოსში რეალურ დროში ინფორმაცია საკმარისი არ არის. ის უნდა იყოს მაღალი სანდოობის ინფორმაცია.
ეს, ალბათ, ყველაზე მნიშვნელოვანი განსხვავებაა.
ხელმძღვანელები ხშირად ითხოვენ „real-time dashboards“-ს.
მაგრამ სიჩქარე ნდობის გარეშე სახიფათოა.
თუ ანგარიში პროგრამის დირექტორს ეუბნება, რომ ასამბლეა 82%-ით დასრულებულია, ზუსტად რას ნიშნავს 82%?
- დახარჯული საათები?
- დასრულებული ოპერაციები?
- წარმოებული ფიზიკური რაოდენობები?
- BoM-ის დასრულებული პოზიციები?
- ხარისხით დამტკიცებული გამომავალი?
- earned value?
- საამქროს თვითაღრიცხვა?
ამიტომ მიზანი უნდა იყოს რეალურ დროში მაღალი სანდოობის პროგრესი.
ამის ნაცვლად, ყოველ პროგრესის განცხადებას უნდა უმაგრდებოდეს მტკიცებულება ძირითადი პროცესებიდან: საწარმოო ოპერაციები, მოხმარებული მასალები, შრომის ტრანზაქციები, მანქანების აქტივობა, ქვეკონტრაქტორების ეტაპები, ინსპექტირების სტატუსი, დამტკიცებული დოკუმენტაცია და გრაფიკის პოზიცია.
მაგალითად, აშშ-ის Digital Engineering Strategy მოითხოვს სისტემური მონაცემებისა და მოდელების ავტორიტეტულ წყაროებს, რომლებიც მოიცავს დისციპლინებსა და სიცოცხლის ციკლს. ის პირდაპირ აკავშირებს ამგვარ ავტორიტეტულ truth source-ს cost, schedule, performance და risk მართვასთან და ამავე დროს უსვამს ხაზს, რომ დაინტერესებულ მხარეებს სწორი ინფორმაცია სჭირდებათ სწორ დროს. Assistant Secretary of War
ეს პრინციპი პირდაპირ გადადის პროექტზე დაფუძნებულ ERP-ში.
გუნდებმა მხოლოდ პროგრესი კი არ უნდა აცხადონ. მათ ის უნდა დაადასტურონ.
სად ცვლის AI თავდაცვისა და კოსმოსის პროექტურ წარმოებას
ProjectVIEW ERP უზრუნველყოფს სტრუქტურირებულ პროცესისა და მონაცემების ფენას. DANAOS აღწერს ProjectVIEW OS-ს და ProjectVIEW AI-ს, როგორც ინტელექტის ფენას, რომელიც მუშაობს სტრუქტურირებულ BoQ, WBS, cost და ოპერაციულ ინფორმაციაზე. გამოქვეყნებულ მიმართულებებს შორისაა ხარჯის გადახრის პროგნოზირება, დაგვიანებისა და პროდუქტიულობის პროგნოზირება, რისკის სკორინგი, შესყიდვების ინტელექტი, ანომალიების აღმოჩენა და AI-ით მხარდაჭერილი სამუშაო პროცესები. Danaos Projects
თავდაცვისა და კოსმოსის წარმოებისთვის ეს რამდენიმე განსაკუთრებით ღირებულ გამოყენების სცენარს ხსნის:
- AI-ით დადასტურებული პროგრესი. AI აგენტს შეუძლია შეადაროს გამოცხადებული საწარმოო პროგრესი BoM-ის შესრულებას, მოხმარებულ მასალებს, შრომის ტრანზაქციებს, მანქანების აქტივობას, ქვეკონტრაქტორების სტატუსს და გავლილ ხარისხის კარიბჭეებს. იმის ნაცვლად, რომ უბრალოდ გაიმეოროს „75% complete“, მას შეუძლია მიუთითოს, რომ მოხსენებულ მდგომარეობას მხოლოდ მტკიცებულებების 61% ადასტურებს და დაადგინოს, რა აკლია.
- AI გრაფიკისა და წარმოების რისკის პროგნოზირება. თუ სპეციალიზებული კომპონენტი გვიან ჩამოდის, ერთი დანადგარი მიუწვდომელია და სავალდებულო ინსპექტირება გადაიწია, AI-ს შეუძლია შეაფასოს მათი კომბინირებული გავლენა საწარმოო routing-ზე, WBS აქტივობაზე და საბოლოო პროექტის ეტაპზე და არა თითოეული პრობლემის ცალკე ანალიზი.
- AI ხარისხისა და კონფიგურაციის ინტელექტი. დოკუმენტური ინტელექტი შეიძლება გამოავლინოს გამოტოვებული ინსპექტირების ჩანაწერები, ნახაზების შეუსაბამო რევიზიები, არასრული სერტიფიკატები, განმეორებადი non-conformance ნიმუშები ან ტრანზაქციები, რომლებიც შესრულებულია მოძველებული ინფორმაციის საფუძველზე. მიზანი არ არის საინჟინრო განსჯის ჩანაცვლება, არამედ წინააღმდეგობების გამოკვეთა მანამდე, სანამ ისინი ქვედა ეტაპებზე გავრცელდება.
როგორ შეუძლია AI-ს შესყიდვებისა და დაინტერესებული მხარეების გადაწყვეტილებების მხარდაჭერა?
- AI შესყიდვებისა და make-or-buy ინტელექტი. რადგან კომპანიას შეუძლია აწარმოოს დამზადებული პროდუქტი შიგნით ან გააუთსორსოს იგი, AI-ს შეუძლია შეადაროს შიდა სიმძლავრე, მანქანების ხელმისაწვდომობა, ისტორიული პროდუქტიულობა, მომწოდებლის მიწოდების ვადები, შესყიდვის ვალდებულებები და პროგნოზირებული ღირებულება, სანამ მენეჯმენტი გადაწყვეტს, აწარმოოს, ქვეკონტრაქტით გააკეთოს თუ შეიძინოს.
- AI-ის აღმასრულებელი და დაინტერესებული მხარეების ბრიფინგები. უფლებამოსილ დაინტერესებულ მხარეს შეიძლება დაესვას კითხვა: რა არის Package X-ის ამჟამინდელი დამტკიცებული სტატუსი, რა აფერხებს დასრულებას, რა არის მისი უახლესი პროგნოზირებული ღირებულება და რომელი მტკიცებულება ამყარებს ამ შეფასებას? შემდეგ AI-ს შეუძლია პასუხი შექმნას სტრუქტურირებული ERP ტრანზაქციებიდან და დაკავშირებული მტკიცებულებებიდან და არა ხელით შეკოწიწებული ელფოსტებიდან და ცხრილებიდან.
მთლიანად კრიტიკული სიტყვაა მტკიცებულება.
AI მნიშვნელოვნად უფრო ღირებული ხდება მაშინ, როდესაც ის მსჯელობს კონტროლირებულ ოპერაციულ მონაცემებზე და არა ცდილობს პროექტის ჭეშმარიტების აღდგენას დაშლილი დოკუმენტებიდან.
კონფიდენციალურობა ცვლის თანამშრომლობის წესებს
თავდაცვისა და კოსმოსის პროგრამებს კიდევ ერთი მოთხოვნა აქვთ: ყველა დაინტერესებულმა მხარემ არ უნდა ნახოს ყველაფერი.
- რეალურ დროში ხილვადობა არ ნიშნავს შეუზღუდავ ხილვადობას.
- პროგრამის ხელმძღვანელობას შეიძლება სჭირდებოდეს ხარჯისა და გრაფიკის ხედვა.
- წარმოების მენეჯმენტს სჭირდება დეტალური საწარმოო სტატუსი.
- ხარისხის გუნდებს სჭირდებათ ინსპექტირებისა და non-conformance ინფორმაცია.
- სპეციალიზებულ კონტრაქტორებს შეიძლება მხოლოდ მათზე მინიჭებული სამუშაო პაკეტი სჭირდეთ.
- მომხმარებლებს შეიძლება სჭირდებოდეთ დამტკიცებული ეტაპის სტატუსი შიდა კომერციულ ან მომწოდებელ ინფორმაციაზე წვდომის გარეშე.
ამიტომ სწორი არქიტექტურაა:
სიმართლის ერთი წყარო, მრავალი ავტორიზებული ხედვა.
აშშ-ის გარემოში, სადაც მუშავდება Controlled Unclassified Information, NIST SP 800-171 Rev.3 მნიშვნელოვან ბენჩმარკს წარმოადგენს: ის ეხება CUI-ის დაცვას არაფედერალურ სისტემებში და მოიცავს წვდომის კონტროლს, მინიმალურ პრივილეგიას, აუდიტირებადობას, სისტემის მთლიანობას და ინფორმაციის დაცვას გადაცემისა და შენახვის დროს. ის კონკრეტულად მოითხოვს მომხმარებლებისა და პროცესების წვდომის შეზღუდვას მხოლოდ მათთვის საჭირო ფუნქციებზე და დეტალური აუდიტ ჩანაწერების შენარჩუნებას. NIST Publications
თუმცა ეს არ ნიშნავს, რომ ERP-ის გამოყენება ავტომატურად უზრუნველყოფს შესაბამისობას NIST-თან, ECSS-თან, ექსპორტის კონტროლის წესებთან ან კონკრეტულ თავდაცვის კონტრაქტთან. ორგანიზაციებმა ყოველთვის უნდა გადაამოწმონ შესაბამისობა კონკრეტული პროგრამის, იურისდიქციის, მონაცემთა კლასიფიკაციისა და საკონტრაქტო ვალდებულებების მიხედვით.
მაგრამ ის განსაზღვრავს სწორ არქიტექტურულ მიმართულებას.
ამიტომ, სისტემამ პროექტის ინფორმაცია უნდა გაანაწილოს იდენტობის, როლის, პასუხისმგებლობისა და საჭიროების ცოდნის პრინციპის მიხედვით.
მაგალითად, შეტყობინებებმა მგრძნობიარე დაინტერესებული მხარეებისთვის იდეალურად უნდა აცნობონ, რომ არსებობს მნიშვნელოვანი მოვლენა და მიაწოდონ ავტორიზებული წვდომა ავტორიტეტულ ჩანაწერზე. მათ არ უნდა გაავრცელონ კონფიდენციალური ტექნიკური ან კომერციული ინფორმაცია დაუკონტროლებელ არხებში საჭიროების გარეშე.
ProjectVIEW-ის ინტეგრირებული CDE უკვე უჭერს მხარს დოკუმენტების ვერსიონირებას, დამტკიცებებს, ისტორიას და აუდიტის კვალს, ხოლო მისი საწარმოო გარემო წარმოების აქტივობას აკავშირებს საწყის პროექტულ სტრუქტურასთან. ProjectVIEW-ის დოკუმენტების კონტროლისა და CDE შესაძლებლობები Danaos Projects
ციფრული ძაფიდან ეკონომიკურ ძაფამდე
თავდაცვისა და კოსმოსის სექტორებს უკვე ესმით ციფრული ძაფი.
ინდუსტრიული ტექნოლოგიის მომწოდებლები მას განმარტავენ, როგორც უწყვეტ კავშირს ინჟინერიას, წარმოებას, საწარმოო პროცესებსა და სასიცოცხლო ციკლის ინფორმაციას შორის. მაგალითად, Siemens aerospace and defence digital thread-ს აწყობს პროგრამის მართვის, ინჟინერიის, მიწოდების ჯაჭვის, წარმოებისა და პროდუქტის მხარდაჭერის ირგვლივ. Siemens Resources
მაგრამ არსებობს კიდევ ერთი ძაფი, რომელიც არანაკლებ მნიშვნელოვანია:
ეკონომიკური ძაფი.
- დიზაინის გადაწყვეტილებას აქვს ღირებულება.
- ანალოგიურად, BoM-ის რევიზიას აქვს შესყიდვებზე გავლენა.
- გვიან ჩამოსულ კომპონენტს აქვს გრაფიკზე გავლენა.
- დანადგარის გაჩერება ცვლის წარმოების ეკონომიკას.
- უარყოფილი დეტალი შრომასა და მასალებს ხარჯავს მიღებული პროგრესის შექმნის გარეშე.
- აუთსორსირებულ პროცესს ქმნის ვალდებულების, გრაფიკისა და ხარისხის დამოკიდებულებები.
- კონფიგურაციის ცვლილებამ შეიძლება გააუქმოს უკვე შესრულებული სამუშაო.
ProjectVIEW-ის პროექტზე დაფუძნებული ლოგიკა ამ ფიზიკურ და საინჟინრო რეალობას აბრუნებს BoQ, WBS და Cost Codes-თან.
შედეგად, ციფრული ძაფი არ მთავრდება ინჟინერიასთან ან საამქროს იატაკთან.
ამის ნაცვლად, ის გრძელდება ბიუჯეტში, ვალდებულებებში, ფაქტობრივ ხარჯში, earned value-ში, პროექტის პროგრესსა და ფინანსურ შესრულებაში.
რატომ არ არის საკმარისი ტრადიციული Manufacturing ERP
ტრადიციულ Manufacturing ERP-ს შეიძლება ძალიან კარგად შეეძლოს შემდეგ კითხვაზე პასუხი:
რა არის საჭირო პროდუქტი A-ს დასამზადებლად?
ამისგან განსხვავებით, თავდაცვისა და კოსმოსის პროექტური წარმოება მოითხოვს უფრო ფართო კითხვას:
რატომ ვამზადებთ Product A-ს, რომელი საკონტრაქტო მოთხოვნისთვის, რომელ გრაფიკის ეტაპზე, რომელი რესურსებით, რომელ კონფიგურაციაში, რა ღირებულებით, რა ხარისხის სტატუსით და როგორ მოქმედებს მისი დასრულება მშობელ პროგრამაზე?
ეს კითხვა კვეთს ინჟინერიას, პროექტის კონტროლს, შესყიდვებს, წარმოებას, ხარისხს, ქვეკონტრაქტინგს, ლოჯისტიკასა და ფინანსებს.
თუმცა მას ვერავინ უპასუხებს სანდოდ, როცა ეს ფუნქციები განცალკევებულ სისტემებში ცხოვრობენ.
ვერც AI უპასუხებს, თუ თვითონ AI-ს ქვემოთ არ აქვს სტრუქტურირებული ოპერაციული სიმართლე.
ეს არის ProjectVIEW-ის BoQ-დან BoM-მდე პროექტური წარმოების მოდელის მნიშვნელობა.
BoM განმარტავს, როგორ ავაგოთ პროდუქტი. შემდეგ WBS განმარტავს, როდის უნდა ავაგოთ იგი. BoQ განმარტავს, რატომ სჭირდება პროექტს ის და სად დგას მისი ეკონომიკური ღირებულება. Cost Codes განმარტავს, რა უჯდება მისი შესრულება საწარმოს. ხარისხისა და კონფიგურაციის ჩანაწერები ადგენს, არის თუ არა გამომავალი რეალურად მისაღები.
პროექტზე დაფუძნებული წარმოება აერთიანებს ამ ხუთივეს.
შემდეგ AI-ს შეუძლია მიღებული ციფრული ქსოვილის ინტერპრეტაცია.
თავდაცვისა და კოსმოსის Manufacturing ERP უნდა იქცეს მართვის სისტემად და არა მონაცემთა ბაზად
რთული თავდაცვისა და კოსმოსის პროგრამებისთვის მიზანი არაა კიდევ ერთი ჩანაწერების სისტემა.
ამის ნაცვლად, ეს არის კონტროლირებადი პროექტური წარმოების მართვის გარემო.
ის უნდა შეძლებდეს მოთხოვნის თვალყურის დევნებას საკონტრაქტო მოცულობიდან საინჟინრო განმარტებამდე; BoQ-დან BoM-მდე; შესყიდვებიდან დამზადებამდე. ასევე უნდა აკვირდებოდეს სამუშაოს შიდა საამქროდან გარე სპეციალისტ კონტრაქტორამდე და წარმოებიდან ინსპექტირებამდე. და ბოლოს, უნდა ადევნებდეს თვალს სამუშაოს დასრულებული კომპონენტიდან აწყობამდე და მონტაჟამდე, ხოლო ფიზიკური შესრულებიდან უკან დროის, ხარჯის, ხარისხისა და პროგრამის შესრულებამდე.
ამ გარემოებებში წარმოებული ნივთი დღეს შეიძლება იყოს პროდუქტი, ხვალ პროექტის რესურსი და მონტაჟის შემდეგ ბევრად უფრო დიდი სისტემის ნაწილი.
ამიტომ საინფორმაციო სისტემამ სამივე მდგომარეობა უნდა გაიგოს.
ეს არის პროექტზე დაფუძნებული წარმოება.
და ეს ზუსტად ის სირთულის ტიპია, რომელსაც ინტეგრირებული, პროექტზე ორიენტირებული ERP, როგორიცაა DANAOS ProjectVIEW ERP, შექმნილია სამართავად.
FAQ: თავდაცვისა და კოსმოსის პროექტზე დაფუძნებული წარმოება
რა განსხვავებაა BoQ-სა და BoM-ს შორის?
BoQ წარმოადგენს პროექტის ან საკონტრაქტო მოცულობას და რაოდენობებს, ხოლო BoM აღწერს კომპონენტებს, რომლებიც საჭიროა პროდუქტის დასამზადებლად. პროექტზე დაფუძნებულ წარმოებაში მნიშვნელოვანი შესაძლებლობაა მათ შორის კავშირის შენარჩუნება, რათა დამზადებული პროდუქტები დარჩეს დაკავშირებული იმ პროექტის მოთხოვნასთან, WBS აქტივობასთან, ბიუჯეტთან და ხარჯების სტრუქტურასთან, რომელმაც შექმნა მოთხოვნა.
რას ნიშნავს BoQ-to-BoM?
BoQ-to-BoM ნიშნავს პროექტის deliverable-ს ან დამზადებულ ელემენტს, რომელიც განსაზღვრულია კომერციულ/პროექტულ სტრუქტურაში, და მისი გაფართოებას იმ მასალებად, კომპონენტებად, ოპერაციებად და რესურსებად, რომლებიც საჭიროა მის დასამზადებლად. დასრულების შემდეგ დამზადებული პროდუქტი მშობელ პროექტში ბრუნდება როგორც კონტროლირებადი რესურსი აწყობის, მონტაჟის ან ინსტალაციისთვის.
რატომ არის პროექტზე დაფუძნებული წარმოება მნიშვნელოვანი თავდაცვისა და კოსმოსისთვის?
იმიტომ, რომ ინჟინრები თავდაცვისა და კოსმოსის ბევრ deliverable-ს კონკრეტული პროგრამისთვის, კონფიგურაციისთვის ან მისიისთვის ქმნიან და არა განმეორებადი მარაგისთვის. შესაბამისად, მათ სჭირდებათ ერთდროული კონტროლი ინჟინერიაზე, წარმოებაზე, პროექტის გრაფიკზე, ხარისხზე, შესყიდვებზე, ქვეკონტრაქტინგსა და ხარჯზე.
როგორ შეუძლია AI-ს გააუმჯობესოს თავდაცვისა და კოსმოსის წარმოების ERP?
AI-ს შეუძლია შეადაროს მოხსენებული პროგრესი ოპერაციულ მტკიცებულებებს, იწინასწარმეტყველოს წარმოებისა და შესყიდვების რისკები, აღმოაჩინოს ანომალიები, განიხილოს დოკუმენტაცია, გამოავლინოს კონფიგურაციის შეუსაბამობები და უფლებამოსილ დაინტერესებულ მხარეებს მიაწოდოს მტკიცებულებაზე დაფუძნებული პროექტის ბრიფინგები. თუმცა მისი სანდოობა ძლიერ არის დამოკიდებული ქვედა ფენის ERP მონაცემების ხარისხსა და სტრუქტურაზე.
რატომ არის უსაფრთხო ხილვადობა დაინტერესებული მხარეებისთვის მნიშვნელოვანი?
იმიტომ, რომ მგრძნობიარე პროგრამები მოითხოვს როგორც სწრაფ ინფორმაციულ ნაკადს, ისე მკაცრ ინფორმაციულ კონტროლს. მიზანი არ არის ყველა პროექტული ინფორმაციის ყველასთვის გახსნა, არამედ თითოეული უფლებამოსილი დაინტერესებული მხარისთვის სწორი დამოწმებული ინფორმაცია, სწორ დროს, სწორი მიზნით მიწოდება.
