რატომ განსაზღვრავს თქვენი ERP სისტემის წარმოშობა იმას, ნამდვილად მოემსახურება თუ არა ის თქვენს ინდუსტრიას, თუ თავის შეზღუდვებთან შეგუებას გაიძულებთ.
ყოველი საწარმოთა პროგრამული სისტემა მის წარმომავლობაში ჩადებულ გენეტიკურ კოდს ატარებს. როგორც არქიტექტურული საფუძვლები განსაზღვრავს, რა შეიძლება აშენდეს მათ ზემოთ, ERP სისტემის თავდაპირველი დანიშნულება აყალიბებს მის ლოგიკას, ძლიერ მხარეებს და საბოლოოდ, იმ ინდუსტრიებს, რომელთაც ის რეალურად ემსახურება.
მშენებლობასა და პროექტებზე დაფუძნებულ ინდუსტრიებში ეს მემკვიდრეობის საკითხი აკადემიური არ არის — ოპერაციულია. როდესაც სისტემა შეიქმნა საცალო ტრანზაქციების ან HR სამუშაო პროცესების სამართავად, ვერც ერთი „ინდუსტრიული მოდული“ ვერ გადააწყობს მის ძირითად დაშვებებს იმის შესახებ, თუ როგორ სრულდება სამუშაო.
მოვსინჯოთ მსხვილი ERP მოთამაშეების გენეალოგია და ვნახოთ, რას ამჟღავნებს მათი DNA მათი ნამდვილი შესაძლებლობების შესახებ.
Oracle: მონაცემთა იმპერია გაფართოებას შეძენით ახორციელებს
Oracle-ის ისტორია იწყება არა ბიზნესპროცესებით, არამედ მონაცემთა ინფრასტრუქტურით. დაარსდა 1977 წელს, Oracle-მ თავისი იმპერია რელაციურ მონაცემთა ბაზის ტექნოლოგიაზე ააგო — საწარმოთა აპლიკაციების ქვეშ არსებული ინფრასტრუქტურა და არა თავად აპლიკაციები.
როცა Oracle-მა ERP სივრცეში შემოსვლა დაიწყო, ეს გააკეთა შეძენის გზით და არა ორგანული განვითარებით. PeopleSoft-ის შეძენამ 2005 წელს (რომელმაც თავად შეიძინა J.D. Edwards), შემდეგ კი Siebel Systems-მა, Oracle-ის ეკოსისტემაში აპლიკაციების გამოცდილება შემოიტანა. Oracle Fusion Cloud, რომელიც კომპანიის ერთიან cloud ERP პლატფორმად გაეშვა, წარმოადგენს ამ განსხვავებული შენაძენების ერთიან, თანმიმდევრულ სისტემად შერწყმის მცდელობას.
რას აჩვენებს მემკვიდრეობა: Oracle-ის DNA ინფრასტრუქტურაზეა ორიენტირებული და შემდეგ მოდის აპლიკაციები. მისი ძლიერი მხარეა მონაცემთა უზარმაზარი მოცულობებისა და რთული საწარმოო არქიტექტურების მართვა. ისეთი ინდუსტრიებისთვის, რომლებსაც სჭირდებათ ღრმა, სპეციალიზებული ოპერაციული ლოგიკა განსაკუთრებით მათთვის, ვისაც აქვს ფიზიკური წარმოების სამუშაო ნაკადები Oracle Fusion-ს ხშირად სჭირდება ფართო პერსონალიზაცია, რათა შეივსოს უფსკრული ზოგად საწარმოო პროცესებსა და ინდუსტრიისთვის სპეციფიკურ რეალობას შორის.
SAP: სააღრიცხვო წიგნებიდან საწარმოთა ამბიციამდე
SAP-ის ისტორია 1972 წელს იწყება მანჰაიმში, გერმანიაში, ხუთი ყოფილი IBM ინჟინრისგან. თავად სახელწოდება — Systems, Applications, and Products in Data Processing — ცხადყოფს დამფუძნებელ ხედვას: ფინანსური ბუღალტერიისა და ხელფასების პროცესების ავტომატიზაციას.
SAP R/1, R/2 და საბოლოოდ R/3 განვითარდა სწორედ ამ სააღრიცხვო ფესვებიდან და თანდათან გაფართოვდა შესყიდვების, წარმოებისა და ადამიანური რესურსების მიმართულებით. კომპანიის ზრდა ლოგიკურ გზას მიჰყვა: ფინანსური ჩანაწერების წარმოებიდან იმ ტრანზაქციებამდე, რომლებიც ამ ჩანაწერებს ქმნის.
რას ავლენს მემკვიდრეობა: SAP-ის ძირითადი ლოგიკა ფუნდამენტურად რჩება ტრანზაქციულად და ფინანსებზე ორიენტირებულად. სისტემა განსაკუთრებით ძლიერია ფულადი ნაკადების თვალთვალსა და საბუღალტრო შესაბამისობის უზრუნველყოფაში. თუმცა, იმ დარგებში, სადაც ოპერაციული სირთულე წინ უსწრებს ფინანსურ სირთულეს, სადაც ხარჯის დადგენამდე ჯერ უნდა გაიგოთ როგორ სრულდება სამუშაო, SAP ხშირად მოითხოვს, რომ ფიზიკური სამყარო მოერგოს მის ფინანსურ აბსტრაქციებს და არა პირიქით.
Salesforce: CRM გიგანტი, რომელიც ოპერაციებში უკან იხედება
Salesforce-მა საწარმოთა პროგრამული უზრუნველყოფა რევოლუციურად შეცვალა არა ფუნქციონალით, არამედ მიწოდების მოდელით. დაარსდა 1999 წელს „No Software“ სლოგანით, Salesforce-მა cloud-ზე დაფუძნებული CRM დააარსა — მომხმარებელთან ურთიერთობის, გაყიდვების მილსადენებისა და მარკეტინგული ავტომატიზაციის მართვა.
მისი გაფართოება უფრო ფართო საწარმოთა სივრცეში სტრატეგიული შესყიდვებით მოხდა: MuleSoft ინტეგრაციისთვის, Tableau ანალიტიკისთვის, Slack თანამშრომლობისთვის. კომპანია სულ უფრო მეტად პოზიციონირდება, როგორც საწარმოთა პლატფორმა, თუმცა მისი ბირთვი კვლავ მყარად არის დამაგრებული მომხმარებელთან ურთიერთობის პროცესებზე.
რას აჩვენებს მემკვიდრეობა: Salesforce ფიქრობს წინიდან უკან: მომხმარებელთან ურთიერთობიდან შესრულებამდე. იმ ინდუსტრიებისთვის, სადაც სირთულე მდგომარეობს მიწოდებაში და არა გაყიდვაში, სადაც პროექტის მოგება მხოლოდ მრავალწლიანი ოპერაციული გამოწვევის დასაწყისია, Salesforce გთავაზობთ შესანიშნავ pipeline-ის მართვას, მაგრამ შეზღუდულ ბუნებრივ გაგებას ოპერაციული შესრულების შესახებ.
Workday: HR და ფინანსები, შექმნილი სერვისის ეკონომიკისთვის
Workday გაჩნდა 2005 წელს PeopleSoft-ის შემქმნელებისგან და სპეციალურად შეიქმნა ადამიანური კაპიტალის მართვისა და ფინანსური დაგეგმვისთვის. მოძველებული ERP მომწოდებლებისგან განსხვავებით, რომლებიც ასაკოვანი არქიტექტურების cloud-ზე გადაყვანას ცდილობდნენ, Workday თავიდანვე cloud-native იყო.
მისი ძლიერი მხარეა სამუშაო ძალის დინამიკის მართვა: დაქირავება, ანაზღაურება, ორგანიზაციული დიზაინი და ადამიანებზე ორიენტირებული ბიზნესების გარშემო არსებული ფინანსური დაგეგმვა. სისტემა შექმნილია იმ საწარმოებისთვის, სადაც ადამიანური კაპიტალი არის მთავარი საწარმოო რესურსი.
რას ავლენს მემკვიდრეობა: Workday გამორჩეულად ძლიერია იმ დარგებში, სადაც ადამიანები და მათთან დაკავშირებული ხარჯები წარმოადგენს ძირითად ოპერაციულ საკითხს. აქტივებზე ინტენსიური, პროექტზე დაფუძნებული დარგებისთვის, სადაც ტექნიკა, მასალები, ქვეკონტრაქტორები და რთული წარმოების გრაფიკები ისეთივე მნიშვნელოვანია, როგორც შიდა პერსონალი, Workday-ის ადამიანურ კაპიტალზე ორიენტირებული არქიტექტურა მხოლოდ ნაწილობრივ ხედვას იძლევა ოპერაციულ რეალობაზე.
Infor: შენაძენების აგრეგატორი, რომელიც ინდუსტრიულ ფოკუსს ეძებს
Infor, ალბათ, წარმოადგენს საწარმოთა პროგრამულ უზრუნველყოფაში ყველაზე აგრესიულ კონსოლიდაციის სტრატეგიას. კომპანია 2002 წელს SSA Global-ისა და Infor Global Solutions-ის შერწყმით შეიქმნა და ათობით სპეციალიზებული აპლიკაცია შეისრუტა: Lawson (ჯანდაცვა, მოდა), MAPICS (წარმოება), SyteLine და მრავალი სხვა.
2020 წლიდან Koch Industries-ის მფლობელობაში ყოფნის შემდეგ, Infor-მა გააძლიერა ინდუსტრიულად სპეციფიკური „CloudSuites“, ცდილობს შეძენილი პორტფელის თანმიმდევრულ ვერტიკალურ გადაწყვეტილებებად გარდაქმნას.
რას ავლენს მემკვიდრეობა: Infor-ის ძლიერი მხარე მისი შეძენილი პროდუქტების სპეციალიზებულ შესაძლებლობებშია. მისი გამოწვევა ინტეგრაციაში მდგომარეობს, განსხვავებული არქიტექტურების, მონაცემთა მოდელებისა და ოპერაციული ფილოსოფიების მქონე განსხვავებული სისტემების ერთმანეთთან დაკავშირებაში. ორგანიზაციებისთვის, რომლებსაც სჭირდებათ უწყვეტი ნაკადი პროექტის სასიცოცხლო ციკლის ფაზებს შორის, შეძენილ პროდუქტებს შორის არსებული ნაკერები შეიძლება გადაიქცეს ოპერაციული ხახუნის წერტილებად.
IFS: აქტივების მართვიდან საწარმოთა მასშტაბამდე
IFS (Industrial and Financial Systems) 1983 წელს, შვედეთის ლინჩიოპინგში დაიწყო, და მისი ფოკუსი იყო კომპონენტებზე დაფუძნებული ERP პროექტებზე ორიენტირებული და აქტივებზე ინტენსიური ინდუსტრიებისთვის. მისი ისტორიული ძლიერი მხარეა აერონავტიკა და თავდაცვა, რთული წარმოება და აქტივის სიცოცხლის ციკლის მართვა.
კომპანია გაიზარდა მიზნობრივი შენაძენებით, მათ შორის Astea International-ით (საველე სერვისის მართვა), და პოზიციონირდება როგორც ERP სასურველი არჩევანი იმ ორგანიზაციებისთვის, რომლებიც რთულ, ხანგრძლივ სიცოცხლის მქონე აქტივებს მართავენ.
რას ავლენს მემკვიდრეობა: IFS ნამდვილად კარგად ესმის პროექტების სირთულე და აქტივებზე ინტენსიური ოპერაციები. მისი არქიტექტურა შეიქმნა იმ დარგებისთვის, სადაც მნიშვნელოვანია ტექნიკური მომსახურება, სერვისი და აქტივის გრძელვადიანი წარმადობა. თუმცა, მისი მემკვიდრეობა წარმოებისა და აქტივების ტექნიკური მომსახურების მიმართულებიდან განსხვავდება იმ დარგებისგან, რომლებიც ფოკუსირებულია აქტივების შექმნაზე, სადაც მთავარი გამოწვევაა რთული პროექტების კონცეფციიდან მშენებლობამდე და ჩაბარებამდე მიყვანა.
Sage: მცირე და საშუალო ბიზნესის სააღრიცხვო პლატფორმა, რომელიც ზემოთ იწევს
Sage 1981 წელს, ნიუკასლში, დიდ ბრიტანეთში დაიწყო და მცირე ბიზნესისთვის სააღრიცხვო პროგრამას აწვდიდა. მისი ზრდა კლასიკურ სქემას მიჰყვა: საბაზო ბუღალტერიიდან უფრო ფართო ბიზნეს მენეჯმენტამდე, ძირითადად მცირე და საშუალო საწარმოების მომსახურებით.
Sage Intacct-ის მსგავსმა პროდუქტებმა (შეძენილი 2017 წელს) კომპანია უფრო დიდ ბაზრის სეგმენტებში შეიყვანა, თუმცა მისი ძირითადი კლიენტური ბაზა კვლავ მცირე ორგანიზაციებია, რომლებსაც ხელმისაწვდომი ფინანსური მართვა სჭირდებათ.
რას ავლენს მემკვიდრეობა: Sage-ის დნმ არის ხელმისაწვდომობა და საბუღალტრო სიმარტივე. ის ემსახურება ორგანიზაციებს, რომლებსაც ფინანსების მართვა სჭირდებათ საწარმოს მასშტაბის სირთულის გარეშე. დარგებისთვის, რომლებიც საჭიროებენ ოპერაციულ სიღრმეს, დეტალურ პროექტულ კონტროლს, რესურსების რთულ დაგეგმვას და ინტეგრირებულ ხარჯთინჟინერიას, Sage-ის მსუბუქ არქიტექტურას, როგორც წესი, სჭირდება სპეციალიზებული წერტილოვანი გადაწყვეტილებებით შევსება.
ProjectVIEW ERP: დაბადებული სამშენებლო ობიექტზე
შემდეგ კი არსებობს განსხვავებული ისტორია — ისტორია, რომელიც იწყება არა მონაცემთა ბაზის ლაბორატორიებში ან ბუღალტრულ დეპარტამენტებში, არამედ აქტიურ სამშენებლო ობიექტებზე, სადაც ბეტონი ისხმება, ფოლადი ეწყობა და ასობით მილიონიანი პროექტები ნახაზიდან რეალობად იქცევა.
ProjectVIEW ERP წარმოიშვა DANAOS Projects-ის ოთხი ათწლეულის პირდაპირი გამოცდილებიდან მშენებლობის, საზღვაო, გემთმშენებლობისა და ინფრასტრუქტურის ინდუსტრიებში. მისი ფუძემდებლური ლოგიკა სხვა ინდუსტრიიდან არ ყოფილა ადაპტირებული ის ამოღებულ იქნა პროექტზე დაფუძნებული წარმოების ოპერაციული რეალობიდან.
სისტემის არქიტექტურა ამ მემკვიდრეობას ფუნდამენტურად ასახავს:
სამსვეტიანი ბირთვი: მაშინ როცა სხვა სისტემები იწყებენ ფინანსური ტრანზაქციებიდან და უკან მუშაობენ, ProjectVIEW იწყება Bill of Quantities-ით იმ ფიზიკური მოცულობით, რაც უნდა აშენდეს. BoQ ორმხრივად უკავშირდება Work Breakdown Structure-ს როგორაა ორგანიზებული სამუშაო და Cost Codes-ს როგორ კატეგორიზდება რესურსები, რითაც ქმნის სამკუთხედად კონტროლის სისტემას, რომელიც ასახავს იმას, თუ როგორ მუშაობს მშენებლობა რეალურად.
წარმოების პირველადი ლოგიკა: რესურსების დაგეგმვა, ტექნიკის განაწილება და ქვეკონტრაქტორების მართვა ფინანსურ სისტემაზე მიბმული შემდგომი დამატებები არ არის, ისინი ძირითადი არქიტექტურული ელემენტებია. სისტემა აცნობიერებს, რომ მშენებლობაში ფიზიკური წარმოება უნდა დაგეგმოთ მანამდე, სანამ ფინანსურ შედეგს ზუსტად იწინასწარმეტყველებთ.
პრეტენზიებისა და ცვლილებების მართვა: დაიბადა დარგში, სადაც სახელშეკრულებო სირთულე ნორმაა, ProjectVIEW პრეტენზიებს, ვარიაციებს და კონტრაქტის კორექტირებებს განიხილავს როგორც პირველხარისხოვან ოპერაციულ ელემენტებს და არა გამონაკლისებს, რომლებიც შემოვლით გადაწყვეტებს საჭიროებს.
რას ავლენს მემკვიდრეობა: ProjectVIEW შეიქმნა იმ დარგებისთვის, სადაც ძირითადი სირთულე ოპერაციულია, სადაც წარმატება ათასობით აქტივობის კოორდინაციაზე, ცვალებადი მასალების ნაკადების მართვასა და გაჭიანურებულ პროექტის ვადებზე კონტროლის შენარჩუნებაზეა დამოკიდებული. მისი ფინანსური შესაძლებლობები ემსახურება მის ოპერაციულ ბირთვს და არა პირიქით.
მემკვიდრეობის ტესტი: სამი კითხვა ERP-ის შერჩევისთვის
როცა პროექტებზე დაფუძნებული ინდუსტრიებისთვის რომელიმე ERP სისტემას აფასებთ, მემკვიდრეობის კითხვა შეიძლება სამ დიაგნოსტიკურ შეკითხვამდე დავიყვანოთ:
1. სად იწყება სისტემის ლოგიკა? იწყება ის ფინანსური ტრანზაქციებით და შემდეგ უკან, ოპერაციებამდე მიდის? თუ იწყება ოპერაციული მასშტაბით და მისგან წარმოქმნის ფინანსურ შედეგებს? მშენებლობისა და პროექტზე დაფუძნებული დარგებისთვის მეორე მიდგომა შეესაბამება იმას, თუ როგორ მოძრაობს სამუშაო რეალურად.
2. რომელ დარგში შეიქმნა სისტემა თავდაპირველად? ყველა სისტემას თან ახლავს მისი შექმნის კონტექსტიდან გამომდინარე დაშვებები. საცალო ვაჭრობაში დაბადებული ERP ინვენტარს სხვაგვარად ესმის, ვიდრე სამშენებლო მოედანზე დაბადებული სისტემა. HR-ში დაბადებული ERP „რესურსებზე“ როგორც თანამშრომლებზე ფიქრობს, ხოლო სამშენებლო სფეროში დაბადებული სისტემა რესურსებს აღიქვამს როგორც შრომის, ტექნიკის, მასალებისა და ქვეკონტრაქტორების ინტეგრირებულ ერთობლიობას.
3. როგორ გაფართოვდა სისტემა? ახალ შესაძლებლობებზე ორგანული გაფართოება არქიტექტურულ თანმიმდევრულობაზე მიუთითებს. შეძენების გზით ზრდამ შეიძლება სპეციალიზებული შესაძლებლობები შემოიტანოს, თუმცა ხშირად აჩენს ინტეგრაციის სირთულეს და ფილოსოფიურ არათანმიმდევრულობას.
აირჩიეთ პროგრამა, რომელიც თქვენი ინდუსტრიის ენაზე საუბრობს
ERP ლანდშაფტი სავსეა ძლიერი, უნარიანი სისტემებით — თითოეული ნამდვილად შესანიშნავია იმ ინდუსტრიებისთვის, რომელთაც ემსახურებოდა. გამოწვევა არა „კარგი“ ERP-ის პოვნაა; გამოწვევა ისეთ სისტემის პოვნაა, რომლის ფუძემდებლური დაშვებები თქვენს ოპერაციულ რეალობას ემთხვევა.
მშენებლობის, ინფრასტრუქტურის, საზღვაო, გემთმშენებლობისა და სხვა პროექტზე დაფუძნებული ინდუსტრიების ორგანიზაციებისთვის ეს ნიშნავს ისეთი სისტემების ძიებას, სადაც ოპერაციული სირთულე პირველია — სადაც Bill of Quantities არ არის შემდგომი აზრი, სადაც წარმოების დაგეგმვა ფინანსურ პროგნოზს მართავს და სადაც პროექტზე დაფუძნებული მუშაობის ცვალებადობა არქიტექტურულად ბუნებრივია და არა უხალისოდ მოთმენილი.
ERP DNA მნიშვნელოვანია. აირჩიეთ სისტემა, რომლის მემკვიდრეობაც თქვენი ინდუსტრიის ენაზე საუბრობს.
