Project controls სავსეა ლამაზი ილუზიებით.
ერთ-ერთი ყველაზე მდგრადი? იდეა, რომ აქტივობის ხანგრძლივობის გადაჭარბებები — განსხვავება ფაქტიურ და დაგეგმილ ხანგრძლივობებს შორის — წარმოადგენს ეფექტიანობასა და პროდუქტიულობას.
ეს მეცნიერულად ჟღერს და ზუსტადაც გამოიყურება. გარდა ამისა, მას მოჰყვება ისეთი აბრევიატურები, როგორიცაა TPR (Time Performance Ratio).
მაგრამ აი სიმართლე: ეს ფუგაზი არის — მათემატიკური მირაჟი, რომელიც შედეგიანობის ხედვას ნიღბავს.
1. გამოგონილის შედარების გამოგონილობა
მოკლედ, TPR „ფაქტიურ ხანგრძლივობას“ „საწყის ხანგრძლივობაზე“ ყოფს და ამას შედეგიანობას უწოდებს.
თუმცა, ლოგიკა იშლება იმ წამს, როცა კითხულობთ: რას წარმოადგენს სინამდვილეში ეს რიცხვები?
- საწყისი ხანგრძლივობა ჩვეულებრივ მხოლოდ ვარაუდია — effort-driven ან time-constrained, თვითნებური რესურსული დაშვებებით.
- ამავე დროს, გუნდები ხშირად ფაქტიურ ხანგრძლივობას ტეხენ მოგვიანებით, სავარაუდო პროგრესის ან არასრული საიტური ანგარიშების საფუძველზე.
ამგვარად, როცა ერთ დაშვებას მეორეზე ყოფთ, თქვენ არ აფასებთ შედეგიანობას — თქვენ ადარებთ ფიქციას ფიქციას. ეს ანალიტიკა არაა. ეს ნუმეროლოგიაა!
2. პროგრესის ილუზია
პროექტების უმეტესობაში პროგრესს არავინ ზომავს — გუნდები მას აფასებენ.
მაგალითად, „60% დასრულებულია“ იშვიათად ნიშნავს დამონტაჟებული რაოდენობის 60%-ს. უფრო ხშირად ეს უბრალოდ ვიღაცის თავდაჯერებულობის დონეა.
როდესაც ეს სუბიექტური პროგრესი ხანგრძლივობის მეტრიკებში შედის, მიიღება შეფასების შეფასება.
შესაბამისად, სანამ TPR-ის მნიშვნელობა დეშბორდამდე მივა, მას ინტერპრეტაციის ფენები გაფილტრავს. ის უკვე აღარ ასახავს სამუშაო მოედნის შედეგიანობას.
შედეგი? ლამაზი გრაფიკები, რომლებიც რეალურს არაფერს აღწერს.
3. კრიტიკული გზის მირაჟი
Critical Path Method (CPM) ანალიზი ვარაუდობს, რომ ხანგრძლივობები ეყრდნობა რეალისტურ ბრიგადულ შემადგენლობებსა და პროდუქტიულობის მაჩვენებლებს.
მაგრამ როცა დამგეგმავები effort-driven აქტივობებს რეალურ რესურსებს არ უკავშირებენ, თქვენი კრიტიკული გზა პროგრამული უზრუნველყოფის ილუზიაა.
ამიტომ ის Primaverea-ში აჩვენებს, რა არის დაგვიანებული — და არა იმას, რა არის კრიტიკული ობიექტზე.
სხვა სიტყვებით, თქვენი გრაფიკი შეიძლება მათემატიკურად სწორი იყოს და ფიზიკურად უაზრო.
4. როცა WBS იშლება
რეალურ პროექტებში Work Breakdown Structure (WBS) ვითარდება — მაგალითად, ახალი BoQ-ების, დიზაინის ცვლილებებისა და variation order-ების მეშვეობით.
მაგრამ როცა WBS-ის განახლებები რესურსების ახალ გამოთვლებს არ იწვევს, თქვენ გუშინდელ რეალობას გასული თვის დაშვებებით მოდელირებთ.
შედეგი? ხანგრძლივობის გადაჭარბებები, რომლებიც არ ასახავს არაეფექტიანობას — ისინი ასახავს მოდელს, რომელიც მოწყვეტილია სამუშაო მოედანს.
5. დაკარგული ხერხემალი: BoQ-ზე დაფუძნებული რესურსული ლოგიკა
გრაფიკის ანალიზისთვის გონივრულობის დასაბრუნებლად ერთადერთი გზა არის მისი BoQ-WBS კავშირზე და სამუშაო ადგილზე დადასტურებულ პროდუქტიულობის მონაცემებზე დაფუძნება.
აი სიმართლის იერარქია:
- BoQ → WBS Mapping: ყოველი WBS აქტივობა პირდაპირ უნდა ებმოდეს გაზომვად BoQ რაოდენობებს.
- რესურსები → რაოდენობები: თითოეული BoQ ელემენტი უნდა უკავშირდებოდეს ხარჯის რეცეპტებს — შრომას, ტექნიკას, მასალებს — რომლებიც რეალური პროდუქტიულობის ბენჩმარკებიდან არის მიღებული.
- ხარჯი → დროის ინტეგრაცია: როგორც კი რესურსებს რაოდენობებს დაუკავშირებთ, ხანგრძლივობების გამოთვლა უკვე შეიძლება რეალური წარმოების ტემპებიდან და არა თვითნებური ვარაუდებიდან.
შედეგად იქმნება ნამდვილი ხარჯისა და დროის საწყისი ხაზი. არა Excel-ის ფანტაზია. არა დამგეგმავის ოპტიმიზმი. ცოცხალი მოდელი, რომელიც გაზომვად სამუშაოზეა დაფუძნებული.
6. გადახდის ლოგიკა, რომელიც მუშაობს
როდესაც BoQ-ს, WBS-სა და რესურსებს ერთმანეთთან აკავშირებთ, გადახდის ეტაპები აღარ არის თვითნებური თარიღები. პირიქით, ისინი ხდება სახელშეკრულებო საკონტროლო წერტილები, რომლებიც რეალურ პროგრესს უკავშირდება.
პრაქტიკაში, ყოველი გადახდის ეტაპი შეესაბამება:
- რაოდენობრივად გაზომვად, დადასტურებულ შესრულებულ სამუშაოს;
- რესურსების გამოყენებას, რომელიც BoQ ელემენტებს შეესაბამება;
- ხარჯის მტკიცებულებას, რომელიც აუდიტსა და დავას უძლებს.
ასე ინარჩუნებთ კონტროლს დროზე, ხარჯსა და ფულადი ნაკადზე. თავის მხრივ, კლიენტები გიხდიან იმ ღირებულებისთვის, რომელიც რეალურად მიაწოდეთ, და არა პროგრესის ილუზიისთვის.
7. მონაცემთა თეატრიდან მტკიცებულებაზე დაფუძნებულ კონტროლამდე
BoQ-რესურსების ნამდვილი ინტეგრაციით სამი რამ ხდება შესაძლებელი:
- პირველ რიგში, შეგიძლიათ თვალყური ადევნოთ labor productivity-ს ფაქტობრივი ადამიანური საათების დაგეგმილ შრომით დანახარჯთან შედარებით.
- მეორე, შეგიძლიათ გაზომოთ აღჭურვილობის გამოყენებადობა მანქანა-საათების შესრულების შედარებით.
- ბოლოს, შეგიძლიათ თვალყური ადევნოთ მასალების მოხმარებას ფაქტიურ ხარჯვასა და გეგმას შორის განსხვავებით.
ეს მძიმე, მკაცრი მეტრიკებია. ამიტომ, ისინი საშუალებას გაძლევთ რესურსები მტკიცებულებაზე დაყრდნობით დაარეგულიროთ და არა ვარაუდებზე.
ასე აღდგება პროექტები. ასევე ასე უძლებს პრეტენზიები. მოკლედ, ასე მართავთ რეალობას და არა Excel-ს.
8. რატომ მხოლოდ ProjectVIEW ERP-ს შეუძლია ამის გაკეთება
აქ პირდაპირი სიმართლეა: ვერც ერთი ცალკე დაგეგმვის ინსტრუმენტი — ვერც Primavera და ვერც MS Project — ვერ უზრუნველყოფს ასეთ ინტეგრაციას. ისინი მუშაობენ ლოგიკასა და დროში, მაგრამ არა ხარჯისა და რაოდენობის რეალობაში.
საპირისპიროდ, DANAOS-მა ProjectVIEW ERP სხვაგვარად შექმნა.
ეს არის ერთადერთი მშენებლობის მართვის სისტემა, რომელიც აგებულია BoQ-ზე დაფუძნებული WBS სტრუქტურების, რესურსების პროდუქტიულობის შაბლონების და სამუშაო ადგილზე დადასტურებული ხარჯის რეცეპტების გარშემო.
ProjectVIEW ERP-ით შეგიძლიათ:
- BoQ რაოდენობები პირდაპირ დაუკავშიროთ WBS ელემენტებს;
- ფაქტობრივი პროდუქტიულობის მონაცემებიდან შექმნათ ხარჯისა და დროის საწყისი ხაზები;
- დინამიკურად განაახლოთ რესურსები, როცა მოცულობა იცვლება;
- პროგრესი, გადახდები და შედეგიანობა ერთ უწყვეტ საკონტროლო ციკლში მოაქციოთ.
ეს მხოლოდ software არაა — ეს არის მშენებლობის ინტელექტი.
ამრიგად, ის გრაფიკირებას ხელოვნებიდან მეცნიერებად აქცევს, ილუზიიდან მტკიცებულებად.
9. დასკვნა
ხანგრძლივობის გადაჭარბებები, TPR-ები და მსგავსი სამშენებლო გრაფიკის მეტრიკები ობიექტურად ჩანს. თუმცა, ისინი ხშირად არასწორ რამეს ზომავენ.
ისინი ზუსტობის ილუზიას იძლევიან მაშინ, როცა რეალიზმის არარსებობას მალავენ.
ამის საპირისპიროდ, ProjectVIEW ERP ამ ილუზიას შლის.
ის ხარჯს, დროსა და რესურსებს ერთ შემოწმებად მოდელში აერთიანებს. შედეგად, ყოველი გრაფიკი ხდება ცოცხალი ანარეკლი იმისა, რაც რეალურად ხდება ობიექტზე.
სანამ ინდუსტრია არ მიიღებს BoQ-ზე დაფუძნებულ რესურსულ ლოგიკას, ჩვენ კვლავ აგვერევა ratios reality-ში.
და ეს არის საბოლოო სიყალბე.
10. ნამდვილი მიზეზი, რატომაც ეს მეთოდები რჩება
დავასრულოთ იმ სიმართლით, რომლის ხმამაღლა თქმას არავინ ისურვებს.
ფაქტობრივად, ხანგრძლივობის გადაჭარბების მეტრიკები და TPR ანალიზები პოპულარულია იმიტომ, რომ არასწორ ადამიანებს ემსახურება.
მათი შემქმნელები მათ პროექტის მენეჯერებისთვის, დეველოპერებისთვის და კონსულტანტებისთვის ქმნიდნენ და არა კონტრაქტორებისთვის.
კონსულტანტებს უყვართ ისინი, რადგან ობიექტურად გამოიყურებიან, ანგარიშებს ავსებენ და პასუხისმგებლობას გადაანაწილებენ.
და აი, მთავარი დასკვნა:
კონსულტანტებსა და დეველოპერებს რეალურად ხარჯი არ ადარდებთ — რადგან უმეტეს შემთხვევაში ხარჯი კონტრაქტორის პრობლემაა.
როცა მოდელი მარცხდება, ზარალს კონტრაქტორი იღებს, და არა კონსულტანტი, რომელმაც გრაფიკი შეადგინა.
სწორედ ამიტომ რჩება ეს ხარვეზიანი მეთოდები — ისინი მაგიდის არასწორ მხარეს იცავენ.
და სწორედ ამიტომ სჭირდებათ კონტრაქტორებს ისეთი ინსტრუმენტები, როგორიცაა ProjectVIEW ERP — სისტემები, რომლებიც შექმნილია მათი რეალობის, მტკიცებულებებისა და გადახდის დასაცავად.
მაგრამ აქ არის გარდამტეხი მომენტი —
როდესაც კონსულტანტები საბოლოოდ მიიღებენ ProjectVIEW ERP მენტალიტეტს, ისინი მიიღებენ წვდომას რეალურ Earned Value KPI-ებზე, ზუსტ სტატუს ანგარიშებზე და სარწმუნო პროგრესის განახლებებზე.
მაშინ ისინი შეძლებენ ბიუჯეტებისა და გრაფიკების თავიდან პროგნოზირებას ფაქტობრივი საიტური პირობების საფუძველზე და არა ჰიპოთეტური თანაფარდობებით.
მაშინ project controls შეწყვეტს აკადემიურ საქმიანობას და გახდება ანგარიშვალდებული.
მანამდე კი ხანგრძლივობის გადაჭარბების მეტრიკები დარჩება ის, რაც ყოველთვის იყო:
ინსტრუმენტები, რომლითაც კონსულტანტები ჭკვიანურად გამოჩნდებიან, ხოლო კონტრაქტორები ფულს დაკარგავენ.
