Work Breakdown Structure (WBS) აუცილებელია პროექტის კონტროლისთვის, მაგრამ ის არ წარმოადგენს პროექტის ხარჯთა კონტროლის სრულ მოდელს.
სამშენებლო, ინფრასტრუქტურულ, გემთმშენებლობისა და გემების შეკეთების, საზღვაო და ოფშორული მშენებლობის, სამთო და კარიერული მოპოვების, ასევე პროექტებზე დაფუძნებული წარმოების სფეროებში სანდო კონტროლს ასევე სჭირდება რაოდენობრივად განსაზღვრული მოცულობა, Cost Codes, რესურსები, ვალდებულებები, ფაქტობრივი შესრულება და ფინანსური ჩანაწერები.
მიზანი არ არის WBS-ის ჩანაცვლება. პირიქით, მიზანია მისი დაკავშირება იმ განზომილებებთან, რომლებიც ხსნის რა იყო დაგეგმილი, რა იქნა მიწოდებული, რა იქნა მოხმარებული და ახლა რა ფასად არის პროგნოზირებული პროექტი.
რას აკეთებს WBS და რას არ აკეთებს?
WBS პროექტს შლის deliverables-ებად, სამუშაო პაკეტებად და მართვად კომპონენტებად. გარდა ამისა, ის უზრუნველყოფს ერთიან სტრუქტურას დაგეგმვისთვის, გრაფიკისთვის, პასუხისმგებლობისთვის, პროგრესის გაზომვისთვის და მენეჯმენტის ანგარიშგებისთვის.
AACE International-ის cost-engineering-ის სახელმძღვანელო WBS-ს განიხილავს როგორც უფრო ფართო პროექტის კონტროლის სტრუქტურის ერთ კომპონენტს. AACE ასევე განმარტავს, როგორ იკვეთება სამუშაო და რესურსის სტრუქტურები cost centres-სა და Cost Codes-ის შესაქმნელად.
Work Breakdown Structures და Cost Breakdown Structures-ის ინტეგრაციის შესახებ peer-reviewed კვლევა ასევე აჩვენებს, რატომ უნდა დააკავშირონ გუნდებმა ხარჯისა და გრაფიკის სტრუქტურები, ნაცვლად იმისა, რომ ისინი ერთ იერარქიაში მოაქციონ.
ეს არ ნიშნავს, რომ კონტრაქტორს არ შეუძლია ხარჯის მიამაგრება WBS-ს. რა თქმა უნდა, შეუძლია.
ამის ნაცვლად, ეს ნიშნავს, რომ მხოლოდ WBS თავისთავად არ განსაზღვრავს:
- მიწოდებულ ფიზიკურ ან კომერციულ რაოდენობას;
- ერთეულ გამომავალზე საჭირო რესურსებს;
- შიდა კლასიფიკაციას, რომელიც გამოიყენება ხარჯის დაგროვებისთვის;
- შესყიდვებისა და ქვეკონტრაქტების ვალდებულებებს;
- ფაქტობრივ რესურსების მოხმარებას და პროდუქტიულობას;
- ცვლილების ხარჯობრივ, შემოსავლისა და გრაფიკულ შედეგებს.
მოკლედ, WBS მენეჯმენტს ეუბნება სად ეკუთვნის სამუშაო.
თუმცა, სრული პროექტის ხარჯთა კონტროლი ასევე უნდა განმარტავდეს რამდენი გამომავალია ჩართული, რა უნდა მოიხმაროს ამ გამომავალმა, რა მოიხმარა ფაქტობრივად და რა რჩება.
პროექტის კონტროლის რომელი განზომილებები უნდა იყოს დაკავშირებული?
DANAOS Projects-მა ადრე შეისწავლა, როგორ ემთხვევა ინტეგრირებული პროექტის შესრულების ბეისლაინი მშენებლობაში მოცულობას, დროს, რესურსებს და ღირებულებას.
გარდა ამისა, იგივე კონტროლის პრინციპი ვრცელდება რთულ პროექტებზე დაფუძნებულ ინდუსტრიებში.
პრაქტიკაში, ძირითადი განზომილებებია:
- რაოდენობრივად განსაზღვრული მოცულობა ან კომერციული სტრუქტურა: რას ვაწვდით, რა გაზომვად რაოდენობაში და რა საკონტრაქტო ან საწარმოო სტრუქტურის ქვეშ?
- WBS და გრაფიკი: რა სამუშაო უნდა შეასრულოს გუნდმა, სად ეკუთვნის ის და როდის უნდა მოხდეს?
- Cost Codes ან Cost Breakdown Structure: როგორ უნდა დააკლასიფიციროს და აკონტროლოს კონტრაქტორმა შრომა, მასალები, მანქანა-დანადგარები, ქვეკონტრაქტორები და არაპირდაპირი ხარჯები?
- რესურსების მოდელი: რა უნდა მოიხმაროს თითოეულმა ერთეულმა ან სამუშაო პაკეტმა?
- ვალდებულებები და ფაქტობრივი მონაცემები: რა შეუკვეთა, გააფორმა, მიიღო, გამოიყენა, დაასრულა და ფინანსურად გაატარა პროექტმა?
ეს სტრუქტურები არ უნდა ეჯიბრებოდეს ერთმანეთს. პირიქით, ისინი სხვადასხვა კითხვებს პასუხობენ ერთი და იმავე პროექტის რეალობის შესახებ.
რატომ არის მნიშვნელოვანი ფიზიკური რაოდენობა?
მაგალითად, ვთქვათ, სამუშაო პაკეტი აცხადებს 60% პროგრესს.
თუ მისი ბეისლაინ რაოდენობა არის 10,000 ერთეული, მაშინ აღნიშნული პროგრესი უნდა შეესაბამებოდეს დაახლოებით 6,000 დასრულებულ ერთეულს.
მაგრამ ვთქვათ, პროექტმა უკვე მოიხმარა შრომის, მასალების, მანქანა-დანადგარების ან ქვეკონტრაქტის ძალისხმევა, რომელიც ბიუჯეტით გათვლილი იყო 7,500 ერთეულის წარმოებისთვის.
ამ შემთხვევაში, გრაფიკი შესაძლოა კვლავ აჩვენებდეს 60% პროგრესს.
ანალოგიურად, მთავარი წიგნი შესაძლოა სწორად აჩვენებდეს ხარჯს.
თუმცა, არც ერთი ჩანაწერი ცალკე არ ხსნის, რატომ მისცა 7,500 ერთეულის ეკვივალენტურმა რესურსმა მხოლოდ 6,000 ერთეული.
სხვა სიტყვებით რომ ვთქვათ, ეს არის პროდუქტიულობისა და პროექტის ხარჯთა კონტროლის საკითხი.
ამაზე პასუხის გასაცემად საჭიროა, რომ ფიზიკური გამომავალი, რესურსული ძალისხმევა, დრო და ღირებულება ერთმანეთთან დაკავშირებული დარჩეს.
ამიტომ არის მნიშვნელოვანი BoQ-ზე ორიენტირებული შეფასება მშენებლობასა და Engineering, Procurement and Construction პროექტებში. შედეგად, შეფასებამ უნდა შეინარჩუნოს რესურსული დაშვებები თითოეული გაზომვადი პოზიციის უკან, ნაცვლად იმისა, რომ კონტრაქტის მინიჭების შემდეგ სტატიკურ სატენდერო ცხრილად იქცეს.
სხვა პროექტულ ინდუსტრიებში გუნდებმა რაოდენობრივად განსაზღვრულ სტრუქტურას შეიძლება უწოდონ Job List, სამუშაო პაკეტი, bill of materials, წარმოების ორდერი ან სხვა მოცულობის მოდელი.
რა თქმა უნდა, ტერმინოლოგია იცვლება.
თუმცა, გაზომვადი გამომავლის მოთხოვნა არ იცვლება.
ვრცელდება თუ არა ეს პრინციპი მშენებლობის ფარგლებს გარეთაც?
დიახ. სხვადასხვა პროექტზე დაფუძნებული ინდუსტრიები იზიარებენ ერთ საკონტროლო ბირთვს, თუმცა მათი გამომავალი, მეთოდები და ოპერაციული გარემო განსხვავდება.
მშენებლობასა და ინფრასტრუქტურაში გამომავალი შეიძლება იყოს ბეტონის კუბური მეტრები, არმატურის ტონები, მილების მეტრები ან დასრულებული სისტემები. გარდა ამისა, ხარჯის მამოძრავებელ ფაქტორებს მიეკუთვნება შრომა, მასალები, ტექნიკა, ქვეკონტრაქტორები და ობიექტის არაპირდაპირი ხარჯები.
ანალოგიურად, გემთმშენებლობასა და გემების შეკეთებაში გამომავალი შეიძლება იყოს გემის ბლოკი, სისტემა, Job List-ის ელემენტი, სარემონტო პაკეტი ან მოწყობის სამუშაო. შესაბამისად, პროექტის ხარჯების კონტროლმა უნდა დააკავშიროს ეზოს შრომა, მასალები, საამქროები, დოკები, მანქანა-დანადგარები და ქვეკონტრაქტორები გემის მიწოდების გეგმასთან.
საზღვაო და ოფშორულ მშენებლობაში შესრულება შეიძლება მოიცავდეს დრეჯირების მოცულობებს, წყალქვეშა მონტაჟს, დამზადების პაკეტებს, გემებს, ეკიპაჟებს, სპეციალურ აღჭურვილობას, საწვავს და ამინდზე დამოკიდებულ სამუშაო ფრონტებს.
ანალოგიურად, სამთო მოპოვებასა და კარიერებში მართვას შესაძლოა სჭირდებოდეს გადაადგილებული ტონაჟის, გაბურღული მეტრების, წარმოების გამომუშავების, აღჭურვილობის საათების, შრომის, საწვავის, ტექნიკური მომსახურების, მასალებისა და კონტრაქტორის ხარჯების დაკავშირება.
პროექტზე დაფუძნებულ წარმოებაში მაკონტროლებელი მოდელი შეიძლება აკავშირებდეს პროექტის მოცულობას მასალების უწყისთან, მარშრუტიზაციებთან, წარმოების დავალებებთან, დანადგარების დროსთან, საამქროს შრომასთან და მიწოდების ეტაპებთან.
მოკლედ, ფიზიკური ერთეული იცვლება.
თუმცა, ფუნდამენტური საკონტროლო კითხვა არ იცვლება:
რა გამომავალი შექმნა პროექტმა, რა უნდა მოხმარებოდა ამ გამომავალს, რა მოიხმარა ფაქტობრივად და რა დაჯდება დარჩენილი სამუშაო?
რატომ არ არის საკმარისი მხოლოდ ბუღალტერია?
ბუღალტერია აუცილებელია, მაგრამ ფინანსური ასახვა და ოპერაციული პროექტის კონტროლი სხვადასხვა კითხვებს პასუხობს.
მაგალითად, შესყიდვის ორდერი ქმნის დადგენილ ხარჯს ინვოისის მიღებამდე.
ანალოგიურად, ობიექტმა შეიძლება მასალა მიიღოს, მაგრამ ჯერ არ მოიხმაროს.
ამავე დროს, შრომის პროდუქტიულობა შეიძლება გაუარესდეს ხელფასების დახურვამდე.
გარდა ამისა, მანქანებს ან გემებს შეუძლიათ დაგროვონ უქმი საათები, როცა საქმიანობა გრაფიკს ჩამორჩება.
და ბოლოს, ქვეკონტრაქტორმა შეიძლება დაასრულოს გაზომვადი სამუშაო სერტიფიცირებასა და ფინანსურ ასახვამდე.
ამიტომ ოპერაციულმა პროექტის კონტროლმა ფინანსური ჩანაწერები უნდა განმარტოს პროგრესთან, რესურსების მოხმარებასთან, ვალდებულებებთან და დასრულებამდე დარჩენილი ხარჯის პროგნოზთან ერთად.
DANAOS Projects-ის ანალიზი ინტეგრირებული ხარჯთკონტროლის მოდულის არქიტექტურის შესახებ განმარტავს, თუ როგორ უწყობს შეფასება, შესყიდვები, მასალები, შრომა, მანქანა-დანადგარები, ქვეკონტრაქტორები, პროექტის შესრულება და ფინანსები სხვადასხვა მტკიცებულებას ერთი და იმავე ხარჯობრივი სურათისთვის.
მოკლედ, ბუღალტერია განმარტავს, რა აღიარა კომპანიამ ფინანსურად.
ამის საპირისპიროდ, ოპერაციულმა პროექტის კონტროლმა ასევე უნდა აჩვენოს, რა ხდება ახლა და რა არის მოსალოდნელი შემდეგ.
როგორ უდგება პრობლემას ProjectVIEW ERP?
ProjectVIEW ERP ეფუძნება შემდეგ კავშირს:
BoQ ან რაოდენობრივად განსაზღვრული მოცულობა ↔ WBS ↔ Cost Codes
- პირველ რიგში, რაოდენობრივად განსაზღვრული პროექტის ბიუჯეტი ადგენს, რა უნდა მოხმარებოდა სამუშაოს.
- შემდეგ, WBS ორგანიზებას უკეთებს შესრულებასა და დროს.
- Cost Codes ქმნის შიდა ხარჯების კონტროლის სტრუქტურას.
- შემდეგ შესყიდვები ადგენს ვალდებულებებს.
- ობიექტის, ეზოს, გემის, მაღაროს ან წარმოების ტრანზაქციები იძლევა ფაქტობრივი შესრულების მონაცემებს.
- და ბოლოს, ბუღალტერია აღრიცხავს ფინანსურ შედეგს.
ProjectVIEW ERP-ის ხარჯების კონტროლის მოდული აკავშირებს პროექტის საბაზისო გეგმას ფაქტობრივ პროგრესთან და რესურსების ინფორმაციასთან, მათ შორის შრომის რესურსებთან, მასალებთან, ტექნიკასთან ან დანადგარებთან, ქვეკონტრაქტორებთან და პროექტის ტრანზაქციებთან.
ანალოგიურად, ProjectVIEW ERP Budget Estimation & Bidding Module ადგენს რესურსებზე დაფუძნებულ ბიუჯეტს, საიდანაც იწყება პროექტის კონტროლი.
თუმცა, მიზანი არ არის, რომ ყველა ინდუსტრიამ გამოიყენოს იდენტური ტერმინოლოგია ან ოპერაციული სტრუქტურები.
სანაცვლოდ, მიზანია, რომ გუნდებს შეეძლოთ მოცულობის, დროის, რესურსების, ვალდებულებების, ფაქტობრივი შესრულების, ხარჯისა და შემოსავლის ერთმანეთთან დაკავშირება ერთ, მართვად პროექტის მოდელში.
ეს ასახავს 25+ წლიან ERP გამოცდილებას პროექტზე დაფუძნებული ინდუსტრიებიდან. პროექტზე ორიენტირებული ორგანიზაციები უწყვეტად გარდაქმნიან რესურსებს ფიზიკურ პროგრესად და ფიზიკურ პროგრესს კომერციულ ღირებულებად.
ამიტომ მათი ოპერაციული სისტემები უნდა იყოს უნარიანი, ორივე გარდაქმნას მიჰყვეს.
რა უნდა ჰკითხონ პროექტის ლიდერებმა?
იმის ნაცვლად, რომ მხოლოდ იკითხონ, „გვაქვს თუ არა WBS?“, პროექტის ლიდერებმა უნდა ჰკითხონ:
- შეუძლიათ თუ არა გუნდებს გაზომვადი მოცულობის დაკავშირება WBS სამუშაო პაკეტებთან და გრაფიკის აქტივობებთან?
- ასევე, შეუძლია თუ არა გუნდს ბიუჯეტირებული რესურსებისა და Cost Codes-ის შესაბამის მოცულობასთან დაკავშირება?
- შეუძლიათ თუ არა მენეჯერებს ფაქტობრივი გამომავლის ფაქტობრივ რესურსების მოხმარებასთან შედარება?
- შეუძლია თუ არა სისტემას დადგენილი ხარჯის იდენტიფიცირება მანამ, სანამ ის ინვოისირებული ხარჯი გახდება?
- გარდა ამისა, შეუძლია თუ არა ცვლილებებს მოცულობას, რაოდენობას, რესურსებს, გრაფიკს, ხარჯსა და შემოსავალს შორის კავშირის შენარჩუნება?
- შეუძლია თუ არა მენეჯმენტს პორტფელის KPI-დან ჩაძიება ქვემდებარე ოპერაციულ ტრანზაქციამდე?
- და ბოლოს, შეუძლია თუ არა პროექტის ოპერაციული მონაცემების შეჯერება კორპორაციულ ფინანსურ გარემოსთან?
როცა რამდენიმე პასუხი არის არა, სისუსტე შესაძლოა არ იყოს WBS.
სანაცვლოდ, შესაძლოა სუსტი იყოს მის გარშემო არსებული არქიტექტურა.
WBS აუცილებელია. ინტეგრაცია ქმნის კონტროლს.
სამუშაოების დაშლის სტრუქტურა უზრუნველყოფს პროექტის სამუშაოების ორგანიზების ფუნდამენტს.
მაგრამ რთული პროექტები ერთდროულად არის ფიზიკური, დროითი, რესურსებზე დაფუძნებული, კომერციული და ფინანსური სისტემები.
შედეგად, ვერც ერთი იერარქია სრულად ვერ ასახავს ყველა განზომილებას.
მოკლედ, პრაქტიკული პრინციპი მარტივია:
WBS არ ჩაანაცვლოთ. დააკავშირეთ ის.
დააკავშირეთ სამუშაო რაოდენობრივად განსაზღვრულ მოცულობასთან.
შემდეგ დააკავშირეთ მოცულობა ბიუჯეტირებულ რესურსებთან.
დააკავშირეთ რესურსები Cost Codes-თან.
შემდეგ დააკავშირეთ შესყიდვის ვალდებულებები პროექტის საჭიროებასთან.
დააკავშირეთ ფაქტობრივი შესრულება საბაზისო გეგმასთან.
და ბოლოს, დააკავშირეთ ოპერაციული რეალობა ფინანსურ ანგარიშგებასთან.
საბოლოოდ, სწორედ ასე გადადიან პროექტზე დაფუძნებული ორგანიზაციები იმიდან, რომ იციან, სად ეკუთვნის სამუშაო, იმ გაგებამდე, რას აწარმოებს, მოიხმარს და საბოლოოდ რა უჯდებათ ეს სამუშაო.
