საზღვაო მშენებლობა და upstream პროექტები ოფშორში არ იწყება. ისინი ბიუჯეტში იწყება.
ფაქტობრივად, ბიუჯეტირების დროს სამუშაოების რაოდენობრივი უწყისი (BoQ) და სამუშაოების დაშლის სტრუქტურა (WBS) უკვე განსაზღვრავს:
- რა სამუშაოს შეასრულებს გუნდი (საქმიანობის აღწერა – WBS)
- რა რაოდენობით და ინტენსივობით (BoQ)
- რა დროის ფანჯარაში (მოახლოებითი გრაფიკი)
შედეგად, ამ მომენტიდან სამშენებლო გემებისა და მძიმე საზღვაო აღჭურვილობის ტიპი და კატეგორია აღარ არის ვარაუდი — ეს არის ბიუჯეტში გათვალისწინებული პროექტის რესურსები.
მაგალითად, საძირკვლის ჩასობის საქმიანობა გულისხმობს პილოტის ჩასობის გემს ან jack-up-ს. ანალოგიურად, თხრილის ამოღების BoQ გულისხმობს CSD-ს, backhoe dredger-ს ან შემცვლელ ფლოტაციას. საბოლოოდ, ღრმა წყალში მონტაჟის საქმიანობა გულისხმობს DP-ს მქონე სამშენებლო გემს.
ამიტომ, სწორედ აქ იწყება ProjectVIEW ERP — პროექტის მობილიზაციამდე.
BoQ-დან და WBS-დან გემის ტიპამდე და ჩანაცვლების ლოგიკამდე
პრაქტიკაში ProjectVIEW პირდაპირ აკავშირებს:
- BoQ რაოდენობები → სამუშაო დატვირთვის ინტენსივობა
- WBS საქმიანობები → შესრულების მეთოდი
- შესრულების მეთოდი → გემის კატეგორია და დასაშვები ჩანაცვლებები
შემდეგ, თითოეული საქმიანობისთვის ProjectVIEW განსაზღვრავს:
- ძირითად გემის ტიპს
- დამტკიცებულ შემცვლელ გემებს
- ოპერირების რეჟიმს (DP, ანკერით, spud, ნაოსნობა)
- მოსალოდნელ პროდუქტიულობის მაჩვენებელს
- დაკავშირებულ ეკიპაჟსა და ოპერატორებს
შედეგად, ეს გამორიცხავს ბუნდოვან დაგეგმვას, მაგალითად:
„იმ დროს, ალბათ, დაგვჭირდება ამწე ბარჯი.”
ამის ნაცვლად, სისტემამ იცის:
„ეს საქმიანობა მოიხმარს 420 საოპერაციო საათს DP-ს მქონე ამწე გემზე ან დამტკიცებულ ანკერით მდგომ ალტერნატივაზე.”
ბიუჯეტირება შეუძლებელია ტექნიკური მომსახურების, HR-ის და ინსტრუმენტების შესაბამისობის გარეშე
თუმცა, სწორედ აქ ინგრევა სისტემების უმეტესობა.
ბოლოს და ბოლოს, გემის ხელმისაწვდომობის ბიუჯეტირება შეუძლებელია იმის ცოდნის გარეშე:
- ტექნიკური მომსახურების ფანჯრები
- დახარჯული საოპერაციო საათები
- ეკიპაჟის სერტიფიცირება და როტაციები
- ინსტრუმენტების და სათადარიგოების მზადყოფნა
ამ მიზეზით, ProjectVIEW ბიუჯეტირებას აიძულებს, რომ შეესაბამებოდეს:
- სამუშაო საათებთან დაკავშირებულ ტექნიკური მომსახურების გრაფიკებს
- ინსტრუმენტებისა და დამხმარე აღჭურვილობის ხელმისაწვდომობას
- ეკიპაჟს, ოპერატორებსა და სერტიფიკატებს
- სათადარიგო ნაწილების კრიტიკულობას
მოკლედ, შედეგი არის დავარაუდებული, მაგრამ რეალისტური ხელმისაწვდომობა და არა ოპტიმისტური გამონაგონი.
მაგალითად, გემი არ არის „ხელმისაწვდომი“, თუ:
- მას 80 საათი დარჩა სავალდებულო მომსახურებამდე
- სერტიფიცირებული DP ეკიპაჟი ხელმისაწვდომი არ არის
- კრიტიკული სათადარიგოები მარაგში არ არის
- შემცვლელი გემი არღვევს პროექტის შეზღუდვებს
შესაბამისად, ProjectVIEW ამ კონფლიქტებს ბლოკავს ბიუჯეტირების ეტაპზე და არა ოფშორში.
დაგეგმვა და მობილიზაცია რესურსების გათანაბრების გზით
როგორც კი ბიუჯეტი მზად არის, ProjectVIEW გადადის დაგეგმვასა და მობილიზაციაზე. იქ ის ყველაფერს აწყობს დროისა და საქმიანობის თანმიმდევრობის მიხედვით:
- გემები
- შემცვლელი ფლოტები
- მძიმე ტექნიკა
- ოპერატორები და ეკიპაჟი
- ინსტრუმენტები და დამხმარე აღჭურვილობა
თუმცა, არავინ გეგმავს იზოლირებულად.
ამის ნაცვლად, ProjectVIEW აწყობს:
- გემის ხელმისაწვდომობა WBS საქმიანობებთან მიმართებით
- ეკიპაჟის როტაციები ოპერირების რეჟიმებთან მიმართებით
- ტექნიკური მომსახურების ფანჯრები კრიტიკულ გზასთან მიმართებით
- შემცვლელები, როდესაც შეზღუდვები ზღუდავს ძირითად აქტივებს
სხვა სიტყვებით, მობილიზაცია არ არის თარიღი — ეს არის რესურსების დროში გათანაბრების შედეგი.
პროექტის მიერ მოხმარებული საათები განაპირობებს ტექნიკურ მომსახურებას და ხელმისაწვდომობას
შესრულების დაწყებისთანავე ProjectVIEW აკვირდება რეალურად პროექტის მიერ მოხმარებულ საოპერაციო საათებს:
- თითო გემზე
- თითო ოპერირების რეჟიმზე
- თითო პროექტზე
- თითო საქმიანობაზე
თავის მხრივ, ProjectVIEW ტექნიკურ მომსახურებას იწვევს შემდეგით:
- საოპერაციო საათები
- დრეჯირების საათები
- ამწის აწევის საათები
- DP საათები
- ძრავის ან დამხმარე სისტემების გამოყენება
და არა კალენდარული ვარაუდებით.
შემდეგ, როცა გამოყენება ზღვარს მიაღწევს:
- სისტემა ავტომატურად გეგმავს ტექნიკურ მომსახურებას
- ის ბლოკავს აქტივის ხელმისაწვდომობას
- ის იწვევს სათადარიგოებსა და მომსახურებებს
- ის ახდენს ხარჯების ჩარიცხვას იმ პროექტზე, რომელმაც ეს საათები მოიხმარა
შედეგად, ეს ქმნის პროექტულ ანგარიშვალდებულებას და არა ფლოტის დონის ბუნდოვანებას.
ოპერატორისა და ეკიპაჟის შესაბამისობა არის სავალდებულო, არა ვარაუდი
გემი სწორი ეკიპაჟის გარეშე არის რისკი.
ამიტომ, ProjectVIEW აწესებს:
- ოპერატორისა და გემის თავსებადობას
- სერტიფიკატის ვალიდურობას
- გამოცდილებას გემის კლასის მიხედვით
- დაღლის, როტაციისა და შესაბამისობის წესებს
მოკლედ, გუნდი ეკიპაჟს გეგმავს გემთან ერთად და არა შემდეგ.
რატომ შეუძლია ამის გაკეთება მხოლოდ ProjectVIEW ERP-ს
ამის საპირისპიროდ, ზოგადი ERP-ები მართავენ:
- აქტივებს როგორც სტატიკურ რეესტრებს
- ტექნიკურ მომსახურებას როგორც ბუღალტრულ მოვლენებს
- ეკიპაჟს როგორც HR ჩანაწერებს
- დაგეგმვას გათიშული ინსტრუმენტებით
თუმცა, საზღვაო მშენებლობა ასე არ მუშაობს.
ProjectVIEW ERP არის ერთადერთი პროექტზე ორიენტირებული სისტემა, რომელიც კოორდინაციას უწევს:
- გემებსა და მძიმე აღჭურვილობას
- დამტკიცებულ ჩანაცვლებებს
- პროექტის მიერ მოხმარებულ საათებზე დაფუძნებულ ტექნიკურ მომსახურებას
- ოპერატორები და ეკიპაჟი
- ინსტრუმენტებსა და სათადარიგოებს
- ბიუჯეტირებას, დაგეგმვას, მობილიზაციას და შესრულებას
ის ამას აკეთებს ერთ პროექტულ კონტექსტში, სადაც BoQ, WBS, დრო და ღირებულება არეგულირებს ყველა გადაწყვეტილებას.
საბოლოო შეჯამება
საზღვაო მშენებლობა არ არის აქტივების ფლობა. ეს არის დროის მიმართ შეზღუდული, ძვირადღირებული, მაღალი რისკის რესურსების კოორდინაცია.
ProjectVIEW ERP არ კითხულობს:
„გვაქვს თუ არა გემი?“
ამის ნაცვლად, ის კითხულობს:
„შეუძლია თუ არა ამ პროექტს ამ საქმიანობის შესრულება, ამ დროს, ამ გემით, ამ ეკიპაჟით და დარჩენილი ტექნიკური მომსახურების ამ რესურსით?“
საბოლოოდ, სწორედ ეს არის განსხვავება დაგეგმვასა და კონტროლს შორის.
