სამშენებლო კონტრაქტის ტიპი ბევრად მეტს განსაზღვრავს, ვიდრე იმას, როგორ იღებს კონტრაქტორი ანაზღაურებას.
ფაქტობრივად, ის განსაზღვრავს ვინ ატარებს საპროექტო რისკს, ვინ ატარებს ხარჯის რისკს, როგორ მართავენ მხარეები ცვლილებებს, როგორ ადასტურებენ პროგრესს და საბოლოოდ რამდენად არის კონტრაქტორი დაუცველი ხარჯების გადაჭარბების მიმართ.
ეს განსაკუთრებით მნიშვნელოვანია დიდ EPC, Lump Sum, Turnkey, BOT და PPP პროექტებში, სადაც კლიენტის კომერციულ სტრუქტურაში შეიძლება არ იყოს საკმარისი დეტალები მშენებლობის რეალური ხარჯის სამართავად.
მოკლედ, მთავარი პრინციპი მარტივია:
დონე, რომელზეც კონტრაქტორი იღებს ანაზღაურებას, აუცილებელი არ არის ის დონე, რომელზეც მან თავისი ხარჯები უნდა აკონტროლოს.
საწარმოო კონტრაქტორებისთვის სახელშეკრულებო Quantity-ის უწყისი (BoQ) ამიტომ პროექტის კონტროლის მხოლოდ ერთი განზომილებაა.
შედეგად, ნამდვილი სამშენებლო ხარჯების კონტროლი მოითხოვს BoQ-ის, Work Breakdown Structure-ის (WBS-ის), Cost Code-ების და ფაქტობრივი სამშენებლო შესრულების ერთმანეთთან დაკავშირებას.
და სწორედ აქ ხდება სამშენებლო სპეციფიკური ERP კრიტიკულად მნიშვნელოვანი.
პირველი, FIDIC, EPC, Lump Sum, BOT და PPP ერთი და იგივე არ არის
ხშირად ეს ტერმინები ერთად გამოიყენება. თუმცა ისინი პროექტის მიწოდების სხვადასხვა ასპექტს აღწერს.
- FIDIC უზრუნველყოფს სამშენებლო და საინჟინრო კონტრაქტების სტანდარტიზებულ ფორმებს.
- EPC — Engineering, Procurement and Construction აღწერს მიწოდების მოდელს. აქ კონტრაქტორი იღებს პასუხისმგებლობას დიზაინზე, შესყიდვებსა და მშენებლობაზე.
- Lump Sum (LS) პირველ რიგში აღწერს ფასის შეთანხმებას. ამ შემთხვევაში კონტრაქტორი თანხმდება განსაზღვრული მასშტაბის მიწოდებაზე შეთანხმებულ ფასად, ხელშეკრულების დებულებების შესაბამისად ცვლილებებისა და სხვა კორექტირებების შესახებ.
- BOT — Build-Operate-Transfer აერთიანებს მშენებლობას იმ საკონცესიო პერიოდთან, რომლის განმავლობაში კერძო მხარე ექსპლუატაციას უწევს აქტივს მის გადაცემამდე.
- PPP — Public-Private Partnership კიდევ უფრო ფართოა. ის ჩვეულებრივ მოიცავს საჯარო და კერძო სექტორებს შორის გრძელვადიან სახელშეკრულებო ურთიერთობას. ეს ურთიერთობა მოიცავს დიზაინის, მშენებლობის, დაფინანსების, ექსპლუატაციისა და ტექნიკური მომსახურების კომბინაციებს.
პრაქტიკაში ეს სტრუქტურები შეიძლება გადაკვეთილიც იყოს.
მაგალითად, კონტრაქტორს შეუძლია EPC პროექტის შესრულება როგორც Lump Sum Turnkey კონტრაქტით FIDIC Silver Book-ის გამოყენებით.
თუმცა ხარჯების კონტროლის თვალსაზრისით მთავარია, რამდენი კომერციული, დიზაინის, სამშენებლო და შესრულების რისკი გადადის კონტრაქტორზე.
რაც უფრო დიდია რისკი, მით უფრო მაღალია შიდა ხარჯების დეტალიზაციის საჭიროება.
FIDIC Red, Yellow და Silver: რისკის სხვადასხვაგვარი განაწილება
FIDIC Red Book-ის მიხედვით, Employer ტრადიციულად უზრუნველყოფს დიზაინის დიდ ნაწილს, ხოლო კონტრაქტორი ასრულებს სამშენებლო სამუშაოებს.
შედეგად, ეს ჩვეულებრივ ქმნის შედარებით პირდაპირ კავშირს დიზაინს, რაოდენობებს, გაზომვას, პროგრესსა და გადახდას შორის.
- FIDIC Yellow Book-ი დიზაინის უფრო დიდ პასუხისმგებლობას ანიჭებს კონტრაქტორს. შესაბამისად, კონტრაქტორმა სულ უფრო მეტად უნდა მართოს ინჟინერია, შესყიდვები, მშენებლობა, დრო და ხარჯი როგორც ურთიერთდაკავშირებული პროცესები.
- FIDIC Silver Book-ი, რომელიც ხშირად EPC/Turnkey მიწოდებასთან ასოცირდება, კონტრაქტორზე არსებითად უფრო მეტ პასუხისმგებლობას გადააქვს.
სხვა სიტყვებით რომ ვთქვათ, Employer ფაქტობრივად ყიდულობს შედეგს:
მიაწოდეთ საჭირო ობიექტი, ქარხანა ან ინფრასტრუქტურული აქტივი შეთანხმებული მოთხოვნების, ფასისა და დასრულების ვალდებულებების შესაბამისად.
თუმცა კონტრაქტორისთვის ამ შედეგის მიწოდება შეიძლება ნიშნავდეს ათიათასობით აქტივობას, რესურსს, შესყიდვის შეკვეთას, მასალის გადაადგილებას, შრომით ტრანზაქციებს, დანადგარების საათებსა და ქვეკონტრაქტორულ ოპერაციებს.
ეს ქმნის დიდ ხარჯების კონტროლის პრობლემას.
EPC-ის პარადოქსი: მარტივ კომერციულ ფასს შეუძლია დამალოს უზარმაზარი სამშენებლო სირთულე
მაგალითად, წარმოიდგინეთ გამარტივებული EPC BoQ, რომელიც შეიცავს ასეთ სტრიქონს:
სამშენებლო სამუშაოები — $12 მილიონი
კლიენტის კომერციული თვალსაზრისით ეს შეიძლება სრულიად საკმარისი იყოს.
თუმცა კონტრაქტორის ხარჯების კონტროლის თვალსაზრისით ეს თითქმის არაფრის მთქმელია.
პრაქტიკაში ეს $12 მილიონი შეიძლება მოიცავდეს:
გათხრებს, წყლის ამოტუმბვას, არმირებას, ბეტონს, ფორმებს, კონსტრუქციულ ფოლადს, შრომას, ამწეებს, ტუმბოებს, დროებით სამუშაოებს, სახარჯ მასალებს, ლოჯისტიკას, მასალის დანაკარგს, სპეციალიზებულ ქვეკონტრაქტორებს და ირიბ რესურსებს.
საწყის BoQ-ს შეიძლება არ ჰქონდეს ამ დონეზე საინჟინრო ანალიზი. მიუხედავად ამისა, კონტრაქტორი ვერ დაკმაყოფილდება დეტალების არქონით.
ამის ნაცვლად, კონტრაქტორს უწევს ამ დეტალიზაციის შიდა დონეზე შექმნა.
სწორედ ამიტომ ხდება Cost Code-ები სტრატეგიულად მნიშვნელოვანი.
Cost Code-ები შეიძლება გახდეს პირველი დონის უხეში ბიუჯეტი
ProjectVIEW ERP სამშენებლო ხარჯების კონტროლს სამ ურთიერთდაკავშირებულ პროექტულ განზომილებაში განიხილავს:
BoQ ↔ WBS ↔ Cost Codes
- BoQ წარმოადგენს კომერციულ განზომილებას: რას ყიდულობს კლიენტი და რას ყიდის საბოლოოდ კონტრაქტორი.
- WBS, პირიქით, წარმოადგენს შესრულებისა და დროის განზომილებას: სად, როდის და რა თანმიმდევრობით უნდა შეასრულოს გუნდმა სამუშაო.
- და ბოლოს, Cost Code (Cost Control Accounts) წარმოადგენს შიდა ხარჯების კონტროლის განზომილებას: როგორ კლასიფიცირებს და აკონტროლებს კონტრაქტორი ხარჯვას.
ამასთან, ProjectVIEW მხარს უჭერს Cost Code-ების მიბმას BoQ-ის ბიუჯეტზე და BoQ-ის ბიუჯეტსა და პროექტის დაგეგმვის სტრუქტურებს შორის ურთიერთობების დამყარებას.
როცა EPC BoQ-ს საკმარისი საინჟინრო დეტალი არ აქვს, Cost Code-ებს შეუძლიათ უზრუნველყონ პროექტის ბიუჯეტის პირველი შიდა უხეში დაშლა.
მაგალითად, კონტრაქტორს შეუძლია შიდა დონეზე გაანაწილოს მაღალი დონის BoQ-ის ელემენტი, როგორიცაა სამშენებლო სამუშაოები, ხარჯთა კატეგორიებად მიწის სამუშაოებისთვის, ბეტონისთვის, არმირებისთვის, ფორმებისთვის, კონსტრუქციული ფოლადისთვის, შრომისთვის, მანქანა-დანადგარებისთვის და ქვეკონტრაქტორებისთვის.
შედეგად, კონტრაქტორი აღარ არის დამოკიდებული კლიენტის კომერციულ სტრუქტურაზე, რათა გადაწყვიტოს, როგორ მართოს პროექტი შიგნიდან.
WBS ამატებს იმას, რაც BoQ-ს არ აქვს: დროს
ჯერ Cost Code-ები პასუხობს:
რა ტიპის ხარჯს ვიღებთ?
შემდეგ WBS პასუხობს:
სად და როდის ვასრულებთ სამუშაოს?
ProjectVIEW-ის სატენდერო და ბიუჯეტირების მეთოდოლოგია გუნდს საშუალებას აძლევს რესურსები, პროდუქტიულობის დაშვებები და ვადები დაუკავშიროს BoQ სტრუქტურებსა და პროექტის დაგეგმვას.
ეს ქმნის ერთი და იმავე პროექტის სამ განსხვავებულ, მაგრამ ურთიერთდაკავშირებულ ხედვას:
BoQ = კომერციული
WBS = დრო და შესრულება
Cost Codes = ხარჯების კლასიფიკაცია
ერთად ეს სამი დაკავშირებული განზომილება პროექტის საწყის ხარჯთკონტროლის ჩარჩოს ქმნის.
მაგრამ ნამდვილი ინტელექტი მაშინ იწყება, როცა მშენებლობა იწყება.
ადგილზე შესრულება ქმნის დაკარგულ საინჟინრო დეტალს
ბოლოს და ბოლოს, ბიუჯეტი მხოლოდ დაშვებაა.
მშენებლობა რეალობაა.
ყოველდღე სამშენებლო მოედანი ქმნის ინფორმაციას, რომელსაც შეუძლია თანდათან გაამდიდროს საწყისი ბიუჯეტი.
რამდენი სამუშაო შეასრულა მოედანმა?
რამდენი შრომითი საათი იყო საჭირო?
და რამდენი მასალა მოიხმარეს ბრიგადებმა?
ანალოგიურად, რამდენ საათს მუშაობდა ამწე, ექსკავატორი ან სხვა ტიპის აღჭურვილობა?
რამდენი ქვეკონტრაქტული სამუშაო შეასრულა და დაამოწმა პროექტმა?
რა უნდა დაჯდომოდა ფიზიკური პროგრესის ამ მოცულობას?
და რეალურად რა დაუჯდა?
ProjectVIEW-ის ხარჯების კონტროლის მეთოდოლოგია აღრიცხავს ყოველდღიურ ტრანზაქციებს, მათ შორის პროექტის პროგრესს, თანამშრომელთა ტრანზაქციებს და დანადგარების ტრანზაქციებს. შემდეგ მათ იყენებს პროექტის რეალური ხარჯების სურათის ასაგებად.
ამასთან, მისი ფართო სამშენებლო მართვის მოდელი აკავშირებს მასალებს, ქვეკონტრაქტორთა სერტიფიცირებებს, შრომის პროდუქტიულობას და დანადგარების გამოყენებას BoQ–WBS–Cost Code ურთიერთობებთან.
ეს არის გზა, რომ შედარებით უხეში EPC ბიუჯეტი თანდათან იქცევა დეტალურ საინჟინრო ხარჯების მოდელად.
უხეში ბიუჯეტიდან შვილეულ დონეზე ხარჯების ანალიზამდე
სატენდერო ეტაპზე კონტრაქტორი შეიძლება დაიწყოს შემდეგით:
BoQ → Cost Code
შემდეგ, პროექტის დაგეგმვისას, ეს ხდება:
BoQ → Cost Code → WBS
და ბოლოს, მშენებლობის დროს ის კიდევ უფრო ვითარდება:
BoQ → Cost Code → WBS → რესურსები → ყოველდღიური ტრანზაქციები
ამგვარად, საწყისი მაღალი დონის ბიუჯეტი თანდათან იძენს შვილეულ დონეზე ოპერაციულ დეტალს.
შედეგად, მენეჯმენტს საბოლოოდ შეუძლია სტრუქტურული სამუშაოების ბიუჯეტის ანალიზი კონკრეტულ WBS აქტივობამდე, ხარჯთა კატეგორიამდე, ბრიგადამდე, მასალის მოხმარებამდე, დანადგარის გამოყენებამდე, ქვეკონტრაქტორის სერტიფიკატამდე და ფიზიკური პროგრესის ტრანზაქციამდე.
უბრალოდ იმის ცოდნის ნაცვლად, რომ კონსტრუქციული სამუშაოები ბიუჯეტს აჭარბებს, ხელმძღვანელობას შეუძლია დაიწყოს ასეთი კითხვების დასმა:
რომელი აქტივობა?
რომელი Cost Code?
რომელი რესურსი?
რომელი ბრიგადა?
რომელი ქვეკონტრაქტორი?
რომელი მასალა?
რომელი მანქანა?
რომელი დღე?
ეს არის ხარჯების კონტროლის ფუნდამენტურად განსხვავებული დონე.
დღიური სამუშაო დავალებები: მშენებლობის ხარჯების ქირურგიული გარჩევა
თუმცა, კონტრაქტორები პროექტებს სინამდვილეში თვიური ფინანსური ანგარიშებით არ აშენებენ.
სინამდვილეში, ისინი მათ აშენებენ დღიური სამუშაოებით.
ამიტომ, მშენებლობის ხარჯების კონტროლის უმაღლესი დონე არის საოპერაციო ტრანზაქციების პროექტის კომერციულ, დაგეგმვით და ხარჯვით სტრუქტურებთან დაკავშირების უნარი.
დღიურმა სამუშაო ტრანზაქციამ უნდა გასცეს პასუხი:
რას ვაშენებთ? — BoQ
სად ვაშენებთ მას? — WBS
ხარჯის რა კატეგორიას მოიცავს? — Cost Code
ვინ შეასრულა სამუშაო? — შრომითი რესურსი ან ქვეკონტრაქტორი
რა მასალები დახარჯეს? — მასალები
რა აღჭურვილობა იყო საჭირო? — ტექნიკა
რა პროგრესი მიაღწიეს? — ფიზიკური პროგრესი
რა უნდა ღირდა ეს პროგრესი? — ბიუჯეტი
რა დაუჯდა სინამდვილეში? — ფაქტობრივი ხარჯი
აი, რას ვგულისხმობთ მშენებლობის პროექტის ქირურგიულ გარჩევაში.
ProjectVIEW იგივე ლოგიკას შესყიდვებშიც ავრცელებს. მომხმარებლებს შეუძლიათ მასალების შესყიდვისა და საწყობის პროცესების დაკავშირება BoQ-ებთან, WBS-თან და Cost Codes-თან. ეს უზრუნველყოფს, რომ ხარჯი მისი პროექტული დანიშნულებით იყოს დაკავშირებული მოთხოვნიდან შესყიდვამდე და ობიექტზე მოხმარებამდე.
ქვეკონტრაქტორების ხელშეკრულებებსა და სერტიფიკატებსაც შეუძლიათ Cost Codes-ის ქონა, რაც ქვეკონტრაქტით შესრულებულ სამუშაოს ერთსა და იმავე ხარჯთკონტროლის სტრუქტურაში მოაქცევს.
BoQ უნდა გადაიქცეს ცოცხალ ხარჯვით სტრუქტურად
ამიტომ, ტენდერის დროს მიღებული BoQ არ უნდა დარჩეს სტატიკურ Excel დოკუმენტად, რომელიც შესრულების პროცესს მოწყვეტილია.
ProjectVIEW-ს შეუძლია Excel BoQ-ის იმპორტი და მისი BoQ კოდური ხაზების იერარქიულ სტრუქტურად გარდაქმნა. შემდეგ დამთვლელებს შეუძლიათ ამ ხაზებს დააკავშირონ მასალები, შრომა, ტექნიკა და ქვეკონტრაქტორები.
მშენებლობის დაწყებისთანავე რეალობა იწყებს თავდაპირველი მოდელის გამდიდრებას.
ციფრული ევოლუცია ხდება:
ტენდერის BoQ
→ Cost Code-ით კოდირებული ბიუჯეტი
→ WBS-თან დაკავშირებული პროექტის საბაზისო ხაზი
→ რესურსების ბიუჯეტი
→ ობიექტის ყოველდღიური ტრანზაქციები
→ ფაქტობრივი და ბიუჯეტირებული ხარჯი
→ პროდუქტიულობისა და რესურსების ვარიაციები
→ ხელმძღვანელობის მოქმედება
ეს ხურავს მშენებლობაში ყველაზე მუდმივ ინფორმაციულ ხარვეზთაგან ერთ-ერთს:
ხარვეზს იმის შეფასებას შორის, რა უნდა დაჯდეს მშენებლობა, და იმის გაგებას შორის, რეალურად რა უჯდება მშენებლობა.
რატომ არის ეს კიდევ უფრო მნიშვნელოვანი EPC და Lump Sum პროექტებში
გარდა ამისა, ფინანსური შედეგები განსაკუთრებით მნიშვნელოვანი ხდება EPC და Lump Sum ხელშეკრულებების პირობებში.
მაგალითად, წარმოიდგინეთ, რომ კონტრაქტორს აქვს:
საკონტრაქტო შემოსავალი: $500 მილიონი
ბიუჯეტირებული ხარჯი: $450 მილიონი
მოსალოდნელი მარჟა: $50 მილიონი
ვთქვათ, შესრულების საბოლოო ღირებულება არის $485 მილიონი. დამატებითი $35 მილიონი არ ქრება იმის გამო, რომ დამკვეთის BoQ-ს საკმარისი დეტალიზაცია არ ჰქონდა.
ის პირდაპირ კონტრაქტორის მარჟიდან მოდის.
ამიტომ, მშენებლობის ხარჯების კონტროლის მიზანი მხოლოდ გადაჭარბებული ხარჯის შემდეგ ანგარიშგება ვერ იქნება.
მიზანი უნდა იყოს გადახრების იდენტიფიცირება მანამ, სანამ ხელმძღვანელობას ჩარევის დრო ჯერ კიდევ აქვს.
პრაქტიკაში ეს ნიშნავს მუდმივად შედარებას:
ბიუჯეტირებული და ფაქტობრივი შრომის პროდუქტიულობა
ბიუჯეტირებული და ფაქტობრივი მასალის მოხმარება
დაგეგმილი და ფაქტობრივი ტექნიკის გამოყენება
ბიუჯეტირებული და სერტიფიცირებული ქვეკონტრაქტორის ხარჯები
დაგეგმილი და ფაქტობრივი ფიზიკური პროგრესი
ბიუჯეტირებული და ფაქტობრივი პროექტის ხარჯი
ProjectVIEW-ის ხარჯთკონტროლის მოდელი აღრიცხავს ობიექტის ტრანზაქციებს. შემდეგ ის შესრულებას ადარებს პროექტის საბაზისო ხაზს და აღარ ელოდება, რომ ბუღალტერია იქნება პირველი ნიშანი იმისა, რომ რაღაც არასწორად წავიდა.
ტრადიციული ხარჯთაღრიცხვიდან „კვანტურ“ ხარჯთკონტროლამდე
ტრადიციული ფინანსური ERP ძალიან კარგად პასუხობს კითხვას:
რა დავხარჯეთ?
თუმცა, მშენებლობის ხარჯების ინჟინერიამ მნიშვნელოვნად უფრო შორს უნდა წავიდეს:
რა დავხარჯეთ, სად დავხარჯეთ, რომელი რესურსი მოხმარდა, რა ფიზიკური პროგრესი წარმოშვა, რა უნდა დაჯდომოდა ეს პროგრესი, რატომ არის გადახრა და რისი გაკეთება შეგვიძლია ჯერ კიდევ?
დაკავშირებით:
BoQ ↔ WBS ↔ Cost Codes
და ამ სტრუქტურის მუდმივი შევსებით შემდეგით:
შრომა ↔ მასალები ↔ ტექნიკა ↔ ქვეკონტრაქტორები ↔ პროგრესი
ProjectVIEW ERP თანდათან ყოფს პროექტის შესრულებას უფრო მცირე საზომ ერთეულებად.
ეს ქმნის იმას, რასაც ჩვენ ვუწოდებთ „კვანტურ“ ხარჯთკონტროლს: პროექტის ხარჯისა და შესრულების უწყვეტ დაშლას უფრო და უფრო წვრილ საოპერაციო ელემენტებად. ეს მენეჯერებს საშუალებას აძლევს, გადახრები უფრო ახლოს დაინახონ იმ ადგილსა და დროსთან, სადაც ისინი წარმოიშობა.
თვე დასრულებისას ბეტონის სამუშაოების ბიუჯეტის გადაჭარბების აღმოჩენის ნაცვლად, ხელმძღვანელობას უნდა შეეძლოს ძირითადი საოპერაციო მიზეზისკენ ჩაღრმავება.
ეს არის განსხვავება ხარჯის გადაჭარბების ანგარიშგებასა და მის კონტროლს შორის.
ნამდვილი ციფრული ძაფი: ტენდერიდან მშენებლობამდე
ბევრი მსხვილი კონტრაქტორი ჯერ კიდევ სხვადასხვა, ერთმანეთთან დაუკავშირებელი ტექნოლოგიური ფენებით მუშაობს.
ერთი სისტემა შეფასებას მართავს.
Primavera გეგმვას მართავს.
ამავდროულად, სხვა პლატფორმა ობიექტის აქტივობებს მართავს.
შესყიდვები კორპორაციული ERP-ით მიმდინარეობს.
ქვეკონტრაქტორების ინფორმაცია სხვაგან ინახება.
ბუღალტერია ფინანსურ ტრანზაქციებს აღრიცხავს.
და ბოლოს, Excel ცდილობს ყველაფრის შეჯერებას.
შედეგი არ არის ციფრული ტრანსფორმაცია.
ეს არის ციფრული ფრაგმენტაცია.
საპირისპიროდ, ProjectVIEW ERP განსხვავებულ მიდგომას იყენებს და ქმნის სამშენებლო ინდუსტრიისთვის განკუთვნილ ინტეგრირებულ საყრდენს, რომელიც აკავშირებს:
ტენდერი → ბიუჯეტირება → დაგეგმვა → შესყიდვები → ობიექტზე შესრულება → ქვეკონტრაქტორები → ხარჯთკონტროლი
პირველ რიგში, დამკვეთის BoQ ხდება კომერციული საწყისი წერტილი.
Cost Codes უზრუნველყოფს კონტრაქტორის შიდა ხარჯვით სტრუქტურას.
შემდეგ WBS ემატება გრაფიკსა და შესრულებას.
შესყიდვები ხარჯავს ბიუჯეტს.
ამავდროულად, ობიექტის ტრანზაქციები რეალობას აფიქსირებს.
ქვეკონტრაქტორების სერტიფიკატები გარე წარმოებას აღრიცხავს.
შემდეგ პროგრესი ზომავს, რა აშენდა სინამდვილეში ობიექტზე.
და შედეგად მიღებული ინფორმაცია უწყვეტად კვებავს პროექტის ხარჯთკონტროლს.
DANAOS-მა ProjectVIEW-ის არქიტექტურა სპეციალურად ისე შექმნა, რომ დაეკავშირებინა შეფასება, შესყიდვები, ქვეკონტრაქტორები, ობიექტის ოპერაციები და ხარჯთკონტროლი BoQ, WBS და Cost Codes საერთო განზომილებების ირგვლივ.
მიზანი არ არის კიდევ ერთი დაფა.
ეს არის ციფრული ხარჯთკონტროლის საყრდენი მშენებლობისთვის.
EPC-ში ხელშეკრულების ფასი მხოლოდ დასაწყისია
FIDIC, EPC, Lump Sum, BOT და PPP შეთანხმებები პასუხისმგებლობებსა და რისკებს სხვადასხვაგვარად ანაწილებს.
მაგრამ ერთი პრინციპი სულ უფრო მნიშვნელოვანი ხდება, როცა მეტი რისკი კონტრაქტორზე გადადის:
კომერციული სიმარტივე არასოდეს უნდა აირიოს საოპერაციო სიმარტივეში.
EPC კონტრაქტორს შეიძლება მიეცეს შედარებით მაღალი დონის საკონტრაქტო BoQ.
თუმცა, ეს არ ნიშნავს, რომ წვრილმანი ხარჯთკონტროლი შეუძლებელია.
სინამდვილეში, ეს წვრილმანი ხარჯთკონტროლს უფრო მნიშვნელოვანს ხდის.
ProjectVIEW ERP ამას წყვეტს Cost Codes-ის, როგორც პირველი დონის, უხეში ბიუჯეტირების ელემენტების გამოყენებით, მათ აკავშირებს საკონტრაქტო BoQ პუნქტებთან და დროზე დაფუძნებულ WBS აქტივობებთან, შემდეგ კი ამ სტრუქტურას თანდათან ამდიდრებს რეალური სამშენებლო მონაცემებით:
შრომის პროდუქტიულობა.
მასალების გამოყენება.
ტექნიკის გამოყენების დონე.
შესყიდვები.
ქვეკონტრაქტორების სერტიფიკატები.
ფიზიკური პროგრესი.
ობიექტის ყოველდღიური ტრანზაქციები.
შედეგად, პროექტს შეუძლია თანდათან განვითარდეს შემდეგიდან:
ხელშეკრულება → BoQ → Cost Code → WBS → რესურსები → ყოველდღიური შესრულება → ფაქტობრივი ხარჯი
და სწორედ აქ ხდება მშენებლობაზე მორგებული ERP ფუნდამენტურად განსხვავებული ზოგადი ფინანსური ERP-ისგან.
ბუღალტერია გიჩვენებთ, სად წავიდა ფული.
მშენებლობის ხარჯების ინჟინერიამ უნდა გითხრათ, რატომ წავიდა იქ და საკმარისად ადრე, რომ რამე გააკეთოთ.
საბოლოოდ, EPC და Lump Sum კონტრაქტორებისთვის, რომლებსაც მნიშვნელოვანი შესრულების რისკი აქვთ, ეს განსხვავება საბოლოოდ შეიძლება განსაზღვროს, დაიცავენ თუ არა ისინი პროექტის მარჟას, თუ ახსნიან, რატომ გაქრა ის.
