რატომ სჭირდებათ მსხვილ კონტრაქტორებს, „integration“-ზე საუბრამდე, განასხვაონ task-level software, project-level platforms და company-wide სამშენებლო ERP
დღეს Construction კომპანიებს უამრავი პროგრამული უზრუნველყოფა აკრავს გარს.
გრაფიკის პროგრამები. შეფასების პროგრამები. რაოდენობრივი დაკვალვის აპლიკაციები. BIM პლატფორმები. Common Data Environments. დოკუმენტების მართვის სისტემები. შესყიდვების ხელსაწყოები. საველე აპლიკაციები. საბუღალტრო სისტემები. Human Resources Management Systems. Warehouse Management Systems. Project controls პლატფორმები. Construction management პლატფორმები. Enterprise Resource Planning სისტემები.
და თითქმის ყველა მომწოდებელი ახლა აცხადებს, რომ სთავაზობს „integrated platform“, „single source of truth“ ან „end-to-end solution“.
თუმცა ეს ფუნდამენტურ პრობლემას ქმნის.
სხვა სიტყვებით, ჩვენ ერთსა და იმავე სიტყვებს ვიყენებთ ისეთი სისტემების აღსაწერად, რომლებიც კონსტრუქციული ბიზნესის სრულიად განსხვავებული დონეების გადაწყვეტისთვისაა შექმნილი.
- მაგალითად, გრაფიკის აპლიკაციას შეიძლება ჰქონდეს სრულყოფილი ინტეგრაცია გრაფიკირებისთვის.
- ანალოგიურად, Common Data Environment-ს შეუძლია უზრუნველყოს შესანიშნავი ერთი წყარო პროექტის დოკუმენტაციისთვის.
- ამავე დროს, პროექტის მართვის პლატფორმას შეუძლია ასობით დაინტერესებული მხარის დაკავშირება ერთი პროექტის მიწოდების ირგვლივ.
მაგრამ არცერთი მათგანი ავტომატურად არ აქცევს სისტემას კონტრაქტორის საწარმოო ოპერაციულ ბირთვად.
ამიტომ, იმისთვის, რომ მშენებლობის ტექნოლოგია სწორად გავიგოთ, ვფიქრობ, ბაზარი სამ ფართო ფენად უნდა დავყოთ:
1. კონკრეტული დანიშნულების აპლიკაციები
2. პროექტზე ორიენტირებული სამშენებლო პლატფორმები (სამშენებლო ფენები)
3. კომპანიის მასშტაბის სამშენებლო ERP სისტემები
მათ შორის, რა თქმა უნდა, გადაკვეთა არსებობს.
სინამდვილეში, საზღვრები სულ უფრო ბუნდოვანი ხდება, რადგან მომწოდებლები ფუნქციონალს აფართოებენ, სხვა აპლიკაციებს იძენენ და ინტეგრაციის ეკოსისტემებს ქმნიან.
მაგრამ განსხვავება მაინც არსებითია.
რადგან რეალური კითხვა არ არის:
“რამდენი ფუნქცია აქვს ამ პროგრამას?”
ნამდვილი კითხვა არის:
ორგანიზაციის რომელ დონეს მართავს ეს პროგრამა?
ეს კითხვა ყველაფერს ცვლის.
1. კონკრეტული დანიშნულების სამშენებლო აპლიკაციები: ერთი პრობლემის უკიდურესად კარგად გადაწყვეტა
პირველ კატეგორიაში შედის აპლიკაციები, რომლებიც შექმნილია კონკრეტული ამოცანის, დისციპლინის ან ოპერაციული გამოწვევის გარშემო.
მაგალითებია:
- გრაფიკების შედგენა და დაგეგმვა;
- მოცულობების დათვლა;
- ხარჯთაღრიცხვა;
- BIM მოდელირება;
- დოკუმენტების ანოტირება;
- რეალობის აღქმა;
- უსაფრთხოების მართვა;
- აღჭურვილობის ტელემატიკა;
- ხელფასების დარიცხვა;
- ბუღალტრული აღრიცხვა;
- შესყიდვები;
- აქტივების ტექნიკური მომსახურება;
- ობიექტზე ანგარიშგება;
- ხარისხის მართვა.
ეს აპლიკაციები ფასეულია სწორედ იმიტომ, რომ სპეციალიზებულია.
მაგალითად, განვიხილოთ Oracle Primavera P6.
Oracle Primavera P6 Enterprise Project Portfolio Management-ს აღწერს, როგორც გადაწყვეტას პროექტების, პროგრამებისა და პორტფელების პრიორიტეტიზაციის, დაგეგმვის, მართვისა და შეფასებისთვის. მისი ძლიერი მხარეებია გრაფიკების შედგენა, რესურსები, პროგრესის მონიტორინგი და პროექტთა პორტფელის მართვა. Oracle ასევე პირდაპირ აღნიშნავს, რომ P6-ს შეუძლია მონაცემების გაზიარება ფინანსურ, ადამიანური კაპიტალისა და ERP სისტემებთან.
ზუსტად ეს უნდა ველოდოთ კიდეც.
ბოლოს და ბოლოს, Primavera-ს არ სჭირდება გახდეს კონტრაქტორის ხელფასების, შესყიდვების, სასაწყობო მეურნეობისა და მთავარი წიგნის სისტემა, რათა იყოს გამორჩეული გრაფიკების პლატფორმა.
მისი ძირითადი პასუხისმგებლობა სხვაა.
ანალოგიურად, სპეციალიზებულმა Quantity Take-Off სისტემებმა, ხარჯთაღრიცხვის სისტემებმა, BIM აპლიკაციებმა, მანქანა-დანადგარების ტელემატიკის პლატფორმებმა და რეალობის აღქმის ტექნოლოგიებმა შეიძლება უკეთ გადაჭრას თავიანთი ამოცანები, ვიდრე ამას დიდი საწარმოებრივი აპლიკაცია შეძლებდა.
ამოცანაზე ორიენტირებული პროგრამული უზრუნველყოფის ძალა არის სიღრმე.
ამასთან, მისი ბუნებრივი შეზღუდვაა ორგანიზაციული მასშტაბი.
შედეგად, სპეციალიზებული აპლიკაცია, როგორც წესი, ქმნის იმას, რასაც შეიძლება ვუწოდოთ:
ამოცანის დონეზე არსებული ჭეშმარიტება
დაგეგმვის სპეციალისტი Primavera-ს ენდობა გრაფიკისთვის.
ანალოგიურად, ხარჯთაღმრიცხველი ენდობა ხარჯთაღრიცხვის სისტემას ხარჯთაღრიცხვისთვის.
BIM გუნდი ენდობა საკუთარ მოდელს.
ამასობაში, ამზომველი ენდობა QTO აპლიკაციას.
დანადგარების მენეჯერი ენდობა ტელემატიკის პლატფორმას.
თითოეული მათგანი შეიძლება სწორი იყოს საკუთარი დომენის ფარგლებში.
პრობლემა იწყება მაშინ, როდესაც საწარმოს სჭირდება გააცნობიეროს, როგორ მოქმედებს ყველა ეს ჭეშმარიტება ერთმანეთზე.
2. პროექტზე ორიენტირებული სამშენებლო პლატფორმები: პროექტის დონის ჭეშმარიტების შექმნა
მეორე კატეგორია წარმოიშვა იმიტომ, რომ მშენებლობას კიდევ ერთი უნიკალური მახასიათებელი აქვს:
ერთი კომპანია იშვიათად ახორციელებს მხოლოდ ერთ პროექტს.
დიდ პროექტში შესაძლოა მონაწილეობდნენ:
- დამკვეთი;
- ინჟინერი ან კონსულტანტი;
- მთავარი კონტრაქტორი;
- ერთობლივი საწარმოს პარტნიორები;
- ქვეკონტრაქტორები;
- მომწოდებლები;
- დიზაინერები;
- პროექტის მენეჯერები;
- ხარჯთაღმრიცხველები;
- სახელმწიფო ორგანოები;
- დამოუკიდებელი ინსპექტორები.
ამ ორგანიზაციებს სჭირდებათ ინფორმაციის უზარმაზარი მოცულობების გაცვლა, ისე რომ არ ეკუთვნოდნენ აუცილებლობით ერთსა და იმავე საწარმოს.
ისინი ცვლიან:
ნახაზებს, RFI-ებს, წარდგენილ მასალებს, კორესპონდენციას, ცვლილების მოთხოვნებს, ინსპექტირების ჩანაწერებს, კონტრაქტებს, მოდელებს, გრაფიკებს, ფოტოებს, დოკუმენტებსა და კომერციულ ინფორმაციას.
შედეგად, ამან შექმნა საჭიროება პროექტზე ორიენტირებული სამშენებლო პლატფორმების მიმართ.
მათი ბუნებრივი ორგანიზაციული ობიექტია პროექტი.
Procore
Procore ძლიერი მაგალითია.
ის უზრუნველყოფს ფართო სამშენებლო-მართვის გარემოს პროექტის შესრულების, საველე მართვის, კომერციული მართვისა და პროექტის ფინანსური სამუშაო პროცესების გარშემო.
თუმცა Procore-ის საკუთარ არქიტექტურაშიც ჩანს მნიშვნელოვანი განსხვავება.
მაგალითად, მისი ERP Integration ინსტრუმენტები Procore-ს აკავშირებს ისეთ სისტემებთან, როგორებიცაა Viewpoint Vista, Spectrum, Sage, NetSuite, CMiC, QuickBooks, Acumatica, Workday და სხვა. Procore ამ ინტეგრაციებს აღწერს, როგორც მექანიზმებს, რომლებიც აკავშირებს სამშენებლო პროექტის ინფორმაციას კომპანიის ERP ან ბუღალტრულ გარემოსთან.
ეს არ ასუსტებს Procore-ის შეთავაზებას.
პირიქით, ეს გვეხმარება მის განსაზღვრაში.
Procore შეიძლება იყოს ძალიან ძლიერი სამშენებლო-მართვის ფენა, ხოლო სხვა პლატფორმა დარჩეს პასუხისმგებელი საწარმოს ბუღალტერიასა და ERP ფუნქციებზე.
Autodesk Construction Cloud
Autodesk Construction Cloud ასევე მსგავს არქიტექტურულ პრინციპს მიჰყვება.
Autodesk უზრუნველყოფს ფართო სამშენებლო-მართვის შესაძლებლობებს და ინტეგრაციის ეკოსისტემას, რომელიც Autodesk Construction Cloud-ს უკავშირებს გარე ERP და ფინანსურ აპლიკაციებს.
გარდა ამისა, Autodesk პირდაპირ აქვეყნებს მითითებებს, თუ როგორ უნდა დაუკავშირდეს მისი სამშენებლო გარემო ERP და ფინანსურ სისტემებს, რათა აიცილოს ორმაგი შეყვანა და სინქრონიზდეს ფინანსური ინფორმაცია საველე და back-office გარემოებს შორის.
კიდევ ერთხელ, ეს ასახავს განსხვავებას პროექტის შესრულების ტექნოლოგიას და საწარმოს საყრდენს შორის.
Oracle Aconex
Oracle Aconex, ალბათ, ერთ-ერთი ყველაზე მკაფიო მაგალითია იმისა, რასაც მე ვუწოდებ პროექტის დონის ჭეშმარიტებას.
Oracle Aconex-ს აღწერს, როგორც Common Data Environment-ს, ცენტრალურ გარემოს, რომელიც აკავშირებს ორგანიზაციებს, პროცესებსა და პროექტის ინფორმაციას.
Aconex განსაკუთრებით ძლიერია, რადგან პროექტში მონაწილე თითოეული ორგანიზაცია ინარჩუნებს კონტროლს საკუთარ ინფორმაციაზე და ამავე დროს თანამშრომლობს საერთო პროექტულ გარემოში. Oracle მას პირდაპირ აღწერს, როგორც სისტემას, რომელიც ქმნის პროექტისთვის ერთადერთ ჭეშმარიტების წყაროს.
ეს ფორმულირება მნიშვნელოვანია:
პროექტისთვის.
პრაქტიკაში Aconex-ს შეუძლია უზრუნველყოს პროექტის ავტორიტეტული ჩანაწერი, რომელიც მოიცავს დოკუმენტებს, კომუნიკაციებს, მოდელებს, დამტკიცებებსა და გადაწყვეტილებებს.
ეს უზომოდ ფასეულია.
მაგრამ პროექტის ჭეშმარიტება და საწარმოს ჭეშმარიტება აუცილებლობით ერთი და იგივე არ არის.
Trimble ProjectSight
Trimble ProjectSight კიდევ ერთ სასარგებლო მაგალითს წარმოადგენს.
Trimble-ის ამჟამინდელი დოკუმენტაცია მომხმარებლებს საშუალებას აძლევს ProjectSight-ში კომპანიები და პროექტები პირდაპირ დაუკავშირონ ERP გარემოს. შემდეგ მომხმარებლებს შეუძლიათ Contracts და Purchase Orders-ის სინქრონიზაცია ამ ERP-თან.
კიდევ ერთხელ, თავად არქიტექტურა გვიჩვენებს რაღაცას.
პროექტის პლატფორმა მართავს სამშენებლო სამუშაო პროცესებს.
ამასობაში, ERP რჩება საწარმოებრივ სისტემად.
3. კომპანიის მასშტაბის სამშენებლო ERP: კონტრაქტორის მართვა და არა მხოლოდ პროექტის
ახლა მესამე კატეგორიამდე მივდივართ.
კონტრაქტორი მხოლოდ პროექტების ერთობლიობა არ არის.
უპირველეს ყოვლისა, ის არის კომპანია.
და მსხვილი საწარმოებრივი კონტრაქტორები ხშირად ამაზე ბევრად უფრო რთულნი არიან.
მაგალითად, ისინი შეიძლება შედგებოდნენ:
- მრავალი იურიდიული პირისგან;
- შვილობილი კომპანიებისგან;
- ერთობლივი საწარმოებიდან;
- ბიზნეს ერთეულებიდან;
- რეგიონული ოპერაციებიდან;
- ასობით ერთდროული პროექტიდან;
- ათასობით თანამშრომლიდან;
- აღჭურვილობის პარკებიდან;
- წარმოების ან ფაბრიკაციის მოედნებიდან;
- საწყობებიდან;
- ქვეკონტრაქტორები;
- მომწოდებლები;
- მრავალ ვალუტიდან;
- მრავალ საგადასახადო იურისდიქციიდან;
- განსხვავებული სახელფასო რეჟიმებიდან;
- კორპორატიული დამტკიცების იერარქიებიდან;
- ანგარიშთა გეგმის სხვადასხვა სტრუქტურიდან.
გარდა ამისა, პროექტები მოიხმარს ამ საწარმოს ეკუთვნილ რესურსებს.
და სწორედ ამიტომ არსებობს Enterprise Resource Planning თავდაპირველად.
ამიტომ კომპანიის მასშტაბის სამშენებლო ERP-ს სჭირდება მართოს არა მხოლოდ პროექტი, არამედ ურთიერთობა პროექტსა და საწარმოს შორის.
კატეგორიის მაგალითებია ისეთი სისტემები, როგორიცაა Trimble Viewpoint Vista, CMiC, Sage X3 Construction და DANAOS ProjectVIEW ERP, თუმცა მათი არქიტექტურა, ფუნქციური სიღრმე და სამიზნე ბაზრები არსებითად განსხვავდება.
Viewpoint Vista
მაგალითად, Trimble აღწერს Vista-ს, როგორც სრულად ინტეგრირებულ სამშენებლო ERP გადაწყვეტას, რომელიც მოიცავს სფეროებს, მათ შორის:
- job costing;
- ფინანსური მართვა;
- ხელფასების დარიცხვა;
- HR;
- აღჭურვილობა;
- სერვისის მართვა;
- ობიექტის ოპერაციები;
- ანალიტიკა.
Vista-ს დოკუმენტაცია ზუსტად აჩვენებს, რას ნიშნავს საწარმოებრივი ინტეგრაცია. მაგალითად, სახელფასო ტრანზაქციებს შეუძლია განაახლოს Job Cost, General Ledger, Equipment Management, Accounts Payable და სხვა ფინანსური სტრუქტურები.
ეს უფრო მეტია, ვიდრე დოკუმენტის გაზიარება ან რომელიმე ველის სინქრონიზაცია.
პირიქით, ეს არის ტრანზაქციული ინტეგრაცია.
CMiC
CMiC თავის არქიტექტურას პირდაპირ აღწერს, როგორც სამშენებლო ERP-ს, რომელიც აგებულია ერთიან მონაცემთა ბაზის პლატფორმაზე.
მისი გადაწყვეტა აერთიანებს Construction Financials-სა და Project Management-ს, ხოლო Workflow და Analytics ორივეს კვეთს.
მისი ფინანსური გარემო მოიცავს ბუღალტერიას, ხელფასების დარიცხვას, Human Capital Management-ს, აღჭურვილობასა და მარაგებს, ხოლო პროექტის მართვის გარემო ვრცელდება project controls-ზე, procurement-ზე, ხარისხზე, უსაფრთხოებაზე, ნახაზებსა და დოკუმენტაციაზე.
კიდევ ერთხელ, მნიშვნელოვანი განსხვავება არის მასშტაბი.
აპლიკაცია არ მართავს მხოლოდ იმას, რაც ხდება პროექტის შიგნით.
პირიქით, ის პირდაპირ აკავშირებს პროექტის აქტივობას საწარმოს ფინანსურ და ოპერაციულ პროცესებთან.
Sage X3 Construction
Sage X3 Construction კიდევ ერთ მაგალითს წარმოადგენს.
Sage ამ გადაწყვეტას პოზიციონირებს ხარჯთაღრიცხვის, პროექტის მართვის, პროექტის თვითღირებულების, procurement-ის, მარაგების, კონტრაქტების მართვის, ფინანსური მართვის, HR-ის, სახელფასო დარიცხვისა და ანალიტიკის მიმართულებებზე.
მნიშვნელოვანია, რომ ის ასევე მხარს უჭერს მრავალ პროექტს, ვალუტასა და ბიზნეს ერთეულს.
ეს ERP-ის მახასიათებელია.
ამიტომ სისტემამ უნდა ესმოდეს ორივე:
პროექტის სტრუქტურა
და
კორპორატიული სტრუქტურა.
კატეგორიები არ არის აბსოლუტური — და ეს მნიშვნელოვანია
ბოლოს და ბოლოს, პროგრამული უზრუნველყოფის ბაზრები სტატიკური არ არის.
- პროექტების მართვის მომწოდებლები განაგრძობენ ფინანსური ფუნქციონალის დამატებას.
- ამავდროულად, ERP მომწოდებლები განაგრძობენ საველე და პროექტის მართვის შესაძლებლობების დამატებას.
- ანალოგიურად, გრაფიკების მომწოდებლები ფართოვდებიან project controls-ში.
გარდა ამისა, CDE პლატფორმები სულ უფრო მეტად უჭერენ მხარს სამუშაო პროცესებს, კომერციულ პროცესებსა და ანალიტიკას.
Microsoft Dynamics 365 Project Operations შესანიშნავი მაგალითია ამ შერევისა.
Microsoft Project Operations-ს სთავაზობს სხვადასხვა დანერგვის კონფიგურაციით, მათ შორის ძირითად პროექტზე ორიენტირებულ გარემოსა და Dynamics 365 Finance-თან ინტეგრირებულ გარემოს. Microsoft მკაფიოდ განასხვავებს Project Operations-ის ფუნქციონალსა და ERP-თან ინტეგრირებულ დანერგვებს შორის.
ERP-თან ინტეგრირებულ არქიტექტურაში Microsoft სინქრონიზაციას ახდენს მონაცემებს Dataverse-სა და Dynamics 365 Finance-ს შორის dual-write ტექნოლოგიის გამოყენებით, ხოლო Finance უზრუნველყოფს პროექტის ბუღალტრულ და ფინანსურ ჩარჩოს.
ამიტომ ეს სტატია არ ცდილობს ხელოვნური პროგრამული ჩარჩოების შექმნას.
კატეგორიები აღწერს არქიტექტურულ პასუხისმგებლობას.
პლატფორმა შეიძლება მონაწილეობდეს რამდენიმე შრეში.
მაგრამ საბოლოოდ, ყოველ საწარმოებრივ არქიტექტურას მაინც უწევს პასუხი გასცეს კითხვას:
რომელი სისტემა მართავს რომელ ჭეშმარიტებას?
ამოცანის ჭეშმარიტება, პროექტის ჭეშმარიტება და საწარმოს ჭეშმარიტება
მოკლედ, ეს განსხვავება შეიძლება სამ დონემდე დავიყვანოთ.
მიზანზე ორიენტირებული აპლიკაცია
ქმნის ამოცანის ჭეშმარიტებას
რა არის მიმდინარე გრაფიკი?
რა რაოდენობები იქნა გაზომილი?
რას შეიცავს BIM მოდელი?
პროექტზე ორიენტირებული პლატფორმა
ქმნის პროექტის ჭეშმარიტებას
რომელი ნახაზებია დამტკიცებული?
რომელი RFI-ები რჩება ღია?
რა მდგომარეობაშია ქვეკონტრაქტი?
რა გადაწყვეტილებები მიიღეს პროექტის დაინტერესებულ მხარეებს შორის?
კომპანიის მასშტაბის ERP
ქმნის საწარმოს ჭეშმარიტებას
რა არის ჩვენი დადასტურებული ხარჯი?
რომელ მარაგს ვფლობთ?
რამდენი შრომა მოხმარდა ამ აქტივობას?
რა არის ფინანსური შედეგები?
რა არის ჩვენი გადასახდელი და მისაღები ანგარიშები?
რა არის ამ პროექტის მომგებიანობა?
რა არის ჩვენი კონსოლიდირებული ექსპოზიცია ყველა პროექტსა და კომპანიაზე?
ეს ჭეშმარიტებები ურთიერთშემავსებელია.
მაგრამ ისინი ურთიერთშემცვლელი არ არის.
Common Data Environment სულაც არ არის აუცილებლობით ERP
ეს განსხვავება განსაკუთრებულ ყურადღებას იმსახურებს, რადგან CDE და Single Source of Truth ტერმინები ზედმეტად ხშირად და არასწორად გამოიყენება.
Oracle Common Data Environment-ს განსაზღვრავს, როგორც ღრუბელზე დაფუძნებულ გარემოს, სადაც უფლებამოსილი მონაწილეები ინახავენ და იღებენ წვდომას სამშენებლო პროექტის ინფორმაციაზე.
ეს შესაბამისი განსაზღვრებაა.
პრაქტიკაში CDE შეიძლება გახდეს ავტორიტეტული გარემო შემდეგისთვის:
- დოკუმენტები;
- ნახაზები;
- მოდელები;
- კორესპონდენცია;
- რევიზიები;
- დამტკიცებები;
- პროექტის ჩანაწერები.
მაგრამ ERP-ს უნდა უპასუხოს კითხვების განსხვავებულ ნაკრებს:
- ვინ ფლობს მასალას?
- რომელ საწყობშია ის?
- რომელ მომწოდებელს გადაუხადა კომპანიამ?
- რომელმა იურიდიულმა პირმა გააფორმა კონტრაქტი მომწოდებელთან?
- და რომელმა პროექტმა მოიხმარა მასალა?
- რომელ ხარჯის კოდზე აისახა ის?
- რომელი საბუღალტრო გატარება წარმოქმნა მან?
- რა საგადასახადო რეჟიმი გამოიყენა ფინანსებმა?
- როგორ იმოქმედა ტრანზაქციამ ფულად ნაკადზე?
- როგორ იმოქმედა მან პროექტის მომგებიანობაზე?
სხვა სიტყვებით, ეს არის საწარმოებრივი ტრანზაქციები და არა უბრალოდ პროექტის ინფორმაცია.
პროექტის CDE და საწარმოს ERP შეიძლება თანაარსებობდეს და ხშირად უნდა კიდეც.
მაგრამ ორივეს „Single Source of Truth“-ად მოხსენიება დომენის განსაზღვრის გარეშე იწვევს დაბნეულობას.
კავშირგაბმულობა არ ნიშნავს ინტეგრაციას
შესაძლოა, ეს იყოს მთელი განხილვის ყველაზე მნიშვნელოვანი საკითხი.
დღეს თითქმის ყველა საწარმოებრივ აპლიკაციას აქვს API.
თუმცა ეს არ ნიშნავს, რომ ყველა საწარმოებრივი აპლიკაცია ინტეგრაციას აღწევს.
მაგალითად, API-ს შეუძლია გაგზავნოს:
- მომწოდებლის ნომერი,
- შესყიდვის ორდერი,
- ინვოისი,
- პროექტის კოდი,
- ხარჯის მნიშვნელობა,
- რაოდენობა,
- დოკუმენტი,
- ან სტატუსი.
ეს ადასტურებს, რომ სისტემებს შეუძლიათ ურთიერთგაგება.
თუმცა ეს არ ამტკიცებს, რომ მათ აქვთ ერთი და იგივე ბიზნეს-ლოგიკა.
პირიქით, რეალური საწარმოებრივი ინტეგრაცია ბევრად მეტს მოითხოვს.
საჭიროა:
- საერთო ძირითადი მონაცემები;
- საერთო იდენტიფიკატორები;
- საერთო ორგანიზაციული სტრუქტურები;
- საერთო სამუშაო პროცესის ლოგიკა;
- ტრანზაქციული უწყვეტობა;
- ფინანსური შეჯერება;
- წვდომის მართვა;
- მონაცემთა წარმომავლობა;
- ანგარიშვალდებულება.
განვიხილოთ სამშენებლო სფეროს მარტივი მაგალითი.
ობიექტს სჭირდება 2,000 მეტრი კაბელი.
ეს მოთხოვნა უბრალოდ შესყიდვის ორდერად არ უნდა იქცეს.
პირიქით, შესაძლოა ის უნდა უკავშირდებოდეს:
პროექტი → BoQ → WBS აქტივობა → ხარჯის კოდი → მასალის კოდი → მომწოდებელი → შესყიდვის პაკეტი → საწყობი → GRN → ობიექტზე გაცემა → ფაქტობრივი მოხმარება → ხარჯი → ბუღალტერია
- გრაფიკი განსაზღვრავს, როდის სჭირდება ობიექტს მასალა.
- შესყიდვები განსაზღვრავს, როგორ და ვისგან უნდა მოხდეს მისი მომარაგება.
- შემდეგ საწყობი აფიქსირებს მიღებას.
- ობიექტი აფიქსირებს მოხმარებას.
- ხარჯების კონტროლი ადარებს მოხმარებას ფიზიკურ პროგრესს.
- ფინანსური სამსახური აღიარებს ვალდებულებას და გადახდას.
- საბოლოოდ, მენეჯმენტი აფასებს გავლენას პროექტის მომგებიანობასა და ფულად ნაკადზე.
თუ თითოეული დეპარტამენტი ამ ტრანზაქციას საკუთარ პროგრამაში დამოუკიდებლად აღადგენს, კომპანიას ინტეგრირებული პროცესი არ აქვს.
ამის ნაცვლად, მას აქვს მრავალი მონაცემთა ბაზა, რომლებიც პერიოდულად ცდილობენ ერთმანეთთან შეჯერებას.
ეს სრულიად სხვა რამეა.
მშენებლობის ციფრული პრობლემა უკვე აღარ არის პროგრამული უზრუნველყოფის დეფიციტი
ინდუსტრიას უკვე აქვს უზარმაზარი მოცულობის პროგრამული უზრუნველყოფა.
პრობლემაა უფრო მეტად ფრაგმენტაცია.
McKinsey-მ სამშენებლო ტექნოლოგია აღწერა, როგორც ძლიერ ფრაგმენტირებული და point-solution-ებზე დაფუძნებული ბაზარი. მან ასევე აღნიშნა, რომ მრავალრიცხოვანი point solution-ების ინტეგრირების მიმართ უკმაყოფილებამ ხელი შეუწყო ინდუსტრიის გადასვლას ინტეგრირებული პლატფორმებისკენ.
- ეს დაკვირვება კვლავაც ძალიან აქტუალურია.
- წლების განმავლობაში ჩვენ ვციფრულიზებდით ცალკეულ ამოცანებს.
- ახლა კი უნდა დავაკავშიროთ შედეგად მიღებული ციფრული კუნძულები.
გამოწვევა გადავიდა შემდეგიდან:
„როგორ ვაქციოთ ეს პროცესი ციფრულად?“
შემდეგზე:
„როგორ უზრუნველვყოთ, რომ ყველა ციფრულად გარდაქმნილი პროცესი ერთსა და იმავე ბიზნეს რეალობას წარმოადგენდეს?“
რატომ სჭირდებათ საწარმოებრივ კონტრაქტორებს ERP საყრდენი
საწარმოებრივი დონის კონტრაქტორისთვის საბოლოოდ რამდენიმე რამს სჭირდება ერთი კორპორატიული მფლობელი.
1. ძირითადი მონაცემები
ვიღაცამ უნდა მართოს:
- მასალები,
- შრომის სპეციალობები,
- თანამშრომლებზე,
- მომწოდებლები,
- ქვეკონტრაქტორები,
- მექანიზმები,
- დანახარჯების კოდები,
- კომპანიები,
- ვალუტები,
- საზომი ერთეულები,
- პროექტებზე,
- საწყობები,
- საბანკო ანგარიშები.
თუ თითოეულ პროექტის აპლიკაციას განსხვავებული ვერსია აქვს, ინტეგრაცია მუდმივ შეჯერებად იქცევა.
2. ფინანსური შედეგი
თითქმის ყველა სამშენებლო აქტივობას საბოლოოდ ფინანსური შედეგი აქვს.
- შრომა ფული ღირს.
- მასალები ფული ღირს.
- მექანიზმები ფული ღირს.
- ქვეკონტრაქტორები ფული ღირს.
- დაყოვნებები ფული ღირს.
- ცვლილება ფული ღირს.
თვით პროგრესსაც კი კომერციული მნიშვნელობა აქვს, რადგან პროგრესი საბოლოოდ იქცევა:
სერტიფიცირებად → შემოსავლად → ინვოისად → დებიტორულ დავალიანებად → ნაღდ ფულად.
ამიტომ სამშენებლო მენეჯმენტი და ფინანსური მენეჯმენტი მუდმივად ვერ დარჩება განცალკევებული.
3. კორპორაციული რესურსები
პროექტები დამოუკიდებლად არ ფლობენ კომპანიის სამუშაო ძალას, საწარმოო პარკს, მომწოდებლებთან ურთიერთობებს, ნაღდ ფულს ან კორპორაციულ ცოდნას.
ამის ნაცვლად, enterprise ფლობს ამ რესურსებს და ანაწილებს მათ პროექტებს შორის.
შედეგად, პროექტის შესრულება საბოლოოდ უნდა დაუკავშირდეს საწარმოს რესურსების მართვას.
4. პორტფელის მართვა
Project Manager მართავს პროექტს.
თუმცა CEO ამას არ აკეთებს.
სამაგიეროდ, CEO მართავს კომპანიას, რომელსაც აქვს პროექტების პორტფელი.
ამიტომ უმაღლეს მენეჯმენტს სჭირდება ერთგვაროვნება შემდეგ საკითხებში:
- პროექტებზე,
- ბიზნეს ერთეულები,
- ქვეყნები,
- შვილობილი კომპანიები,
- ერთობლივი საწარმოები,
- ვალუტები,
- და საანგარიშგებო პერიოდები.
ამ დონის მართვა საწარმოს მოდელს მოითხოვს.
სწორი არქიტექტურა არ არის „ერთი აპლიკაცია ყველაფერს აკეთებს“
ეს კიდევ ერთი მნიშვნელოვანი განსხვავებაა.
თუმცა ERP-ის ბირთვის დასაბუთება არ ნიშნავს სპეციალიზებული პროგრამული უზრუნველყოფის წინააღმდეგ პოზიციონირებას.
ეს ტექნოლოგიურად გულუბრყვილობა იქნებოდა.
მაგალითად, კონტრაქტორმა სრულიად ლეგიტიმურად შეიძლება გამოიყენოს:
- Primavera P6 დაგეგმვისთვის.
- Revit ან Tekla დიზაინისა და BIM-ისთვის.
- Aconex როგორც სახელშეკრულებო CDE.
სპეციალიზებული რეალობის დაფიქსირების სისტემა სამშენებლო მოედნის ვიზუალიზაციისთვის.
სპეციალიზებული მექანიზმების ტელემატიკა.
სპეციალიზებული საინჟინრო აპლიკაციები.
და, შესაძლოა, კლიენტის მიერ სავალდებულოდ განსაზღვრული პლატფორმები, რომელთა შეცვლაც კონტრაქტორს არ შეუძლია.
სწორი არქიტექტურული პრინციპია:
სპეციალისტები ზღვარზე. ERP ცენტრში.
სპეციალიზებული აპლიკაციები ასრულებენ იმ ამოცანებს, რისთვისაც არსებობს.
ამ დროს ERP ორგანიზებას უწევს კომერციულ, ოპერაციულ და ფინანსურ შედეგებს მთელ საწარმოში.
მოკლედ, პრობლემა არაა ბევრი აპლიკაციის არსებობა.
პრობლემა არის ბევრი გრავიტაციის ცენტრის არსებობა.
სად ჯდება DANAOS ProjectVIEW ERP?
DANAOS ProjectVIEW ERP უპირველესად მესამე კატეგორიას მიეკუთვნება:
კომპანიის მასშტაბის სამშენებლო ERP
DANAOS-მა ProjectVIEW შეიმუშავა, როგორც საწარმოს გადაწყვეტა დისციპლინათაშორისი, მრავალეროვნული და მრავალფუნქციური სამშენებლო ორგანიზაციებისთვის, რომლებსაც გაფანტული ოპერაციები აქვთ. DANAOS-ის ტექნიკური დოკუმენტაცია მის მოდულებს აღწერს, როგორც დანიშნულებით სპეციფიკურ აპლიკაციებს, რომლებიც შესაბამისობაშია სამშენებლო კომპანიის დეპარტამენტებთან. თუმცა ეს მოდულები საერთო master ფაილებსა და სისტემურ რესურსებს იზიარებენ ერთ ცენტრალიზებულ პლატფორმაზე.
მისი დაფარვის არეალი მოიცავს:
- შეფასება და ტენდერი;
- ბიუჯეტირება და დანახარჯების კონტროლი;
- შესყიდვა და procurement;
- საწყობი და მასალების მართვა;
- ქვეკონტრაქტორების მართვა;
- წარმოება და ფაბრიკაცია;
- მექანიზმები და ტექნიკური მომსახურება;
- HRMS და შრომის მართვა;
- დამკვეთის კონტრაქტები;
- ბუღალტერია და ფინანსები;
- დოკუმენტები;
- ანალიტიკა;
- workflow-ები;
- საველე აპლიკაციები;
- გარე პორტალები.
ძირითადი პრინციპი მნიშვნელოვანია.
ეს მოდულები არ მუშაობენ როგორც ერთმანეთისგან დამოუკიდებელი დეპარტამენტული კუნძულები.
სამაგიეროდ, ისინი მუშაობენ საერთო პროექტისა და საწარმოს სტრუქტურაზე.
გარდა ამისა, DANAOS-ის მიმდინარე SaaS არქიტექტურა ProjectVIEW ERP-ს აღწერს, როგორც სამშენებლო კლასის ERP-ს, რომელიც შედგება 10+1 საწარმოს მოდულისგან და მოიცავს კომერციულ, ოპერაციულ, საწარმოო და ფინანსურ პროცესებს.
ProjectVIEW-ის ძირითადი სამშენებლო ლოგიკა: BoQ ↔ WBS ↔ Cost Codes
მშენებლობა ERP-ს განსაკუთრებულ გამოწვევას უქმნის, რადგან მისი ფუნდამენტური განზომილებები სხვადასხვა წყაროდან მოდის.
მოცულობათა უწყება — BoQ გვეუბნება, რა უნდა მიაწოდოს კონტრაქტორმა კლიენტს და რა რაოდენობით.
სამუშაოთა დაშლის სტრუქტურა — WBS გვეუბნება, როგორ დაალაგებს კონტრაქტორი სამუშაოს დროში.
და ბოლოს, Cost Code-ის სტრუქტურა გვეუბნება, როგორ კლასიფიცირებს კონტრაქტორი შიდა დონეზე დანახარჯებსა და რესურსებს.
ეს სტრუქტურები ერთმანეთთან დაკავშირებულია.
მაგრამ ისინი იდენტური არ არის.
ამიტომ ProjectVIEW-ის ბიზნესლოგიკა აკავშირებს:
BoQ ↔ WBS ↔ Cost Codes
DANAOS ამას აღწერს როგორც პროექტის ბირთვს, რომელიც აკავშირებს მოცულობას, დროსა და ღირებულებას.
შიდა დოკუმენტაციაში ProjectVIEW-ის აღწერა ამ ურთიერთობას განსაზღვრავს, როგორც კლიენტის BoQ-ის, დაგეგმვის WBS-ის და შიდა Cost Codes-ის ტრილატერალურ ინტეგრაციას, რათა მოხდეს ღირებულების, დროისა და რესურსების დაკავშირება.
ეს იმაზე მნიშვნელოვანია, ვიდრე თავიდან ჩანს.
რადგან გრაფიკის პროგრესი მარტო ვერ გაზომავს სამშენებლო შესრულებას.
მაგალითად, წარმოიდგინეთ, რომ მოედნიდან მოდის ანგარიში:
„აქტივობა 50%-ით დასრულებულია.“
მაშინ აშკარა კითხვა უნდა იყოს:
50% რის მიხედვით?
გუნდებმა შესაძლოა ფიზიკური პროგრესი გაზომონ რაოდენობის ან დასრულებული პროცენტის მიხედვით შესაბამის BoQ-ს ან WBS-სთან შედარებით.
მაგრამ Cost Control მოითხოვს მეორე კითხვას:
რა რესურსი მოიხმარა სამუშაომ ამ 50%-ის მისაღწევად?
შრომა.
მასალებს.
მექანიზმები.
ქვეკონტრაქტორები.
არაპირდაპირი რესურსები.
თუ მიღწეული რაოდენობა, წარმოების ტემპი, დრო და მოხმარებული დანახარჯი საბაზისოს არ ემთხვევა, ეს ნიშნავს, რომ რაღაც შეიცვალა.
სწორედ ამ წერტილში ხდება სამშენებლო მენეჯმენტი ეკონომიკურ კონტროლად და არა მხოლოდ პროგრესის ანგარიშგებად.
რატომ ინტეგრირდება ProjectVIEW მაინც Primavera-სთან, BIM-თან, SAP-თან და Oracle-თან
თუ ProjectVIEW ERP არის, რატომ უნდა ინტეგრირდეს სხვა სისტემებთან?
იმიტომ, რომ საწარმოს ბირთვი ტექნოლოგიური იზოლაციის საბაბად არ უნდა იქცეს.
ProjectVIEW უკავშირდება სპეციალიზებულ სამშენებლო ტექნოლოგიებს, მათ შორის Oracle Primavera P6-ს, Microsoft Project-სა და BIM გარემოებს.
ასევე, საჭიროების შემთხვევაში, მას შეუძლია API-ების მეშვეობით დაუკავშირდეს მესამე მხარის საწარმოო პლატფორმებს, როგორიცაა SAP ან Oracle. DANAOS-ის ტექნიკური დოკუმენტაცია პირდაპირ ითვალისწინებს ასეთ ჰიბრიდულ არქიტექტურებს.
ეს განსაკუთრებით მნიშვნელოვანია ძალიან დიდი მრავალეროვნული ჯგუფებისთვის.
მაგალითად, ჰოლდინგ კომპანიას ფინანსებისთვის შეიძლება გლობალურად უკვე სტანდარტად ჰქონდეს SAP ან Oracle.
ამ პლატფორმის ჩანაცვლება შეიძლება არც კომერციულად იყოს რეალისტური და არც ტექნოლოგიურად აუცილებელი.
ასეთ სცენარში:
SAP/Oracle შეიძლება დარჩეს კორპორაციულ ფინანსურ ERP-ად, ხოლო
ProjectVIEW ხდება სამშენებლო ოპერაციული ფენა, რომელიც მართავს სამშენებლო სპეციფიკურ უფრო ღრმა პროცესებს.
ეს ლეგიტიმური არქიტექტურაა.
ამიტომ ერთსა და იმავე პროგრამას deployment-ის მიხედვით შეიძლება სხვადასხვა როლი ჰქონდეს.
მაშ, სინამდვილეში რას უნდა ნიშნავდეს „ერთიანი ჭეშმარიტების წყარო“?
ეს არ უნდა ნიშნავდეს, რომ ყველა ბაიტი ფიზიკურად ერთ მონაცემთა ბაზაში უნდა ინახებოდეს.
ეს განმარტება უკვე აღარ მუშაობს.
სამაგიეროდ, თანამედროვე საწარმოს კანონიერად შეუძლია რამდენიმე სისტემის ჩანაწერის ერთდროულად ექსპლუატაცია.
მთავარი მოთხოვნაა, რომ მფლობელობა ცალსახა იყოს.
მაგალითად:
- Primavera შეიძლება ფლობდეს დამტკიცებულ გრაფიკს.
- BIM გარემომ შეიძლება ფლობდეს მიმდინარე მოდელს.
- Aconex-მა შეიძლება ფლობდეს სახელშეკრულებო დოკუმენტების ჩანაწერს.
და ბოლოს, ERP-ს შეიძლება ეკუთვნოდეს მომწოდებლის, თანამშრომლის, ბუღალტრული, შესყიდვისა და დანახარჯების ტრანზაქციები.
მნიშვნელოვანია, რომ ყველა მონაწილე სისტემამ იცოდეს:
რომელი სისტემა ფლობს რომელ ჭეშმარიტებას,
რომელი იდენტიფიკატორები აკავშირებს მათ,
და
როგორ გადადის ტრანზაქცია მათ შორის მნიშვნელობის დაკარგვის გარეშე.
ეს არის საწარმოს არქიტექტურა.
როგორ უნდა შეამოწმონ კონტრაქტორებმა, არის თუ არა პლატფორმა ნამდვილად ინტეგრირებული?
იმის ნაცვლად, რომ მომწოდებელს ჰკითხოთ:
„გაქვთ APIs?“
დასვით შემდეგი კითხვები:
სად იქმნება master მონაცემები?
ვინ ფლობს მომწოდებლებს, მასალებს, თანამშრომლებს, მექანიზმებს, Cost Codes-ს, ორგანიზაციებს და პროექტებს?
შეუძლია ტრანზაქციებს საკუთარი იდენტობის შენარჩუნება?
შეუძლია მოთხოვნას გადაადგილდეს საიტზე მოთხოვნიდან შესყიდვამდე, Purchase Order-მდე, მიღებამდე, მოხმარებამდე, დანახარჯამდე და ფინანსებამდე ისე, რომ ვერავინ თავიდან არ შექმნას იგი?
შეუძლია სისტემას ფიზიკური პროგრესის შეჯერება რესურსების მოხმარებასთან?
შეუძლია მენეჯმენტს გაიგოს, ამოწეული სამუშაოს რაოდენობა თუ ამართლებს გაწეულ დანახარჯს?
შეუძლია სისტემას კორპორაციული სტრუქტურის მართვა?
- რამდენიმე კომპანია?
- შვილობილი კომპანიები?
- ერთობლივი საწარმოები?
- ქვეყნები?
- ვალუტები?
- პროექტები?
შეუძლია ოპერაციულ აქტივობას ფინანსებამდე მისვლა?
აშენების ტრანზაქცია საბოლოოდ ქმნის თუ არა აუდიტირებად ფინანსურ შედეგს?
შეუძლიათ ხელმძღვანელებს პროექტების თანმიმდევრულად შედარება?
თუ Business Intelligence-ს ჯერ ათი სხვადასხვა მონაცემთა სტრუქტურის ნორმალიზება უწევს?
შეუძლიათ მომხმარებლებს KPI-ს მის ტრანზაქციამდე მიყოლა?
თუ მენეჯმენტი ხედავს დანახარჯის გადახრას, შეუძლიათ მომხმარებლებს ჩაღრმავება და განსაზღვრა, რომელი შრომის, მასალის, მექანიზმის, ქვეკონტრაქტორის ან შესყიდვის ტრანზაქციაა პასუხისმგებელი?
ეს კითხვები feature comparison-ზე ბევრად მეტს ავლენს.
სად ჯდება AI ამ ყველაფერში?
არსებობს კიდევ ერთი მიზეზი, რატომ გახდა ეს განხილვა გადაუდებელი.
AI.
კომპანიები ახლა ჩქარობენ სამშენებლო სფეროში AI აგენტების, copilot-ების და პროგნოზული სისტემების დანერგვას.
მაგრამ AI ქვემოთ არსებულ მონაცემთა და პროცესთა ხარისხს მრავლად ზრდის.
თუ საწარმოში არსებობს ერთმანეთთან წინააღმდეგობაში მყოფი მომწოდებლების ჩანაწერები, არათანმიმდევრული Cost Codes-ები, დაუკავშირებელი გრაფიკები, დუბლირებული მასალების განსაზღვრებები და შეუჯერებელი პროექტის ფინანსები, AI არ ქმნის საწარმოს ჭეშმარიტებას ჯადოსნურად.
სამაგიეროდ, ის აჩქარებს არათანმიმდევრულობის მოხმარებას.
ამიტომ სტრუქტურირებული ERP მონაცემები სტრატეგიულად მნიშვნელოვანი ხდება.
ProjectVIEW-ის მიმდინარე არქიტექტურა ERP-ს აყენებს, როგორც სტრუქტურირებულ პროცესისა და მონაცემთა ფენას მისი AI გარემოს ქვემოთ, BoQ-ს, WBS-სა და Cost Codes-ს იყენებს, როგორც მანქანისთვის გასაგებ პროექტის განზომილებებს.
სანამ ორგანიზაციები ავტონომიურ სამშენებლო AI-სკენ წავლენ, მათ სჭირდებათ ბევრად ნაკლებად თვალისმომჭრელი, მაგრამ ბევრად უფრო მნიშვნელოვანი რამ:
თანმიმდევრული საწარმოო მონაცემები.
ხშირად დასმული კითხვები
რა განსხვავებაა Construction Management Software-სა და სამშენებლო ERP-ს შორის?
Construction Management Software უპირველესად ეხმარება პროექტების შესრულების კოორდინაციასა და კონტროლს.
ამის საპირისპიროდ, სამშენებლო ERP აკავშირებს პროექტის შესრულებას საწარმოს ფუნქციებთან, როგორიცაა შესყიდვა, მარაგი, ხელფასები, მექანიზმები, ბუღალტერია, ფინანსები, კორპორაციული რესურსები და პორტფელის მართვა.
Procore ERP არის?
Procore უზრუნველყოფს ფართო სამშენებლო-მენეჯმენტისა და პროექტის ფინანსური ფუნქციონალს, თუმცა თავად Procore-ს აქვს სპეციალური ინტეგრაციები მრავალ ERP და საბუღალტრო სისტემასთან. ეს აჩვენებს მის უნარს, იარსებოს საწარმოს ERP ბირთვთან ერთად და არა იმ მოთხოვნით, რომ თავად Procore-მა შეასრულოს ყველა ERP ფუნქცია.
Autodesk Construction Cloud ERP არის?
Autodesk Construction Cloud უპირველესად სამშენებლო და პროექტის მიწოდების გარემოა. თუმცა Autodesk აქტიურად უჭერს მხარს გარე ERP, საბუღალტრო და ფინანსურ აპლიკაციებთან ინტეგრაციებს.
CDE იგივეა, რაც ERP?
არა.
CDE მართავს საერთო პროექტის ინფორმაციასა და თანამშრომლობას.
ამის საპირისპიროდ, ERP მართავს საწარმოს რესურსებს, ტრანზაქციებსა და ფინანსურ შედეგებს.
ისინი შეიძლება და ხშირად უნდა იმუშაონ ერთად.
ERP გამორიცხავს სპეციალიზებულ აპლიკაციებს?
არა.
მოწიფულ საწარმოო არქიტექტურაში სპეციალიზებული აპლიკაციები უნდა შენარჩუნდეს, როდესაც ისინი უკეთეს დომენურ ფუნქციონალს უზრუნველყოფენ.
სამაგიეროდ, ERP მათ უნდა უწევდეს ორგანიზებას.
შეუძლია თუ არა ზოგად ERP-ს, როგორიცაა SAP, Oracle ან Dynamics, იმოქმედოს როგორც საწარმოს ბირთვი?
სრულიად.
დიდ ERP პლატფორმებს შეუძლიათ უზრუნველყონ კორპორაციული ბირთვი.
თუმცა, კონტრაქტორებისთვის კითხვა ის არის, სისტემას ნატიურად აქვს თუ არა საკმარისი სამშენებლო სპეციფიკური ბიზნესლოგიკა, თუ მას სჭირდება დამატებითი სამშენებლო ოპერაციული ფენა.
ProjectVIEW ERP მხოლოდ პროექტის მართვის პლატფორმაა?
არა.
ProjectVIEW ERP-ის არქიტექტურა მოიცავს კომერციულ, ოპერაციულ და ფინანსურ პროცესებს, მრავალკომპანიურ და მრავალპროექტიან შესაძლებლობებთან ერთად, ხოლო სამშენებლო სპეციფიკური მოდულები საერთო საწარმოო მონაცემებს იზიარებენ.
შეუძლია ProjectVIEW-ს SAP-თან ან Oracle-თან თანაცხოვრება?
დიახ.
DANAOS მხარს უჭერს გარე ERP გარემოებთან ინტეგრაციას, როდესაც უფრო დიდ კორპორაციულ ჯგუფს სურს შეინარჩუნოს არსებული კორპორაციული ფინანსური პლატფორმა.
სწორი ციფრული ტრანსფორმაციის კითხვა
ბოლო ათი წლის განმავლობაში მშენებლობა ძლიერ იყო ფოკუსირებული ცალკეული პროცესების დიჯიტალიზაციაზე.
ეს აუცილებელი იყო.
მაგრამ ახლა ჩვენ შემდეგ ეტაპზე გადავდივართ.
გამოწვევა აღარ არის მხოლოდ:
„შეგვიძლია ამ ამოცანის დიჯიტალიზაცია?“
ამის ნაცვლად, გამოწვევაა:
„შეგვიძლია ისე მოვაწყოთ ყველა ციფრული პროცესი, რომ ერთი და იგივე ბიზნეს რეალობა აღწეროს?“
ეს არქიტექტურას მოითხოვს.
ასევე მოითხოვს governance-ს.
თანაბრად საჭიროა master მონაცემები.
საჭიროა ტრანზაქციული უწყვეტობა.
და, უპირველესად, საჭიროა მოედნის ოფისთან დაკავშირება, პროექტის კომპანიასთან დაკავშირება და საბოლოოდ მშენებლობის ფიზიკური პროგრესის მისი ფინანსური შედეგის დაკავშირება.
დანიშნულებით სპეციფიკური აპლიკაციები კვლავაც აუცილებელი იქნება.
პროექტის თანამშრომლობის პლატფორმები კვლავაც აუცილებელი იქნება.
CDE-ები კვლავაც აუცილებელი იქნება.
დაგეგმვის აპლიკაციები კვლავაც აუცილებელი იქნება.
BIM კვლავაც აუცილებელი იქნება.
მაგრამ საწარმოო კონტრაქტორებს ცენტრში მაინც სჭირდებათ რაღაც.
რაღაცამ უნდა გაიგოს კომპანია.
მას ასევე უნდა ესმოდეს მისი რესურსები.
რაღაცამ უნდა გაიგოს თითოეული პროექტი.
გარდა ამისა, მან უნდა გადააქციოს სამშენებლო აქტივობა დანახარჯად, შემოსავლად, ფულადი ნაკადად და მომგებიანობად.
და ბოლოს, მან უნდა შეათანხმოს:
რა ვპირდებოდით აშენებას
როდის ვგეგმავდით მის აშენებას რა რესურსი მოვიხმარეთ რა დაჯდა ის სინამდვილეში და რა ღირებულება მივიღეთ
ეს არის სამშენებლო ERP-ის როლი.
დანიშნულებით სპეციფიკური აპლიკაციები ოპტიმიზაციას უკეთებს ამოცანებს.
პროექტზე ორიენტირებული პლატფორმები კოორდინაციას უწევს პროექტებს.
სამშენებლო ERP მართავს საწარმოს.
და ზუსტად აქ აპირებს მუშაობას DANAOS ProjectVIEW ERP:
არა როგორც კიდევ ერთი აპლიკაცია, რომელიც სამშენებლო პროექტს აკრავს გარს, არამედ როგორც სამშენებლო სპეციფიკური საწარმოს ბირთვი, რომელიც მას უკან მდგომ კომპანიას მართავს.
წყაროები და დამატებითი საკითხავი
LinkedIn — AI Search Visibility Guidelines LinkedIn-ის რეკომენდაციით, გრძელფორმატიანი სტატიები ავტორიტეტის გამაძლიერებელ აქტივად ითვლება და ხაზგასმით აღნიშნავს მკაფიო ტერმინოლოგიას, კითხვით სათაურებს, დამოუკიდებელ პასუხის სექციებს და თანმიმდევრულ კატეგორიულ ენას AI მოძიებისთვის. LinkedIn: How to Maximize AI Visibility for Your LinkedIn Posts
McKinsey — სამშენებლო ტექნოლოგიების ფრაგმენტაცია და პლატფორმების ინტეგრაცია McKinsey: პლატფორმების ეპოქის აღმავლობა — შემდეგი თავი სამშენებლო ტექნოლოგიებში
Oracle Primavera P6 Enterprise Project Portfolio Management Oracle Primavera P6 EPPM
Oracle Aconex — პროექტის კოლაბორაცია და მონაცემთა ერთიანი გარემო Oracle Aconex სამშენებლო პროექტების მართვა
Procore ERP Integrations Procore ERP Integrations Documentation
Autodesk Construction Cloud — ERP and Financial Integration Autodesk: სამშენებლო ERP and Financial Integrations
Trimble ProjectSight — ERP Integration Trimble ProjectSight ERP Integration
Trimble Viewpoint Vista — სამშენებლო ERP Trimble Vista სამშენებლო ERP
CMiC — სამშენებლო ERP CMiC სამშენებლო ERP Platform
Sage X3 Construction Sage X3 სამშენებლო ERP
Microsoft Dynamics 365 Project Operations Microsoft Dynamics 365 Project Operations Documentation
DANAOS — ProjectVIEW OS და BoQ ↔ WBS ↔ ხარჯის კოდების არქიტექტურა ProjectVIEW OS: ოპერაციული სისტემა მშენებლობისთვის
DANAOS — Why ERP Comes Before AI Walk Before You Run: Why ERP Comes Before AI
DANAOS — ProjectVIEW ERP SaaS არქიტექტურა და ფუნქციური მოცვა DANAOS ProjectVIEW ERP ძირითადი SaaS ჩარჩო
