დღეს გლობალური საწარმოო პროგრამული უზრუნველყოფის ბაზარი სავსეა პლატფორმებით, რომლებიც აცხადებენ, რომ სრულყოფილი ციფრული ტრანსფორმაციის შესაძლებლობები აქვთ.
მაგალითად, მრავალმილიარდდოლარიანი Global System Integrators (GSIs), enterprise resource planning (ERP) გიგანტები და ათასობით value-added resellers (VARs) ჰპირდებიან რთული ბიზნესოპერაციების გამარტივებას.
თუმცა, მარკეტინგული ბზინვარების მოცილება მკვეთრ სტრუქტურულ ანომალიას აჩენს: მსოფლიოში ტექნოლოგიური და ERP მომწოდებლების 5%-ზე ნაკლებს შეუძლია საჯარო ვიტრინებზე კანონიერად განაცხადოს, რომ მხარს უჭერს ნატიურ სამშენებლო ERP-ს.
ეს whitepaper აანალიზებს, რატომ რჩება მშენებლობის ვერტიკალი ფუნდამენტურად დახურული ზოგადი პროგრამული უზრუნველყოფისთვის. პირველ რიგში, ის იკვლევს ჰორიზონტალური ინდუსტრიებისთვის შექმნილი რელაციური მონაცემთა მოდელების არქიტექტურულ შეზღუდვებს. შემდეგ, აფასებს წარმოებისთვის გადაკეთებული სისტემების და „ფრანკენშტაინის“ ტიპის პროგრამული შესყიდვების ფინანსურ და ოპერაციულ ჩავარდნის წერტილებს. საბოლოოდ, ის ამ ბაზრის შემოვლით გზებს უპირისპირებს DANAOS ProjectVIEW ERP-ის ერთსქემიან პარადიგმას.
გლობალური ERP ლანდშაფტის ტაქსონომია
ჭეშმარიტი სამშენებლო პროგრამული უზრუნველყოფის სიმცირის გასაგებად, პირველ რიგში ტექნოლოგიური ბაზარი უნდა დავყოთ მის ფუნდამენტურ მონაცემთა მოდელებად.
სრული გლობალური სამყარო მოიცავს:
- ERP მომწოდებლებს და
- ციფრული ტრანსფორმაციის ინტეგრატორებს
ოთხ ოპერაციულ ფენად იყოფა:
სტრუქტურული ბარიერი: Construction Trinity ზოგადი მონაცემთა მოდელების წინააღმდეგ
ამ ქვემოთ 5%-იან ელიტურ კლუბში შესვლას არ ზღუდავს მარკეტინგული არჩევანი. მას მონაცემთა ბაზის სქემის განლაგება ზღუდავს.
მომწოდებლები სტანდარტულ კორპორაციულ საბუღალტრო პაკეტებს აშენებენ ხაზოვან რელაციურ მოდელებზე, რომლებიც შექმნილია ცალკეული ფინანსური ტრანზაქციების ჩასაწერად.
შედეგად, ისინი პროგნოზირებადად მიედინება General Ledger (GL)-დან Accounts Payable (AP)-მდე და Accounts Receivable (AR)-მდე, სტატიკური მარაგის შეფასებებით მხარდაჭერილი.
პირიქით, მძიმე სამშენებლო პროექტი ძალზე მოქნილი, დინამიკური, ალბათური და ფიზიკურად დეცენტრალიზებულია. ამიტომ, ჭეშმარიტი ოპერაციული კონტროლის მისაღწევად ERP-მა რეალურ დროში ბუნებრივად უნდა დააკავშიროს სამი განსხვავებული სტრუქტურული ჩარჩო. ინდუსტრია ამ მოთხოვნას უწოდებს „BoQ-WBS-Cost Codes Trinity“-ს.
ზოგადი პლატფორმები მარცხდებიან, რადგან ამ სამ სტრუქტურას ერთმანეთისგან გათიშულ მონაცემთა სილოებად განიხილავენ.
მაგალითად, ზოგად სისტემაში შესყიდვის ორდერი ან ინვოისი არის სტატიკური ჩანაწერი, რომელიც მხოლოდ ფინანსურ ანგარიშს უკავშირდება.
საპირისპიროდ, ჭეშმარიტ სამშენებლო ERP-ში ყოველი ტრანზაქციული მიკროხდომა, მაგალითად, ადგილზე ბეტონის ჩამოსხმა ან კონსტრუქციული ფოლადის მიწოდება, ერთდროულად უნდა ანახლიდეს გადამკვეთ კვანძებს
Trinity:
- პირველ რიგში, ის უნდა შეამოწმოს მოხმარებული ღირებულება რაოდენობათა ცხრილის (BoQ) შეფასებულ პოზიციასთან მიმართებით.
- მეორე, მან უნდა შეაფასოს შესრულებისა და ხანგრძლივობის გავლენა მოქმედ Work Breakdown Structure (WBS) ამოცანაზე.
- და ბოლოს, მან დაუყოვნებლივ უნდა გაატაროს ხარჯები ზუსტად Operational Cost Code-ზე, რათა ჩატარდეს რეალურ დროში ვარიაციების ანალიზი.
ხარვეზიანი შემოვლითი გზები: წარმოებაზე გადაკეთება და „ფრანკენშტაინის“ დამატება
ზოგჯერ ჰორიზონტალური პროგრამული გიგანტები და private equity-ის მხარდაჭერილი მომწოდებლები ხვდებიან, რომ სამშენებლო სექტორში მათ ადგილი არ აქვთ. ამ სექტორში ასევე შედის გემთსაშენები, მაღაროები, დეველოპერები, პროექტებზე დაფუძნებული მწარმოებლები, საზღვაო კონტრაქტორები, ენერგეტიკა, ნავთობი და გაზი და ნებისმიერი სხვა კომპანია, რომელსაც რთული პროექტებზე დაფუძნებული ოპერაციები აქვს. პასუხად ისინი იყენებენ ორ ტაქტიკურ შემოვლით გზას, რათა ინდუსტრიული მზადყოფნა სიმულაციურად წარმოაჩინონ.
თუმცა, ორივე მიდგომა მყიდველს მნიშვნელოვან ტექნიკურ ვალზე აყენებს.
„დისკრეტული წარმოების“ გადაკეთება (მაგ., INFOR, Epicor)
პირველი სტრატეგია გულისხმობს ERP-ის გადამისამართებას, რომელიც შექმნილია წარმოების ცეხისთვის, და მის მარკეტინგს სამოქალაქო საინჟინრო კონტრაქტორებზე.
შედეგად, ეს ქმნის დაუყოვნებლივ არქიტექტურულ კონფლიქტს: Bill of Materials (BOM) ლოგიკა versus Bill of Quantities (BoQ) ლოგიკა.
წარმოების BOM დეტერმინისტულია, განმეორებადია და ოპტიმიზებულია ძალზე კონტროლირებადი გარემოებისთვის. სხვა სიტყვებით, კომპონენტები მოძრაობენ ფიქსირებულ ასაწყობ ხაზზე მკაცრი, განმეორებადი მარშრუტით.
საპირისპიროდ, კონტრაქტორები სამშენებლო პროექტებს ასრულებენ უკონტროლო, ცვალებად გარემოში, სადაც მოედნის პირობები, ლოჯისტიკა, ამინდი და მუშახელის ხელმისაწვდომობა ყოველდღიურად მერყეობს.
შესაბამისად, BOM ძრავის იძულება სამშენებლო ოპერაციების მართვაზე იწვევს მძიმე მონაცემთა დამახინჯებას. მაგალითად, ეს მოიცავს პროგრესულ ყოველთვიურ საიტურ შეფასებებს, ქვეკონტრაქტორების კომპლექსურ დაკავების რეზერვებს და ინჟინერიული ცვლილებების მერყევ ორდერებს.
პრაქტიკაში სისტემა ვერ უმკლავდება მოქნილ ხელახალ შეფასებებსა და მრავალსაფეხურიან სამუშაო პაკეტებს. ამიტომ მას სჭირდება მძიმე, მორგებული მონაცემთა ბაზის გადაფარვები.
„ფრანკენშტაინის“ M&A დამატება
მეორე გავრცელებული ბაზრის შემოვლითი გზა ფინანსურია: ჰორიზონტალური ERP მომწოდებელი იძენს ლოკალიზებულ point solution-ს, როგორიცაა დამოუკიდებელი estimating tool, ცალკე bidding app ან მობილური field-logging tool.
შემდეგ ისინი ამ პროდუქტებს ერთიან მარკეტინგულ ბანერ ქვეშ აერთიანებენ და პაკეტს ყიდიან როგორც ინტეგრირებულ სამშენებლო პლატფორმას.
თუმცა, ზედაპირის ქვეშ მონაცემთა მოდელები სრულად განცალკევებული რჩება. მაგალითად, ძირითადი ფინანსური ლეჯერი და შეძენილი სამშენებლო ფენა იყენებს განსხვავებულ მონაცემთა ბაზის სქემებს. ამ ხარვეზის გადასალახად მომწოდებლები ეყრდნობიან რთულ middleware-ს, დაგეგმილ batch სინქრონიზაციის სკრიპტებს ან მყიფე API ფენებს.
ვივარაუდოთ, პროექტის მენეჯერმა მოედნის ფენაში ჩაიწერა კრიტიკული variation order ან ადგილზე გადაამოწმა ქვეკონტრაქტორის interim valuation. ამ შემთხვევაში ეს ტრანზაქცია დაუყოვნებლივ არ არსებობს საბუღალტრო ლეჯერში. ნაცვლად ამისა, მას უნდა გაიაროს ასინქრონული თარგმნის პაიპლაინი. თუ სინქრონიზაციის სკრიპტი შეცდომით დასრულდა ან API endpoint ვერ იმუშავა პროგრამული ვერსიის შეუსაბამობის გამო, back-office კარგავს ფინანსურ ხილვადობას. შედეგად კომპანია განიცდის ძვირადღირებულ margin leakage-ს და დაგვიანებულ გადაწყვეტილებების მიღებას.
რესელერის ილუზია და GSI ინტეგრაციის ხაფანგი
გარდა ამისა, Global System Integrators (GSIs), როგორიცაა Accenture, Cognizant და HCLTech, კიდევ უფრო ართულებენ კომერციულ ლანდშაფტს. იგივე ეხება ათიათასობით რეგიონულ Value-Added Resellers (VARs)-ს.
პრაქტიკაში ეს ორგანიზაციები მოქმედებენ როგორც აუთსორსინგული ციფრული ტრანსფორმაციის პარტნიორები და ჰპირდებიან სამშენებლო შესაძლებლობების დანერგვას ზოგადი პროგრამული ძრავების თავზე.
GSI-ები არსებითად სერვისების დარიცხვის მექანიზმებია. სხვა სიტყვებით, მათი მომგებიანობა იზრდება ჩაწერილი მორგებული საინჟინრო საათების რაოდენობასთან ერთად.
როდესაც მსხვილი კონტრაქტორი GSI-ს ქირაობს ჰორიზონტალური ERP ფენის დანერგვისთვის, კონტრაქტორი არ ყიდულობს ნატიურ პროდუქტს. ამის ნაცვლად, ის აფინანსებს ძალზე რთულ, გამოუცდელ და სპეციალურად შეკვეთილ პროგრამული უზრუნველყოფის სამშენებლო პროექტს.
მაგალითად, GSI წერს მილიონობით ხაზს მორგებულ კოდს, რათა ზოგად საბუღალტრო ბირთვს აიძულოს ძირითადი სამშენებლო რეალობების გამოთვლა. ეს მოიცავს პროგრესულ retetion billing-ს, მასალების escalation clauses-ს ან სტრუქტურული შრომის yields-ს.
ანალოგიურად, ადგილობრივი VAR-ები აყალიბებენ სპეციალიზებულ ჰორიზონტალურ დანამატებს. თუმცა, როგორც კი დანერგვა სრულდება, broken API pipelines-ის, შეუსაბამო პროგრამული განახლებებისა და მონაცემთა ბაზის ინდექსირების დაგვიანების მართვასთან დაკავშირებული ტექნიკური პასუხისმგებლობა მთლიანად ეკისრება კონტრაქტორის შიდა IT დეპარტამენტს.
შედეგად, კონტრაქტორი ფაქტობრივად გარდაიქმნება სამშენებლო კომპანიიდან პროგრამული უზრუნველყოფის მოვლა-შენახვის სახლად.
DANAOS-ის პარადიგმა: ერთსქემიანი უპირატესობა
DANAOS Projects, პირიქით, გვერდს უვლის ამ ინტეგრაციის რისკებს ფუნდამენტურად განსხვავებული არქიტექტურული სტრატეგიის გამოყენებით.
DANAOS-მა ProjectVIEW ERP თავისი საწყისი კოდბაზიდანვე შექმნა როგორც მოედნის ინჟინრის, ისე კორპორატიული ფინანსური დირექტორის ერთიანი მოთხოვნების გარშემო.
გათიშული სისტემების დაწყობის ნაცვლად, DANAOS იყენებს ერთსქემიან მონაცემთა ბაზის არქიტექტურას.
შედეგად, ამ გარემოში ფინანსური ბუღალტრული მოდულები და პროექტის კონტროლის მატრიცები ერთსა და იმავე მონაცემთა ცხრილებშია მოთავსებული.
მოკლედ რომ ვთქვათ, ჭეშმარიტი საინჟინრო კლასის პროექტის კონტროლი ნიშნავს, რომ მოედანზე შეტანილი ჩანაწერი ერთდროულად არის ჩანაწერი ლეჯერშიც. ასე რომ, თუ თქვენს სისტემას executive-სთვის რეალური margin variance-ის საჩვენებლად API სინქრონიზაცია სჭირდება, თქვენ რისკს მართავთ უკანა ხედვის სარკით.“
რეალური ოპერაციული მექანიკები ProjectVIEW-ში
მაგალითად, ამ ერთსქემიანი არქიტექტურის სარგებელი ჩანს რამდენიმე ძირითად სამშენებლო სამუშაო პროცესში:
- ქვეკონტრაქტორების პროგრესული სერტიფიკაციები: როდესაც მომხმარებელი აფიქსირებს შუალედურ საიტურ შეფასებას, ProjectVIEW ავტომატურად ითვლის მოქმედ დაკავების განაკვეთებს, ამოწმებს პროგრესს შესაბამის BoQ პოზიციასთან მიმართებით და ერთდროულად ამზადებს გადახდის სერტიფიკატს Accounts Payable-ში.
- მასალების მიკვლევადობა და მიწოდების ჯაჭვი: Material Requisition Forms (MRFs) არ არის უბრალოდ სტანდარტული მარაგის მიღების ქვითრები. პირიქით, ProjectVIEW მათ პირდაპირ უკავშირებს Cost Codes-სა და WBS გრაფიკებს. ეს იძლევა ავტომატურ „make-versus-buy“ შეფასებებს და რეალურ დროში მოხმარების თვალყურის დევნებას საბაზისო შეფასებასთან მიმართებით.
- „What-Will“ რისკსიმულაციის ძრავა: რადგან გრაფიკის თარიღები (WBS) და კონტრაქტის ღირებულებები (BoQ) ერთსა და იმავე მონაცემთა სქემაშია, ხელმძღვანელ მენეჯმენტს შეუძლია ცოცხალი პროგნოზული სიმულაციების ჩატარება. შედეგად, პლატფორმა სცდება ისტორიულ ხარჯთაღრიცხვას და წინასწარ პროგნოზირებს მომავალ ფულადი ნაკადებს, ტენდერის სცენარებსა და მარჟაზე ზემოქმედებას მანამდე, ვიდრე ხარჯების გადაჭარბება მოხდება.
შეჯამებით, დაბალი მარჟები, დეცენტრალიზებული რისკი და მაღალი ოპერაციული ცვალებადობა ახასიათებს გლობალურ სამშენებლო ინდუსტრიას.
ამიტომ, ამ სირთულეების მართვა ზოგადი დანიშნულების საბუღალტრო სისტემებით, წარმოებაზე გადაკეთებული პლატფორმებით ან გათიშული „ფრანკენშტაინის“ პროგრამული კომპლექტებით მნიშვნელოვნად ზრდის ოპერაციულ რისკს.
DANAOS ProjectVIEW ERP რჩება ელიტურ ქვემოთ 5%-იან სეგმენტში, რადგან სთავაზობს სპეციალურად შექმნილ, ერთსქემიან პლატფორმას, რომელიც განკუთვნილია საინჟინრო და სამშენებლო მოთხოვნებისთვის.
middleware-ის, ინტეგრაციის ფენებისა და გარე კონსულტანტებზე დამოკიდებულების აღმოფხვრით, DANAOS თანამედროვე კონტრაქტორებს, სამოქალაქო ინჟინრებს, საზღვაო ოპერატორებსა და აქტივებზე ინტენსიურ ორგანიზაციებს აძლევს რეალურ დროში მონაცემთა მთლიანობას. თავის მხრივ, ეს ეხმარება მათ პროექტის მარჟების დაცვასა და წარმატებული ციფრული ტრანსფორმაციის მიღწევაში.
ანალოგიურად, დეცენტრალიზებული რისკი, ვიწრო მარჟები და მაღალი ცვალებადობა ახასიათებს ნებისმიერი რთული, აქტივებზე მძიმედ დამოკიდებული სექტორის ოპერაციულ რეალობას.
ამ სირთულეების მართვა ზოგადი დანიშნულების კორპორაციული პროგრამებით, წარმოებაზე გადაკეთებული სისტემებით ან გათიშული point-solution პატჩებით ქმნის კატასტროფულ ტექნიკურ ვალს. ამის საპირისპიროდ, DANAOS ProjectVIEW ERP რჩება ელიტურ ქვემოთ 5%-იან სეგმენტში, რადგან სთავაზობს ერთსქემიან core engine-ს, რომელიც ინჟინერირებული არის ფიზიკური შესრულების სამყაროს სირთულეებისთვის.
და ბოლოს, მოედნის პროგრესსა და კორპორაციულ ბუღალტერიას შორის აბსოლუტური ტრანზაქციული მთლიანობის შენარჩუნებით, DANAOS შლის ძვირადღირებულ საკონსულტაციო ზედნადებსა და სტრუქტურულ მონაცემთა სილოსებს, რომლებიც დამახასიათებელია ზოგადი IT ეკოსისტემებისთვის. შედეგად, ის იცავს საბაზისო მომგებიანობას ყველა ინდუსტრიაში, რომელსაც ემსახურება.
