სამშენებლო კომპანიებისთვის პროექტის კონტროლის ერთ-ერთი ყველაზე სახიფათო გაუგებრობაა, რომ ფაქტობრივი ღირებულება გეუბნებათ, არის თუ არა პროექტი ფინანსურად კონტროლქვეშ.
სინამდვილეში, ასე არ არის.
ფაქტობრივი ღირებულება გეუბნებათ, რას აღრიცხა უკვე ფინანსებმა გაწეულ ხარჯად.
თუმცა, პროექტის კონტროლმა ბევრად უფრო მნიშვნელოვანი კითხვა უნდა უპასუხოს:
რისი რისკის წინაშე ვდგავართ უკვე მანამდე, სანამ ხარჯი ინვოისად იქცევა?
აქ ხდება ვალდებული ღირებულება კრიტიკული.
ფაქტობრივი ღირებულება უკან იყურება. ვალდებული ღირებულება წინ იყურება.
მაგალითად, წარმოიდგინეთ, რომ კონტრაქტორს სამუშაო პაკეტისთვის აქვს დამტკიცებული AED 10 მილიონიანი ბიუჯეტი.
ამ დროისთვის კონტრაქტორმა ფაქტობრივ ხარჯად მხოლოდ AED 2 მილიონი აღრიცხა.
ერთი შეხედვით, პროექტი კომფორტულად გამოიყურება.
მაგრამ რა მოხდება, თუ კონტრაქტორს უკვე აღებული აქვს კიდევ AED 5 მილიონი შესყიდვის შეკვეთებითა და ქვეკონტრაქტებით?
და რა მოხდება, თუ დარჩენილი სამუშაოს დასასრულებლად კიდევ AED 4 მილიონია საჭირო?
მაშინ რეალური ექსპოზიცია აღარ არის AED 2 მილიონი.
სინამდვილეში, პროექტი შესაძლოა უკვე გადახარჯვისკენ მიდიოდეს.
ამიტომ სამშენებლო ხარჯების კონტროლი ვერ დაეყრდნობა მხოლოდ აღრიცხულ საბუღალტრო ტრანზაქციებს.
ამის ნაცვლად, სწორმა პროექტის კონტროლმა უნდა დააკავშიროს:
ფაქტობრივი ღირებულება + დარჩენილი ვალდებულებები + დარჩენილი არავალდებული ღირებულება = დასრულებისას პროგნოზირებული საბოლოო ღირებულება
ეს მჭიდროდ შეესაბამება პროექტის კონტროლში გამოყენებულ დასრულებისას შეფასების კონცეფციას:
რა არის ვალდებული ღირებულება?
ვალდებული ღირებულება წარმოადგენს ხარჯს, რომელიც კონტრაქტორმა უკვე ავტორიზებულია ისეთი მექანიზმებით, როგორიცაა:
- შესყიდვის ორდერები
- ქვეკონტრაქტები
- დამტკიცებული საკონტრაქტო ცვლილებები
- აღჭურვილობის იჯარის ხელშეკრულებები
- სხვა ფორმალურად მინიჭებული ვალდებულებები
მაგრამ არსებობს მნიშვნელოვანი განსხვავება.
მაგალითად, შესყიდვის შეკვეთის სრული მინიჭებული ღირებულება სულაც არ არის დარჩენილი ვალდებულება.
მაგალითად, პროექტს შესაძლოა უკვე მიღებული, მოხმარებული ან აღრიცხული ჰქონდეს ამ შესყიდვის შეკვეთის ნაწილი, როგორც ფაქტობრივი ღირებულება.
თუ მენეჯმენტი სრულ შესყიდვის შეკვეთის ღირებულებას დაამატებს ფაქტობრივ ხარჯებს, ორმაგმა დათვლამ შეიძლება გადააჭარბოს პროექტის პროგნოზს.
ამიტომ სწორ სამშენებლო ERP-ს უნდა შეეძლოს განასხვაოს:
- სრული მინიჭებული ღირებულება
- უკვე გაწეული ხარჯი
- დარჩენილი ვალდებული ღირებულება
- დასრულებისათვის საჭირო არავალდებული ღირებულება
Oracle თავად განასხვავებს სხვადასხვა ვალდებულების კატეგორიებსა და ტრანზაქციის სტატუსებს პროექტის ხარჯთაღრიცხვის დოკუმენტაციაში:
მოკლედ, გაკვეთილი მარტივია:
წარწერა „Committed Cost“ საკმარისი არ არის. ზუსტად უნდა იცოდეთ, რა დგას ამ რიცხვის უკან.
რატომ შეიძლება საბუღალტრო მონაცემები პროექტის კონტროლისთვის ძალიან გვიან მივიდეს
თუმცა, ეს არ ნიშნავს, რომ საბუღალტრო სისტემებს არ შეუძლიათ ხარჯების აღიარება ინვოისის მიღებამდე.
სინამდვილეში, შეუძლიათ.
დარიცხვის აღრიცხვის მეშვეობით კომპანიებს შეუძლიათ აღიარონ ვალდებულებები უკვე მიღებული, მაგრამ ჯერ არ ინვოისირებული საქონლის ან მომსახურებისთვის.
იხილეთ IFRS-ის მიდგომა დარიცხვებსა და გადასახდელებზე:
Oracle ასევე დოკუმენტირებს არაინვოისირებული მიღების დარიცხვებს:
რეალური პრობლემა მაშინ იწყება, როცა პროექტის მენეჯმენტი ოპერაციული გადაწყვეტილებებისთვის მხოლოდ აღრიცხულ საბუღალტრო მონაცემებს ეყრდნობა.
იმ დროისთვის, როცა მომწოდებლის ინვოისი ფინანსებში მივა, შესაძლოა რამდენიმე რამ უკვე მომხდარიყო:
ჯერ ვიღაცამ მოითხოვა მასალა.
შემდეგ მენეჯერმა დაამტკიცა შესყიდვის შეკვეთა.
გუნდმა აირჩია მომწოდებელი.
შემდეგ მოხდა მიწოდება.
ობიექტს შესაძლოა უკვე მოეხმარა მასალა.
ამავდროულად, სამუშაო შესაძლოა უკვე წინ წასული იყოს.
სხვა სიტყვებით, კომერციული რისკი ინვოისის გამოჩენამდე დიდი ხნით ადრე არსებობდა.
ამიტომ პროექტის კონტროლი პროცესში უფრო ადრე უნდა დაიწყოს.
სამშენებლო ხარჯების კონტროლი ინვოისამდე იწყება
კონტრაქტორმა ტრანზაქციის ფინანსური გავლენა უნდა აკვირდებოდეს იმ მომენტიდან, როცა ვინმე ქმნის მოთხოვნას.
ტიპური თანმიმდევრობაა:
მოთხოვნა → რეკვიზიცია → დამტკიცება → შესყიდვის შეკვეთა → მიწოდება → მოხმარება → ხარჯის აღიარება → ინვოისი → გადახდა
თითოეული ეტაპი განსხვავებულ კითხვასაც პასუხობს.
მაგალითად, რეკვიზიცია აჩვენებს მოთხოვნას.
შესყიდვის შეკვეთა აჩვენებს კომერციულ ვალდებულებას.
ანალოგიურად, მიწოდება აჩვენებს მიღებას.
მასალის მოხმარება აჩვენებს გამოყენებას.
ინვოისი ქმნის ფინანსურ ვალდებულებას.
და ბოლოს, გადახდა აჩვენებს ნაღდი ფულის მოძრაობას.
ამიტომ გუნდებმა ეს მოვლენები ურთიერთჩანაცვლებად არ უნდა განიხილონ.
ეს არის ერთ-ერთი ცენტრალური იდეა პროექტზე დაფუძნებული შესყიდვების უკან ProjectVIEW ERP-ში
თუმცა, მიზანი მხოლოდ შესყიდვების დიჯიტალიზაცია არ არის.
მისი მიზანია შესყიდვის გადაწყვეტილებების დაბრუნება იმ პროექტის ბიუჯეტსა და ოპერაციულ მოთხოვნასთან, რომელმაც ისინი შექმნა.
ყველაზე დიდი შეცდომა: ორმაგი დათვლა
მაგალითად, განვიხილოთ ქვეკონტრაქტი სრული მინიჭებული ღირებულებით AED 6 მილიონი.
ქვეკონტრაქტორმა უკვე შეასრულა AED 2 მილიონი სამუშაო და კონტრაქტორმა ეს ფაქტობრივ ხარჯად აღრიცხა.
ამიტომ დარჩენილი ვალდებულება დაახლოებით AED 4 მილიონია, თუ სხვა კორექტირება არ არსებობს.
თუ მენეჯმენტი ითვლის:
AED 2 მილიონი ფაქტობრივი ხარჯი + AED 6 მილიონი ვალდებული ღირებულება
მაშინ პროგნოზი ხდება AED 8 მილიონი.
მაგრამ AED 2 მილიონი ფაქტობრივი ხარჯი უკვე მოიცავს ამ AED 6 მილიონიანი ვალდებულების ნაწილს.
შედეგად, პროგნოზი ფაქტობრივად ერთსა და იმავე სამუშაოს ორჯერ ითვლის.
ამიტომ სწორი ლოგიკა ასეთია:
ფაქტობრივი ხარჯი + დარჩენილი ვალდებულება
ეს კიდევ უფრო მნიშვნელოვანი ხდება, როცა დარიცხვები გამოიყენება.
თუ ფინანსებმა უკვე დაარიცხა სამუშაო და მოგვიანებით მომწოდებლის ინვოისი მოვა, ფინანსებმა უნდა გააქროს ან ჩაანაცვლოს დარიცხვა და არა ისევ ჩათვალოს იგი.
სინამდვილეში, Oracle ცალსახად აღწერს ამ ტიპის დარიცხვის უკუქცევის ლოგიკას
რატომ არ ეუბნება committed cost მაინც სრულ ისტორიას
ვალდებული ღირებულებაც კი არ არის საკმარისი.
კონტრაქტორს შეიძლება ჯერ კიდევ ჰქონდეს მნიშვნელოვანი სამუშაო, რომელიც ჯერ არ შეუძენია ან არ გაუფორმებია ქვეკონტრაქტით.
მაგალითად, განვიხილოთ:
- სამომავლო შრომითი მოთხოვნები
- მანქანა-დანადგარების გამოყენება
- საწვავი
- დროებითი სამუშაოები
- ობიექტის ზედამხედველობა
- მასალების დამატებითი რაოდენობები
- პროექტის გახანგრძლივებული ვადა
- არამინიჭებული ქვეკონტრაქტის პაკეტები
ეს ხარჯები შესაძლოა ჯერ არც კი არსებობდეს შესყიდვის შეკვეთების სახით.
მაგრამ ისინი მაინც წარმოადგენენ პროექტის დასრულების სამომავლო ღირებულების ნაწილს.
ამიტომ რეალური პროექტის კონტროლის კითხვა არ არის:
რა დავხარჯეთ?
არც ეს არის:
რა გვაქვს ვალდებული?
ის არის:
ახლა რა ღირებულება იქნება მოსალოდნელი პროექტის დასრულებისას?
რატომ უნდა იყოს დაკავშირებული მოცულობა, გრაფიკი და ღირებულება
თუმცა, ამ კითხვაზე სწორად პასუხისთვის ხარჯები ვერ იარსებებს იზოლაციაში.
სანაცვლოდ, მათ კონტექსტი სჭირდებათ.
DANAOS Projects-ში ამას ვაწყობთ შემდეგი ურთიერთობით:
BoQ ↔ WBS ↔ Cost Codes
პირველ რიგში, სამუშაოების რაოდენობათა უწყება განსაზღვრავს კომერციულ და გაზომვად მოცულობას.
შემდეგ, სამუშაოთა დაშლის სტრუქტურა ამ მოცულობას აკავშირებს შესრულებასა და დროსთან.
და ბოლოს, Cost Codes გუნდებს საშუალებას აძლევს, ხარჯები და რესურსები თანმიმდევრულად დაახარისხონ.
ამას დეტალურად აქ განვიხილავთ:
BoQ, WBS და Cost Codes: მოცულობის, გრაფიკისა და ღირებულების დაკავშირება
შედეგად, ეს კავშირი მენეჯმენტს საშუალებას აძლევს დასვას უფრო არსებითი კითხვები.
მოცულობის რომელი ნაწილი ეკუთვნის ამ ვალდებულებას?
რომელ აქტივობაზე მოქმედებს?
რა რაოდენობა დარჩა?
რომელი რესურსები სჭირდება სამუშაოს ჯერ კიდევ?
რამდენი ბიუჯეტი დარჩა?
რა არის მოსალოდნელი საბოლოო ღირებულება?
ამ სტრუქტურის გარეშე კომპანიამ შეიძლება იცოდეს, რამდენი დახარჯა, მაგრამ ვერ გაიგოს, რატომ დახარჯა.
ობიექტის მონაცემები თანაბრად მნიშვნელოვანია
პროექტის ხარჯების კონტროლი ასევე დამოკიდებულია იმაზე, თუ რა ხდება ფაქტობრივად ობიექტზე.
მაგალითად, შესყიდვის შეკვეთამ შეიძლება აჩვენოს, რა იყიდა კომპანიამ.
თუმცა, ეს არ გეუბნებათ, იყენებდა თუ არა ობიექტი რესურსს ეფექტურად.
ანალოგიურად, მიწოდებული მასალა აუცილებლად არ ნიშნავს მოხმარებულ მასალას.
ობიექტზე მყოფი მუშახელი აუცილებლად არ ნიშნავს პროდუქტიულ მუშახელს.
ანალოგიურად, ხელმისაწვდომი აღჭურვილობა აუცილებლად არ ნიშნავს პროდუქტიულ აღჭურვილობას.
ბუღალტერიაში დაფიქსირებული პროგრესი ავტომატურად არ ასახავს ფიზიკურ პროგრესს.
ამიტომ არის, რომ ობიექტის მონაცემების აღება ფუნდამენტურია მშენებლობის ხარჯების კონტროლისთვის
მოკლედ, მიზანია ფინანსური რისკის დაკავშირება ოპერაციულ რეალობასთან.
როგორ უდგება ProjectVIEW ERP პრობლემას
ProjectVIEW ERP აერთიანებს შესყიდვებს, ობიექტზე ოპერაციებს, ქვეკონტრაქტირებას, ბიუჯეტირებას და ხარჯების კონტროლს ერთ, პროექტისთვის განკუთვნილ ოპერაციულ გარემოში.
გაძლიერებულ ინტეგრირებულ არქიტექტურას აქ განვმარტავთ: როგორ აღწევს ProjectVIEW ERP ნამდვილ ხარჯების კონტროლს
თუმცა, მიზანი უბრალოდ კიდევ ერთი ხარჯების ანგარიშის შექმნა არ არის.
ამის ნაცვლად, მიზანია პროექტის გუნდებმა ხარჯების რისკი გაიგონ მაშინ, როცა მოქმედებისთვის ჯერ კიდევ არსებობს დრო.
საბოლოო აზრი
რა თქმა უნდა, ბუღალტერია აუცილებელია.
მაგრამ ბუღალტერია და პროექტის კონტროლი განსხვავებულ მიზნებს ემსახურება.
ბუღალტერია ორგანიზაციას ეუბნება, რა აქვს მას ფინანსურად აღიარებული.
ამის საპირისპიროდ, პროექტის კონტროლმა ასევე უნდა გაიგოს, რა აქვს პროექტს ნაკისრი და მოხმარებული, რა რჩება ჩასაბარებელი და რა ეღირება ახლა, სავარაუდოდ, მისი დასრულება.
ამიტომ, კონტრაქტორებისთვის ყველაზე მნიშვნელოვანი კითხვა არ არის:
„რამდენი დავხარჯეთ?“
ის არის:
“რამდენად ვართ უკვე დაუცველები და რამდენი დაუჯდება ეს პროექტი რეალისტურად დასრულებისას?”
მოკლედ, სწორედ ეს არის განსხვავება ხარჯის ანგარიშგებასა და ხარჯის კონტროლს შორის.
