მეგაპროექტებში ხარჯების კონტროლი მარცხდება, როცა კომერციული მოცულობა, პროექტის შესრულება და ფაქტობრივი ხარჯი სხვადასხვა ენაზეა აღწერილი.
BoQ–WBS წყვეტა წარმოიქმნება მაშინ, როცა პროექტის შეფასებისა და ფასწარმოქმნისთვის გამოყენებული კომერციული მოცულობის სისტემურად შეჯერება შეუძლებელია მის დასაგეგმად და შესასრულებლად გამოყენებულ სამუშაო სტრუქტურასთან და ფაქტობრივი ხარჯის აღსარიცხად გამოყენებულ კოდირების სტრუქტურასთან.
- ხარჯთაღმრიცხველი აზროვნებს სამუშაოთა მოცულობების უწყისით (BoQ).
- დამგეგმავი აზროვნებს სამუშაოთა დეკომპოზიციის სტრუქტურით (WBS).
- შესყიდვების განყოფილება აზროვნებს მასალებით, შესყიდვის შეკვეთებითა და ქვეკონტრაქტებით.
- ობიექტი აზროვნებს დამონტაჟებული მოცულობებით, შრომის საათებით, ტექნიკის დატვირთვითა და დღიური წარმოებით.
- ფინანსები აზროვნებს ხარჯების კოდებით, ანგარიშებით, ინვოისებით, დარიცხვებითა და საანგარიშო პერიოდებით.
თითოეული ეს ხედვა შეიძლება ცალკე აღებული სწორი იყოს.
მაგრამ თუ მათი დაუყოვნებლივ შეჯერება შეუძლებელია, ხელმძღვანელობას რეალურ დროში ხარჯების კონტროლი არ აქვს. მას აქვს ერთი და იმავე პროექტის რამდენიმე წარმოდგენა, რომლებიც საბოლოოდ უნდა შეჯერდეს.
ეს განსხვავება ფუნდამენტურია.
ბაზრის ფასების ზრდა, მოცულობის ცვლილება, პროექტირების განვითარება, მწარმოებლურობის დანაკარგი, ლოჯისტიკური შეფერხებები, სახელშეკრულებო დავები და გაუთვალისწინებელი პირობები — ყველაფერმა ამან შეიძლება პროექტის ბიუჯეტის ლეგიტიმური გადაჭარბება გამოიწვიოს.
თუმცა ერთმანეთთან დაუკავშირებელი საპროექტო მონაცემები სხვა პრობლემასაც ქმნის:
ხელმძღვანელობა ეკონომიკურ გავლენას ძალიან გვიან აღმოაჩენს.
Baker Tilly-ის კაპიტალური პროექტების პრაქტიკა მშენებლობის განმეორებად რისკებს შორის ასახელებს შეუჯერებელ ხარჯების ანგარიშებს, არათანმიმდევრულ ფინანსურ და ოპერაციულ ჩანაწერებს, ბიუჯეტის სუსტ კონტროლს, დაგვიანებულ ხილვადობასა და პროექტის კონტროლის არასრულყოფილ პროცესებს. მისი საკონსულტაციო მეთოდოლოგია ხაზს უსვამს პროგრესის, ხარჯების, განრიგისა და სამუშაოს ხარისხის ინტეგრირებულ მონიტორინგს. Baker Tilly — კაპიტალური პროექტების კონსულტირება Baker Tilly — სამშენებლო ხარჯების გამჭვირვალობის ქეის-სტადი
სტრუქტურული პასუხი კიდევ ერთი დაშბორდი არ არის.
ეს არის ხარჯების კონტროლის ინტეგრირებული არქიტექტურა.
ProjectVIEW ERP-ისთვის ეს არქიტექტურა იწყება შემდეგით:
BoQ ↔ WBS ↔ ხარჯების კოდები
ProjectVIEW OS — BoQ-ის, WBS-ისა და ხარჯების კოდების არქიტექტურა
რა არის BoQ–WBS წყვეტა?
განვიხილოთ მსხვილი ინფრასტრუქტურული პაკეტი.
ტენდერი შეიძლება შეიცავდეს BoQ პოზიციას 150 000 მ³ მიწის სამუშაოებზე.
განრიგმა ეს მოცულობა შეიძლება გაანაწილოს ზონებს, ნაგებობებს, სამუშაო ფრონტებსა და მრავალ WBS აქტივობას შორის.
ფინანსებმა ხარჯები შეიძლება მიიღოს მიწის სამუშაოების შრომის, ნაქირავები ტექნიკის, საწვავის, ქვეკონტრაქტორების, ტრანსპორტირებისა და განთავსების მუხლებით.
შესაბამისად, პროექტში ერთი და იგივე ეკონომიკური რეალობა შეიძლება სამ სხვადასხვა სტრუქტურაში იყოს წარმოდგენილი:
| განზომილება | კითხვა, რომელსაც პასუხობს |
|---|---|
| BoQ | რა შევაფასეთ და რის მიწოდების ვალდებულება ავიღეთ? |
| WBS | რა სამუშაო უნდა შესრულდეს, სად და როდის? |
| ხარჯების კოდები | რა რესურსები და ხარჯები იხარჯება მის შესასრულებლად? |
თუ ამ განზომილებებს შორის კავშირები სუსტია, საპროექტო გუნდმა შეიძლება იცოდეს, რამდენი დახარჯა, ისე რომ ზუსტად არ იცოდეს, რა შედეგი მოიტანა ამ ხარჯმა.
ან შეიძლება იცოდეს, რომ ფიზიკური პროგრესი მიღწეულია, ისე რომ არ იცოდეს ამ პროგრესის მიღწევის სრული ღირებულება.
სწორედ ამ პრობლემის გამოსავლენად არის განკუთვნილი ათვისებული ღირებულების მართვა (Earned Value Management, EVM).
რატომ არღვევს წყვეტა ათვისებული ღირებულების მართვას?
ათვისებული ღირებულების მართვა PMI — ათვისებული ღირებულების მართვის განმარტება სამ ფუნდამენტურ საზომს აერთიანებს:
- დაგეგმილი ღირებულება (Planned Value, PV) — საანგარიშო თარიღისთვის დაგეგმილი სამუშაოს საბიუჯეტო ღირებულება.
- ათვისებული ღირებულება (Earned Value, EV) — ფაქტობრივად შესრულებული სამუშაოს საბიუჯეტო ღირებულება.
- ფაქტობრივი ხარჯი (Actual Cost, AC) — ამ სამუშაოს შესრულებისას რეალურად გაწეული ხარჯი.
ამ სამი საზომიდან გამომდინარე:
- ხარჯების გადახრა: CV = EV − AC
- განრიგის გადახრა: SV = EV − PV
- ხარჯების შესრულების ინდექსი: CPI = EV / AC
- განრიგის შესრულების ინდექსი: SPI = EV / PV
PMI-ის მიმდინარე EVM სახელმძღვანელო ხაზს უსვამს, რომ არითმეტიკა მარტივია; შედეგის აზრიანობას განსაზღვრავს საფუძვლად არსებული მოცულობის, განრიგის, ხარჯებისა და პროგრესის ინფორმაციის ხარისხი.
აშშ-ის მთავრობის ანგარიშვალდებულების ოფისი (GAO) უფრო შორს მიდის.
მისი ხარჯების შეფასებისა და ანალიზის სახელმძღვანელო (Cost Estimating and Assessment Guide) აცხადებს, რომ უნდა არსებობდეს ერთი საპროექტო WBS, რომელიც შეესაბამება ხარჯთაღრიცხვისა და განრიგის WBS-ს, რათა ფაქტობრივი ხარჯები ორივეში აისახოს. იგი ასევე საკონტროლო ანგარიშს (control account) განსაზღვრავს, როგორც წერტილს, სადაც ფაქტობრივი ხარჯები გროვდება და საბაზისო გეგმასთან გადახრები იზომება. GAO-ს ხარჯების შეფასებისა და ანალიზის სახელმძღვანელო — ათვისებული ღირებულების მართვა
ეს გადამწყვეტ დასკვნამდე მიგვიყვანს:
EVM ფორმულით არ იწყება. ის მონაცემთა არქიტექტურით იწყება.
რეალური პრობლემა არა მხოლოდ კოდირება, არამედ დროის სინქრონიზაციაცაა
არსებობს კიდევ ერთი მიზეზი, რომლის გამოც ფრაგმენტირებული სისტემები პროექტის კონტროლის შეცდომიში შეყვანილ ინფორმაციას ქმნის.
ათვისებული ღირებულება და ფაქტობრივი ხარჯი ერთსა და იმავე სამუშაოს უნდა ასახავდეს ერთსა და იმავე საანგარიშო პერიოდში.
აშშ-ის ენერგეტიკის დეპარტამენტის EVMS სახელმძღვანელო ამ პრობლემას პირდაპირ ეხება. როცა მასალები მიღებულია, მომწოდებლის ინვოისები კი ჯერ არ შემოსულა, შესაძლოა საჭირო იყოს შეფასებითი ფაქტობრივი ხარჯები, რათა ხარჯი იმავე პერიოდში აღიაროს, რომლის დროსაც ათვისებული ღირებულება ფიქსირდება; სხვაგვარად პროექტმა შესაძლოა ცრუ გადახრები გამოიმუშავოს. აშშ-ის ენერგეტიკის დეპარტამენტი — EVMS სახელმძღვანელო
PLANTA-ს მიერ ათვისებული ღირებულების მართვის მიმდინარე ახსნა იმავეს აღნიშნავს: ფაქტობრივი ხარჯების გატარების დაგვიანებამ შესაძლოა შეცდომიში შემყვანი ეფექტურობის მაჩვენებლები გამოიწვიოს, რადგან ათვისებული ღირებულება აღარ შეესაბამება ამ სამუშაოზე რეალურად გაწეულ ხარჯებს. PLANTA — ათვისებული ღირებულების მართვა და ხარჯების პროგნოზირება
ეს არის მონაცემების საბედისწერო ჩამორჩენა.
პროექტი შესაძლოა ჯანსაღი ჩანდეს, რადგან სამუშაო აღრიცხულია, ხოლო სრული ხარჯი — ჯერ არა.
- შემდეგ ინვოისები მოდის.
- დარიცხვები იტარება.
- ქვეკონტრაქტორების სერტიფიკატები დამტკიცდება.
- ტექნიკის ხარჯები განაწილდება.
- ხელფასის პერიოდი იხურება.
- შემოსავლიანობის წარმოსახული მარჟა ქრება.
- ბიუჯეტის გადაჭარბება თვის ბოლოს უეცრად არ წარმოქმნილა.
თვის დასასრულმა მხოლოდ გამოამჟღავნა ის, რაც ოპერაციულად უკვე მოხდა.
როგორ უნდა დაპროექტდეს BoQ, WBS და ERP ხარჯების კოდები?
მიზანს ზოგიერთი BoQ-ს, WBS-სა და ხარჯების კოდებს შორის 1:1:1 ურთიერთობად აღწერს.
საქართვლის მიხედვით ეს სასარგებლო ორიენტირია, მაგრამ მსხვილი პროექტებისთვის ტექნიკურად ზედმეტად გამარტივებულია.
რთულ პროექტში ერთი BoQ პოზიცია შეიძლება სავსებით კანონიერად სრულდებოდეს განრიგის რამდენიმე აქტივობით. რამდენიმე კომერციული BoQ პოზიცია ასევე შეიძლება იზიარებდეს საერთო შიდა რესურსს ან ხარჯების კლასიფიკაციას.
ამიტომ მიზანი არ უნდა იყოს იძულებითი ერთი-ერთზე შესაბამისობა.
მიზანი უნდა იყოს:
სრული, მართვადი და ცალსახა რელაციური მიკვლევადობა.
ProjectVIEW-ის გამოქვეყნებული არქიტექტურა პირდაპირ უჭერს მხარს BoQ კოდების WBS-თან დაკავშირებას და BoQ კოდებსა და შიდა ხარჯების კოდებს შორის მრავალი-ერთთან ასოციაციას, ნაცვლად იმისა, რომ ყოველი პროექტი ხელოვნურ ერთი-ერთზე სტრუქტურამდე დაიყვანოს. ProjectVIEW ERP-ის ბროშურა — სამმხრივი კავშირი
მყარი დანერგვა უნდა აყალიბებდეს კოდირების ერთ მართვად მოდელს ხუთ შრეში:
- კომერციული მოცულობა: BoQ-ის ყოველი რელევანტური სტრიქონი განსაზღვრავს რაოდენობას, ერთეულს, კომერციულ ღირებულებასა და ფასდადებულ მოცულობას.
- შესრულების სტრუქტურა: WBS-ის ელემენტები და სამუშაო პაკეტები განსაზღვრავს, როგორ და როდის შესრულდება მოცულობა.
- ხარჯების კლასიფიკაცია: შიდა ხარჯების კოდები ან ხარჯების დეკომპოზიციის სტრუქტურა თანმიმდევრულად აკლასიფიცირებს სამუშაო ძალას, მასალებს, ტექნიკას, ქვეკონტრაქტორებსა და სხვა პირდაპირ ხარჯებს.
- საკონტროლო ანგარიშები: მართვის საკონტროლო წერტილები აერთიანებს მოცულობას, განრიგს, ბიუჯეტს, ორგანიზაციულ პასუხისმგებლობასა და ფაქტობრივ ხარჯებს.
- ტრანზაქციების მიბმა: შესყიდვები, მასალების გაცემა, სამუშაო ძალა, ტექნიკა, ქვეკონტრაქტორები, წვრილი ხარჯები, პროგრესი და სხვა ფაქტობრივი ტრანზაქციები შესაბამის საპროექტო კოდირებას იღებენ, ნაცვლად იმისა, რომ შემდგომ ხელით შეჯერდონ.
შედეგი მხოლოდ უკეთესი ანგარიშგება არ არის.
იქმნება პროექტის მანქანისთვის წაკითხვადი ეკონომიკური მოდელი.
რატომ არის საკონტროლო ანგარიშები ასეთი მნიშვნელოვანი?
საკონტროლო ანგარიში (control account) კიდევ ერთი ხარჯების ცენტრის ველზე ბევრად მეტია.
აშშ-ის თავდაცვის დეპარტამენტი საკონტროლო ანგარიშს განსაზღვრავს, როგორც მართვის წერტილს, სადაც ბიუჯეტები და ფაქტობრივი ხარჯები გროვდება და მართვის კონტროლის მიზნით ათვისებულ ღირებულებას შეედარება. აშშ-ის თავდაცვის დეპარტამენტი — ათვისებული ღირებულების მართვის განმარტებები
PMI ანალოგიურად აღწერს მას, როგორც წერტილს, სადაც მოცულობა, განრიგი, ბიუჯეტი და ფაქტობრივი ხარჯი ეფექტურობის გასაზომად ერთიანდება. PMI — მოცულობის, განრიგისა და ხარჯების ინტეგრაცია საკონტროლო ანგარიშების მეშვეობით
სწორედ ასეთი არქიტექტურა სჭირდება მეგაპროექტების ხარჯების კონტროლს.
მხოლოდ BoQ არ კმარა.
მხოლოდ WBS არ კმარა.
მხოლოდ მთავარი წიგნი არ კმარა.
მენეჯმენტს სჭირდება საკონტროლო სტრუქტურა, სადაც სამუშაოს ერთი და იგივე ერთეულს ერთდროულად შეუძლია ოთხ კითხვას უპასუხოს:
- რის მიწოდებას დავეთანხმეთ?
- როდის უნდა მიგვეწოდებინა ის?
- რამდენი ღირებულება ავათვისეთ რეალურად?
- რა დაგვიჯდა რეალურად ამ პროგრესის მიღწევა?
ასეთი საერთო საკონტროლო წერტილის გარეშე ხარჯების გადახრა ოპერაციული სიგნალის ნაცვლად შეჯერების სავარჯიშოდ იქცევა.
სატენდერო სახარჯთაღრიცხვოდან შესრულების ბიუჯეტამდე
ხარჯების კონტროლის წარუმატებლობის მნიშვნელოვანი წყარო მშენებლობის დაწყებამდეც კი იჭრება თავს.
- ტენდერი ერთი სახარჯთაღრიცხვო სტრუქტურით იგება.
- შემდეგ საპროექტო გუნდი სხვა ბიუჯეტს ქმნის.
- დაგეგმვის განყოფილება სხვა WBS-ს აშუავებს.
- ფინანსები სხვა საბუღალტრო სტრუქტურას ადგენს.
- შესყიდვები შესყიდვის შეკვეთებს სხვა ტაქსონომიის მიხედვით კოდავს.
- რამდენიმე კვირაში ქრება თავდაპირველი კომერციული ლოგიკა, რომელმაც გამარჯვებული შეთავაზება გაამართლა.
ეს სასიცოცხლოდ მნიშვნელოვან კავშირს ანადგურებს:
სახარჯთაღრიცხვო → ბიუჯეტი → ვალდებულება → ფაქტი → პროგნოზი
ProjectVIEW-ის ბიუჯეტის შეფასებისა და ტენდერების არქიტექტურა უზრუნველყოფს BoQ-ის იმპორტს, რაოდენობრივ სტრუქტურებს, რისკებისა და ზედნადები ხარჯების მოდელირებას, BoQ–WBS სინქრონიზაციას და ხარჯების ბიუჯეტის შექმნას ერთსა და იმავე საკორპორაციო გარემოში. DANAOS Master SaaS Framework — ProjectVIEW-ის ბიუჯეტის შეფასება და ტენდერები
მისი ძირითადი პროცესების ნაკადი შემდგომ BoQ-ს, WBS-სა და ხარჯების ბიუჯეტს აკავშირებს შესყიდვებთან, მასალებთან, ქვეკონტრაქტორებთან, სამუშაო ძალასთან, ტექნიკასთან, პროექტის პროგრესთან, ფაქტობრივ ხარჯთან, მომხმარებლებთან დადებულ კონტრაქტებთან და ბუღალტრულ აღრიცხვასთან. ProjectVIEW ERP-ის ძირითადი პროცესების ნაკადები
ეს უწყვეტობა მნიშვნელოვანია, რადგან გამარჯვებული სახარჯთაღრიცხვო კონტრაქტის გაფორმების შემდეგ არქეოლოგიურ დოკუმენტად არ უნდა იქცეს.
იგი უნდა იქცეს ეკონომიკურ საბაზისო ხაზად, რომლის მიმართადაც შესრულება უწყვეტად მოწმდება.
რას ნიშნავს რეალურად ხარჯების კონტროლი რეალურ დროში?
„ხარჯების კონტროლი რეალურ დროში“ ხშირად არასწორად აღიქვამს.
ეს არ ნიშნავს უკონტროლო ფინანსური პროგნოზის ყოველ წამს გადათვლას.
ათვისებული ღირებულების ოფიციალური ანგარიშგება კვლავ მოითხოვს კონტროლირებად საბაზისო გეგმებს, საანგარიშო თარიღებს, დამტკიცებულ ცვლილებებსა და დისციპლინირებულ საანგარიშო პერიოდებს.
რეალურ დროში ხარჯების კონტროლი ნიშნავს ოპერაციულ მოვლენასა და მისი ეკონომიკური გავლენის მენეჯმენტისთვის ხილვადობას შორის დაყოვნების შემცირებას.
- როცა ობიექტის ინჟინერი პროგრესს აღრიცხავს, სისტემამ უნდა იცოდეს, რომელი სამუშაო შესრულდა.
- როცა მასალები გაიცემა, სისტემამ უნდა იცოდეს, რომელმა სამუშაო პაკეტმა მოიხმარა ისინი.
- როცა სამუშაო საათები აღირიცხება, სისტემამ უნდა იცოდეს, რომელმა საპროექტო აქტივობამ გამოიყენა ეს საათები.
- როცა ტექნიკა მუშაობს, მისი ხარჯი შესაბამის სამუშაოს უნდა მიეკუთვნოს.
- როცა ქვეკონტრაქტორის სერტიფიკატი დამტკიცდება, შესაბამისი საპროექტო მოცულობა და ბიუჯეტი უკვე ცნობილი უნდა იყოს.
სწორედ ეს არის ProjectVIEW ERP-ის „ობიექტიდან ოფისამდე“ მოდელის ფილოსოფია. მისი გამოქვეყნებული სამშენებლო არქიტექტურა დღიურ პროგრესს აკავშირებს მასალების მოხმარებასთან, შრომის მწარმოებლურობასთან და ტექნიკის დატვირთვასთან, ხოლო პროცესებს BoQ-სთან, WBS-სთან და ხარჯების კოდებთან ასოცირებს. ProjectVIEW ERP — სამშენებლო ხარჯებისა და ობიექტის კონტროლის არქიტექტურა
აზრი მეტი მონაცემი არ არის.
აზრი ისეთი მონაცემებია, რომლებიც ეკონომიკურად კლასიფიცირდება იმ მომენტში, როცა პროექტი მათ ქმნის.
ხარჯების პასიური ანგარიშგებიდან აქტიურ პროგნოზირებამდე
ტრადიციული ხარჯების ანგარიშგება სვამს კითხვას:
- რამდენი დავხარჯეთ წინა თვეში?
პროექტის კონტროლმა უნდა იკითხოს:
- იმის გათვალისწინებით, რაც დღეს ვიცით, რა დაჯდება ეს პროექტი დასრულებისას?
სწორედ ეს არის დასრულებისას მოსალოდნელი ხარჯის შეფასების (Estimate at Completion, EAC) დანიშნულება.
PMI პროგნოზირების რამდენიმე მიდგომას გამოყოფს, იმის მიხედვით, თუ რა ვარაუდს ვაკეთებთ მომავალ ეფექტურობაზე. თუ მოსალოდნელია, რომ მიმდინარე ხარჯების ეფექტურობა გაგრძელდება:
EAC = BAC / CPI
თუ ისტორიული გადახრა გამონაკლისად ითვლება და დარჩენილი სამუშაო საწყისი ბიუჯეტის შესაბამისად შესრულდება:
EAC = AC + (BAC − EV)
სხვა მიდგომები იყენებს დასრულებამდე დარჩენილი ხარჯის (Estimate to Complete) ახალ ქვემოდან ზემოთ შეფასებას ან ერთდროულად ითვალისწინებს ხარჯებისა და განრიგის შესრულებას. PMI — EVM პროგნოზირება და დასრულებისას მოსალოდნელი ხარჯის შეფასება
PLANTA ანალოგიურად აღწერს EAC, ETC, VAC და TCPI მაჩვენებლებს, როგორც პროექტის კონტროლის მომავლისკენ ორიენტირებულ საზომებს, რომლებიც წარსულ და მიმდინარე შესრულებას მოსალოდნელი საბოლოო ხარჯის სურათად გარდაქმნის. PLANTA — EAC და EVM პროგნოზირების მაჩვენებლები
მთავარი ის არ არის, რომელი ფორმულა იგებს.
მთავარია, საინდოა თუ არა ფორმულაში შემავალი ინფორმაცია.
თუ პროგრესი WBS-ის A აქტივობის მიხედვით აღირიცხება, ხოლო მისი ფაქტობრივი ხარჯი დამალულია საბუღალტრო ხარჯის კოდში, რომელიც B, C და D აქტივობებსაც მოიცავს, პროგნოზირების ფორმულის სიზუსტე უმნიშვნელო ხდება.
გამოთვლა შეიძლება მათემატიკურად ზუსტი, ხოლო ოპერაციულად მცდარი იყოს.
ბუღალტრული ისტორიიდან პროექტის წინასწარხედვისკენ
ტრადიციული ფინანსური აღრიცხვა აუცილებელია.
თუმცა ბუღალტრული აღრიცხვა სხვა კითხვას პასუხობს.
იგი აღრიცხავს და აწესრიგებს იმას, რაც კომპანიას ფინანსურად უკვე გაუწევია.
პროექტის ხარჯების კონტროლმა დამატებით უნდა გაიგოს, რომელმა სამუშაომ შექმნა ეს ხარჯი და რას ნიშნავს მიმდინარე შესრულება მომავლისთვის.
სწორედ ამიტომ ვერ იქცევა მთავარი წიგნი, განრიგის სისტემა და BI დაშბორდი ავტომატურად პროექტის კონტროლის ინტეგრირებულ გარემოდ მხოლოდ ფაილების გაცვლით.
პროექტზე ცენტრირებულმა არქიტექტურამ უნდა შეინარჩუნოს სემანტიკური კავშირი შემდეგ ელემენტებს შორის:
მოცულობა → რაოდენობა → განრიგი → რესურსი → ვალდებულება → ფაქტობრივი ხარჯი → პროგრესი → პროგნოზი
ProjectVIEW ამას აღწერს, როგორც საკუთარ BoQ ↔ WBS ↔ ხარჯების კოდების საპროექტო ბირთვს. ProjectVIEW OS — პროექტზე ცენტრირებული ბიზნეს-ლოგიკა
ამ ბირთვის ღირებულება იზრდება, როცა კომპანიები პრედიქტიულ ანალიტიკასა და AI-ს ნერგავენ.
რა იცვლება, როცა AI პროექტის ხარჯების კონტროლში შედის?
AI არ აუქმებს პროექტის დისციპლინირებული კონტროლის საჭიროებას.
იგი ამ საჭიროებას ზრდის.
დიდ ენობრივ მოდელს (LLM) შეუძლია ათასობით ჩანაწერის შეჯამება.
AI აგენტს შეუძლია საფასო შეთავაზებების ანალიზი.
მანქანური სწავლების მოდელებს შეუძლიათ ხარჯების არატიპური შაბლონების აღმოჩენა.
პროგნოზირების ძრავებს შეუძლიათ ახალი ტენდენციების გამოვლენა.
თუმცა AI-ს არ შეუძლია ფუნდამენტურად ბუნდოვანი საპროექტო მონაცემების კომპენსაცია.
თუ საწარმომ არ იცის, რომელი ფაქტობრივი ხარჯი რომელ მოცულობას, აქტივობასა და საანგარიშო პერიოდს ეკუთვნის, AI იმავე გაურკვევლობას იღებს.
სწორედ ამიტომ ამტკიცებს DANAOS, რომ ERP წინ უნდა უსწრებდეს AI-ს. DANAOS — რატომ წინ უსწრებს ERP AI-ს
გამოქვეყნებული ProjectVIEW OS ხედვა ProjectVIEW AI-ს სტრუქტურირებულ ERP შრეზე აშენებს, სადაც BoQ–WBS–ხარჯების კოდების კავშირი მანქანისთვის წაკითხვად საპროექტო კონტექსტს უზრუნველყოფს. ProjectVIEW OS — ERP-ისა და AI-ს არქიტექტურა
ასეთი საფუძვლით AI-ს შეუძლია ეტაპობრივად უფრო მაღალი ღირებულების კითხვების მხარდაჭერა.
იმის ნაცვლად, რომ იკითხოს:
- „რამდენი დავხარჯეთ?“
AI-ს შეუძლია გამოიკვლიოს:
- „რატომ უარესდება ბეტონის ხარჯების ეფექტურობა მე-3 ზონაში?“
იმის ნაცვლად, რომ იკითხოს:
- „რა არის ჩვენი მიმდინარე CPI?“
იგი დაგვეხმარება იკითხოთ:
- „რომელი სამუშაო პაკეტები იწვევს CPI-ს გაუარესებას და რას ნიშნავს მიმდინარე მწარმოებლურობა EAC-სთვის?“
იმის ნაცვლად, რომ იკითხოს:
- „რომელი შესყიდვის შეკვეთები აჭარბებს ბიუჯეტს?“
იგი დაგვეხმარება გამოვიკვლიოთ:
- „შესყიდვების რომელი ვალდებულებები გამოიწვევს ყველაზე მეტად მომავალში ბიუჯეტის გადაჭარბებას, მიმდინარე რაოდენობების, ფასებისა და დარჩენილი მოცულობის გათვალისწინებით?“
ეს არის გადასვლა მონაცემების მოძიებიდან ოპერაციულ მსჯელობაზე.
AI არ ჩანაცვლებს ათვისებული ღირებულების მართვას
ეს განსხვავება მნიშვნელოვანია.
AI-მ არ უნდა გამოიგონოს ათვისებული ღირებულება, ფაქტობრივი ხარჯი, ხარჯების ან განრიგის გადახრა.
ეს მნიშვნელობები მართვადი საპროექტო მონაცემებიდან და განსაზღვრული ბიზნეს-წესებიდან უნდა მოდიოდეს.
AI-ს როლი სხვაგან უფრო ღირებულია:
ანომალიების აღმოჩენა → მიზეზების გამოკვლევა → კავშირების გამოვლენა → სცენარების პროგნოზირება → რისკის ახსნა → ქმედების რეკომენდაცია
ამიტომ ProjectVIEW-ის სტრატეგია შეიძლება ორ შრედ გავიგოთ:
ProjectVIEW ERP უზრუნველყოფს დეტერმინისტულ პროცესებისა და მონაცემების შრეს.
ProjectVIEW AI უზრუნველყოფს ინტელექტისა და ავტონომიის შრეს.
ProjectVIEW OS — ციფრული შესრულება და ავტონომიური ინტელექტი
დეტერმინისტული შრე AI-ს ეუბნება, რა არის ჭეშმარიტი საწარმოს აღრიცხვის სისტემის მიხედვით.
მსჯელობის შრე მენეჯმენტს ეხმარება გადაწყვიტოს, რას ნიშნავს ეს ჭეშმარიტება.
რატომ ვერ გადაჭრის პრობლემას მხოლოდ განრიგის სისტემა
განრიგის მართვის სრულყოფილი სისტემა, მაგალითად Primavera P6, შეუძლია უზრუნველყოფს WBS-ს, აქტივობებს, ლოგიკურ კავშირებს, საკვანძო ეტაპებსა და დროის განზომილებას, რომლებიც პროექტის მოწინავე დაგეგმვისთვისაა საჭირო.
ეს უაღრესად მნიშვნელოვანია.
თუმცა მხოლოდ განრიგის ინფორმაცია ავტომატურად არ შეიცავს პროექტის შესრულების სრულ კომერციულ და ტრანზაქციულ რეალობას.
ამიტომ ProjectVIEW Primavera-სთან ინტეგრირდება, ნაცვლად იმისა, რომ ERP-ის განრიგის მოდულით სპეციალიზებული დაგეგმვის პროგრამული უზრუნველყოფის ჩანაცვლება ცდილოს.
ProjectVIEW ERP-ის არქიტექტურა Primavera-ს WBS სტრუქტურებს აკავშირებს BoQ კოდებთან, ბიუჯეტებთან და პროექტის ფაქტობრივ პროცესებთან, რათა განრიგის პროგრესი კომერციული და ხარჯების სტრუქტურის მიმართ შეფასდეს. ProjectVIEW ERP-ის ბროშურა — Primavera-ს, BoQ-ისა და ხარჯების ინტეგრაცია
არქიტექტურული განსხვავება მარტივია:
დაგეგმვა მენეჯმენტს ეუბნება, როდის უნდა შესრულდეს სამუშაო.
ინტეგრირებული ERP ხარჯების კონტროლი ხსნის, რა ეკონომიკურ გავლენას ახდენს ამ სამუშაოს შესრულება პროექტზე.
ორივეს ღირებულება მნიშვნელოვნად იზრდება, როცა ისინი კოდირების ერთსა და იმავე ენაზე საუბრობენ.
რატომ ვერ გადაჭრის მას მხოლოდ ზოგადი ERP-ც
კორპორატიული ERP სისტემები აუცილებელ ფუნქციებს ასრულებს, მათ შორის ბუღალტრულ აღრიცხვას, შესყიდვებს, ხაზინას, ხელფასებს, აქტივების მართვასა და ფინანსურ კონსოლიდაციას.
თუმცა კაპიტალური პროექტების ხარჯების კონტროლი კიდევ ერთ განზომილებას მოითხოვს:
თავად პროექტის ეკონომიკურ სტრუქტურას.
DANAOS-ის მიერ ზოგადი ERP არქიტექტურების ანალიზი ამტკიცებს, რომ BOM-ები, ხარჯების კოდები, ხარჯების ცენტრები და BoQ-ები ურთიერთჩანაცვლებადი კონსტრუქციები არ არის და რომ WBS-ზე დაფუძნებული დაგეგმვა რაოდენობაზე დაფუძნებული კომერციული მოცულობის გარეშე პროექტის კონტროლში მნიშვნელოვან ხარვეზებს ტოვებს. DANAOS — ზოგადი ERP-ების სტრუქტურული ანალიზი კაპიტალურ პროექტებში
პასუხი ავტომატურად კორპორატიული ERP-ის მოხსნა არ არის.
ProjectVIEW მხარს უჭერს ინტეგრაციებს SAP-თან, Oracle-თან, Primavera-სთან და სხვა საკორპორაციო გარემოებთან. ProjectVIEW ERP — ინტეგრაციის არქიტექტურა
არქიტექტურული მიზანი უფრო პრაგმატულია:
ყოველმა სისტემამ შეასრულოს თავისი როლი, ხოლო მათ შორის შენარჩუნდეს პროექტის ერთიანი, თანმიმდევრული ეკონომიკური სტრუქტურა.
მწარე ჭეშმარიტება: პროგრამული უზრუნველყოფა სუსტ პროექტის კონტროლს ვერ ასწორებს
კომპანიას შეუძლია შეიძინოს მსოფლიოში ერთ-ერთი ყველაზე სრულყოფილი ERP სისტემა და მაინც არასანდო ხარჯების პროგნოზები მიიღოს.
ტექნოლოგია ვერ ანაზღაურებს:
მოცულობის ბუნდოვან პასუხისმგებლობას; არათანმიმდევრულ კოდირებას; საბაზისო გეგმის დაუმტკიცებელ ცვლილებებს; პროგრესის ანგარიშგების დაგვიანებას; გამოტოვებულ დარიცხვებს; არაზუსტ რაოდენობებს; დაუკონტროლებელ ხარჯების გადატანას; შესყიდვების სუსტ დისციპლინას; ან საპროექტო გუნდებს, რომლებიც განსაზღვრულ სამუშაო პროცესებს გვერდს უვლიან.
Baker Tilly-ის სამშენებლო საკონსულტაციო მეთოდოლოგია ხაზს უსვამს პროექტის კონტროლის სტრუქტურებს, პოლიტიკას, პროცედურებს, ხარჯების ანგარიშგებას, პროგრესის მონიტორინგსა და ანგარიშვალდებულებას — და არა მხოლოდ ტექნოლოგიის დანერგვას. Baker Tilly — სამშენებლო აუდიტი და პროექტის კონტროლი
PMI არსებითად იმავეს აღნიშნავს EVM-ის თვალსაზრისით: პლატფორმას შეუძლია ათვისებული ღირებულების მაჩვენებლები ზუსტად გამოთვალოს და მაინც მისცეს მენეჯმენტს შეცდომიში შემყვანი ინფორმაცია, თუ საბაზისო გეგმა სუსტია. PMI — ათვისებული ღირებულების მართვა: რიცხვების წაკითხვა
DANAOS ამ პრინციპს ანალოგიურად გამოხატავს AI-სთვის მზადობის საკუთარ სტრატეგიაში:
ჯერ პროცესის სტანდარტიზაცია, შემდეგ მონაცემების სტრუქტურირება, ბოლოს ავტომატიზაცია და AI-ს გამოყენება.
DANAOS — ჯერ იარე, მერე ირბინე: რატომ წინ უსწრებს ERP AI-ს
ხარჯების უწყვეტი კონტროლის არქიტექტურა
პროექტის კონტროლის ტრადიციული მოდელი ხშირად ასე გამოიყურება:
შესრულება → ლოდინი → შეგროვება → შეჯერება → ანგარიშგება → ახსნა
სანამ უმაღლესი მენეჯმენტი ახსნას მიიღებს, მასწორებელი ვარიანტები შესაძლოა უკვე შეზღუდული იყოს.
უკეთესი მოდელია:
დაგეგმვა → შესრულება → აღრიცხვა → შედარება → აღმოჩენა → პროგნოზირება → კორექტირება
ProjectVIEW-ის ძირითადი ნაკადები ხარჯების ბიუჯეტს აკავშირებს ობიექტის ტრანზაქციებთან, სამუშაო ძალასთან, ტექნიკასთან, მასალებთან, შესყიდვებთან, ქვეკონტრაქტორებთან, პროგრესთან, შემოსავლებთან და ბუღალტრულ აღრიცხვასთან. ProjectVIEW ERP — ძირითადი პროცესების ინტეგრირებული ნაკადი
ეს ქმნის საფუძველს იმისთვის, რასაც DANAOS პროექტის უწყვეტ რეალობის შემოწმებას უწოდებს.
ყოველი ოპერაციული ტრანზაქცია შეიძლება შეფასდეს ორი ფუნდამენტური განზომილების მიხედვით:
- დრო — WBS-ის მეშვეობით
და
- ხარჯი — BoQ-ის, ბიუჯეტისა და ხარჯების კოდების სტრუქტურის მეშვეობით.
მიზანი ის არ არის, რომ აღმოვაჩინოთ, რომ პროექტმა ბიუჯეტს გადააჭარბა.
მიზანია გადაჭარბების გამომწვევი მექანიზმის აღმოჩენა მაშინ, როცა მენეჯმენტს კვლავ შეუძლია შედეგის შეცვლა.
რა არის „ხარჯების კვანტური კონტროლი“ (Quantum Cost Control)?
DANAOS იყენებს ტერმინს Quantum Cost Control ხარჯების ისეთი კონტროლის აღსაწერად, რომელიც ხორციელდება დეტალურ ტრანზაქციულ და საპროექტო პროცესის დონეზე და არა მხოლოდ პერიოდული აგრეგირებული ფინანსური ანგარიშგების მეშვეობით.
ProjectVIEW ERP-ში ფაქტი ბიუჯეტთან შედარებით, პროექტის პროგრესი, შესყიდვები, ქვეკონტრაქტორები, სამუშაო ძალა, ტექნიკა და ობიექტის ტრანზაქციები ერთსა და იმავე პროექტზე ცენტრირებულ საინფორმაციო მოდელში არსებობს. ProjectVIEW ERP — ხარჯების კონტროლი და პროექტის შესრულება
კონცეფცია მარტივია:
თუ ყოველი ეკონომიკურად მნიშვნელოვანი მოვლენა შეიძლება დაუკავშირდეს მის საპროექტო კონტექსტს, მენეჯმენტს აღარ სჭირდება ლოდინი, სანამ ერთმანეთთან დაუკავშირებელი ინფორმაცია ხელით შეჯერდება, რომ შესრულება გაიგოს.
ეს გაურკვევლობას არ აქრობს.
იგი აქრობს ზედმეტ საინფორმაციო ჩამორჩენას.
და მეგაპროექტების ხარჯების კონტროლში ჩამორჩენა შესაძლოა ძალიან ძვირი დაჯდეს.
ხშირად დასმული კითხვები BoQ-ის, WBS-ისა და ERP ხარჯების კოდების შესახებ
რა განსხვავებაა BoQ-სა და WBS-ს შორის?
სამუშაოთა მოცულობების უწყისი (BoQ) ასტრუქტურებს გაზომვად კომერციულ მოცულობას, რაოდენობებს, ერთეულებსა და ფასებს. სამუშაოთა დეკომპოზიციის სტრუქტურა (WBS) პროექტის მოცულობას შესრულების მართვად ელემენტებად შლის, რომლებიც გამოიყენება დაგეგმვისთვის, პასუხისმგებლობის განაწილებისთვის და განრიგის მართვისთვის.
ისინი ერთი და იგივე პროექტის სხვადასხვა განზომილებას აღწერს და, შესაბამისად, რელაციურად უნდა იყოს დაკავშირებული და არა ერთმანეთის ჩამნაცვლებლად განხილული.
რა არის ERP ხარჯის კოდი?
ERP ხარჯის კოდი არის სტრუქტურირებული კლასიფიკაცია, რომელიც გამოიყენება პროექტის ხარჯის განსაზღვრულ ხარჯების კატეგორიაზე ან ხარჯის ობიექტზე მისაკუთნებლად.
პროექტზე ორიენტირებულ ERP-ში ხარჯების კოდები ბევრად უფრო ძლიერი ხდება, როცა ისინი BoQ-ის მოცულობასა და WBS-ის შესრულების სტრუქტურებს უკავშირდება, რადგან მენეჯმენტს შეუძლია გაიგოს ორივე — რა დაიხარჯა და რომელ სამუშაოს დაუჭირა მხარი ამ ხარჯმა.
ProjectVIEW ERP — BoQ-ის, WBS-ისა და შიდა ხარჯების კოდების არქიტექტურა
რატომ იწვევს BoQ–WBS წყვეტა ხარჯების სუსტ კონტროლს?
როცა BoQ-ის მოცულობისა და WBS-ის შესრულების შეჯერება შეუძლებელია, რაოდენობა, განრიგის პროგრესი და ფაქტობრივი ხარჯი პროექტს სხვადასხვა დონეზე აღწერს.
ეს ართულებს დაგეგმილი ღირებულების, ათვისებული ღირებულებისა და ფაქტობრივი ხარჯის შედარებას ერთისა და იგივე მოცულობისა და საანგარიშო პერიოდისთვის და ზრდის ხელით შეჯერებაზე დამოკიდებულებას.
უნდა იყოს თუ არა BoQ-ის, WBS-ისა და ხარჯების კოდების მიბმა 1:1:1?
არა.
მეგაპროექტი ხშირად ძალიან რთულია სიტყვასიტყვითი ერთი-ერთზე ურთიერთობისთვის.
მოთხოვნაა სრული და მართვადი მიკვლევადობა.
მაგალითად, ProjectVIEW მხარს უჭერს BoQ–WBS ასოციაციას და BoQ კოდებსა და შიდა ხარჯების კოდებს შორის მრავალი-ერთთან მიბმას. ProjectVIEW ERP-ის ბროშურა — სამმხრივი კავშირი
რა არის საკონტროლო ანგარიში ათვისებული ღირებულების მართვაში?
საკონტროლო ანგარიში არის მართვის საკონტროლო წერტილი, სადაც პროექტის მოცულობა, ბიუჯეტი, განრიგი, ფაქტობრივი ხარჯი და ორგანიზაციული პასუხისმგებლობა ეფექტურობის გასაზომად ერთიანდება.
როგორც PMI, ისე აშშ-ის სამთავრობო EVMS სახელმძღვანელოები საკონტროლო ანგარიშებს სანდო ათვისებული ღირებულების მართვის საფუძვლად მიიჩნევს. PMI — EVM-ის საკონტროლო ანგარიშები აშშ-ის თავდაცვის დეპარტამენტი — საკონტროლო ანგარიშის განმარტება
რა არის ხარჯების გადახრა EVM-ში?
ხარჯების გადახრა (CV) = ათვისებული ღირებულება (EV) − ფაქტობრივი ხარჯი (AC).
უარყოფითი CV მიუთითებს, რომ გაწეული ხარჯი აჭარბებს ფაქტობრივად შესრულებული სამუშაოს საბიუჯეტო ღირებულებას.
რა არის განრიგის გადახრა EVM-ში?
განრიგის გადახრა (SV) = ათვისებული ღირებულება (EV) − დაგეგმილი ღირებულება (PV).
უარყოფითი SV ნიშნავს, რომ შესრულებული სამუშაოს საბიუჯეტო ღირებულება ნაკლებია საანგარიშო თარიღისთვის დასასრულებლად დაგეგმილ ღირებულებაზე.
რატომ უნდა აღირიცხოს ფაქტობრივი ხარჯი და ათვისებული ღირებულება ერთსა და იმავე პერიოდში?
იმიტომ, რომ CV ადარებს შესრულებული სამუშაოდან ათვისებულ ღირებულებას იმავე სამუშაოს შესრულებაზე გაწეულ ხარჯთან.
თუ ხარჯი პროგრესზე გვიან აღირიცხება, პროექტმა შესაძლოა ხელოვნურად ხელსაყრელი ხარჯების მდგომარეობა აჩვენოს. აშშ-ის EVMS სახელმძღვანელო სპეციალურად ეხება შეფასებითი ფაქტობრივი ხარჯების საჭიროებას შესაბამის შემთხვევებში, ცრუ გადახრების თავიდან ასაცილებლად. აშშ-ის ენერგეტიკის დეპარტამენტი — ფაქტობრივი ხარჯებისა და ათვისებული ღირებულების შესაბამისობა
რა არის დასრულებისას მოსალოდნელი ხარჯის შეფასება?
დასრულებისას მოსალოდნელი ხარჯის შეფასება (EAC) არის პროექტის მოსალოდნელი ჯამური ხარჯის პროგნოზი დასრულებისას.
ერთ-ერთი გავრცელებული ფორმულაა:
EAC = BAC / CPI
იმ შემთხვევაში, როცა ვარაუდობთ, რომ მიმდინარე ხარჯების ეფექტურობა გაგრძელდება.
EAC-ის სხვადასხვა მეთოდი პროგნოზირების ვარაუდის შესაბამისად უნდა შეირჩეს და არა მექანიკურად გამოიყენოს. PMI — დასრულებისას მოსალოდნელი ხარჯის პროგნოზირება
როგორ აუმჯობესებს AI პროექტის ხარჯების პროგნოზირებას?
AI-ს შეუძლია დაეხმაროს ხარჯების არატიპური შაბლონების აღმოჩენას, ეფექტურობის გაუარესების მამოტივებელი ფაქტორების გამოვლენას, ისტორიული შედეგების ანალიზსა და პროგნოზირების სცენარების შეფასებას.
თუმცა AI პროგნოზირება მხოლოდ იმდენად სანდოა, რამდენადაც სანდოა მისთვის მიწოდებული საპროექტო კონტექსტი. მოცულობას, განრიგს, რაოდენობებს, ხარჯსა და ფაქტობრივ შესრულებას შორის სტრუქტურირებული კავშირები AI-სთვის ბევრად უფრო მყარ საფუძველს ქმნის, ვიდრე ერთმანეთთან დაუკავშირებელი ცხრილები ან ბუღალტრული ტრანზაქციები.
შეუძლია თუ არა ProjectVIEW ERP-ს Primavera P6-თან ინტეგრაცია?
დიახ.
ProjectVIEW მხარს უჭერს Primavera-სთან ინტეგრაციას და WBS-ის დაგეგმვის სტრუქტურებს BoQ-სთან, ბიუჯეტთან და პროექტის შესრულების ინფორმაციასთან აკავშირებს.
ჩანაცვლებს თუ არა ProjectVIEW არსებულ კორპორატიულ ERP-ს?
აუცილებლად არა.
ProjectVIEW-ს შეუძლია იმუშაოს როგორც პროექტზე ცენტრირებულმა მშენებლობისა და ხარჯების კონტროლის შრემ, რომელიც ინტეგრირდება დანერგილ საკორპორაციო გარემოებთან, მათ შორის SAP-თან და Oracle-თან დაკავშირებულ სისტემებთან.
როგორ უჭერს მხარს ProjectVIEW ERP სამშენებლო ხარჯების კონტროლს რეალურ დროში?
ProjectVIEW ინტეგრირებულ საპროექტო მონაცემთა მოდელში აკავშირებს BoQ-ს, WBS-ს, ხარჯების კოდებს, ბიუჯეტს, შესყიდვებს, ქვეკონტრაქტორებს, მასალებს, სამუშაო ძალას, ტექნიკას, ობიექტის პროგრესსა და ბუღალტრულ აღრიცხვას.
მისი გამოქვეყნებული არქიტექტურა უზრუნველყოფს ფაქტისა და ბიუჯეტის შედარებით მონიტორინგს და ობიექტზე საქმიანობას საწარმოს საპროექტო სტრუქტურასთან აკავშირებს. ProjectVIEW ERP-ის ბროშურა — სამშენებლო ხარჯების კონტროლი
საბოლოო პრინციპი
მეგაპროექტების ხარჯების კონტროლი უპირატესად დაშბორდის პრობლემა არ არის.
ეს მხოლოდ ბუღალტრული პრობლემა არ არის.
ეს მხოლოდ განრიგის პრობლემა არ არის.
და ეს არც AI-ს პრობლემაა.
ეს არქიტექტურის პრობლემაა.
კომერციული მოცულობა უნდა დაუკავშირდეს შესრულებას.
შესრულება უნდა დაუკავშირდეს განრიგს.
განრიგი უნდა დაუკავშირდეს ბიუჯეტს.
რესურსები უნდა დაუკავშირდეს სამუშაოს.
ფაქტობრივი ხარჯი უნდა დაუკავშირდეს იმ მოცულობას, რომელმაც იგი შექმნა.
პროგრესი და ხარჯი შედარებად პერიოდებში უნდა იზომებოდეს.
პროგნოზირებამ იგივე სტრუქტურა უნდა მემკვიდროს.
მხოლოდ ამის შემდეგ შეუძლიათ EVM-ს, პრედიქტიულ ანალიტიკასა და AI-ს სანდო საპროექტო რეალობაზე იმუშაონ.
სწორედ ამიტომ კავშირი:
BoQ ↔ WBS ↔ ხარჯების კოდები
უფრო მეტია, ვიდრე ProjectVIEW-ის ფუნქცია.
ეს არის პროექტზე ცენტრირებული ხარჯების კონტროლის არქიტექტურის საფუძველი.
- BoQ გეუბნება, რა გაყიდეთ.
- WBS გეუბნება, როგორ და როდის აპირებთ მის აშენებას.
- ხარჯის კოდი გეუბნება, რას მოიხმარს საწარმო მის შესასრულებლად.
ERP ამ რეალობებს აკავშირებს. ხოლო როგორც კი ეს რეალობები დაკავშირდება, პროექტის მართვა შეიძლება გუშინდელი გადაჭარბების ახსნიდან ხვალინდელის აღმოჩენაზე გადავიდეს. სწორედ ეს არის განსხვავება ხარჯების ანგარიშგებასა და ხარჯების კონტროლს შორის.
