დათა ცენტრის მშენებლობაში ხარჯების კონტროლი არ არის მხოლოდ უკვე გაწეული დანახარჯის აღრიცხვა. სწრაფ რეჟიმში ობიექტების მიმწოდებელი კონტრაქტორებისთვის ეფექტური construction cost control მოითხოვს, რომ MEP-ის მოცულობა, შესყიდვების ვალდებულებები, გრაფიკის ეტაპები და პროექტის ფაქტობრივი შესრულება დაკავშირებული დარჩეს ერთსა და იმავე ხარჯითა და დროით საწყის მონაცემებთან.
ეს მოთხოვნა კიდევ უფრო მნიშვნელოვანია დათა ცენტრებში, რადგან პროექტის ღირებულების ძალიან დიდი ნაწილი ტექნიკურად რთულ Mechanical, Electrical and Plumbing (MEP) სისტემებზე მოდის.
Turner & Townsend 2025–2026 Data Centre Construction Cost Index-ის მიხედვით, მექანიკური და ელექტრო სამუშაოები, აღჭურვილობის ჩათვლით, შეადგენს აშშ-ს ბენჩმარკში, დაახლოებით 76% ჰაერით გაგრილებადი data center-ის საჩვენებელი სამშენებლო ღირებულებისა და 81% თხევადით გაგრილებადი ობიექტისთვის.
ამიტომ კონტრაქტორისთვის საკითხი მხოლოდ ეს არ არის:
„რამდენი დავხარჯეთ?“
ამის ნაცვლად, ეს არის:
“მოცულობა, ვალდებულებები, მიწოდების თარიღები, მონტაჟის პროგრესი და პროგნოზირებული ხარჯი კვლავაც თანხვედრაშია?”
რას მოითხოვს ეფექტური მონაცემთა ცენტრის ხარჯების კონტროლი?
პრაქტიკაში, სწრაფ რეჟიმში განხორციელებული data center-ისთვის:
- MEP-ის მოცულობა უნდა რჩებოდეს დამტკიცებულ პროექტის ბიუჯეტთან დაკავშირებული.
- Long-lead procurement უნდა უკავშირდებოდეს WBS-ის ეტაპებსა და ობიექტზე საჭირო თარიღებს.
- ვალდებულებები უნდა ჩანდეს მანამდე, სანამ ინვოისები საბუღალტრო ფაქტობრივ ხარჯად იქცევა.
- დიზაინის ცვლილებებმა და ვარიაციებმა უნდა განაახლოს როგორც ხარჯის, ისე დროის პროგნოზები.
- BoQ, WBS და Cost Codes შესრულების განმავლობაში უნდა დარჩეს ურთიერთდაკავშირებული.
სწრაფი მიწოდება არ ამცირებს კონტროლის საჭიროებას. პირიქით, მას ზრდის.
რატომ არის data center-ის მშენებლობის ხარჯების კონტროლი განსხვავებული?
უპირველესად, data center-ის MEP პაკეტები მოიცავს პროექტის ყველაზე ძვირადღირებულ და გრაფიკულად კრიტიკულ აქტივებს:
ტრანსფორმატორებს, გენერატორებს, switchgear-ს, UPS სისტემებს, ელექტროენერგიის განაწილების მოწყობილობას, chillers-ს, pumps-ს და სულ უფრო დახვეწილ გაგრილების ინფრასტრუქტურას.
შედეგად, კონტრაქტორებმა ეს პაკეტები ორი დაკავშირებული ხედვით უნდა აკონტროლონ.
პირველი, ფინანსურად:
Budget → Approved Changes → Committed Cost → Actual Cost → Forecast Cost at Completion
მეორე, ოპერაციულად:
სამშენებლო ობიექტზე საჭირო თარიღი → შესყიდვის სტატუსი → მიწოდების პროგნოზი → მონტაჟი → ტესტირება → ექსპლუატაციაში გაშვება
რა თქმა უნდა, ჩვეულებრივ საბუღალტრო ანგარიშს საბოლოოდ შეუძლია აჩვენოს დანახარჯი.
მაგრამ დავუშვათ, კრიტიკული ტრანსფორმატორი უკვე დაგვიანებულია, UPS-ის სპეციფიკაცია შესყიდვის შემდეგ შეიცვალა, ან პროექტს ენერგიზაციის დასაცავად დაჩქარებული ტრანსპორტირება სჭირდება. ასეთ შემთხვევაში, ხარჯის ანგარიშგება მოვლენის შემდეგ პროექტის კონტროლი არ არის.
ამიტომ ეფექტური Cost Control უნდა მუშაობდეს საბუღალტრო ფაქტობრივი მონაცემების წინ.
რატომ ხდება შესყიდვა პროექტის კონტროლის ნაწილი?
JLL 2026 Global Data Center Outlook აცხადებს აღჭურვილობის საშუალო გლობალურ lead time-ს დაახლოებით 33 კვირა.
ამავე დროს, JLL აღნიშნავს, რომ ზოგიერთი დეველოპერი გარკვეულ მასალებს 24 თვით ადრე წინასწარ უკვეთავს, თუმცა 2025 წელს data center-ის პროექტების 57%-ს სამშენებლო დაგვიანება სამი თვე ან მეტი ჰქონდა.
შესაბამისად, ეს ცვლის Procurement and Purchasing-ის როლს.
კრიტიკული MEP აღჭურვილობისთვის შესყიდვა, შესაბამისად, არ არის მხოლოდ ქვემოთ მდგომი ადმინისტრაციული ფუნქცია.
ამის ნაცვლად, ის პროექტის გრაფიკის ნაწილი ხდება და, შესაბამისად, project controls-ის ნაწილიც.
მაგალითად, ტიპური კონტროლის ჯაჭვი შეიძლება გაგრძელდეს შემდეგ ეტაპებზე:
დიზაინის გამოშვება → მოთხოვნა → RFQ → ტექნიკური შეფასება → კომერციული შეფასება → შესყიდვის ორდერი → მომწოდებლის წარსადგენი დოკუმენტაცია → წარმოება → FAT → გადაზიდვა → ობიექტზე მიწოდება → მონტაჟი → ტესტირება → ექსპლუატაციაში გაშვება
თავის მხრივ, თითოეულ ეტაპს შეუძლია გავლენა მოახდინოს როგორც Cost-ზე, ისე Time-ზე.
როდესაც ტრანსფორმატორი დაგვიანებით ჩამოდის, შესყიდვა გრაფიკის პრობლემად იქცევა.
ანალოგიურად, თუ მისი სპეციფიკაცია შესყიდვის შემდეგ იცვლება, საინჟინრო მხარე ხარჯის პრობლემად იქცევა.
და თუ გუნდს გრაფიკის აღსადგენად დაჩქარება უწევს, დაგეგმვის გადაწყვეტილება კომერციულ შედეგს ქმნის.
ამიტომ ინჟინერია, შესყიდვა, დაგეგმვა და ხარჯების მართვა ვერ იმუშავებს ერთმანეთისგან მოწყვეტილ მონაცემთა კუნძულებად.
რას ცვლის სწრაფი მიწოდება?
დიზაინის მიხედვით, სწრაფი მშენებლობა განზრახ აცოცხლებს დიზაინის, შესყიდვისა და შესრულების ერთდროულობას.
დიზაინი შეიძლება ჯერ კიდევ ვითარდებოდეს, მაშინ როდესაც კონტრაქტორი გრძელვადიანი მიწოდების პაკეტებს უკვეთავს. ამავდროულად, მშენებლობა შეიძლება დაიწყოს მანამ, სანამ ყველა ქვედა დონის პაკეტი საბოლოო დიზაინის სიმწიფეს მიაღწევს.
შედეგად, ამას შეუძლია საერთო მიწოდების დრო შეამციროს.
მაგრამ ის ასევე ზრდის რისკს შემდეგზე:
- დიზაინის ცვლილებები;
- მიმდინარე ინფორმაციით დადებული შესყიდვის ვალდებულებები;
- ვარიაციები;
- გადამუშავება;
- დაჩქარება;
- მოცულობის ხარვეზები;
- გრაფიკით გამოწვეული ხარჯების ზრდა.
ამიტომ fast-track უნდა ნიშნავდეს:
Controlled concurrency — არა უკონტროლო დაჩქარება.
ამ მიზეზით, თითოეული მსხვილი პაკეტისთვის კონტრაქტორს უნდა შეეძლოს დაადგინოს:
- რომელი მოცულობა იყო ბიუჯეტირებული?
- რომელი რევიზია იყო დაკვეთილი?
- რა შეიცვალა შემდეგ?
- რამდენია უკვე ვალდებულებად აღებული?
- რას ნიშნავს ეს ცვლილება პროგნოზირებულ ხარჯზე?
- რას ნიშნავს ეს ექსპლუატაციაში გაშვების თარიღისთვის?
სხვა შემთხვევაში, ამ მიკვლევადობის გარეშე, გრაფიკის დაჩქარება შეიძლება ჩუმად გადაიქცეს ხარჯების ზრდად.
როგორ უნდა იმუშაონ BoQ, WBS და Cost Codes ერთად?
ამ საკონტროლო არქიტექტურას უფრო დეტალურად განვიხილე BoQ, WBS and Cost Codes: How Contractors Connect Scope, Schedule and Cost-ში.
მოკლედ, პრინციპი მარტივია:
- BoQ = რაოდენობრივად განსაზღვრული და კომერციული მოცულობა
- WBS = შესრულება და დრო
- Cost Codes = შიდა ხარჯობრივი კლასიფიკაცია და კონტროლი
სხვა სიტყვებით, ეს სტრუქტურები სხვადასხვა მართვით მიზანს ემსახურება.
ამიტომ კონტრაქტორებმა ისინი არ უნდა გააერთიანონ ერთ კოდირების იერარქიაში.
ამის ნაცვლად, ისინი უნდა დარჩეს განცალკევებული, მაგრამ ურთიერთდაკავშირებული.
ანალოგიურად, მართვის სწორედ ეს ფილოსოფია არის ცენტრალური ProjectVIEW operating model-ში.
მაგალითად, განვიხილოთ UPS-ის პაკეტი.
- პირველი, BoQ, ან ეკვივალენტური რაოდენობრივად განსაზღვრული კომერციული სტრუქტურა, განსაზღვრავს, რას აწვდის და აყენებს კონტრაქტორი.
- შემდეგ Cost Code განსაზღვრავს, როგორ კლასიფიცირებს კომპანია დანახარჯებს შიდა დონეზე.
- ამავდროულად, WBS განსაზღვრავს, როდის უნდა განხორციელდეს მონტაჟი, ენერგიზაცია, ტესტირება და commissioning.
- შემდეგ შესყიდვა ქმნის ვალდებულებებს ამ მოცულობის მიმართ.
- მიმწოდებლის ცვლილებები, დამტკიცებული ვარიაციები, ლოჯისტიკური ხარჯები და დაჩქარება ანახლებს პროგნოზს.
- საბოლოოდ, ობიექტზე პროგრესი უზრუნველყოფს ფაქტობრივი ფიზიკური შესრულების მტკიცებულებას.
ამიტომ მენეჯმენტს შეუძლია გასცდეს კითხვას:
“რამდენი დავხარჯეთ?”
და დასვას კითხვა:
“ამ პაკეტის ვალდებულებით აღებული და პროგნოზირებული ხარჯი კვლავ შეესაბამება მის დამტკიცებულ ბიუჯეტს და მოვა თუ არა აღჭურვილობა დროულად, რომ WBS-ის ეტაპი დავიცვათ?”
მოკლედ, ეს სამშენებლო ხარჯების კონტროლის ბევრად უფრო სასარგებლო განსაზღვრებაა.
რატომ უნდა იყოს data center-ის კონტროლი commissioning-ზე ორიენტირებული?
Data center-ისთვის კონსტრუქციული ან არქიტექტურული დასრულება არ არის გადამწყვეტი ოპერაციული ეტაპი.
მისგან განსხვავებით, ენერგომომარაგება, გაგრილება, კონტროლი და ინტეგრირებული სისტემები მზად, გამოცდილი და commissioned უნდა იყოს, სანამ ობიექტი თავის დანიშნულებას შეასრულებს.
Turner & Townsend-ის მონაცემთა ცენტრების გრაფიკულ გამოწვევებზე ანალიზის მიხედვით გამოკითხული დარგის ექსპერტების 48%-მა ენერგიის ხელმისაწვდომობა დაასახელა როგორც ყველაზე თვალსაჩინო დაბრკოლება data center-ის პროექტების დროულად მიწოდებისთვის.
შესაბამისად, ეს ამყარებს ერთ მნიშვნელოვან დაგეგმვით პრინციპს:
კონტრაქტორებმა data center-ის მიწოდება უნდა აკონტროლონ ენერგიზაციის, ტესტირებისა და commissioning-ის უკან მიმართული ლოგიკით და არა მხოლოდ მშენებლობის დაწყებიდან წინ მიმართული ლოგიკით.
შემდეგ ურთიერთობა ასე ყალიბდება:
Commissioning Date → WBS Milestones → Equipment Need Dates → Procurement → Commitments → Forecast Cost
ამიტომ მნიშვნელოვანია ინტეგრაცია გრაფიკისა და ხარჯების კონტროლის გარემოს შორის.
Oracle Primavera P6-ის ან Microsoft Project-ის მსგავს საპლანო აპლიკაციებს 사용하는 კონტრაქტორებისთვის native scheduling connectivity შეიძლება დაეხმაროს WBS-ის შესრულებასა და პროექტის ხარჯობრივ სტრუქტურებს შორის კავშირის შენარჩუნებაში.
ამ გარემოში, შესაბამისად, Cost და Time ერთმანეთისგან დამოუკიდებელი მართვითი განზომილებები არ არის.
სინამდვილეში, ერთში დაგვიანებამ შეიძლება დაუყოვნებლივ გამოიწვიოს შედეგი მეორეში.
რა უნდა დაინახოს data center-ის კონტრაქტორმა რეალურ დროში?
სანდო project-control environment-მა მენეჯმენტს უნდა მისცეს შესაძლებლობა უპასუხოს ისეთ კითხვებს, როგორიცაა:
- რომელი MEP პაკეტები უახლოვდება ან აჭარბებს დამტკიცებულ ბიუჯეტებს?
- რომელი long-lead items უქმნის საფრთხეს კრიტიკულ WBS ეტაპებს?
- რა არის დაგეგმილი, ვალდებულებად აღებული, მიღებული, ინვოისით დარიცხული და გადახდილი?
- რომელი მიმწოდებლის ან ქვეკონტრაქტორის ვარიაციები რჩება გადაუჭრელი?
- როგორ ცვლის დიზაინის ცვლილებები Estimate at Completion-ს?
- რომელი შესყიდვის პაკეტები საჭიროებს დაჩქარებას?
- შესრულებული ფიზიკური პროგრესი შეესაბამება ფინანსურ პროგრესს?
- რა დამატებითი ხარჯია საჭირო ენერგიზაციის ან commissioning-ის ეტაპის დასაცავად?
ამ კითხვებიდან არცერთი არ ეკუთვნის მხოლოდ ინჟინერიას.
ან შესყიდვას.
ან დაგეგმვას.
არც მშენებლობას.
ან, ბოლოს, ფინანსებს.
სინამდვილეში, ისინი მოითხოვს საერთო პროექტის მართვის სტრუქტურას, რომელიც ამ ფუნქციებს ერთი და იმავე პროექტის კონტექსტში ამუშავებს.
როგორ შეუძლია ProjectVIEW ERP-ს ამ კონტროლის მოდელის მხარდაჭერა?
ProjectVIEW ERP აგებულია პროექტზე ორიენტირებულ ურთიერთობაზე Scope, Time and Cost-ს შორის. ის არ განიხილავს პროექტის ხარჯების კონტროლს, როგორც იზოლირებულ ფინანსურ ანგარიშგებით აქტივობას.
მისი Cost Control module აკავშირებს ფაქტობრივ და ბიუჯეტურ პროექტის ხარჯებს BoQ, WBS და Cost Code სტრუქტურებთან.
მისი Procurement and Purchasing module მხარს უჭერს პროცესს პროექტის მოთხოვნიდან და RFQ-ებიდან დაწყებული, მომწოდებლის შეფასებით, purchase order-ებით და შეკვეთის რევიზიებით დამთავრებული.
ProjectVIEW ERP ასევე უზრუნველყოფს native connectivity with Oracle Primavera P6 and Microsoft Project.
ეს მნიშვნელოვანია, რადგან გრაფიკი არ უნდა იდგეს ხარჯების კონტროლის გარემოს გარეთ, როგორც დამოუკიდებელი მონაცემთა ნაკრები.
მოკლედ, ძირითადი პრინციპი მარტივია:
შესყიდვის ორდერი არ უნდა არსებობდეს მხოლოდ როგორც ფინანსური ტრანზაქცია.
ამის ნაცვლად, მან უნდა შეინარჩუნოს ის პროექტის კონტექსტი, რომელმაც იგი შექმნა:
Scope → BoQ → Cost Code → WBS → Required Date → Commitment → Actual Execution
general contractors-ისთვის, რომლებიც data center-ებს აშენებენ, ეს განსაკუთრებით მნიშვნელოვანია მაშინ, როცა მათ ერთდროულად უწევთ მაღალი ღირებულების MEP პაკეტების, სპეციალიზებული ქვეკონტრაქტორების, გრძელი მიწოდების ჯაჭვების და შეკუმშული სამშენებლო გრაფიკების კონტროლი.
რატომ არის ეს განსაკუთრებით მნიშვნელოვანი ახლო აღმოსავლეთში?
ახლო აღმოსავლეთი სულ უფრო მნიშვნელოვანი data center construction ბაზარი ხდება.
Turner & Townsend-ის Middle East data-center outlook-ის მიხედვით, რეგიონული სიმძლავრე შეიძლება გაიზარდოს დაახლოებით 1.2 GW-დან 2025 წელს 3.3 GW-მდე 2030 წლისთვის. საუდის არაბეთი და UAE ამ გაფართოებას წამყვან ბაზრებს შორის არიან.
იმ კონტრაქტორებისთვის, რომლებიც hyperscale, cloud და AI ინფრასტრუქტურის პროექტებს იღებენ, შესაძლებლობა, შესაბამისად, ძალიან დიდია.
მაგრამ უფრო სწრაფი მიწოდება, მაღალი MEP ინტენსივობა და მიწოდების ჯაჭვის შეზღუდვებიც ზრდის შესრულების რისკს.
ამიტომ ოპერაციული ჯაჭვი დაკავშირებული უნდა დარჩეს შემდეგიდან:
Scope → Budget → Schedule → Procurement → Commitments → Delivery → Construction → Commissioning → Actual Cost
სწრაფი მიწოდება მეტ კონტროლს საჭიროებს და არა ნაკლებს
როგორც data-center პროექტები უფრო დიდი, უფრო ენერგოტევადი და უფრო გრაფიკზე მგრძნობიარე ხდება, კონტრაქტორებზე მიწოდების დაჩქარების წნეხი გაიზრდება.
თუმცა პასუხი არ უნდა იყოს მეტი ცხრილი.
ანალოგიურად, პასუხი არ უნდა იყოს მეტი ერთმანეთისგან მოწყვეტილი dashboard-ი.
და არც სწრაფი გადაწყვეტილებები უნდა იყოს governance-ის გვერდის ავლით მიღწეული.
ამის ნაცვლად, პასუხია უფრო მჭიდრო ინტეგრაცია scope, schedule, procurement, commitments, physical execution and cost შორის.
როდესაც Cost, Time და პროექტის ოპერაციები სინქრონიზებულია, მენეჯერებს შეუძლიათ გადახრები მაშინვე დაინახონ, როცა ჯერ კიდევ არის მოქმედების დრო.
საბოლოოდ, ეს არის განსხვავება შორის:
პროექტის შესრულების ანგარიშგებას
და
მის აქტიურ კონტროლს.
