გადასვლა შინაარსზე
Danaos

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

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

 

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

 

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

 

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

 

ეს ქმნის ერთ-ერთ ყველაზე მნიშვნელოვან დიგიტალიზაციის გამოწვევას სამშენებლო სამყაროში (Build World):

 

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

 

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

 

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

 

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

 

მიზანი გაცილებით მნიშვნელოვანია:

 

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

 


 

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

 

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

 

FIDIC-ის მიერ გამოცემული საერთაშორისო სამშენებლო კონტრაქტები FIDIC-ის სამშენებლო კონტრაქტები აფორმებს ურთიერთობებს დამკვეთს (Employer/Client), კონტრაქტორსა და ინჟინერს (Engineer) შორის. FIDIC ასევე აქვეყნებს დამკვეთისა და კონსულტანტის მომსახურების სანიმუშო ხელშეკრულებას (Client/Consultant Model Services Agreement) FIDIC-ის „თეთრი წიგნი“ (White Book) ისეთი საქმიანობებისთვის, როგორიცაა ტექნიკურ-ეკონომიკური დასაბუთება, დეტალური პროექტირება, მშენებლობის ადმინისტრირება და პროექტის მართვა.

 

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

 

ფინანსური ინსტიტუტები კიდევ ერთ საინფორმაციო შრეს ქმნიან. ეკვატორის პრინციპებს (Equator Principles) ეკვატორის პრინციპების პროექტული დაფინანსების ჩარჩო რისკების მართვის ჩარჩოდ იყენებენ ფინანსური ინსტიტუტები, რომლებიც ჩართულნი არიან პროექტულ დაფინანსებასა და მასთან დაკავშირებულ ფინანსურ პროდუქტებში.

 

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

 

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

 

მესაკუთრე → კონტრაქტორი

 

და უფრო მეტად ამას:

 

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

 

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

 

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

 

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

 

რას აკავშირებს ProjectVIEW?

 

ProjectVIEW ERP-ის ცენტრში პროექტის ფიზიკური მოცულობა და შესრულება შეიძლება სამი ფუნდამენტური განზომილების გარშემო იყოს სტრუქტურირებული:

 

სამუშაოთა მოცულობების უწყისი — BoQ

 

რა უნდა აშენდეს, დამონტაჟდეს, დამზადდეს, ამოითხაროს ან მიეწოდოს?

 

სამუშაოთა დეკომპოზიციის სტრუქტურა — WBS

 

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

 

ხარჯების კოდები

 

რა რესურსები და ხარჯები იხარჯება ამ სამუშაოს შესასრულებლად?

 

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

 

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

 

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

 

ნახაზის ცვლილება → რაოდენობის ცვლილება → BoQ-ის ცვლილება → გავლენა WBS-ზე → შესყიდვის მოთხოვნა → გავლენა ქვეკონტრაქტორზე → რესურსის მოთხოვნა → გავლენა ხარჯზე → დამკვეთთან ცვლილება → გავლენა ფულად ნაკადებზე

 

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

 

შიდა როლები და გარე დაინტერესებული მხარეები ერთი და იგივე არ არის

 

ეს განსხვავება კრიტიკულია.

 

საწარმოს შიგნით ProjectVIEW მხარს უჭერს ისეთ ოპერაციულ როლებს, როგორიცაა:

 

ხარჯების კონტროლიორები ProjectVIEW ხარჯების კონტროლიორისთვის, პროექტის მენეჯერები ProjectVIEW პროექტის მენეჯერისთვის, ხარჯთაღრიცხველები, რაოდენობების ინჟინრები (quantity surveyors), დამგეგმავები, კონტრაქტების მენეჯერები, შესყიდვების სპეციალისტები, ქვეკონტრაქტორების მენეჯერები, მშენებლობის მენეჯერები, მასალების კონტროლიორები, საწყობის მენეჯერები, წარმოებისა და ფაბრიკაციის მენეჯერები, ტექნიკის მენეჯერები, ადამიანური რესურსებისა და შრომის მწარმოებლურობის გუნდები, ფინანსური მენეჯერები, დოკუმენტების კონტროლიორები, ხარისხის მენეჯერები, HSE მენეჯერები, IT გუნდები, ციფრული ტრანსფორმაციის მენეჯერები და უმაღლესი რგოლის ხელმძღვანელები.

 

ესენი არიან საწარმოს მომხმარებლები.

 

მაგრამ მათ გარშემო გარე დაინტერესებული მხარეები არიან:

 

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

 

ამ დაინტერესებულ მხარეებს შეიძლება არ სჭირდებოდეთ წვდომა მთელ ERP-ზე.

 

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

 

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

 


 

1. მშენებლობა და ინფრასტრუქტურა

 

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

 

ძირითადი დაინტერესებული მხარეები შეიძლება იყვნენ:

 

 

დაინტერესებული მხარეების ეს სტრუქტურა შეესაბამება FIDIC-ისა და buildingSMART-ის მიერ პოპულარიზებულ უფრო ფართო სახელშეკრულებო და ღია მონაცემების მოდელებს.

 

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

 

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

 

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

 

მაგრამ რეალური ბიზნეს-შედეგები შეიძლება მოიცავდეს:

 

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

 

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

 

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

 

მესაკუთრისთვის ეს კაპიტალური ხარჯისა და მიწოდების საკითხად იქცა.

 

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

 

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

 

მზღვეველისთვის ამან შეიძლება შეცვალოს პროექტის საინჟინრო რისკის პროფილი.

 

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

 

ProjectVIEW-ის კონსულტანტის ERP მოდელი ProjectVIEW სამშენებლო კონსულტანტებისთვის უკვე განსაზღვრავს სამშენებლო მოედნის რეალურ დროში ხილვადობას, სამშენებლო დოკუმენტაციას, საპროექტო დამტკიცებებს, QC/QA ინფორმაციასა და ცვლილებების მართვას, როგორც კონსულტანტის ზედამხედველობის მნიშვნელოვან ელემენტებს.

 


 

2. საზღვაო და ოფშორული მშენებლობა

 

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

 

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

 

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

 

ProjectVIEW-ის დაინტერესებულ მხარეთა მოდელი მოიცავს:

 

 

მათთან ერთად:

 

  • EPC კონტრაქტორები
  • საინჟინრო კონსულტანტები
  • გემების მესაკუთრეები / ოპერატორები
  • წყალქვეშა სამუშაოების კონტრაქტორები
  • ფაბრიკაციის ეზოები
  • დრაგირების კონტრაქტორები
  • აღჭურვილობის მომწოდებლები
  • პორტის ადმინისტრაციები
  • ბანკები
  • საინჟინრო და საზღვაო მზღვეველები
  • სურვეიერები
  • სახელმწიფო უწყებები

 

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

 

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

 

შედეგი შეიძლება იყოს:

 

საინჟინრო ცვლილება → შეცვლილი სამუშაო პაკეტი → გემის დამატებითი დღეები → სპეციალიზებული ეკიპაჟი → აღჭურვილობის მობილიზაცია → შესყიდვები → გავლენა განრიგზე → დამატებითი ხარჯი → დამკვეთთან ცვლილება

 

საინჟინრო კონსულტანტს ტექნიკური მიკვლევადობა სჭირდება.

 

კონტრაქტორს რესურსებისა და ხარჯების კონტროლი სჭირდება.

 

E&P მესაკუთრეს გავლენისა და ავტორიზაციის ხილვადობა სჭირდება.

 

გემის ოპერატორს განახლებული მოთხოვნები სჭირდება.

 

კომერციულ მენეჯერს სახელშეკრულებო შედეგი სჭირდება.

 

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

 

ProjectVIEW-ის როლი არ არის სპეციალიზებული ოფშორული ინჟინერიის, გემების მართვის ან კვლევის სისტემების ჩანაცვლება. მისი როლია ფიზიკური შესრულების საწარმოო შედეგების დაკავშირება.

 

ამ განსხვავებას მნიშვნელობა აქვს.

 


 

3. სამთო მრეწველობა და კარიერები

 

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

 

ის შეიძლება ერთდროულად მოიცავდეს:

 

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

 

სამთო სახელმძღვანელო პრინციპების გლობალური ჯგუფი — GMG Global Mining Guidelines Group აღწერს სამთო საზოგადოებას, რომელშიც ჩართულნი არიან მაღაროების ოპერატორები, OEM-ები, ტექნოლოგიების მიმწოდებლები, მომწოდებლები, კონსულტანტები, კვლევითი ორგანიზაციები და სხვა დაინტერესებული მხარეები, ხოლო მისი მმართველობა პირდაპირ უჭერს მხარს დარგობრივ მრავალმხრივ თანამშრომლობას.

 

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

 

 

რომლებიც გარშემორტყმულნი არიან:

 

  • EPCM კონსულტანტებით
  • სამთო ინჟინრებით
  • გეოლოგებით
  • ბურღვისა და აფეთქების კონტრაქტორებით
  • მძიმე ტექნიკის OEM-ებით
  • გადამამუშავებელი საწარმოების კონტრაქტორებით
  • ინფრასტრუქტურის კონტრაქტორებით
  • მომწოდებლებით
  • ბანკებითა და ინვესტორებით
  • საინჟინრო მზღვეველებით
  • გარემოსდაცვითი კონსულტანტებით
  • მარეგულირებლებით
  • ESG და მარწმუნებელი (assurance) გუნდებით

 

მაგალითი: გადამამუშავებელი საწარმოს გაფართოება

 

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

 

ეს მხოლოდ შესყიდვების საკითხი არ არის.

 

მისი გავლენა შეიძლება გავრცელდეს შემდეგ ჯაჭვზე:

 

მომწოდებლის დაგვიანება → მონტაჟის თანმიმდევრობა → WBS → ტექნიკა → სამუშაო ძალა → ქვეკონტრაქტორები → ექსპლუატაციაში გაშვება → წარმოებისთვის მზადყოფნა → ფულადი ნაკადები → პროექტის პროგნოზი

ჩვეულებრივ შესყიდვების სისტემას შეუძლია დაგვიანებული შესყიდვის შეკვეთის იდენტიფიცირება.

 

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

 

სამშენებლო პლატფორმას შეუძლია საველე პრობლემის გამოვლენა.

 

ProjectVIEW-ის დანიშნულებაა ეს რეალობები დაუკავშიროს საწარმოს ხარჯების, რესურსების, სახელშეკრულებო და ფინანსურ მოდელს.

 

ProjectVIEW-ის მაღაროსა და კარიერის მესაკუთრის მოდელი მაღაროს მესაკუთრის პროექტის კონტროლის ERP სპეციალურად პროექტის კონტროლსა და მესაკუთრის ხილვადობაზეა ორიენტირებული, ხოლო სამთო კონტრაქტორის მოდელი სამთო კონტრაქტორის ERP კონტრაქტორის მიერ შესრულებას ეხება.

 


 

4. გემთმშენებლობა და გემების რემონტი

 

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

 

მშენებარე გემი ეკოსისტემის ცენტრშია, რომელიც მოიცავს:

 

 

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

 

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

 

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

 

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

 

ამან შეიძლება გამოიწვიოს:

 

საპროექტო რევიზია → მასალის ცვლილება → შესყიდვები → ფაბრიკაცია → აღჭურვა → ხელახალი ინსპექცია → WBS-ის ცვლილება → გავლენა სამუშაო ძალაზე → გავლენა ხარჯზე → გემთმფლობელის დამტკიცება → კონტრაქტის ცვლილება

 

გემთმშენებელი ინჟინრისთვის ეს საინჟინრო საკითხია.

 

საკლასიფიკაციო საზოგადოებისთვის ეს შესაბამისობის საკითხია.

 

გემსაშენი ქარხნისთვის ეს წარმოების საკითხია.

 

გემთმფლობელისთვის ეს ხარჯისა და მიწოდების საკითხია.

 

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

 

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

 

ProjectVIEW-ის გემთმშენებლობის ERP-ის არქიტექტურა ProjectVIEW გემთმშენებლობის ERP გემის გარშემო აკავშირებს ბიუჯეტირებას, შესყიდვებს, განრიგის მართვას, ხარჯთაღრიცხვას, ფაბრიკაციას, მასალების მოხმარებას, სამუშაო ძალას, ქვეკონტრაქტორებს, დოკუმენტებსა და საწარმოო აქტივობებს. პლატფორმა ასევე მოიცავს დაინტერესებულ მხარეებზე ორიენტირებულ საერთო მონაცემთა გარემოს (Common Data Environment) პროექტების, ინსპექციებისა და ხარისხის დოკუმენტაციის კონტროლირებადი გავრცელებისთვის.

 

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

 


 

5. პროექტზე დაფუძნებული წარმოება და ფაბრიკაცია

 

მშენებლობა სამშენებლო მოედანზე არ იწყება.

 

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

 

  • ფოლადის კონსტრუქციები
  • მოდულური მშენებლობა
  • MEP ასამბლეები
  • ტექნოლოგიური ბლოკები (Process Skids)
  • მილების სექციები (Pipe Spools)
  • ანაკრები ელემენტები
  • ოფშორული მოდულები
  • საზღვაო ფაბრიკაცია
  • შეკვეთით დაპროექტებული (Engineer-to-Order) აღჭურვილობა

 

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

 

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

 

  • მესაკუთრეს
  • EPC კონტრაქტორს
  • გენერალურ კონტრაქტორს
  • დამამზადებელს / მწარმოებელს
  • კონსტრუქტორ ინჟინერს
  • დეტალიზაციის სპეციალისტს
  • მასალის მომწოდებელს
  • QA/QC გუნდს
  • დამოუკიდებელ ინსპექტორს
  • ლოჯისტიკის პროვაიდერს
  • ბანკს / სავაჭრო დაფინანსების პროვაიდერს
  • მზღვეველს

 

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

 

თუ ინჟინერი კონსტრუქციულ ელემენტს შეცვლის, გავლენა შეიძლება გავრცელდეს შემდეგ ჯაჭვზე:

 

პროექტი → რაოდენობა → BOM → მასალის მოთხოვნა → შესყიდვა → ჭრა → ფაბრიკაცია → შედუღება → ინსპექცია → ლოჯისტიკა → მონტაჟი ობიექტზე → ხარჯი

 

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

 

უმეტესობას შეუძლია.

 

მთავარი პრობლემაა:

 

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

 

სწორედ აქ ხდება საწარმოს ინტეგრაცია კრიტიკული.

 

მაგრამ განა სხვა სამშენებლო პლატფორმები უკვე არ აკავშირებენ დაინტერესებულ მხარეებს?

 

დიახ.

 

და ამის ზუსტად თქმა მნიშვნელოვანია.

 

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

 

შეუძლიათ.

 

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

 

Autodesk Construction Cloud / Autodesk Docs

 

Autodesk Docs Autodesk Docs არის ღრუბლოვანი საერთო მონაცემთა გარემო (Common Data Environment), რომელიც დოკუმენტებისა და მონაცემების მართვაზეა ორიენტირებული. Autodesk მის მომხმარებლებს შორის ასახელებს არქიტექტორებს, დიზაინერებს, ინჟინრებს, კონტრაქტორებს, ქვეკონტრაქტორებს, BIM/VDC მენეჯერებს, პროექტის მენეჯერებს, მესაკუთრეებსა და დამამზადებლებს.

 

Autodesk ასევე მხარს უჭერს ხარჯების მართვაში კონტროლირებად თანამშრომლობას კონტრაქტორებს, მესაკუთრეებს, მომწოდებლებს, არქიტექტორებსა და კონსულტანტებს შორის.

 

შესაბამისად, მისი სიმძიმის ცენტრი მჭიდროდ არის დაკავშირებული:

 

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

 

ეს ღირებულია.

 

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

 

Procore

 

Procore Financial Management Procore-ის სამშენებლო ფინანსური მართვა აკავშირებს საველე ინფორმაციას პროექტის ბიუჯეტებთან, პროგნოზირებასთან, ინვოისირებასა და მშენებლობის ფინანსურ პროცესებთან.

 

Procore ასევე ღიად უწყობს ხელს ბუღალტრულ და ERP სისტემებთან ინტეგრაციას და აცხადებს, რომ მისი ეკოსისტემა 500-ზე მეტ ინტეგრაციას მოიცავს.

 

ეს არქიტექტურა განსხვავებას ნათლად აჩვენებს:

 

სამშენებლო / საპროექტო პლატფორმა ↔ ERP / ბუღალტრული სისტემა

 

Procore-მა ასევე გააფართოვა მესაკუთრის მხრიდან ხარჯების მართვა და პორტფელის ხილვადობა.

 

შესაბამისად, ის ფართოდ უწყობს ხელს დაინტერესებულ მხარეთა თანამშრომლობას — თუმცა მისი არქიტექტურა, როგორც წესი, ცალკე საწარმოს ბუღალტრულ ან ERP შრესთან ერთად არსებობს.

 

Oracle Aconex

 

Oracle Aconex ძირითადად ორგანიზაციათაშორისი საპროექტო ინფორმაციისა და თანამშრომლობის შრეში მოქმედებს.

 

Oracle-ის საკუთარი Smart Construction Platform-ის დოკუმენტაცია აჩვენებს Aconex-სა და Primavera Unifier-ს შორის აშკარა სინქრონიზაციას. Oracle Smart Construction Platform-ის ინტეგრაციები

 

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

 

Oracle Primavera Unifier

 

Oracle Primavera Unifier Oracle Smart Construction Platform-ის ინტეგრაციები მოიცავს კაპიტალური პროექტების კონტროლს, ბიზნეს-პროცესებსა და ფინანსურ სამუშაო პროცესებს.

 

Oracle გთავაზობთ ინტეგრაციის რეცეპტებს, რომლებიც Unifier-ს აკავშირებს Oracle Fusion Cloud ERP Procurement and Financials-თან.

 

ეს კიდევ ერთი მნიშვნელოვანი არქიტექტურული მაგალითია:

 

კაპიტალური პროექტების კონტროლი ↔ საწარმოს ERP

 

Autodesk Digital Project Delivery

 

Autodesk აღწერს Digital Project Delivery-ს Autodesk Digital Project Delivery როგორც საერთო ღრუბლოვან მიდგომას, რომელიც მრავალდისციპლინურ მონაცემებს აკავშირებს ისეთი დაინტერესებული მხარეებისთვის, როგორიცაა მესაკუთრეები, არქიტექტორები, კონტრაქტორები, ინჟინრები და სპეციალიზებული ხელოსნები.

 

ესეც პრობლემის მნიშვნელოვან ნაწილს ეხება:

 

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

 

ProjectVIEW სხვა განზომილებას ეხება:

 

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

 


 

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

 

ეს არის ProjectVIEW-ის მთავარი არგუმენტი.

 

  • საერთო მონაცემთა გარემოს (Common Data Environment) შეუძლია ყველას უთხრას, რომელი ნახაზია მიმდინარე.
  • BIM პლატფორმას შეუძლია აქტივის ციფრული აღწერა.
  • დაგეგმვის სისტემას შეუძლია ყველას უთხრას, როდის უნდა შესრულდეს სამუშაო.
  • სამშენებლო მართვის პლატფორმას შეუძლია RFI-ების, საკითხებისა და საველე პროცესების კოორდინაცია.
  • ზოგად ERP-ს შეუძლია შესყიდვების, ხელფასების, ინვოისებისა და ბუღალტრული გატარებების აღრიცხვა.

 

ყველა ეს სისტემა ღირებულებას ქმნის.

 

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

 

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

 

შესაბამისად, ProjectVIEW-ის შეთავაზებაა:

 

კომპანიაზე ორიენტირებული არქიტექტურა.

 

ERP მოქმედებს მთელ საწარმოში — და არა მხოლოდ ცალკეული პროექტის შიგნით.

 

პროექტზე ორიენტირებული ბიზნეს-ლოგიკა.

 

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

 

აქტივზე ორიენტირებული ოპერაციული რეალობა.

 

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

 

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

 

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

 

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

 

რას იღებს თითოეული დაინტერესებული მხარე?

 

მესაკუთრე / დეველოპერი

 

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

 

კონტრაქტორი / EPC

 

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

 

საინჟინრო კონსულტანტი / PMC

 

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

 

დიზაინერი / არქიტექტორი / გემთმშენებელი ინჟინერი

 

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

 

ბანკი / კრედიტორი / ტექნიკური მრჩეველი

 

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

 

ProjectVIEW არ ანაცვლებს ბანკის დაკრედიტების ან რისკების მართვის პლატფორმას.

 

საინჟინრო ან საზღვაო მზღვეველი

 

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

 

ProjectVIEW არ ანაცვლებს ანდერრაიტინგის, საინჟინრო კვლევების ან ზარალის მართვის სისტემებს.

 

ქვეკონტრაქტორი

 

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

 

მომწოდებელი

 

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

 

აუდიტორი

 

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

 

უმაღლესი რგოლის ხელმძღვანელობა

 

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

 


 

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

 

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

 

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

 

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

 

სწორედ ეს არის ProjectVIEW ERP-ის შესაძლებლობა.

 

ყველას არ სჭირდება ERP-ში მუშაობა.

 

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

 

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

 

ხელმძღვანელობისთვის კი ის კიდევ უფრო ფუნდამენტურ რამეს ქმნის:

 

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

 

ეს არის ProjectVIEW-ის ხედვის საფუძველი:

 

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

 

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

 

ერთი მართვადი ოპერაციული რეალობა.

 


 

FAQ

ხშირად დასმული კითხვები

რა არის დაინტერესებულ მხარეთა თანამშრომლობა სამშენებლო ERP-ში?

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

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

შეუძლიათ თუ არა ProjectVIEW ERP-ის გამოყენება როგორც კონტრაქტორებს, ისე პროექტის მესაკუთრეებს?

დიახ.

ProjectVIEW-ს აქვს სპეციალური მოდელები გენერალური კონტრაქტორებისთვის ProjectVIEW გენერალური კონტრაქტორისთვის და მესაკუთრეებისთვის / დეველოპერებისთვის ProjectVIEW მესაკუთრე/დეველოპერისთვის.

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

შეუძლიათ თუ არა საინჟინრო კონსულტანტებს ProjectVIEW ERP-ის გამოყენება?

დიახ.

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

შეუძლიათ თუ არა ბანკებსა და კრედიტორებს ProjectVIEW-ის ინფორმაციის გამოყენება?

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

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

ProjectVIEW-ს შეუძლია ამ საბაზისო მტკიცებულებების მომზადებასა და სტრუქტურირებაში დახმარება.

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

რა სარგებელი შეიძლება მიიღონ მზღვეველებმა ProjectVIEW ERP-ისგან?

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

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

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

დარგობრივი წყაროებია IMIA საინჟინრო მზღვეველთა საერთაშორისო ასოციაცია და IUMI საზღვაო დაზღვევის საერთაშორისო კავშირი.

ანაცვლებს თუ არა ProjectVIEW BIM პროგრამულ უზრუნველყოფას?

არა.

BIM და საინჟინრო პროექტირების აპლიკაციები სპეციალიზებულ პროექტირებისა და მოდელირების ფუნქციებს ასრულებენ.

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

ღია თავსებადობის მიდგომები, როგორიცაა openBIM buildingSMART openBIM, ამ არქიტექტურისთვის კვლავ ძალიან რელევანტურია.

ანაცვლებს თუ არა ProjectVIEW საერთო მონაცემთა გარემოს (Common Data Environment)?

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

თუმცა ორგანიზაციებს შეუძლიათ ProjectVIEW-ს ინტეგრაცია სპეციალიზებულ CDE, BIM და საინჟინრო აპლიკაციებთანაც, მათი ტექნოლოგიური არქიტექტურის მიხედვით.

რით განსხვავდება ProjectVIEW Procore-ისგან?

Procore Procore Financial Management ძლიერ პოზიციონირებულია მშენებლობის მართვის, პროექტის შესრულებისა და მშენებლობის ფინანსური სამუშაო პროცესების გარშემო და ამავდროულად მხარს უჭერს ბუღალტრულ და ERP სისტემებთან ინტეგრაციას.

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

რით განსხვავდება ProjectVIEW Autodesk Construction Cloud-ისგან?

Autodesk Docs / Autodesk Construction Cloud Autodesk Docs ძლიერ არის ორიენტირებული პროექტირებიდან მშენებლობამდე ინფორმაციაზე, დოკუმენტებზე, მოდელებზე, თანამშრომლობასა და საველე/საპროექტო სამუშაო პროცესებზე.

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

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

რით განსხვავდება ProjectVIEW Oracle Aconex-ისა და Primavera Unifier-ისგან?

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

თავად Oracle გთავაზობთ ინტეგრაციებს Aconex-ს, Unifier-სა და Oracle Fusion ERP-ს შორის. Oracle Smart Construction Platform-ის ინტეგრაციები

ProjectVIEW-ის შეთავაზებაა პროექტზე ორიენტირებული ბიზნეს-ლოგიკისა და საწარმოს ტრანზაქციების გაერთიანება ერთ სპეციალიზებულ ERP გარემოში სამშენებლო სამყაროსთვის (Build World).

რომელ ინდუსტრიებს შეუძლიათ ProjectVIEW-ის დაინტერესებულ მხარეთა მოდელის გამოყენება?

ProjectVIEW თავის ბიზნეს-ლოგიკას იყენებს შემდეგ სფეროებში:

მშენებლობა და ინფრასტრუქტურა

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

სამთო მრეწველობა და კარიერები ProjectVIEW მაღაროს მესაკუთრისთვის

გემთმშენებლობა და გემების რემონტი ProjectVIEW გემთმშენებლობის ERP

პროექტზე დაფუძნებული წარმოება ProjectVIEW პროექტზე დაფუძნებული წარმოების ERP

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

საბაზისო მმართველობითი გამოწვევა კი საოცრად მსგავსი რჩება:

მოცულობა + დრო + ხარჯი + რესურსები + კონტრაქტები + დაინტერესებული მხარეები + ფაქტობრივი შესრულება.

რა არის ProjectVIEW ERP-ის მთავარი დანიშნულება?

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

 

მარტივად რომ ვთქვათ:

 

რას ვაშენებთ? როდის უნდა ავაშენოთ? რა უნდა ღირდეს? რა ხდება რეალურად? რა დაჯდა რეალურად? ვის სჭირდება ამის ცოდნა?

 

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

 

Christos Emmanouilidis

About the author

ინჟ. Christos Emmanouilidis

მომხმარებლებთან ურთიერთობისა და კომერციული დირექტორი, DANAOS Projects

Eng. Christos Emmanouilidis is Chief Customer & Commercial Officer at DANAOS Projects and a subject-matter expert in construction cost control, industry-specific ERP and the digital transformation of project-based enterprises. A Civil Engineer with more than 25 years of international experience in engineering, construction management, quality and commercial strategy, he leads the global market development of ProjectVIEW ERP for construction, infrastructure,…