გემთმშენებლობა, drydocking-ი, რეტროფიტები და გემის მასშტაბური განახლება ჩვეულებრივი გემთმართვის საქმიანობა არ არის. ეს არის კაპიტალური პროექტები. ხოლო კაპიტალურ პროექტებს სჭირდებათ პროექტის დონეზე კონტროლი.
გემის მფლობელისთვის ან გემთმმართველისთვის გემის საზღვაო ქარხანაში გაგზავნა ქმნის დროებით, მაგრამ კრიტიკულ საოპერაციო გარემოს, რომელშიც მონაწილეობენ მფლობელის ტექნიკური გუნდი, საზღვაო ქარხანა, ქვეკონტრაქტორები, მომწოდებლები, კლასიფიკაციის საზოგადოებები, აღჭურვილობის მწარმოებლები, ბანკები, ჩარტერები და მზღვეველები.
მილიონობით დოლარის ვალდებულება შეიძლება აიღონ რამდენიმე კვირაში. ასეულობით ან ათასობით სამუშაო ელემენტი შეიძლება ერთდროულად შესრულდეს. სპეციფიკაციები იცვლება. დამატებითი სამუშაოები ჩნდება მექანიზმების გახსნის ან ფოლადის შემოწმების შემდეგ. მიწოდების თარიღები კომერციულად კვლავ კრიტიკულია.
თუმცა მენეჯმენტი ხშირად ასეულობით ან ათასობით კილომეტრის მოშორებით იმყოფება.
ფუნდამენტური კითხვა ხდება:
როგორ მიიღოს გემთმმართველმა „თვალები საზღვაო ქარხნის შიგნით“ ისე, რომ ფიზიკურად ყველგან არ იყოს?
პასუხი არ არის კიდევ ერთი დაფა. ეს არის საზღვაო პროექტების მართვის პლატფორმა, რომელიც აერთებს მასშტაბს, გრაფიკს, ხარჯებს, შესყიდვებს, ხარისხს, დოკუმენტაციას და რეალურ შესრულებას ერთ კონტროლირებულ გარემოში.
ხილვადობის ხარვეზი გემთმმართველსა და საზღვაო ქარხანას შორის
ტრადიციული გემთმართვის ERP სისტემები შესანიშნავად მართავენ გემების საოპერაციო ცხოვრებას: ტექნიკურ მართვას, დაგეგმილ ტექნიკურ მომსახურებას, შესყიდვებს, ეკიპაჟს, ბუღალტერიას, შესაბამისობას და სრუტის ოპერაციებს.
მაგრამ მასშტაბური drydock-ი, კონვერსია, რეტროფიტი ან ახალი მშენებლობის პროგრამა სხვაგვარად მუშაობს.
მას აქვს განსაზღვრული მასშტაბი, ბიუჯეტი და დასრულების თარიღი. მასში მონაწილეობენ კონტრაქტორები და ქვეკონტრაქტორები. სამუშაო უნდა გაიზომოს პროგრესთან მიმართებით. ცვლილებებს დამტკიცება სჭირდება. შესყიდვები უნდა უჭერდეს მხარს დაგეგმილ სამუშაოებს. ინსპექტირება და ხარისხის ჩანაწერები უნდა მიყვებოდეს შესრულებას.
ყველაზე მნიშვნელოვანია, დრო და ხარჯი უწყვეტად ურთიერთქმედებს.
როცა ეს საქმიანობები იმართება ცხრილებით, ელფოსტებით, შეტყობინებების აპლიკაციებით, იზოლირებული დაგეგმვის ინსტრუმენტებით და ქარხნიდან მიღებული ანგარიშებით, მენეჯმენტი იღებს პროექტის ფრაგმენტებს და არა თვითონ პროექტს.
შედეგი არის ხილვადობის ხარვეზი.
იმის ცოდნა, რომ შესყიდვის შეკვეთა გაიცა, საკმარისი არ არის. მენეჯმენტმა უნდა იცოდეს რომელ სამუშაო პაკეტს სჭირდებოდა ის, არის თუ არა ეს სამუშაო გრაფიკში, არის თუ არა მასალა ადგილზე, რა ღირს ის ბიუჯეტთან მიმართებით და ემუქრება თუ არა დაგვიანება გემის მიწოდებას.
Drydocking-ი პროექტია — მართეთ ის როგორც პროექტი
წარმოიდგინეთ მასშტაბური drydock-ი.
მისვლამდე გემთმმართველს უკვე აქვს დაგეგმილი სპეციფიკაცია, რომელიც მოიცავს ფოლადის შეკეთებას, საფარებს, მექანიზმების კაპიტალურ შეკეთებას, სავალდებულო ინსპექტირებებს, კლასის მოთხოვნებს, აღჭურვილობის ჩანაცვლებას და დაგეგმილ განახლებებს.
როგორც კი გემი ქარხანაში შევა, რეალობა გეგმას შეცვლას იწყებს.
ინსპექტირებები აჩვენებს ფოლადის დამატებით განახლებას. მექანიზმებს მოულოდნელი შეკეთება სჭირდება. მომწოდებლები მიწოდების თარიღებს ცვლიან. კლასი დამატებით სამუშაოებს ითხოვს. ქარხანა წარადგენს ცვლილებებს. ერთვებიან ახალი ქვეკონტრაქტორები.
ყოველი ცვლილება პოტენციურად მოქმედებს ხარჯზე, გრაფიკსა და ხელახალ მიწოდებაზე.
ჩვეულებრივ სამუშაო პროცესს შეუძლია ამ მოვლენების დოკუმენტირება. პროექტის კონტროლის პლატფორმამ კი უფრო მნიშვნელოვანი რამ უნდა გააკეთოს:
დაუკავშიროს ისინი ერთმანეთთან.
ეს არის ProjectVIEW ERP-ის ფილოსოფია.
ProjectVIEW შექმნილია ინტეგრირებული პროექტული გარემოს ირგვლივ, რომელშიც პროცესები შეიძლება დაუკავშირდეს პროექტის განზომილებების მეშვეობით BoQ/Scope ↔ WBS/Schedule ↔ Cost Codes. პლატფორმა მხარს უჭერს პროექტების პორტფელის მართვას, სამუშაო ნაკადებს, ანალიტიკას და ცენტრალიზებულ პროექტის მონაცემებს.
გემთმმართველებისთვის ტერმინოლოგია შეიძლება მოერგოს საზღვაო ოპერაციებს: drydock-ის სპეციფიკაცია ან სამუშაო პაკეტი ხდება კომერციული მასშტაბი, WBS წარმოადგენს დაგეგმილ შესრულებას, ხოლო Cost Code-ები უზრუნველყოფს მართვისა და ფინანსური კონტროლის სტრუქტურას.
მენეჯმენტისთვის „თვალების საზღვაო ქარხანაში“ მიცემა
ციფრული ხილვადობა უნდა იწყებოდეს იქ, სადაც სამუშაო სრულდება.
პროექტის გუნდებს უნდა შეეძლოთ პროგრესის, მოთხოვნების, ინსპექტირებების, რესურსების, შესყიდვითი მოვლენების, დოკუმენტაციისა და ცვლილებების აღრიცხვა პირდაპირ ქარხნიდან და არა იმის აღდგენა მოგვიანებით, სათავო ოფისში.
ProjectVIEW-ის არქიტექტურა შექმნილია ცენტრალიზებული პროექტის ინფორმაციისა და სხვადასხვა მდებარეობიდან და მოწყობილობიდან კონტროლირებული წვდომის ირგვლივ. მისი პროექტისთვის სპეციფიკური დანერგვა გემთმშენებლობისა და შეკეთების გარემოებისთვის თანამშრომლობას ავრცელებს ოფისს, ქარხნებს, წარმოებას, მომწოდებლებს, სერვისულ კომპანიებს, ქვეკონტრაქტორებს და კლიენტებს შორის, ამასთან პროექტის პროცესებს უკავშირებს მასშტაბის, გრაფიკისა და ხარჯის განზომილებებს.
ეს ცვლის მართვის კითხვას შემდეგიდან:
“რა ხდება ქარხანაში?”
შემდეგზე:
“მაჩვენეთ, რა შეიცვალა გუშინდელის შემდეგ, რა ჩამორჩება გრაფიკს, რა აჭარბებს ბიუჯეტს და რა საჭიროებს ჩემს დამტკიცებას.”
ეს არის ნამდვილი სიტუაციური ცნობიერება.
ქარხნული პროგრესიდან რეალურ დროში ხარჯების კონტროლამდე
პროგრესი ხარჯის გარეშე არასრული ინფორმაციაა.
ხარჯი პროგრესის გარეშე შეიძლება კიდევ უფრო შეცდომაში შემყვანი იყოს.
წარმოიდგინეთ, რომ drydock-ის ბიუჯეტის 65% უკვე გახარჯულია, მაშინ როცა დაგეგმილი სამუშაოს მხოლოდ 45% არის შესრულებული. ან შესყიდვითი ვალდებულებები მნიშვნელოვნად იზრდება, მაშინ როცა რამდენიმე კრიტიკული სამუშაო პაკეტი კვლავ გრაფიკს ჩამორჩება.
მენეჯმენტმა უნდა გამოავლინოს ეს გადახრები სანამ ჩარევა ჯერ კიდევ შესაძლებელია, და არა საბოლოო ინვოისის მიღების შემდეგ.
ProjectVIEW-ის ბიზნესლოგიკა აკავშირებს ბიუჯეტსა და ხარჯების კონტროლს პროექტის გრაფიკთან და ყოველდღიურ ტრანზაქციებთან, რაც საშუალებას აძლევს ფაქტობრივი პროექტის აქტივობა შეადარონ პროექტის საბაზისო ხაზს. მისი ხარჯების მართვის მეთოდოლოგია აკავშირებს BoQ-ს/მასშტაბს, WBS-ს და Cost Code-ებს და მათ არ განიხილავს განცალკევებულ სამყაროებად.
გემთმმართველებისთვის ეს ნიშნავს, რომ drydock-ი შეიძლება გახდეს უწყვეტად კონტროლირებადი პროექტი, და არა საბოლოო ხარჯების შეჯერების პროცესი.
შესყიდვები უნდა მიჰყვებოდეს პროექტს და არა მის გვერდით იმუშაოს
საზღვაო პროექტები ძლიერად არის დამოკიდებული შესყიდვებზე.
ფოლადი, საფარები, სათადარიგო ნაწილები, სპეციალიზებული აღჭურვილობა, OEM მომსახურება და ქვეკონტრაქტით შესრულებული სამუშაოები უნდა ჩამოვიდეს მაშინ, როცა შესაბამის საქმიანობას სჭირდება.
შესყიდვის შეკვეთის „დამტკიცება“ არ ნიშნავს, რომ პროექტი დაცულია.
ნამდვილი კითხვებია:
რომელი საქმიანობა საჭიროებს მასალას? როდის არის ის საჭირო? დაადასტურა თუ არა მომწოდებელმა? ჩამოვიდა თუ არა? რა მოხდება გემის ხელახლა მიწოდებაზე, თუ არ ჩამოვა?
ProjectVIEW აერთებს მასალების მოთხოვნებს, რექვიზიციებს, RFQ-ებს, მომწოდებელთა შეთავაზებებს, შესყიდვის შეკვეთებს, მიღებებსა და მარაგის პროცესებს უფრო ფართო პროექტულ გარემოში. მისი შესყიდვის სამუშაო ნაკადი შეიძლება წარმოიშვას პროექტის მოთხოვნებიდან და მხარი დაუჭიროს მომწოდებელთა შედარებას, შესყიდვასა და მასალების მიღებას.
გემთმმართველისთვის ეს შესყიდვებს პროექტის შესრულების ნაწილად აქცევს და არა განცალკევებულ ადმინისტრაციულ ფუნქციად.
ცვლილებები არ შეიძლება იქცეს ღია ჩეკად
drydocking-ის დროს ერთ-ერთი უდიდესი კომერციული რისკი დამატებითი სამუშაოა.
ზოგი ცვლილება გარდაუვალია. პრობლემა იწყება მაშინ, როდესაც დამატებითი სამუშაოები დამტკიცდება ფრაგმენტირებული ელფოსტებით, სატელეფონო საუბრებით ან ცხრილებით, მათი ჯამური ეფექტის დაუყოვნებელი ხილვადობის გარეშე.
ყოველი ცვლილება ოთხ კითხვას უნდა პასუხობდეს:
რატომ არის ის აუცილებელი? რა დაჯდება? რას უქადის გრაფიკს? ვინ დაამტკიცა?
სტრუქტურირებული სამუშაო პროცესი ქმნის კვალდაკვალ მიყოლად ჯაჭვს მოთხოვნიდან ტექნიკურ შეფასებამდე, კომერციულ შეფასებასა და დამტკიცებამდე, შესრულების ჩათვლით.
ProjectVIEW მხარს უჭერს სამუშაო ნაკადებზე დაფუძნებულ პროცესების კონტროლს და ცენტრალიზებულ დოკუმენტაციას, რაც ეხმარება პასუხისმგებლობის ჩამოყალიბებას ცვლილებებზე და არ უშვებს უკონტროლო მასშტაბის ზრდას. მისი ქარხანაზე ორიენტირებული კონფიგურაცია კონკრეტულად მოიცავს ცვლილებების მოთხოვნების რეალურ დროში მართვას ხარჯებისა და პროგრესის კონტროლთან ერთად.
ხარისხი მტკიცებულებაა და არა განცხადება
გემის მფლობელებისა და გემთმმართველებისთვის წარმატებული მიწოდება მხოლოდ გემის drydock-იდან გამოყვანა არ არის.
პროექტმა უნდა დატოვოს აუდიტირებადი ჩანაწერი.
ინსპექტირების ანგარიშები, სერტიფიკატები, დამტკიცებული ნახაზები, ტესტირების შედეგები, ფოტოები, RFI-ები, punch list-ები, კლასის დოკუმენტაცია, აღჭურვილობის სერტიფიკატები და საბოლოო ჩანაწერები შეიძლება მოგვიანებით არსებითი მტკიცებულება გახდეს.
ეს მნიშვნელოვანია არა მხოლოდ შიდა კუთხით, არამედ მაშინაც, როცა პროექტის სტატუსისა და აქტივის მთლიანობის დემონსტრირება უნდა მოხდეს კლასიფიკაციის საზოგადოებებისთვის, ფინანსისტებისთვის, ჩარტერებისთვის, მზღვეველებისთვის და სხვა უფლებამოსილი დაინტერესებული მხარეებისთვის, მათი სახელშეკრულებო და მარეგულირებელი მოთხოვნებიდან გამომდინარე.
ამიტომ ცენტრალიზებული დოკუმენტური გარემო, კონტროლირებული წვდომით, ვერსიებით, სამუშაო ნაკადებით და პროექტთან ასოცირებით, ხდება პროექტის მმართველობის ნაწილი და არა მხოლოდ დოკუმენტების საცავი. ProjectVIEW-ის პროექტული გარემო მოიცავს ცენტრალიზებულ დოკუმენტების მართვას და კონტროლირებულ თანამშრომლობას საოპერაციო სამუშაო ნაკადებთან ერთად.
მიზანი მარტივია:
არ უთხრათ დაინტერესებულ მხარეებს, რომ სამუშაო სწორად შესრულდა. შეძლეთ ამის დამტკიცება.
ერთი პლატფორმა საზღვაო პროექტის მთელი სასიცოცხლო ციკლისთვის
იგივე პრინციპი ბევრად სცდება drydocking-ს.
გემთმმართველი შეიძლება ერთდროულად ზედამხედველობდეს ახალი მშენებლობის პროგრამას აზიაში, სკრაბერის ან ბალასტური წყლის რეტროფიტს, ძრავის კონვერსიას, დაზიანების შემდეგ მასშტაბურ შეკეთებას, გემის სიცოცხლის გაგრძელების პროგრამას და რამდენიმე დაგეგმილ drydock-ს.
თითოეულის ცალკეული ცხრილებით და ელფოსტის ჯაჭვებით მართვა პორტფელის დონეზე კონტროლს უკიდურესად ართულებს.
ცენტრალიზებულმა პროექტულმა პლატფორმამ შეუძლია საერთო ოპერაციული მოდელი შექმნას ამ პროექტებს შორის:
- მასშტაბისა და სამუშაო პაკეტების მართვა;
- პროექტის ბიუჯეტირება და ხარჯების კონტროლი;
- გრაფიკი და პროგრესი;
- შესყიდვები და მასალები;
- ქვეკონტრაქტორებისა და სერვისული კომპანიების მართვა;
- ცვლილებებისა და variation-ის კონტროლი;
- ინსპექტირება, QA/QC და დოკუმენტაცია;
- დამტკიცებები და აუდიტის ჩანაწერები;
- მართვის დაფები და პროექტების პორტფელის ანგარიშგება.
ProjectVIEW შექმნილია როგორც მრავალკომპანიურ, მრავალპროექტიან გარემო, რომელიც უზრუნველყოფს ცენტრალიზებულ პროექტის ინფორმაციასა და როლზე დაფუძნებულ ანალიტიკას, ნაცვლად იმისა, რომ ყოველი პროექტი კიდევ ერთ საინფორმაციო სილოში ჩაკეტოს.
ProjectVIEW არ არის საზღვაო ERP-ის ჩანაცვლება
ეს განსხვავება მნიშვნელოვანია.
გემთმმართველს შეიძლება უკვე ჰქონდეს ჩამოყალიბებული საზღვაო ERP, რომელიც მოიცავს გემის ოპერაციებს, ტექნიკურ მომსახურებას, შესყიდვებს, ფინანსებსა და ეკიპაჟს.
მიზანი აუცილებელი არ არის მისი ჩანაცვლება.
ProjectVIEW შეიძლება გახდეს კაპიტალმძლავრი საზღვაო პროექტების შესრულებისა და კონტროლის ფენა, ხოლო საჭიროების შემთხვევაში ინტეგრირდეს არსებულ საწარმოო, ფინანსურ, საზღვაო და სპეციალიზებულ სისტემებთან.
ProjectVIEW უზრუნველყოფს API-ფრეიმვორკს და შექმნილია მესამე მხარის აპლიკაციებთან ინტეგრაციისთვის, ხოლო მისი პროექტული გარემო იძლევა პროექტზე დაფუძნებული შესრულებისთვის საჭირო ბიზნესლოგიკას.
ამ არქიტექტურაში საზღვაო ERP აგრძელებს გემის, როგორც საოპერაციო აქტივის მართვას.
ProjectVIEW მართავს იმ აქტივზე შესრულებულ პროექტს.
ეს სრულიად განსხვავებული მოთხოვნაა.
დისტანციური ზედამხედველობიდან ციფრულ პროექტულ კონტროლამდე
გემთმმართველებს საზღვაო ქარხნებიდან მეტი ანგარიშები არ სჭირდებათ.
მათ სჭირდებათ პირდაპირი, სტრუქტურირებული და დროული ხილვადობა შესრულებაში.
მათ უნდა იცოდნენ რა იყო დაგეგმილი, რა დასრულდა, რა შეიცვალა, რა ჩაიდო ვალდებულებად, რა დაიხარჯა, რა რჩება გასაკეთებელი და რა ემუქრება მიწოდებას.
USD 20 მილიონიანი drydock-ის ან USD 500 მილიონიანი ახალი მშენებლობის პროგრამისთვის გუშინდელ ცხრილზე ლოდინი არ არის პროექტის კონტროლი.
მომავალი არის ციფრული პროექტული გარემო, სადაც მასშტაბი, დრო, ხარჯი, შესყიდვები, ხარისხი, დოკუმენტაცია და ანგარიშვალდებულება უწყვეტად ემთხვევა რეალობას.
სწორედ აქ ProjectVIEW ERP-ს შეუძლია საზღვაო მართვის სისტემების შევსება: გემის მფლობელებსა და გემთმმართველებს მისცეს პროექტის კონტროლის ფენა, რომელიც მათ სჭირდებათ, რათა ციფრული თვალები ქარხნის შიგნით განათავსონ.
