მოცულობათა უწყება (BoQ), სამუშაოების დაშლის სტრუქტურა (WBS) და Cost Codes ერთსა და იმავე რამეს არ აღწერს.
- BoQ აღწერს გაზომვად და კომერციულ მოცულობას.
- WBS აღწერს, როგორ და როდის სრულდება სამუშაო.
- Cost Codes აღწერს, როგორ ახდენს კონტრაქტორი რესურსებისა და დანახარჯების კლასიფიკაციას და კონტროლს.
რთული კონტრაქტორებისთვის მიზანი არ უნდა იყოს ამ განზომილებების ერთ იერარქიაში ძალით მოქცევა. ნაცვლად ამისა, უნდა შეიქმნას მათ შორის მართვადი კავშირები. შედეგად, მენეჯმენტს შეუძლია ფიზიკური მოცულობა, გრაფიკი, რესურსები, დანახარჯი, ვალდებულებები, პროგრესი და ფინანსური შედეგები იმავე პროექტის საბაზისო გეგმამდე მიადევნოს.
მოკლედ, ეს არის ინტეგრირებული პროექტის კონტროლის საფუძველი.
რატომ სჭირდება პროექტებს სამი სტრუქტურა?
პრაქტიკაში პროექტს რამდენიმე ლეგიტიმური პერსპექტივიდან უყურებენ.
- კლიენტს შეიძლება აინტერესებდეს: რა მოცულობა მიაწოდეთ და რა შეიძლება ანგარიშფაქტურით წარადგინოთ?
- დამგეგმავი სვამს კითხვას: რომელი აქტივობა უნდა მიმდინარეობდეს ახლა?
- Cost Controller სვამს კითხვას: რომელ ბიუჯეტსა და Cost Code-ს უნდა დაერიცხოს დანახარჯი?
- სამშენებლო მოედნის მენეჯერი სვამს კითხვას: რა რესურსები გამოვიყენეთ დღევანდელი პროგრესის მისაღწევად?
- და ბოლოს, ფინანსები სვამს კითხვას: სად უნდა გატარდეს შედეგად მიღებული ტრანზაქცია?
რა თქმა უნდა, ამ კითხვებიდან არცერთი არ არის მცდარი.
მცდარი არის იმის მოლოდინი, რომ ერთმა სტრუქტურამ ყველა მათგანს უნდა უპასუხოს.
ყველანი ვეთანხმებით, რომ: მხოლოდ WBS საკმარისი არ არის პროექტის დანახარჯის კონტროლისთვის
შემდეგი კითხვა ამიტომ ასეთია: რასთან უნდა იყოს დაკავშირებული WBS?
ბევრ კონტრაქტორულ გარემოში პასუხი სამი განზომილებით იწყება:
BoQ ↔ WBS ↔ Cost Codes
რას აკონტროლებს BoQ?
მოცულობათა უწყება (BoQ), უპირველეს ყოვლისა, მოცულობის რაოდენობრივ და კომერციულ წარმოდგენას წარმოადგენს.
ის პასუხობს:
- რას ვაწვდით?
- რამდენს ვაწვდით?
- როგორ იზომება და ფასდება ეს სამუშაო?
BoQ-ის ხაზი შეიძლება შეიცავდეს:
- აღწერას;
- საზომ ერთეულს;
- რაოდენობას;
- ტარიფს;
- ღირებულებას;
- კომერციულ ან საკონტრაქტო კლასიფიკაციას.
თუმცა შეფასებისას BoQ გაცილებით უფრო ძლიერ ინსტრუმენტად იქცევა. ეს ხდება მაშინ, როცა შემფასებელი თითოეულ გაზომვად პოზიციას ყოფს იმ რესურსებად, რომლებიც საჭიროა მის შესაქმნელად.
მაგალითად:
1 მ³ არმირებული ბეტონი
შეიძლება მოითხოვდეს:
- X ადამიან-საათს განსაზღვრული სპეციალობების ფარგლებში;
- Y ტონა არმირებას;
- Z მ³ მზა ბეტონს;
- ფორმულების განსაზღვრულ რაოდენობას;
- მექანიზმების საათებს;
- ქვემონტაქტორის რესურსებს.
DANAOS Projects-ს აქვს BoQ-ზე ორიენტირებული შეფასების მოდელი, რომელიც ეფუძნება ობიექტზე გამოცდილი დანახარჯის რეცეპტებსა და პროდუქტიულობის შაბლონებს, რეალურ სამშენებლო მოედნის მონაცემებზე დაყრდნობით.
ამრიგად, BoQ პასუხობს ეკონომიკურ კითხვას, რომელზეც გრაფიკი მარტო პასუხს ვერ გასცემს:
რა გაზომვადი გამომუშავება უნდა შექმნას ამ რესურსებმა?
რას აკონტროლებს WBS?
სამუშაოების დაშლის სტრუქტურა (WBS) ორგანიზებას უკეთებს პროექტის შესრულებას.
ის პროექტს ყოფს თანდათან უფრო მართვად, დროით შეზღუდულ სამუშაო პაკეტებად. გარდა ამისა, ის ქმნის იმ სტრუქტურას, რომლის გარშემოც გუნდები აწყობენ აქტივობებს, პასუხისმგებლობებსა და გრაფიკებს.
ის პასუხობს:
- სად უნდა მიეკუთვნოს ეს სამუშაო?
- როგორ იყოფა შესრულება?
- როდის უნდა შესრულდეს ის?
აშშ-ის GAO WBS-ს აღწერს, როგორც საყრდენს პროექტის სამუშაოების განსაზღვრისა და გრაფიკის, დანახარჯისა და Earned Value Management-ის ინტეგრირებული ჩარჩოს შესაქმნელად.
აშშ-ის GAO-ს ხარჯთაღრიცხვისა და შეფასების სახელმძღვანელო
თუმცა WBS და BoQ ერთმანეთის ჩანაცვლება არ არის.
- BoQ-ის ერთმა პოზიციამ შეიძლება ერთზე მეტ WBS აქტივობას შეუწყოს ხელი.
- საპირისპიროდ, ერთმა WBS აქტივობამ შეიძლება მოიხმაროს BoQ-ის რამდენიმე პოზიცია ან რესურსის ტიპი.
ამიტომ ურთიერთკავშირი შეიძლება იყოს:
ერთ-ერთზე
ერთ-ბევრზე
ან
ბევრ-ბევრზე
პროექტის კომერციული და შესრულების სტრუქტურის მიხედვით.
ამ მიზეზით, სტრუქტურების ერთმანეთთან რუკირება უფრო სასარგებლოა, ვიდრე მათი იდენტურობამდე დაყვანის მცდელობა.
რას აკონტროლებს Cost Codes?
Cost Codes, ან Cost Control Accounts, რომლებიც Cost Breakdown Structure (CBS) ფუნქციას აყალიბებს, წარმოადგენს შიდა მენეჯმენტის ხედვას.
ისინი პასუხობენ:
- რა ტიპის დანახარჯია ეს?
- სად უნდა დაგროვდეს ის?
- ვინ არის მასზე პასუხისმგებელი?
მაგალითად, კონტრაქტორს შეიძლება სურდეს განასხვაოს:
- შრომა;
- ბეტონი;
- არმირება;
- საწვავი;
- მძიმე ტექნიკა;
- ქვემონტაქტირება;
- დროებითი სამუშაოები;
- არაპირდაპირი სამშენებლო მოედნის დანახარჯები;
- მობილიზაცია;
- ზედა ხარჯები.
რა თქმა უნდა, კლიენტს არ სჭირდება აუცილებლობით პროექტის დანახვა ამ სტრუქტურის მიხედვით.
ანალოგიურად, გრაფიკის შემდგენელსაც არ სჭირდება აუცილებლობით დაგეგმვა ამ სტრუქტურის მიხედვით.
მაგრამ Cost Controller-ს და CFO-ს სჭირდება.
სწორედ ამიტომ დამოუკიდებელი პროექტის კონტროლის სისტემები ასევე ინარჩუნებენ კავშირებს შესრულებისა და დანახარჯის სტრუქტურებს შორის.
დამოუკიდებელი საწარმოს პროექტის კონტროლის სისტემები ასევე აღიარებს ერთზე მეტი პროექტის სტრუქტურის საჭიროებას.
Oracle Primavera Unifier, მაგალითად, მხარს უჭერს პროექტის დანახარჯის ტრანზაქციებს, რომლებიც შეიცავს როგორც WBS, ისე CBS კოდებს. შედეგად, ერთი და იგივე ტრანზაქცია შეიძლება აიწეროს როგორც WBS Sheet-ზე, ისე Cost Sheet-ზე.
ეს მნიშვნელოვანი მტკიცებულებაა იმისა, რომ მრავალგანზომილებიანი პროექტის კონტროლი მხოლოდ DANAOS Projects-ისთვის არ არის უნიკალური.
რით განსხვავდება BoQ ↔ WBS ↔ Cost Codes WBS + CBS-ისგან?
თუმცა, აქ არის მნიშვნელოვანი არქიტექტურული განსხვავებაც.
WBS + CBS აკავშირებს შესრულების სტრუქტურას დანახარჯების კლასიფიკაციასთან. ის თავისთავად არ შემოაქვს BoQ ან რაოდენობრივი კომერციული მოცულობა, როგორც მესამე საკონტროლო განზომილება.
კონტრაქტორებისთვის ეს განსხვავება მნიშვნელოვანია.
- Cost Breakdown Structure-ს შეუძლია მენეჯმენტს უთხრას, სად ეკუთვნის დანახარჯი.
- ანალოგიურად, WBS-ს შეუძლია მენეჯმენტს უთხრას, სად და როდის ასრულებს გუნდი სამუშაოს.
მაგრამ BoQ ან მის ანალოგიურ რაოდენობრივ მოცულობას კიდევ ერთ კრიტიკულ კითხვაზე აქვს პასუხი:
რა გაზომვადი გამომუშავება მიეწოდება, რა რაოდენობით და რა კომერციული ღირებულებით?
სწორედ ამაში განსხვავდება ProjectVIEW ERP-ის BoQ ↔ WBS ↔ Cost Codes არქიტექტურა.
სხვა სიტყვებით, BoQ ამატებს რაოდენობრივ და კომერციულ განზომილებას, რომელიც საჭიროა დანახარჯისა და გრაფიკის გასაბრუნებლად გაზომვად ფიზიკურ გამომუშავებაზე.
ეს საშუალებას იძლევა დაისვას ისეთი კითხვები, როგორიცაა:
- რამდენი რაოდენობა უნდა მიაწოდოს ამ WBS აქტივობამ?
- რა რესურსები დაგეგმა შეფასებამ ერთეულ გამომუშავებაზე?
- რა რაოდენობა დასრულდა რეალურად?
- რომელი რესურსები მოიხმარეს გუნდებმა ამის მისაღწევად?
- რა არის შედეგად მიღებული რეალური ერთეულის ღირებულება?
- რამდენი მასალა უნდა უზრუნველყოს ჯერ კიდევ შესყიდვებმა?
- შემდეგ, რა რაოდენობის დადასტურებას ან მოთხოვნას შეიძლება აწარმოებდეს კონტრაქტორი?
- როგორ იმოქმედებს დარჩენილი რაოდენობები დასრულებამდე მისაყვანი დანახარჯის პროგნოზზე?
მოკლედ, განსხვავება ასეთია:
WBS + CBS = სად არის სამუშაო და სად ეკუთვნის დანახარჯი?
BoQ + WBS + Cost Codes = რას ვაწვდით, სად და როდის ვაწვდით, და რა გვიჯდება ეს?
პროექტებზე დაფუძნებული ინდუსტრიებისთვის, სადაც ფიზიკური რაოდენობა, კომერციული შეფასება და რესურსების პროდუქტიულობა კონტროლის ცენტრია, BoQ განზომილება საგრძნობლად აფართოებს პროექტის კონტროლის მოდელს.
BoQ × WBS × Cost Codes: ერთი და იმავე პროექტის რეალობის სამი განზომილება
შეჯამებით, DANAOS Projects-ის მოდელია:
- BoQ = მოცულობა / რაოდენობა / კომერციული განზომილება
- WBS = შესრულება / დროითი განზომილება
- Cost Codes = დანახარჯის კლასიფიკაცია / საკონტროლო განზომილება
DANAOS ამ მოდელს აღწერს, როგორც ინტეგრირებულ პროექტის შესრულების საბაზისო გეგმას.
თუმცა ღირებულება მხოლოდ იმით არ იქმნება, რომ სამივე სტრუქტურა გვაქვს.
ღირებულება იქმნება მათ შორის ურთიერთკავშირების შენარჩუნებით.
განვიხილოთ ბეტონის პაკეტი.
- BoQ ამბობს: 10,000 მ³ არმირებული ბეტონი
- WBS ამბობს: Pier P05 → Foundation → Concrete Pour 03 → Week 27
- Cost Codes ამბობს: შრომა / ბეტონი / არმირება / ფორმულები / ტექნიკა
შედეგად, ორგანიზაციას ახლა შეუძლია დააკავშიროს:
რა არის მიწოდებული
with
სად და როდის სრულდება ის
with
რა უნდა დაუჯდეს
და საბოლოოდ:
რა რესურსები იქნა რეალურად მოხმარებული.
რა ხდება შესაძლებელი, როცა სამი სტრუქტურა ერთმანეთთან არის დაკავშირებული?
1. დანახარჯზე დამყარებული გრაფიკი
პირველ რიგში, დამგეგმავებს შეუძლიათ დროის მიხედვით გაწერონ გაზომვადი მოცულობის რესურსები და ბიუჯეტი შესაბამისი WBS აქტივობების მეშვეობით.
შედეგად, ორგანიზაციას შეუძლია დაინახოს არა მხოლოდ ის, რა დაუჯდება პროექტს, არამედ როდის მოხდება, სავარაუდოდ, ეკონომიკური ზემოქმედება.
2. შესყიდვების დაგეგმვა
მაგალითად, BoQ-ის ერთმა პოზიციამ შეიძლება მოითხოვოს 500 ტონა არმირება, ხოლო შესაბამისი WBS აქტივობა დაიწყოს 30-ე კვირაში. ამ შემთხვევაში შესყიდვებს შეუძლიათ გამოთვალონ საჭირო მასალის რაოდენობა და საჭიროების თარიღიდან უკან გაშალონ გეგმა.
ეს ყიდვას გადააქცევს:
„სამშენებლო მოედანი მასალას ითხოვდა.“
into:
„პროექტის საბაზისო გეგმა ამ მასალის საჭიროებას წინასწარ განსაზღვრავს.“
3. პროდუქტიულობის გაზომვა
ანალოგიურად, თუ შეფასება განსაზღვრავს ერთეულ გამომუშავებაზე საჭირო რესურსებს, ფაქტობრივი შესრულება შეიძლება შეადაროს:
- დაგეგმილი რაოდენობა ფაქტობრივ რაოდენობასთან
- შრომა: დაგეგმილი vs ფაქტობრივი
- დაგეგმილი ტექნიკა vs ფაქტობრივი ტექნიკა
- დაგეგმილი ერთეულის ღირებულება vs ფაქტობრივი ერთეულის ღირებულება
პროდუქტიულობა ხდება გამომუშავებასა და ძალისხმევას შორის ურთიერთობა და არა უბრალოდ ნამუშევარი საათები.
4. Earned Value Management
გარდა ამისა, გუნდებს შეუძლიათ ფიზიკური პროგრესი დაუკავშირონ დასრულებული სამუშაოს დაგეგმილ ღირებულებას.
DANAOS Projects-მა ეს საკითხი უფრო დეტალურად განიხილა Earned Value და მშენებლობის შესრულების კონტროლის განხილვაში.
5. დასრულებამდე მისაყვანი დანახარჯის პროგნოზი
და ბოლოს, როდესაც ფაქტობრივი პროდუქტიულობა, აღებული ვალდებულებები და დარჩენილი რაოდენობები ერთად ჩანს, პროგნოზები შეიძლება რეაგირებდეს შესრულების რეალობაზე და არა მხოლოდ ისტორიული საბუღალტრო დანახარჯის ექსტრაპოლაციაზე.
რა ხდება, როცა სტრუქტურები ერთმანეთისგან მოწყვეტილია?
პრაქტიკაში შედეგები ჩვეულებრივ თავს იჩენს შეჯერების სამუშაოებად.
- დაგეგმვა ინარჩუნებს Primavera P6-ს.
- ამავდროულად, შემფასებლები ინარჩუნებენ საწყის BoQ-ს და ბიუჯეტს Excel-ში ან სხვა შეფასების პლატფორმაზე.
- შესყიდვები მართავს ყიდვებს მასალის მთავარ ჩანაწერებთან მიმართებით.
- ბუღალტერია ასახავს დანახარჯებს ფინანსურ ანგარიშებზე.
- და ბოლოს, სამშენებლო მოედნის გუნდები ცალ-ცალკე ავრცელებენ პროგრესის ანგარიშებს.
შედეგად, ორგანიზაციას ტექნიკურად ყველა მონაცემი აქვს.
თუმცა მონაცემებს შორის მიზეზობრივი კავშირები სუსტია.
ამიტომ მენეჯმენტი დროს ხარჯავს ისეთი კითხვების პასუხებზე, როგორიცაა:
- რომელმა აქტივობამ შექმნა ეს დანახარჯი?
- BoQ-ის რომელი რაოდენობა ეფუძნება ამ შესყიდვის ორდერს?
- რა ფიზიკური გამომუშავება შექმნა ამ ადამიან-მაათებმა?
- რომელმა ვარიაციამ გამოიწვია პროგნოზის ზრდა?
- რატომ არის გრაფიკი 70%-ით შესრულებული, როცა რესურსების მოხმარება უკვე 85%-ზეა?
DANAOS Projects-მა ეს უფრო ფართო პრობლემა განიხილა The Failure of Generalist ERPs in Capital Projects-ში.
სხვა სიტყვებით, საკითხი ნაკლებად ეხება იმას, ფუნქციონირებს თუ არა თითოეული ცალკეული სისტემა სწორად.
უფრო სწორად, საკითხია, აღწერენ თუ არა ისინი იგივე პროექტის რეალობას.
როგორ მუშაობს ეს მულტიპროექტზე, სადაც რამდენიმე კონტრაქტორია?
ეს კიდევ უფრო მნიშვნელოვანი ხდება მფლობელის ან პროგრამის დონეზე.
მაგალითად, მეგაპროექტში შეიძლება მონაწილეობდეს რამდენიმე კონტრაქტორი, თითოეულს აქვს:
- თავისი WBS;
- სხვადასხვა ფიზიკური არეალების იერარქიები;
- თავისი Cost Codes;
- სხვადასხვა ქვემონტაქტორული სტრუქტურები;
- ათასობით აქტივი და ჩაბარების ობიექტი;
- ფიზიკური პროგრესის გაზომვის სხვადასხვა მეთოდი.
არარეალისტურია ვივარაუდოთ, რომ ყველა კონტრაქტორი ერთსა და იმავე შესრულების იერარქიას გამოიყენებს.
ამიტომ, გამოსავალი აუცილებლობით ერთი უზარმაზარი უნივერსალური WBS-ის დაწესება არ არის.
ნაცვლად ამისა, უფრო ძლიერი მიდგომაა საერთო ნორმალიზაციის განზომილებების შექმნა კონტრაქტორულ სტრუქტურებზე ზემოთ ან მათ გასწვრივ, .
ეს შეიძლება მოიცავდეს:
- პროექტის ფაზა;
- დისციპლინა;
- სამუშაოს კლასი;
- ფიზიკური არეალი;
- სისტემა;
- აქტივი;
- ჩაბარების ობიექტი;
- კონტრაქტორი;
- წონით სამუშაო ნაბიჯები.
შემდეგ მფლობელს შეუძლია აქტივები ან ჩაბარების ობიექტები თითოეული კონტრაქტორის შესაბამის WBS-ს დაუკავშიროს. ამავე დროს, ის მაინც ახდენს მათ კლასიფიკაციას საერთო მფლობელის განზომილებებით.
შედეგად, მფლობელს შეუძლია პროგრესი გაანალიზოს მიხედვით:
- კონტრაქტორი
- არეალი
- დისციპლინა
- პროექტის ფაზა
- სამუშაოს კლასი
- აქტივი/სისტემა
ამავდროულად, თითოეული კონტრაქტორის დეტალური შესრულების სტრუქტურის შენარჩუნებით.
თავის მხრივ, ეს ქმნის უფრო მყარ საფუძველს ნორმალიზებული S-მრუდებისთვის, კონტრაქტორებს შორის პროგრესის შედარებისა და პროგრესის მოთხოვნების აუდიტირებადი ვერიფიკაციისთვის.
მოკლედ, პრინციპი იგივეა:
ნუ აიძულებთ ყველა საკონტროლო კითხვას ერთ იერარქიაში მოქცევას—შეინარჩუნეთ კავშირები მართვად განზომილებებს შორის.
როგორ იყენებს ამ მოდელს ProjectVIEW ERP?
ProjectVIEW ERP აგებულია ამ მკაფიო ასოციაციის გარშემო:
BoQ ↔ WBS ↔ Cost Codes
ProjectVIEW ERP Cost Control Module აღწერს ამ ურთიერთობას Oracle Primavera P6/MS Project ინტეგრაციასთან, რესურსების განაწილებასთან, BoQ/WBS-ის მრავალ ვერსიასთან, ფაქტობრივ სამშენებლო მოედნის პროგრესთან, შრომასთან, ტექნიკასთან, ქვემონტაქტორულ აქტივობასა და ფაქტობრივად და ბიუჯეტურად შედარებულ დანახარჯთან ერთად.
ProjectVIEW ERP Budget Estimation & Bidding Module ადგენს რაოდენობრივ, რესურსებზე დაფუძნებულ საბაზისო გეგმას. ამ საბაზისო გეგმასთან მიმართებით კი კონტრაქტორი შემდეგ აკონტროლებს შესრულებას.
გარდა ამისა, ფართო ProjectVIEW OS for the BUILD World ამ პრინციპს ავრცელებს სტრუქტურირებულ პროექტულ მონაცემთა მოდელზე, რომელიც განკუთვნილია მშენებლობის, საზღვაო/offshore, სამთო, გემთმშენებლობისა და სხვა პროექტზე დაფუძნებული გარემოების მხარდასაჭერად.
თუმცა მიზანი მხოლოდ ერთსა და იმავე ტრანზაქციაზე სამი კოდის ჩვენება არ არის.
ნაცვლად ამისა, მიზანია, შესყიდვებმა, რესურსებმა, ქვემონტაქტორებმა, სამშენებლო მოედნის პროგრესმა, ვალდებულებებმა, დანახარჯმა და ფინანსურმა ტრანზაქციებმა მიიღონ ერთი და იგივე პროექტის კონტექსტი.
მოდელი მშენებლობის ფარგლებს გარეთაც გამოიყენება
ტერმინოლოგია ინდუსტრიის მიხედვით იცვლება.
- გემთმშენებელ ქარხანას შეიძლება ჰქონდეს Job Lists, vessel systems, blocks, production work packages და repair items.
- ანალოგიურად, საზღვაო კონტრაქტორმა შეიძლება სამუშაოები მოაწყოს გემების, ოფშორული ლოკაციების, დალექვის მოცულობების ან მონტაჟის პაკეტების გარშემო.
- სამთო კონტრაქტორმა შეიძლება შესრულება მოაწყოს ტერიტორიების, წარმოების რაოდენობების, განვითარების აქტივობებისა და ტექნიკის ფლოტების გარშემო.
- და ბოლოს, პროექტზე დაფუძნებულ მწარმოებელს შეიძლება ჰქონდეს მასალების უწყებები, წარმოების ორდერები და საინჟინრო ასამბლეები.
ProjectVIEW ERP ამ მოდელს ამ განსხვავებულ საოპერაციო სტრუქტურებზე ადაპტირებს.
უნივერსალური პრინციპია:
რაოდენობრივად განსაზღვრული მოცულობა ↔ შესრულების სტრუქტურა ↔ დანახარჯის სტრუქტურა
სახელები შეიძლება შეიცვალოს.
თუმცა, მათი დაკავშირების საჭიროება არ იცვლება.
რა უნდა შეამოწმონ საწარმოს დონის კონტრაქტორებმა?
პრაქტიკული პროექტის კონტროლის არქიტექტურა უნდა პასუხობდეს:
- შეგიძლიათ თუ არა ყველა მნიშვნელოვან პროექტის დანახარჯს დაუკავშიროთ მოცულობა და შესრულება?
- შეიძლება თუ არა ერთ BoQ პოზიციას, საჭიროებისამებრ, რამდენიმე WBS აქტივობასთან მიემართოს?
- ანალოგიურად, შეუძლია თუ არა ერთ WBS აქტივობას მოიხმაროს დანახარჯის რამდენიმე კატეგორია?
- შეიძლება თუ არა ფაქტობრივი ფიზიკური პროგრესის დაკავშირება გაზომვად რაოდენობებთან?
- შეუძლია თუ არა შესყიდვებს მოთხოვნების მიღება პროექტის საბაზისო გეგმიდან და WBS-ის საჭიროების თარიღებიდან?
- ასევე, შეუძლია თუ არა გუნდს შრომისა და ტექნიკის მოხმარების დაკავშირება იმ გამომუშავებასთან, რომელიც მან შექმნა?
- შეიძლება თუ არა აღებული ვალდებულების დაკავშირება მოცულობასთან ინვოისის არსებობამდე?
- შეუძლიათ თუ არა ცვლილებებს შეინარჩუნონ კავშირი BoQ-ს, WBS-ს, Cost Codes-სა და შემოსავალს შორის?
- ასევე, შეუძლია თუ არა მენეჯმენტს პროექტის ანალიზი რამდენიმე განზომილებით მონაცემების დუბლირების გარეშე?
- შეუძლიათ თუ არა საოპერაციო ტრანზაქციებს საბოლოოდ შეეჯამონ კორპორაციულ ფინანსებთან?
თუ სისტემა ამ კითხვებს თანმიმდევრულად ვერ პასუხობს, კიდევ ერთი დაფის დამატებამ შესაძლოა ფუძემდებლური პრობლემა ვერ მოაგვაროს.
ნაცვლად ამისა, პრობლემა, სავარაუდოდ, სტრუქტურულია.
დასკვნა: ინტეგრაცია უფრო მნიშვნელოვანია, ვიდრე იერარქია
BoQ, WBS და Cost Codes სხვადასხვა საქმეს ასრულებს.
შედეგად, მათი ერთ სტრუქტურაში შეჯგუფების მცდელობამ შეიძლება სასარგებლო კონტექსტი გააქროს.
მათი სრულიად განცალკევება შეჯერებას წარმოქმნის.
ამიტომ უკეთესი მიდგომა არის რელაციური.
BoQ გვეუბნება რა და რამდენს.
WBS გვეუბნება სად, როდის და რა თანმიმდევრობით.
Cost Codes გვეუბნება, რა რესურსებს და დანახარჯის რომელი კატეგორიებს მოიხმარს პროექტი.
როდესაც ეს განზომილებები ერთმანეთთან დაკავშირებული რჩება, კონტრაქტორს შეუძლია მთლიანი ჯაჭვის მიყოლა:
Estimate → Budget → Schedule → Procurement → Execution → Progress → Cost → Forecast → Financial Outcome
ეს არის BoQ ↔ WBS ↔ Cost Codes-ის რეალური ღირებულება.
არა სამი კოდი.
ერთი და იმავე პროექტის რეალობის სამი კოორდინირებული ხედვა.
