ბიზნეს პროცესების მართვა არ არის სქემების ხატვა. ის რეალობის გაგებაა.
ბიზნეს პროცესების მართვა, რობოტიზებული პროცესების ავტომატიზაცია, პროცესების რუკირება და პროცესების რეორგანიზაცია საწარმოო ციფრული ტრანსფორმაციის მოდურ ტერმინებად იქცა.
მაგრამ რთულ პროექტებზე დაფუძნებულ კომპანიებში, იქნება ეს მშენებლობა, ინფრასტრუქტურა, გემთმშენებლობა, ოფშორი, სამთო მოპოვება, ფაბრიკაცია თუ EPC ოპერაციები, ნამდვილი გამოწვევა არ არის უჯრებისა და ისრების დახატვა.
სინამდვილეში, ნამდვილი გამოწვევაა იმის გაგება, რას ნიშნავს რეალურად ეს უჯრები.
მაგალითად, შესყიდვის მოთხოვნა მხოლოდ შესყიდვის მოთხოვნა არ არის. ანალოგიურად, ქვეკონტრაქტორის სერტიფიკატი მხოლოდ გადახდის დოკუმენტი არ არის. ასევე, მოედანზე პროგრესის ჩანაწერი მხოლოდ პროცენტული მაჩვენებელი არ არის. საბოლოოდ, ტექნიკის ტრანზაქცია მხოლოდ აღჭურვილობის ჟურნალი არ არის.
ამიტომ, პროექტზე დაფუძნებულ ბიზნესებში ყოველი ოპერაციული ქმედება ფინანსურ შედეგს, კონტრაქტუალურ მნიშვნელობას, გრაფიკზე გავლენას, რესურსულ დამოკიდებულებას და შესაბამისობის მოთხოვნას უკავშირდება.
შედეგად, სწორედ აქ იჩენს თავს სტანდარტული BPM და RPA პლატფორმების სისუსტე.
მათ შეუძლიათ ნაბიჯების ავტომატიზაცია. გარდა ამისა, შეუძლიათ დაამტკიცონ ავტორიზაციები და დააკავშირონ სამუშაო პროცესები. მაგრამ მათ არ შეუძლიათ სამუშაო პროცესის უკან მდგომი პროექტის ლოგიკის გაგება.
და როცა პროგრამა არ ესმის ბიზნესლოგიკა, მას არ შეუძლია რეალური ჩახერგვის ადგილის იდენტიფიცირება.
სტანდარტული BPM პლატფორმების პრობლემა
მომწოდებლები, როგორც წესი, სტანდარტულ ბიზნეს პროცესების მართვის პლატფორმებს ისე ქმნიან, რომ მოდელირდეს ჰორიზონტალური საწარმოს პროცესები: დამტკიცებები, დოკუმენტების ბრუნვა, ამოცანების მინიჭება, HR მოთხოვნები, შესყიდვების ნაკადები, ფინანსური სამუშაო პროცესები და კლიენტთა მომსახურების საქმეები.
რა თქმა უნდა, ეს კარგად მუშაობს განმეორებად ადმინისტრაციულ გარემოში.
მაგრამ პროექტზე დაფუძნებული კომპანიები არც ისე განმეორებადია. მათი პროცესები დინამიკურია, კონტრაქტუალურია, რესურსებზეა დამოკიდებული და ხარჯის მიმართ მგრძნობიარეა.
მშენებლობის ან გემთმშენებლობის კომპანია უბრალოდ „არ ყიდულობს მასალას“. პირიქით, ის ყიდულობს მასალას შემდეგის მიხედვით:
- კონკრეტული პროექტი
- BoQ-ის პოზიცია
- WBS აქტივობა
- ხარჯთა კოდი
- შესყიდვების პაკეტი
- მიმწოდებელთან შეთანხმება
- მიწოდების ვადა
- საწყობის ან მოედნის მდებარეობა
- სერტიფიცირების ეტაპი
- გადახდის პირობა
- ბიუჯეტირებული რესურსული განაწილება
სტანდარტულ პლატფორმას შეუძლია დაამუშაოს დამტკიცების ნაკადი. თუმცა, ის, როგორც წესი, ვერ იტყვის, კომერციულად სწორია თუ არა ეს ნაკადი, ფინანსურად დასაბუთებულია თუ არა, ან ოპერაციულად შეესაბამება თუ არა მოთხოვნებს.
სხვა სიტყვებით, ის ხედავს ტრანზაქციას. ამის საპირისპიროდ, ProjectVIEW ERP ტრანზაქციას კონტექსტში ხედავს.
ProjectVIEW ERP ეფუძნება BoQ ↔ WBS ↔ Cost Codes უნიკალურ კავშირს, რომელიც აერთიანებს პროექტის მოცულობას, გრაფიკსა და ხარჯს ერთ საოპერაციო ლოგიკაში. შედეგად, ეს საშუალებას იძლევა რეალურ დროში შედარდეს ფაქტობრივი და დაგეგმილი ხარჯი და პროგრესი დაინტერესებულ მხარეებს შორის.
რატომ არ არის RPA საკმარისი
რობოტიზებული პროცესების ავტომატიზაცია ძლიერია, როცა სწორად გამოიყენება. მაგალითად, მას შეუძლია შეამციროს ხელით შესრულებადი სამუშაო, ავტომატიზაცია გაუკეთოს განმეორებად მონაცემთა შეყვანას და ინფორმაცია ამოიღოს. მას ასევე შეუძლია მონაცემების სისტემებს შორის გადატანა და რუტინული ტრანზაქციების დაჩქარება.
მაგრამ RPA-ს სერიოზული შეზღუდვა აქვს: ის ავტომატიზაციას უკეთებს იმას, რაც უკვე არსებობს.
თუ არსებული პროცესი არ მუშაობს, RPA უბრალოდ ხარვეზიან პროცესს უფრო სწრაფს ხდის.
ეს სახიფათოა პროექტებზე დაფუძნებულ ოპერაციებში.
მაგალითად, დამტკიცების ავტომატიზაციამ ხარჯზე გავლენის გაუგებრობის შემთხვევაში შეიძლება გააჩქაროს გადახრები. ანალოგიურად, შესყიდვების ავტომატიზაციამ BoQ-სთან, WBS-თან და ბიუჯეტთან დაკავშირების გარეშე შეიძლება გააძლიეროს დანაკარგები. გარდა ამისა, ინვოისის გასუფთავების ავტომატიზაციამ მოედანზე პროგრესის ვალიდაციის გარეშე შეიძლება ფინანსური რისკი შექმნას. საბოლოოდ, ქვეკონტრაქტორთა სერტიფიცირების ავტომატიზაციამ ხარჯთა კოდის კონტროლის გარეშე შეიძლება დაამახინჯოს პროექტის მომგებიანობა.
მოკლედ, RPA არ არის ინტელექტი. RPA არის შესრულება.
ამიტომ, იმისთვის, რომ RPA-მ ღირებულება შექმნას, მან უნდა იმუშაოს სტრუქტურირებული, ინტეგრირებული და პროექტზე ორიენტირებული პროცესების საფუძვლის თავზე. სწორედ ასეთ საფუძველს უზრუნველყოფს ProjectVIEW ERP.
ProjectVIEW ERP მოიცავს სრულ ოპერაციულ ჯაჭვს. ეს მოიცავს შეფასებასა და ტენდერირებას, ბიუჯეტირებასა და ხარჯების კონტროლს, შესყიდვებს, ქვეკონტრაქტორებს, საწყობსა და მასალებს, ასევე HR-სა და სახელფასო განრიგს. იგი ასევე მოიცავს ტექნიკასა და მოვლა-პატრონობას, ბუღალტერიას, მოედნის პროგრესს, RFI-ებს, სერტიფიცირებებსა და პროექტის ანალიტიკას.
პროცესების რუკირება პროექტის ლოგიკის გარეშე მხოლოდ დეკორაციაა
ბევრი ორგანიზაცია ინვესტირებას ახდენს პროცესების რუკირების აქტივობებში. პირველ რიგში, კონსულტანტები ესაუბრებიან დეპარტამენტებს და აფიქსირებენ არსებულ სამუშაო პროცესებს. შემდეგ ისინი ქმნიან swimlane-ებს და ამზადებენ დიაგრამებს.
ერთი შეხედვით, შედეგი შთამბეჭდავად გამოიყურება.
მაგრამ რთული კითხვა ასეთია:
შეუძლია თუ არა რუკას ახსნას, სად იკარგება მოგება?
პრაქტიკაში, სტანდარტული პროცესების რუკების უმეტესობას ეს არ შეუძლია.
მათ შეუძლიათ აჩვენონ, რომ მოთხოვნა გადადის მოედნის ინჟინრიდან პროექტის მენეჯერთან, შემდეგ შესყიდვებში და ბოლოს ფინანსებში. მაგრამ ისინი, როგორც წესი, ვერ პასუხობენ კითხვას:
რატომ ითხოვა მოედანმა ეს მასალა ახლა? შედიოდა თუ არა ის ბიუჯეტში? უკავშირდება თუ არა სწორ BoQ პოზიციას? მოითხოვდა თუ არა ამას გრაფიკი? გუნდმა უკვე შეიძინა თუ არა იგი? მიმწოდებელმა ფასი განაახლა თუ არა? იყო თუ არა ხარჯის ფორმულა რეალისტური? მოედანმა მოიხმარა მეტი სამუშაო ძალა ან ტექნიკა, ვიდრე დაგეგმილი იყო? საბოლოოდ, ეს არის შესყიდვის საკითხი, დაგეგმვის საკითხი, პროდუქტიულობის საკითხი თუ კონტრაქტის ცვლილება?
მოკლედ, ეს არის განსხვავება სამუშაო პროცესის რუკირებასა და ოპერაციულ ინტელექტს შორის.
ProjectVIEW ERP მხოლოდ სამუშაო პროცესებს არ რუკავს. პირიქით, ის თავად სამუშაო პროცესში აერთიანებს პროექტის კომერციულ, ოპერაციულ და ფინანსურ სტრუქტურას.
მისი ტრენინგისა და პროცესის სტრუქტურა ამას მკაფიოდ აჩვენებს. პირველ რიგში, შესყიდვები იწყება მოედნის/მასალის მოთხოვნებიდან და უკავშირდება მოთხოვნებს, RFQ-ებს, მიმწოდებლის შეთავაზებებს, შედარებებს, შეკვეთებსა და ხარჯების კონტროლს. მეორე მხრივ, ბიუჯეტირება აკავშირებს BoQ ბიუჯეტებს, ხარჯთა კოდებს, Primavera-ს კავშირებს, ყოველდღიურ ტრანზაქციებს, პროექტის პროგრესს, სამუშაო ძალასა და ტექნიკას. საბოლოოდ, კლიენტის კონტრაქტები აკავშირებს ბიუჯეტს, მოედნის ტრანზაქციებს, RFI-ებს, სერტიფიკატებსა და ფასის განახლებებს.
რატომ ვერ ამჩნევენ სტანდარტული პლატფორმები რეალურ ჩახერგვას
ჩახერგვის წერტილი პროექტზე დაფუძნებულ კომპანიაში იშვიათად არის ერთი დაგვიანებული დამტკიცება.
მაგალითად, ეს შეიძლება შესყიდვის დაგვიანებად ჩანდეს, მაგრამ ფესვური მიზეზი შესაძლოა იყოს არასწორი შეფასება. ანალოგიურად, ქვეკონტრაქტორის დაგვიანება შეიძლება დიზაინის დოკუმენტაციის არქონიდან მომდინარეობდეს. ხარჯების გადაჭარბება, თავის მხრივ, შესაძლოა არარეალისტური პროდუქტიულობის დაშვებებისგან იყოს. საბოლოოდ, თითქოს მოედანზე არსებული პრობლემა შეიძლება რეალურად გვიან RFQ-ს, არასწორ მასალის კოდირებას ან არაზუსტ რაოდენობრივ გამოთვლას უკავშირდებოდეს.
სტანდარტული პლატფორმები ბოთლნეკებს, როგორც წესი, დროის მიხედვით ასახელებენ: „ამოცანა X-ს 12 დღე დასჭირდა 3-ის ნაცვლად“.
ეს სასარგებლოა, მაგრამ საკმარისი არ არის.
ამის საპირისპიროდ, პროექტებზე დაფუძნებულ კომპანიებს სჭირდებათ ბოთლნეკების იდენტიფიცირება დროის, ხარჯის, რესურსების, მოცულობის, პასუხისმგებლობისა და კონტრაქტუალური ზემოქმედების მიხედვით.
ProjectVIEW ERP ამას უზრუნველყოფს, რადგან აკავშირებს ოპერაციულ პროცესს პროექტის ხარჯისა და გრაფიკის საბაზისო ხაზთან. ის ასევე ადარებს დაგეგმილ და ფაქტობრივ შესრულებას და აერთებს მოედნის მონაცემებს ოფისის კონტროლთან. გარდა ამისა, DANAOS სისტემას სამშენებლო-სპეციფიკურ კომპლექტად წარმოაჩენს. ის ეხება ტენდერირებას, დაგეგმვას, დიზაინს, შესყიდვებს, ტექნიკას, ფაბრიკაციას, მოედნის სამუშაო ძალასა და პროექტის შესრულებას. ამავდროულად, ის ინტეგრირდება Primavera-სა და BIM-თან ხარჯის, დროისა და რესურსების 5D ხედვისთვის.
სწორედ ამიტომ ProjectVIEW ERP-ს შეუძლია რეალური ჩახერგვის წერტილის გამოვლენა და არა მხოლოდ ხილული დაგვიანების.
„Low-code“ პროცესული პლატფორმების ფარული სისუსტე
Low-code და no-code პლატფორმები მოქნილობას გვპირდებიან. მაგალითად, ისინი კომპანიებს საშუალებას აძლევს სწრაფად შექმნან სამუშაო პროცესები.
მაგრამ ინდუსტრიული ლოგიკის გარეშე მოქნილობა სხვა პრობლემას ქმნის: თითოეული დეპარტამენტი რეალობის საკუთარ ვერსიას ქმნის.
შესყიდვები ქმნის ერთ ნაკადს. ამავდროულად, ხარჯების კონტროლი ქმნის მეორეს, დაგეგმვა კი მესამეს. მოედნის გუნდები, თავის მხრივ, იყენებენ ცხრილებს. ფინანსები შემდეგ ითხოვს შეჯერებებს. საბოლოოდ, მენეჯმენტი იღებს დაგვიანებულ ანგარიშებს.
შედეგად, ეს არ არის ციფრული ტრანსფორმაცია.
პირიქით, ეს არის ციფრული ფრაგმენტაცია.
პროექტებზე დაფუძნებული კომპანიებისთვის საკითხი მხოლოდ სამუშაო პროცესების ავტომატიზაცია არ არის. უფრო სწორად, საკითხია პროცესების სტანდარტიზაცია ყველა პროექტში, დეპარტამენტში, მომხმარებელთან და რეგიონში.
DANAOS-მა ProjectVIEW ERP შექმნა როგორც ერთიანი ინტეგრირებული სისტემა და არა გათიშული აპლიკაციების ნაკრები. მისი არქიტექტურა ცენტრალიზებულად აერთიანებს წვდომის კონტროლს, სამუშაო პროცესებს, ინფორმაციის გაზიარებას, ბიზნეს ერთეულებს შორის ციფრულ ინტეგრაციას, ანგარიშგებას, მორგებულ ანგარიშგებასა და მომხმარებლის დეტალურ აქტივობის ლოგირებას.
ეს მნიშვნელოვანია, რადგან მდგრადობა სტანდარტიზაციიდან მოდის.
როცა ყველა პროექტი ერთსა და იმავე ოპერაციულ ლოგიკას მიჰყვება, მენეჯმენტს შეუძლია შედარება, კონტროლი, პროგნოზირება და ჩარევა.
ProjectVIEW ERP, როგორც ბიზნეს პროცესების მართვის ძრავა
ProjectVIEW ERP ბიზნეს პროცესების მართვას პროექტებზე დაფუძნებული შესრულების რეალურ სამყაროში შემოაქვს.
სტანდარტული ინსტრუმენტებისგან განსხვავებით, ის არ იწყებს ცარიელი workflow დიზაინერიდან.
პირიქით, ის იწყებს პროექტის ლოგიკიდან:
Scope: რა უნდა მივაწოდოთ? BoQ: რას ვაფასებთ და ვზომავთ? WBS: როდის უნდა მოხდეს ეს? Cost Codes: სად ვაფიქსირებთ ხარჯს? Resources: რა სამუშაო ძალა, ტექნიკა, მასალები, ქვეკონტრაქტორები და არაპირდაპირი ხარჯები სჭირდება სამუშაოს? Procurement: რა უნდა მოვიპოვოთ, როდის და ვისგან? Execution: რა ხდება რეალურად მოედანზე ან ეზოში? Certification: რა შეგვიძლია დავარიცხოთ ან გადავიხადოთ? Control: ვართ თუ არა დროის, ხარჯის, პროდუქტიულობისა და შესაბამისობის ფარგლებში?
მოკლედ, ეს არის ბიზნეს პროცესების მართვა ოპერაციული მეხსიერებით.
ეს მხოლოდ სქემა არ არის. ეს საწარმოს ოპერაციული მოდელია.
გარდა ამისა, ProjectVIEW ERP-ის საკუთარი პროცესული დაფარვა მოიცავს პროექტების მართვას, შესყიდვებს, მასალების მართვას და საწყობის მართვას. ის ასევე მოიცავს მანქანა-დანადგარების გამოყენებას, შრომის პროდუქტიულობას, სამშენებლო მოედნის პროდუქტიულობას, მწვანე ოპერაციებს და ქარხნულ მოვლა-შენახვას. ერთად ეს აჩვენებს ფართო ოპერაციულ კვეთას პროექტებზე დაფუძნებულ ინდუსტრიებში.
პროცესების რაინჟინერია ინდუსტრიის სპეციფიკური უნდა იყოს
კომპანიებს მშენებლობაში, გემთმშენებლობაში, ოფშორულ სექტორში, სამთო საქმეში და EPC-ში არ შეუძლიათ პროცესების რაინჟინერიის ბანკინგიდან, რითეილიდან ან ზოგადი წარმოებიდან გადმოღება.
ბოლოს და ბოლოს, პროცესის ლოგიკა განსხვავებულია.
პროექტებზე დაფუძნებულ კომპანიაში ორგანიზაცია მუდმივად თავიდან აწყობს საკუთარ თავს დროებით საწარმოო სისტემებზე დაყრდნობით. ეს მოიცავს პროექტებს, მოედნებს, ეზოებს, პაკეტებს, ქვეკონტრაქტორებს, ლოკაციებს, ბრიგადებს, აღჭურვილობას, კლიენტის მოთხოვნებს, კონსულტანტებს და მარეგულირებლებს.
შედეგად, ეს ქმნის ისეთ სირთულეს, რომელსაც ზოგადი სისტემები სათანადოდ ვერ აფასებენ.
ProjectVIEW ERP შექმნეს მშენებლობისა და პროგრამული უზრუნველყოფის პროფესიონალებმა. შედეგად, პროგრამა ესმის ტენდერირება, დაგეგმვა, დიზაინი, მასალების შესყიდვა, მანქანა-დანადგარების მონიტორინგი, მოედნის სამუშაო ძალის მართვა და პროექტის შესრულება. ის ასევე „ლაპარაკობს“ დაინტერესებული მხარეების ენაზე როგორც მოედანზე, ისე ოფისში.
ზუსტად ეს არის არსი.
პროცესების რაინჟინერია ვერ იქნება ეფექტური, თუ სისტემა არ ესმის ინდუსტრიის ენა.
სხვა შემთხვევაში კომპანიები თავიანთ ბიზნესს აყალიბებენ ისე, რომ მოერგოს ზოგად პლატფორმას, ნაცვლად იმისა, რომ პლატფორმა დააკონფიგურირონ უკეთესი ბიზნეს-შედეგების მხარდასაჭერად.
ავტომატიზაციიდან ოპერაციულ მდგრადობამდე
ეფექტური ოპერაციები მხოლოდ სწრაფი არ არის. ისინი კონტროლირებადიც არის.
ანალოგიურად, ეფექტური ოპერაციები მხოლოდ ციფრული არ არის. ისინი გაზომვადიც არის.
და ბოლოს, მდგრადი ოპერაციები მხოლოდ დაკავშირებული არ არის. მათ ასევე შეუძლიათ ცვლილების შთანთქმა კონტროლის დაკარგვის გარეშე.
ProjectVIEW ERP ადგენს სტანდარტს, რადგან ქმნის საოპერაციო გარემოს, სადაც ყოველი პროცესი პროექტის რეალობას უკავშირდება. როდესაც ტრანზაქცია ხდება, ის არ დგას ცალკე. ამის ნაცვლად, სისტემა აფასებს მას ბიუჯეტთან, დროსთან, რესურსებთან, სამუშაო ნაკადთან, დამტკიცებებთან, დოკუმენტაციასთან და ხარჯობრივ გავლენასთან მიმართებით.
ამ გზით კომპანიები რეაქტიული მართვიდან სიტუაციურ ცნობიერებამდე გადადიან.
მაგალითად, ProjectVIEW ERP მომხმარებლებს საჭირო მოქმედებებზე წინასწარ აფრთხილებს დაფების, გაფრთხილებებისა და შეტყობინებების საშუალებით. ის ასევე მხარს უჭერს ანგარიშგებას, ანალიტიკას, KPI-ებს, შესრულების მონიტორინგსა და პროცესების ოპტიმიზაციას.
აი, აქ იწყება მდგრადობა: არა მას შემდეგ, რაც პრობლემა ხილული ხდება, არამედ მანამდე, სანამ ის ძვირი გახდება.
რატომ ადგენს სტანდარტს ProjectVIEW ERP
ProjectVIEW ERP ადგენს სტანდარტს Business Process Management-ის, RPA მზადყოფნისა და პროცესების რაინჟინერიისთვის რთულ, პროექტებზე დაფუძნებულ კომპანიებში, რადგან ის აერთიანებს ხუთ კრიტიკულ ელემენტს:
1. ინდუსტრიისთვის სპეციფიკური ბიზნესლოგიკა ის ბუნებრივად ესმის პროექტებზე დაფუძნებული ოპერაციები, მათ შორის BoQ, WBS, ხარჯთა კოდები, რესურსები, შესყიდვები, ქვეკონტრაქტორები, პროგრესი, სერტიფიკატები და მოედან-ოფისის თანამშრომლობა.
2. ინტეგრირებული ოპერაციული არქიტექტურა ის აერთებს დეპარტამენტებს, რომლებსაც ზოგადი ხელსაწყოები ხშირად აცალკევებენ: შეფასება, დაგეგმვა, შესყიდვები, მოედანზე შესრულება, კონტრაქტები, ფინანსები, HR, ტექნიკა, საწყობი და მენეჯმენტი.
3. ხარჯისა და დროის ცნობიერება სისტემა ყოველ პროცესს პროექტის საბაზისოსთან მიმართებით აფასებს, რაც საშუალებას იძლევა რეალურ დროში გაკონტროლდეს დაგეგმილ და ფაქტობრივ შესრულებას შორის სხვაობა.
4. სამუშაო ნაკადის დისციპლინა კონტროლირებადი მოქნილობით დინამიკური დამტკიცებები გუნდებს საშუალებას აძლევს სწრაფად უპასუხონ, აუდიტირებადობის, ანგარიშვალდებულებისა და შესაბამისობის დაკარგვის გარეშე.
5. ჭეშმარიტების ერთიანი წყარო ProjectVIEW ERP აერთიანებს პროექტის ცოდნას, რაც პროცესების ავტომატიზაციას, ანალიტიკასა და AI-ს უფრო სანდოს ხდის, რადგან მონაცემები სტრუქტურირებული, კონტექსტური და ოპერაციულად მნიშვნელოვნია.
ვერ დაავტომატიზებ იმას, რასაც არ ესმის
ზოგადი BPM და RPA პლატფორმები სასარგებლო ინსტრუმენტებია. მაგრამ რთულ, პროექტებზე დაფუძნებულ კომპანიებში ისინი საკმარისი არ არის.
მათ შეუძლიათ ამოცანების გადაადგილება და დაწკაპუნებების ავტომატიზაცია. გარდა ამისა, შეუძლიათ სამუშაო ნაკადების გაწერა და დამტკიცებების დაჩქარება.
მაგრამ მათ არ შეუძლიათ გაიგონ ღრმა კავშირი მასშტაბს, დროს, ხარჯს, რესურსებს, კონტრაქტებს, შესყიდვებს, პროდუქტიულობასა და რისკს შორის.
ProjectVIEW ERP-ს შეუძლია.
ამიტომ ProjectVIEW ERP მხოლოდ პროცესების მართვის პროგრამა არ არის. ის არის პროექტებზე დაფუძნებული ოპერაციული სისტემა ეფექტური, შედეგიანი და მდგრადი ოპერაციებისთვის.
საბოლოო ჯამში, მილიარდდოლარიან პროექტებს რომ მართავენ, მომავალს ვერ მოიგებენ ისინი, ვინც ყველაზე მეტს ავტომატიზაციას გაუკეთებს.
მომავალი ეკუთვნის მათ, ვინც თავის ოპერაციებს ყველაზე კარგად ესმის — და აკონტროლებს მათ მანამ, სანამ ისინი გეზს დაკარგავენ.
